[COMPANY lOGO]

[C LICK HERE AND TYPE P ROJECT N AME ]

SOFTWARE REQUIREMENT SPECIFICATION

Version <current version>

[COMPANY NAME] Page 1 of 11

 Software Requirement Specifications

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 2 of 11
 Software Requirement Specifications

Contents
1 Introduction......................................................................................................4
1.1 Purpose............................................................................................................4
1.2 Scope...............................................................................................................4
1.3 References.......................................................................................................4
1.4 Terms and Abbreviations.................................................................................4
2 Module Description..........................................................................................4
3 Flows................................................................................................................4
4 Data Model.......................................................................................................4
5 Interfaces.........................................................................................................4
6 Screen Flow.....................................................................................................5
7 Screen Details..................................................................................................5
7.1 Screen <Screen ID – Name>...........................................................................6
7.1.1 Layout..................................................................................................6
7.1.2 GUI Elements......................................................................................6
7.1.3 Validation Rules...................................................................................8
7.1.4 Control Action Rules............................................................................8
8 Non-Functional Requirement.........................................................................10
8.1 Performance Requirements...........................................................................10
8.2 Safety Requirements.....................................................................................10
8.3 Security Requirements...................................................................................10
8.4 Software Quality Attributes............................................................................10
8.5 <Other NFs>..................................................................................................10
9 Appendix........................................................................................................10
9.1 Appendix A: Glossary....................................................................................10
9.2 Appendix B: Analysis Models.........................................................................10
9.3 Appendix C: Autorespone (Notification/Email)...............................................11
9.4 Appendix C: Issues List.................................................................................11

Page 3 of 11
 Software Requirement Specifications

1 Introduction

1.1 Purpose
<State the purpose of this functional specification: is a formal document that describes
the capabilities, appearance, and interactions with users of a product or a module or a
component in great detail.>

1.2 Scope
<A brief description of the scope of this document: product level or module level or
component level?>

1.3 References
<Provide a complete list of all documents referenced somewhere in this document. Each
document should be identified by ID, Name, Published Version (optional), Author, and
Storage Location (optional)>

1.4 Terms and Abbreviations

<Include explanation of domain jargons and abbreviations used in this document>

2 Module Description

2.1 Use Case

< Include Use Case diagrams (if any)>

2.2 Use Case Specification

<List out all specification of each use case if any>

3 Flows
<Include process workflows and data flow diagrams (if any)>

4 Data Model
<Include entity relationship diagrams (if any)>

Page 4 of 11
 Software Requirement Specifications

5 Interfaces
<Describe all interfaces that the product or module or component communicates to,
especially input and output messages (if any)>

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

7 Screen Details

Page 5 of 11
 [COMPANY lOGO]

7.1 Screen <Screen ID – Name>

<Repeat this section for each screen>

7.1.1 Layout

<Image of screen wireframe or snapshot>

7.1.2 GUI Elements

Note: If there are any discrepancies between screenshot and GUI Elements table, follow the GUI Elements table as the correct one.
Field Name Description Control Data Default Required Rules
Type Type Value
(Y/N)
<Caption of <Include: <See <See <Include:
the element guidelines guidelines
- Meaning of the field - Select values/Enable this
on the below> below>
field, what function/field will be
screenshot - Where does the data of
impacted?
> this field come from?
-Validation rules: see
>
guidelines below
-Action rules: see guidelines
below
>

[COMPANY NAME] Page 6 of 11

 Software Requirement Specifications

<Guidelines for UI Elements table above:

Control Type:
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

Page 7 of 11
 Software Requirement Specifications

- Integer
- Decimal
- Date Time
- Date
- Time
- Boolean
- Enum {v1, v2, v3}
>

7.1.3 Validation Rules

Field Name Constraint Message ID

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

7.1.4 Control Action Rules

Field Name Action Result

<Caption of the element on <normally including the following actions: < Tell rules that the system behaves when actor
the screenshot > does actions on GUI elements>
- Loading form

Page 8 of 11
 Software Requirement Specifications

- 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)
>

Page 9 of 11
 [COMPANY lOGO]

8 Non-Functional Requirement
8.1 Performance Requirements
<If there are performance requirements for the product under various circumstances,
state them here and explain their rationale, to help the developers understand the intent
and make suitable design choices. Specify the timing relationships for real time systems.
Make such requirements as specific as possible. You may need to state performance
requirements for individual functional requirements or features.>
8.2 Safety Requirements
<Specify those requirements that are concerned with possible loss, damage, or harm
that could result from the use of the product. Define any safeguards or actions that must
be taken, as well as actions that must be prevented. Refer to any external policies or
regulations that state safety issues that affect the product’s design or use. Define any
safety certifications that must be satisfied.>
8.3 Security Requirements
<Specify any requirements regarding security or privacy issues surrounding use of the
product or protection of the data used or created by the product. Define any user identity
authentication requirements. Refer to any external policies or regulations containing
security issues that affect the product. Define any security or privacy certifications that
must be satisfied.>
8.4 Software Quality Attributes
<Specify any additional quality characteristics for the product that will be important to
either the customers or the developers. Some to consider are: adaptability, availability,
correctness, flexibility, interoperability, maintainability, portability, reliability, reusability,
robustness, testability, and usability. Write these to be specific, quantitative, and
verifiable when possible. At the least, clarify the relative preferences for various
attributes, such as ease of use over ease of learning.>
8.5 <Other NFs>
<…..>
9 Appendix (Other Requirement)
<Define any other requirements not covered elsewhere in the SRS. This might include
database requirements, internationalization requirements, legal requirements, reuse
objectives for the project, tooltip list/content, form list/template, report list and so on. Add
any new sections that are pertinent to the project>.
9.1 Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or
the entire organization, and just include terms specific to a single project in each SRS.>
9.2 Appendix B: Analysis Models
<Optionally, include any pertinent analysis models, such as data flow diagrams, class
diagrams, state-transition diagrams, or entity-relationship diagrams.>

[COMPANY NAME] Page 10 of 11

 Software Requirement Specifications

9.3 Appendix C: Autorespone (Notification/Email)

< This is include list of used emails, list of notifications/emails with attached content >
9.4 Appendix C: Issues List
< This is a dynamic list of the open requirements issues that remain to be resolved,
including TBDs, pending decisions, information that is needed, conflicts awaiting
resolution, and the like.>

Page 11 of 11