FUNCTIONAL SPECIFICATIONS

Version <current version>

BAC Page 1 of 11
 <SRS of sample case study>

Page 2 of 11
 <SRS of sample case study>

Revision History

Date Version Summary of Change Author

<dd/Mmm/ <x.y> <Section> - <Change> <First Name +
yyyy> Last Name>
12 Apr 2014 0.1 Initial version Thuy Tran
15 May 2014 0.2 Update upon review with internal team: Thuy Tran
Section 3 – Updated flow diagram #
Section 4 - Removed flow #
Section 1 – Add new rule XYZ
1 Jun 2014 0.3 Update upon review with customer: Thuy Tran
Section 2 – Change field label from A to B
Section 4 - Update flow # - step #

Distribution for Review/Approval

Name Title & Company Issue Issue Review Approval

Version Date Date Date
<First Name + <Title> - <Company> <x.y> <dd/ <dd/ <dd/
Last Name> Mmm/ Mmm/ Mmm/
yyyy> yyyy> yyyy>

Page 3 of 11
 <SRS of sample case study>

Contents
1 Introduction 3
1.1 Purpose 3
1.2 Scope 3
1.3 References 3
1.4 Terms and Abbreviations 3
2 Module Description 3
3 Flows 3
4 Data Model 3
5 Interfaces 3
6 Screen Flow 3
7 Screen Details 3
7.1 Screen <Screen ID – Name> 3
7.1.1 Layout 3
7.1.2 UI Elements 3

Page 4 of 11
 <SRS of sample case study>

1 Introduction

1.1 Purpose

<State the purposes of this this document>

For example:
1/ SRS is a formal requirement document: contract between Dev Team and Customer
2/ Who are readers: (BA needs to specify who will be readers and determine what sections in the document will be written in a
appropriate style and detail level)
- For Dev team (QC, Dev) 🡪 section a,b?
- Customer presentative (PO, QC, Technical Team, BA) 🡪 section m,n?
- Management Team (proposal) 🡪 section x,y?

1.2 Scope

<A brief description of what kinds of information will be included in this document: why this project, overall background of the business,
context diagram of the project, high level features (a.k.a. project scope), low level functional requirements, non-functional
requirements, etc.>
For example:
This document will cover the following details:
- Product Overview: why having this product, business background, interfaces with other systems
- High-level Reqs
- Low-level Reqs (function and non-funcitonal reqs)

1.3 References

Page 5 of 11
 <SRS of sample case study>

<Provide a complete list of all documents either

- Source of information of the information in this document
- Be referenced somewhere in this document to have further information.
Each document should be identified by ID, Name, Published Version (optional), Author, and Storage Location (optional)>

1.4 Terms and Abbreviations

<Include explanations of domain terminologies and abbreviations used in this document>

2 Product Overview

2.1 Product Perspective

<Include information
- for readers to understand why having this project,
- a diagram to express integrations among this product with other systems/applications>

2.2 Business Background

<Include as much as possible information to help readers understand about the business domain of this project, including but not
limited to
- Business workflows
- Business data models, Terminologies, Data workflows, or State transitions diagrams
- Characteristics or working environment description of end users
- Problems that end users face or want to make better>

3 Business Requirements
<Include original requirements provided by customer, end users. Can embed or link separate files here>

Page 6 of 11
 <SRS of sample case study>

4 High Level Requirements

<Include the feature list of the system that will be developed. Please pay attention to many aspects such as:
- Features to manage master data
- Features to execute business activities
- Features to address Problems of end users
- Features to focus Usability
- Features of Security (e.g. manage users or roles or permission, authentication, authorization, etc.)
- Features of integration with other systems (e.g. sync data, import, export, etc.)

5 Functional Requirements
<This section provides detail requirements for each item in High Level Requirements section in one of the following ways
- Use Case
- User Story
- Functional Spec
- ….>

<This assignment requests students to compose details requirements in style of Functional Specifications, so students need to think
about how many screens there should be and the flows among them based on the feature list in the previous section>

5.2 Screen Flow

<Draw a screen flow if the number of screens is big or there is a complex flow between screens.>

5.3 Screen ID – Screen Name

<Repeat this section for each screen>

5.3.1 Layout

Page 7 of 11
 <SRS of sample case study>

<Image of screen wireframe/mockup or screen snapshot>

5.3.2 UI Elements

Note: If there are any discrepancies between mockup and UI Elements table, follow the UI Elements table as the correct one.
Field Name Description Control Data Rules
Type Type
<Caption of <Include: <Put name <Put <Include:
the element of UI control name of
- Meaning of the field 1/ What is default value?
on the type. See data type
wireframe > - Where does the data of guidelines of the 2/ Is it required fields?
this field come from? below> field. See 3/ Select values or enable this field, what other functions
> guidelines or fields will be impacted?
below>
4/ List all Validation rules applied to the field. See
guidelines below
5/ List all Action rules applied to the field. See guidelines
below
>

<Guidelines for UI Elements table above:

Control Type:

Page 8 of 11
 <SRS of sample case study>

Use one of the following control type:

- Text field: single line
- Text area: multiple lines
- Drop down: cannot type in the text box
- Combo box: allow to type in the text box
- List box
- Date Time
- Date
- Time
- Button
- Radio button
- Check box
- Hyperlink’
- Label
Note: Grid control is not listed here because each Grid Column will be presented as a single Field Name.

Data Type:
Use one of the following data type:
- String (length)
- String
- Integer
- Decimal
- Date Time

Page 9 of 11
 <SRS of sample case study>

- Date
- Time
- Boolean
- Enum {v1, v2, v3}

Validation Rules:
Tell all rules to validate data when leaving fields, or before saving to database, normally including the following constraints:
- Wrong data type
- Wrong data range
- Wrong data format
- Required field
- Relation between two fields (ex: Value of field A < Value of field B)

Action Rules:
Tell rules that the system behaves when actor does actions on UI Elements, normally including the following actions:
- Loading form
- Leaving field
- Check/Uncheck field A, system does enable/disable field B
- Select a value of field A, system changes value(s) of field B
- Click action or Shortcut key (ex. button, hyperlink)
- Drag and Drop action (ex. list box)
- Double Click action (ex. grid row)
- Right Click action (ex. controls in Window-based)
>

6 Non-functional Requirements
<Include all non-functional requirements that are applied to this product, particularly:

Page 10 of 11
 <SRS of sample case study>

- System Requirements: what browsers, devices end users will use the product
- Performance: response time of the system
- Audit: what data will be tracked changes
- Volumetric Data: the capacity of data at present, data increase in future
- Migration: requirements to migrate old data to this system
- Industry Standards: industry standards that must apply to this product such as HL7 for US healthcare industry, etc.
>
6.2 System Requirements
<Describe requirements in details if applicable>
6.3 Performance
6.4 Audit
6.5 Volumetric Data
6.6 Migration
6.7 Industry Standards

Page 11 of 11