GUIDELINE OF REQUIREMENT MANAGEMENT
1. Purpose
Requirement Management sheet (RM sheet) is a tool for managing project requirements by:
1.1 Recording and tracking ALL of requirements and their changes of the projects in order not to miss or
misunderstand customer requirements.
1.2 Aligning the changing customer requirements with the products your project developed. Besides, it helps in
determining the impact of a change to the system requirements, ensuring all the requirements are covered/
implemented fully throughout all activities/phases of the projects. This is also help in investigating and impact
analysing changes to the requirements.
The document contains
RequirementManagement sheet: to record and track all requirements over project implementation life
(including Changed requirements and Cancelled requirements).
TraceAbilityMatrix sheet: is to describe and follow the life of a requirement, in both a forward and backward
direction, throughout the project life cycle. correlates any two baselined documents that require a many-to-many
relationship to determine the completeness of the relationship. It is often used with customer requirements to the
matching parts of Requirement specification, Design, Source code, Test cases and release of the software product.
On the other hand the relationship among requirements are also be traced.
RequirementStatus_Flow sheet: provide guidance of Requirement status flow.
InfoData sheet: contains based data for combo boxes used in the documents is hidden. To unhide sheet to view
the information, implement the following steps:
Step 1: Menu -> Format -> Sheet -> Unhide.
Step 2 : On Unhide, select InfoData, click OK.
After unhide sheet InfoData, you could change correspondent list item with your project information.
After changed, you to hide the sheet by
Step 1: Active the sheet to be hide.
Step 2: Menu -> Format -> Sheet -> Hide
Attention: Several parts in the file are logged with password “FSOFT2008”. It is recommended to used this
password only if necessary. Once changes are completed, it is to relocked.
2. Scope
Application to all FSOFT departments/projects.
3. Definition & Criteria
REQ ID is the unique identifying number of the requirement.
Title of REQ: one-line description of the REQ
Description of Requirement give brief information of the requirement or specify URD and SRS section(s) or link to the
record where the description of requirements is recorded.
Originator - who nominate the requirement: Name or Role of the Originator in project.
Type: New or Change Request, where Change Request are the changes to existing requirements. For fix price
projects, any one or a group of new requirements come after the 1st baselined version of requirement document will be
considered as Change Request also.
Category: this is left to projects to determine. In normal case, it contains.
- Functional: the function that the product is to execute.
- Non-Functional: are the ones that act to constrain the solution. Nonfunctional requirements are also known as
attribute or quality requirements of the product.
- Process: are constraints on the development of the product.
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 1/23
Size: be reflected by amount of work/effort needed to implement this REQ. It is used to measure the Requirement
Completeness.
Difficulty: difficulty in implementation of this REQ, weighted as Low-Medium-High. This field is optional.
Key: the requirements are very important, have significant impact on product/process quality, functionality. It means
that if the key requirements are not implemented, product/process quality, functionality does not function at all or
crashes.
Priority: urgency of implementation. This field is optional.
Person in charge: Person who is assigned responsibility for implementing the change. This field is optional.
Effort: estimated effort needed to implement the requirement. This field is recommended to Change Request, and
optional, could be omitted to New REQ.
Status: current status of the change request as it moves through the states described in the RequirementFlow sheet.
4. Procedure of Requirement Management
a- Requirement Management
a-1 Every requirement is registered in a separate row.
a-2 It is recommended to modify/add information as they changed as following:
a) As new requirement come, add one more row to record that requirement, record its "Type" as New.
b) As customer change the existing requirements, update description of the corresponding requirement and
change its "Type" as Change Request. For fix price projects, any one or a group of new requirements come
after the 1st baselined version of requirement document will be considered as Change Request also.
c) As customer requires to remove a requirement, its "Status" is changed to Cancelled.
d) As any of new requirements come, and it is a child requirement of any other requirement, add one more row
below its Parent REQ to record the requirement and get REQ ID to reflect the relationship.
a-3 REQ ID shall to set by the project according to the pre-defined rule so that it is to easy to understand, easy to
search. The requirements have relationship with each other should have a common identity in their ID. Parent-
child relationship among require requirements must be realized via REQ ID.
a-4 Person in charge, status and expected completion date of every requirement to be identified. It could be tracked in
other documents of the project (for instance: project schedule, project tasklist).
Attention: In order to ensure integrity of the information among the sheets, it is recommended to click "Add row"
or "Delete row" to insert, delete row in the sheets.
b- Traceability Matrix
b-1 Requirement information in that sheet is integrated from the sheet “RequirementManagement".
b-2 Every part of other products of project (System Requirement, Design, code, test…) is recorded in a separate
column with the name of the parent products.
b-3 As new requirements come or new products developed, new columns are inserted in that sheet.
b-4 To trace relation of products to requirements, we mark in correspondent cells of the requirements (driver) and the
products (satisfier). The relationship of driver to satisfier can be one-to-one, one-to-many, many-to-one, or many-
to-many. Traceability requires unique identifiers (ID) for each requirement and product.
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 2/23
Requirement Management Sheet
Project Code
Person in charge
Last update 29-Dec-2008
Req Stability 38.46%
Req Completeness 61.23%
Please use these above buttons to add new or delete a row.
Req ID Requirement Title Description
<F-0001> <Function 1> <Add new button into ABC screen>
<F-0002> <Function 2> <Add new button into ABC screen>
<F-0003> <Function 3> <Add new fields into CSV file>
<F-0004> <Function 4> <Change column name in DB>
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 3/23
s to add new or delete a row.
Please refer to RequirementFlow for more detail about status
Req Source Type Category Size Difficulty Key Priority
Change Request 1 ○ High
New 4
New 4 ○ High
Change Request 4
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 4/23
ore detail about status
Change
Coding Submitted Committed Designed
PIC Status Status
Effort(pd) Date Date Date
Date
<ThanhDQ> Tested 17-Nov-2008
<ThanhDQ> Coded 5-Dec-2008
<ThanhDQ> Designed 5-Dec-2008
Coded 5-Dec-2008
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 5/23
Design Code
Coded Tested Delivered Accepted
Reviewed Reviewed
Date Date Date Date
Date Date
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 6/23
Cancelled
Note
Date
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 7/23
Trace Ability Matrix
Project Code
Person in charge
Last update 29-Dec-2008
Direction:
Take the identifier for each of the items of one document and place them in the left column. The identifiers for the other docum
When an item in the left column is related to an item across the top, a mark is placed in the intersecting cell. The number of re
This value indicates the mapping of the two items. Zero values indicate that no relationship exists. It must be determined if one
Large values imply that the item is too complex and should be simplified.
Requirement ID Requirement content Description
<F-0001> <Function 1> <Add new button into ABC screen>
<F-0002> <Function 2> <Add new button into ABC screen>
<F-0003> <Function 3> <Add new fields into CSV file>
<F-0004> <Function 4> <Change column name in DB>
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 8/23
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 9/23
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 10/23
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 11/23
dentifiers for the other document are placed across the top row.
secting cell. The number of relationships are added up for each row and each column.
. It must be determined if one must be made.
D_ .xls
D_ .xls
D_ .xls
D_ .xls
D_ .xls
D_ .xls
D_ .xls
ls
D_ .xls
D_ .xls
D_ .xls
D_ .xls
D_ .xls
D_ .xls
mo e01.h
1.c
8.x
1
2
3
4
5
6
1
2
3
4
5
6
7
1
2
3
4
5
6
le0
q_
q_
q_
q_
q_
q_
00
00
00
00
00
00
00
00
00
00
00
00
00
00
l
du
du
Re
Re
Re
Re
Re
Re
D_
mo
DD
DD
DD
DD
DD
DD
DD
DD
AD
AD
AD
AD
AD
AD
PIC Status Requirement Architecture Design Detail design Source
<ThanhDQ
Tested ○ ○ ○ ○
>
<ThanhDQ
Coded ○
>
<ThanhDQ
Designed
>
Coded
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 12/23
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 13/23
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 14/23
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 15/23
mo
du
l
mo e01.h
du
l
○
mo e01.
du c
le0
mo 2.h
du
le0
mo 2.c
du
Source Code
le0
mo 3.h
du
le0
mo 3.c
du
le0
mo 4.h
du
le0
06de-BM/PM/HDCV/FSOFT v2/1
Ca
teg 4.c
ory
Ca 01
teg
ory
Ca 02
teg
ory
Ca 03
teg
ory
Test case Ca 04
teg
ory
Ca 05
Internal use
teg
ory
Ca 06
teg
ory
Ca 07
teg
ory
Do 08
cu
me
Do nt
cu 01
me
Do nt
cu 02
me
Do nt
cu 03
me
Do nt
cu 04
me
Do nt
cu 05
Other documents
me
Do nt
cu 06
me
Do nt
cu 07
me
nt
16/23
08
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 17/23
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 18/23
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 19/23
08
nt
me
cu
Do
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 20/23
Requirement is raised
Requirement is analyzed
Submitted by project team Analyzed Requirement is approved Committed
Design is completed
Imｐlementing
Designed
Cancelled
Code is reviewed & unit tested
Coded
Test is completed
Accepted Accepted by customer Delivered FI is pased Tested
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 21/23
PIC Status list Check list Category Size Priority Req Source Type
<ThanhDQ> Submitted ○ Functionality 1 High Customer New
<PhuongTH1> Analyzed Non-functionality 2 Medium Project Change Request
<ChinhNK> Cancelled Process 3 Low
<ThonNV> Committed UI 4
<ChungNK> Designed 5
<HungTN> Coded
Tested
Delivered
Accepted
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 22/23
Submitted Analyzed Committed Designed Coded Tested Delivered Accepted
0% 5% 10% 24% 76% 92% 96% 100%
06de-BM/PM/HDCV/FSOFT v2/1 Internal use 23/23
