1. Requirements Specification and Management
Ch-3
Requirements Specification and Management

2. Introduction Good requirements are essential for executing projects.
Improperly understood or documented requirements lead to cost escalations, late delivery, and poor quality, in short leads to dissatisfied customers.
Two major activities are requirement analysis and specification and requirements change management.
Requirement specification activity is done at start of the project and change management is done throughout the project.
Requirement traceability is another activity that aims to ensure that all requirements can be traced to elements in the outputs produced in the later stages of the project. The goal is to ensure that final software satisfies the customer’s requirements is met.

3. Requirement analysis and specification
The main objective is to produce a document that satisfies all requirements of the customer.
SRS is the primary output of this phase.
The activities performed during this phase focuses on two areas: problem analysis and product description.
Problem analysis activities are grouped into 3 phases of preparing, gathering requirements and analysis.
Product description activities are grouped into 3 phases: preparing the SRS, reviewing it and obtaining the final sign-off from the customer.

4. Process for requirements analysis and specification
prepare
Gather requirements
analyze
Obtain sign-off
review
Prepare srs and
Acceptance criteria

5. Requirement specification
It includes planning, elicitation and analysis activities.
SRS document is the main output of this stage.
Requirements elicitation, analysis and specification is human activity that converts into a formal document. So mistakes are likely to happen and if caught during testing can cost 100 times more than if caught during requirements.
Communication gap between supplier and customer is another problem in this phase which low down the customer satisfaction.
For requirement validation, requirements review is done and involves the customer.

6. Template for SRS Overview Current system
Limitations of the current system
Proposed system
Objectives of the proposed system
Functional requirements
System requirements
Scope and boundary
Context diagram
Business events
 External events
 Temporal events

7. Continue…. Inputs and outputs Relationships Precedence relationships
Screens
External interface requirements
Operating environment requirements
Hardware
Software
Network
Communication

8. Continue…. Performance requirements Standards requirements
User interface
Detailed design
Coding
Document
Special user requirements
Security
Audit trail
Reliability
Transaction volume and data volume
Back up and recovery

9. Continue…. Legal Data migration Data retention Installation
User training
User manual and help
Automated and manual functions
Features not required
Constraints
Prototype
Glossary of terms

10. Requirements change management
There are two main reasons for change in requirements.
One is world around the system changes. So the system requires changes to adapt with environment.
Second reason is sometimes user is not aware of the desired requirements so he starts with some basic. As the time passes he becomes clear of what he want and hence their requirements for software changes.
Requirements change management process defines the set of activities that needs to be performed when there are some new requirements or changes to existing requirements
The goal of this phase is to control the requirements changes and minimize their effect on the project.

11. Continue….
This goal necessitates understanding the full implications of a requirement change request.
It also requires making the customer fully aware of the effects of the changes on the project.
Requirements change management includes: agreement with the customer about how to deal with the changes and process of actually making the changes. It is the part of the proposal as well as project management plan.
Project leader is main participant in this phase.
Besides this customer, business manager and development team also participate.

12. Continue….
The entry criteria for this process is that a change request has been received. Inputs are the change request and the work products that have been already produced in the project.
The main outputs are impact analysis report for change request, the revised project plan and the changed work products.
The exit criterion is that the change has been incorporated.

13. Continue…. Following are the major steps in the process.
Log the changes
Perform impact analysis on the work products
Estimate effort needed for the change request
Re estimate delivery schedule
Perform cumulative cost impact analysis
Review the impact with senior management, if thresholds are exceeded.
Obtain customer sign-off
Rework work products

14. Traceability management
In this phase there exists a way for checking that software meets all the requirements.
Two types of traceability exists: forward and backward
Forward traceability implies that it is possible to trace a requirement to elements in the outputs of later phases in the life cycle.
Backward traceability implies that it is possible to trace elements in the output of various stages back to requirements.
Forward traceability is to ensure that the software meets the requirements.
Backward traceability is useful during change, regression testing etc.

15. Traceability matrix
the simplest way to support traceability is to have a mapping from requirement elements to design elements, from design elements to code elements and from code elements to test cases.
In this matrix, reqmt # is a reference to the requirement specification. Use of this matrix requires a proper numbering scheme to be used in the srs such that individual requirements have unique numbers or labels.
HLD Ref # is a reference to the functional specification that satisfies corresponding requirement.
Design is a section number from corresponding design document.
Reference could be functional, architectural and database design.

16. Continue…
Implementation refers to the corresponding program that implements the requirement.
Unit test case represents test case number in the unit test plan.
Integration/system test case for the requirement.
The corresponding acceptance test for particular requirement is mentioned in acceptance test case.

17. Matrix maintenance and usage
Traceability matrix helps in tracing all requirements through various phases.
It helps reviews by providing mechanism for reviewers to check that all requirements have been handled.
Matrix contains information that can be used for impact analysis when requirements change.
It helps in demonstrating to the customer that the software has been developed to meet all requirements.
Traceability matrix is of limited use.
Because of its design it will not remain static and needs to be updated.
At the start matrix contains data in first two columns only. As the development proceeds, data for other fields are added.
For maintenance of a traceability matrix, numbering schemes must be used in all documents.