Requirements Specification and Management Ch-3 Requirements Specification and Management

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.

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.

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

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.

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

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

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

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

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.

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.

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.

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

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.

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.

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.

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.