FUNCTIONAL AREAS

<Organization Name>

<Project Name>

SYSTEM REQUIREMENTS SPECIFICATION

<FUNCTIONAL AREA>

DECEMBER 2012

PREPARED BY <YOUR NAME HERE>

 SRS - <FUNCTIONAL AREA>

DOCUMENT CONTROL
Author: <your name here>
Date: 99 month 2012
Version: 0.1

Audience: Project Team

Approval: Pending
Approval Date:

VERSION CONTROL
Version Date Prepared by Reviewed by Comments

0.1 Initial draft

0.2

Document Reviews

Date Participants Approval Comments

CONFIDENTIAL PAGE 2 OF 15
 SRS - <FUNCTIONAL AREA>

TABLE OF CONTENTS

1 INTRODUCTION 4

2 BASIC FUNCTIONS 5
2.1 <FUNCTION #1> 5

3 USE CASES 6
3.1 <USE CASE #1> - <USE CASE NAME> 7

4 STORYBOARDS AND SCREEN MOCKUPS 10

5 BASIC ENTITIES 11
5.1 <ENTITY #1> 11

6 FORMAL REQUIREMENTS 12

7 SECURITY 13

8 E-R DIAGRAM 14

9 GLOSSARY 16

CONFIDENTIAL PAGE 3 OF 15
 SRS - <FUNCTIONAL AREA>

1 INTRODUCTION
This section should contain a general description of the functional area, and
any sub-functional areas it contains. If the sub-functional area is described in
a separate sub-SRS document, a reference to that document should be made
here.

CONFIDENTIAL PAGE 4 OF 15
 SRS - <FUNCTIONAL AREA>

2 BASIC FUNCTIONS
This section will define the basic high-level functions that are required in the
Functional Area. There should be a high-level diagram describing the various
functions and their relationships to one another.

Figure 1 - Chart of Accounts Functionality

2.1 <Function #1>

<include workflow, dataflow, or structure diagram, as appropriate for each

function>

CONFIDENTIAL PAGE 5 OF 15
 SRS - <FUNCTIONAL AREA>

3 USE CASES
This section should contain a description of the various use cases addressed
by this functional area.

<include use case diagrams for every use case>

<include security considerations>
<use cases should be numbered based on WBS ID>

CONFIDENTIAL PAGE 6 OF 15
 SRS - <FUNCTIONAL AREA>

Figure 2 - Journal Entry System Use Cases

3.1 <Use Case #1> - <Use Case Name>

<e.g., GJ-1.5.3. - Enter a manual journal entry>

CONFIDENTIAL PAGE 7 OF 15
 SRS - <FUNCTIONAL AREA>

[An actor is a person or other entity external to the software system being
Actors: specified who interacts with the system and performs use cases to accomplish
tasks. Different actors often correspond to different user classes, or roles,
identified from the customer community that will use the product. Name the
actor that will be initiating this use case (primary) and any other actors who
will participate in completing the use case (secondary).]
ex.

1. Accountant
[Provide a brief description of the reason for and outcome of this use case.]
Description:
[Identify the event that initiates the use case. This could be an external
Trigger: business event or system event that causes the use case to begin, or it could
be the first step in the normal flow.]
[List any activities that must take place, or any conditions that must be true,
Preconditions: before the use case can be started. Number each pre-condition. e.g.

1. User has list of accounts and corresponding amounts that need to be

entered.
2. User has "Enter Manual JE" permissions.]

Postconditions: [Describe the state of the system at the conclusion of the use case execution.
Should include both minimal guarantees (what must happen even if the
actor’s goal is not achieved) and the success guarantees (what happens
when the actor’s goal is achieved. Number each post-condition. e.g.

1. Journal entry is entered and ready for posting]

Normal Flow: [Provide a detailed description of the user actions and system responses that
will take place during execution of the use case under normal, expected
conditions. This dialog sequence will ultimately lead to accomplishing the goal
stated in the use case name and description.

1. User selects "Enter manual journal entry function"

2. System presents Manual Journal Entry form
3. System autopopulates Journal Entry header information
a. JE ID #
b. Date/Time
c. User ID
d. Type (= "Manual")
e. Source
4. User enters additional Journal Entry header information
a. Description
b. ....
5. For each line item of the journal entry the user enters/selects:
a. Account number
b. DR/CR
c. Amount
6. When user is finished entering line items, system verifies JE to ensure
DRs = CRs
7. JE is entered in "Unposted" status
[Document legitimate branches from the main flow to handle special
Alternative Flows: conditions (also known as extensions). For each alternative flow reference the
[Alternative Flow 1 – branching step number of the normal flow and the condition which must be
true in order for this extension to be executed. e.g. Alternative flows in the
JE does not balance] Enter Manual JE transaction:

CONFIDENTIAL PAGE 8 OF 15
 SRS - <FUNCTIONAL AREA>

6a. In step 5 of the normal flow, user can select "Auto-offset":

1. System will allow user to select automatic offsetting account
2. System generates JE line with offset amount equal to all credits
3. System generates JE line with offset amount equal to all debits

Note: Insert a new row for each distinctive alternative flow. ]

Exceptions: [Describe any anticipated error conditions that could occur during execution
of the use case, and define how the system is to respond to those conditions.
e.g. JE does not balance:

6a. In step 6 of the normal flow, if the JE does not balance:

4. System will indicate that JE is out of balance and the amount it is out of
balance by
1. Use Case resumes on step 5

Includes: [List any other use cases that are included (“called”) by this use case.
Common functionality that appears in multiple use cases can be split out into
a separate use case that is included by the ones that need that common
functionality]
[How often will this Use Case be executed. This information is primarily useful
Frequency of Use: for designers. e.g. enter values such as 50 per hour, 200 per day, once a
week, once a year, on demand etc.]

Special [Identify any additional requirements, such as nonfunctional requirements, for

Requirements: the use case that may need to be addressed during design or implementation.
These may include performance requirements or other quality attributes.]
[List any assumptions that were made in the analysis that led to accepting this
Assumptions: use case into the product description and writing the use case description.]
[List any additional comments about this use case or any remaining open
Notes and Issues: issues or TBDs (To Be Determined) that must be resolved.]

CONFIDENTIAL PAGE 9 OF 15
 SRS - <FUNCTIONAL AREA>

4 STORYBOARDS AND SCREEN MOCKUPS

This section should contain storyboards and/or screen or report mockups
illustrating a user's interaction with the portion of the system described in this
functional area. These are not necessarily binding mockups, but a point-of-
departure for the design process.
<input documents>

CONFIDENTIAL PAGE 10 OF 15
 SRS - <FUNCTIONAL AREA>

5 BASIC ENTITIES
This section should describe the functional data entities that are required for
this functional area. Entities listed here should be the same as those in the E-
R diagram section. More detailed definitions of data entities (as RDBMS
tables and columns) will be derived in the detail design process.

5.1 <entity #1>

A description of the entity, it's attributes, and rules for usage of the entity, as
well as its relationships to other entities.

CONFIDENTIAL PAGE 11 OF 15
 SRS - <FUNCTIONAL AREA>

6 FORMAL REQUIREMENTS
A list of specific requirements stated in a formal manner. Each requirement
should be identified with a unique identifier. One way to do so might be to
prefix the identifier with an abbreviation identifying the functional area, e.g.,
"GL" for General Ledger, "GJ" for General Journal, "PAY" for payments, etc.
This list of requirements is the input to the Requirements Traceability
Verification Matrix (RTVM).

Req. ID Mandatory Requirement Description

GL0001

CONFIDENTIAL PAGE 12 OF 15
 SRS - <FUNCTIONAL AREA>

7 SECURITY
This section should contain an overview of security considerations of this
functional area. It will supplement the security issues addressed in the use
cases.

CONFIDENTIAL PAGE 13 OF 15
 SRS - <FUNCTIONAL AREA>

8 E-R DIAGRAM

<this should be a conceptual E-R diagram>

Figure 3 - Entity Relationship Diagram

CONFIDENTIAL PAGE 14 OF 15
 SRS - <FUNCTIONAL AREA>

9 GLOSSARY

account a record in the General Ledger identified by a unique combination of

chart of accounts elements.

bill When a vendor submits an invoice for payment, this invoice is

referred to as a "bill".

challan Receipt for payment, in this case against some obligation to

government.

CGA Controller General of Accounts

GOB Government of Bangladesh

invoice A request for payment.

CONFIDENTIAL PAGE 15 OF 15