K2 COE – BUILD –

FUNCTIONAL
SPECIFICATION
6/1/2017
K2 CoE – Build – Functional Specification

INTRODUCTION
This document is designed to be a template to be completed for a client deliverable. Sections
included are indicative only, any real project may have more or less information required. The intent of
this document is to record the minimum amount of information to have a successfully implementation,
but certain areas are avoided as not all implementations require them.

Note: Where text is enclosed in squared brackets [] it is intended to be removed or replaced.

[The point of any application is to fulfil the business requirement. The goal of a functional specification
is to record that at a sufficient level of detail that when combined with a technical specification the
system in question can be developed.

Note: K2 Professional Services offer implementation skills or remote mentoring.]

WHAT IS THE APPLICATION?

[This is the purpose of the system. Not to be confused with the high-level requirements, the statement
here is the summary of what the system is. To contextualize it may be helpful to refer to an example:
an Expense Claim system would allow users to submit their expense claims, validate and approve
that information and subsequently pay the initiator.]

MINIMUM VIABLE PRODUCT

[Alternatively name Key Features. This is a list of the high level functional requirements for the
system. This would be the main list that would serve as the user acceptance testing (UAT) sign off.
They are often written as use cases:

 As an employee I need to be able to submit an expense claim.

 As a manager I need to be able to approve, decline, or request more information for an
expense claim.
 As an employee I need to be reimbursed for an expense claim.

Fundamentally, if the completed system can achieve these stated goals then this is a minimally viable
product which can be promoted to a production system.]

BUSINESS PROCESS
[All business processes require a high level diagram. Often there are a number of these diagrams at
varying levels of complexity. Higher level diagrams may drill into lower level diagrams. Additionally,
any shared processes would be documented here too. In the case of the Expense Claim System
example a single process governs the system:

© 2017 SOURCECODE TECHNOLOGY HOLDINGS, INC. 1

K2 CoE – Build – Functional Specification

Expense Claim
Phase
User

Submit Expense Resubmit Expense

Start Cancel End
Claim Claim
System

Send for
Validate Rules End
Payment
Management

Approve /
Review Expense
Decline / More End
Claim
Info

Note: Visio is used here but any tool (including K2 Workflow Designer) will suffice.]

WIREFRAMES
[Any user application requires a user interface. The tool of choice for K2 is K2 SmartForms, but
regardless of the underlying technology, wireframes need to be produced to give the business users
an understanding of what the final look and feel of the system will be. It also provides the developers
with a template to create the SmartForm against. Each screen needs to be rendered in this document.
As a rule of thumb a single workflow will have five (5) forms associated. Although SmartForm States
are often used to enable reuse of a given single form.

Note: administration screens for data take on – where required – would need to be needed included in
this section.

The forms required here are:

 Expense Claim submission

 Expense Claim review
 Expense Claim resubmission
 Expense Claim report
 Expense Claim approved

© 2017 SOURCECODE TECHNOLOGY HOLDINGS, INC. 2

K2 CoE – Build – Functional Specification

Note: Balsamiq is used here but any tool (including K2 SmartForms) will suffice.

Business rules need to be documented, like:

 If an expense type is ‘Hotel’ then the line item description must be completed with the hotel’s
name
 Airfares must be claimed in USD

Note: the details are what will make the application powerful, document what makes sense.

In addition, the wireframes create an implicit set of rules that need to be conformed to. These could
be documented for completeness, but in normal rapid application development cycles they are
generally left to the developer to intuit. Examples from the above wireframe:

 Amount * Quantity = Sub Total

 Sum (Sub Totals) = Total
 Etc.

There are many more implicit rules, but only document the obvious ones if the project rigor requires
it.]

SYSTEM OF RECORD
[Generally there are a number of systems involved in any K2 implementation. It is possible to have a
K2 implementation using only SmartBox as the data store, but this is rare. For any given integration a

© 2017 SOURCECODE TECHNOLOGY HOLDINGS, INC. 3

K2 CoE – Build – Functional Specification

number of items will need to be answered, but in terms of the functional specification what is
important is that the team knows which system to get what data from. Common systems are:

 Active Directory / Azure Active Directory - user properties and manager

 SQL Server – Line of Business Information
 SharePoint – Line of Business Information / Document management
 Etc.

Note: Generally it is better to find a system of record and integrate to that system rather than take the
data on in a new schema. This is project dependent.]

ADDITIONAL ITEMS
[There are a number of items that are not covered here as the above will work well for most systems.
Larger systems tend to have additional requirements and some of those are recorded here and could
become their own sections where required.

Item Reason

Navigation Users need a way to get to the various parts of the system. K2 has a
method via the work desk application and future versions will invest in
WorkSpace as a user’s landing page.

Personas Vitally important for enterprise systems these are the types of users
that your system will cater for. People in a finance role have different
dashboard requirements than people in an operations role.

Localizations / Are there particular requirements for localization and or languages?

Regionalization

Scope What’s in scope for version 1 versus out of scope and moved to the
backlog?

Nonfunctional Performance is usually top of mind here, but usability is often a key
requirements requirement. Taking a dependency on out of the box tooling only has
an impact here.

Note: the above is not an exhaustive list. Add, remove or expand upon as required.]

© 2017 SOURCECODE TECHNOLOGY HOLDINGS, INC. 4