Requirements Management SE 555 Software Requirements Specification Requirements

Requirements Management SE 555 Software Requirements & Specification

Requirements Engineering Activities n Requirements Development n Elicitation n Analysis n Specification n Validation n Requirements Management n Track versions n Trace relationships between requirements elements n Trace relationships from requirements to design, implementation, and test elements n Control requirements change and its impact on related elements n Track requirements attributes (priority, volatility, cost, benefit, etc. ) SE 555 Software Requirements & Specification

Requirements Baseline n n The requirements baseline is the set of functional and nonfunctional requirements that the development team has committed to implement in a specific increment or release n Separately track proposed but not accepted requirements The baseline represents a critical agreement between the stakeholders and the developers n The bridge between requirements development and requirements management SE 555 Software Requirements & Specification

Activities & Ownership Major requirements management activities n Change control n Version control n Requirements status tracking n Requirements tracing n Someone on the team should “own” the requirements management activities n SE 555 Software Requirements & Specification

Managing Change n n n Through the life of a project the software requirements will change – new ones added, old ones deleted, others modified. Uncontrolled change is common source of project chaos, schedule slips, and quality problems. n Change always has a price An effective change management process ensures that: n Before committing to proposed requirements changes, they are carefully considered and the appropriate decision makers are part of the approval process n Approved changes are communicated to everyone n Changes are carried out in a consistent and efficient manner n The change process is as simple as possible (but no simpler) n The requirements documentation/model will accurately describe the delivered product SE 555 Software Requirements & Specification

A Change Control Procedure n n n During initial development work, changes are made freely to the work product The work product is baseline after technical review or inspection and declared complete and approved n Put the baselined work product under configuration management control Further changes are submitted to change control board via a “change proposal” describing proposed change and impact n Change control board identifies affected parties for review n Each party assesses costs and benefits from their viewpoint n Change control board makes a decision and notifies all concerned parties [Mc. Connell 1997] SE 555 Software Requirements & Specification

Change Activities Proposing changes n Analyzing the impact of the proposed change n Making decisions about the proposal n Updating plans n Implement the change n Updating requirements documents and models n Update designs, code, tests n Test: test changed functionality and regression test unchanged functionality n Assessing requirements volatility n SE 555 Software Requirements & Specification

Change Request Data n n n n n Change request ID Title (change summary) Project in which change is requested Description of request Date submitted Change type (requirement change, enhancement, new requirement, defect report) Change origin (e. g. , marketing, management, customer, development, test, etc. ) Submitter of request Submitter’s assessment of priority n n n n Status (submitted, evaluated, rejected, approved, change made, change cancelled, verified, closed) Implementation priority (CCB’s assessment) Assigned to Date updated Planned release Response(s) Verifier SE 555 Software Requirements & Specification

Impact Analysis n n n Identify all the code, data, models, documents, tests, etc. that might be impacted Identify the indirect impact of change n Especially quality impact: performance degradation, maintenance problem, etc. Identify and estimate the tasks to implement the change Assess the cost/benefit/risk trade-offs See the checklists in Wiegers Figures 19 -5, 19 -6, and 19 -7 SE 555 Software Requirements & Specification

Impact Analysis Report n n n n Change request ID n Title/summary n Description n Assigned analyst n Date of response n Prioritization estimates n n Relative Benefit (1 -9) n n Relative Penalty (1 -9) n n Relative Cost (1 -9) n n Relative Risk (1 -9) Calculated priority with respect to other pending requirements Estimated total effort Estimated lost effort (discarding work already done) Estimated schedule impact Additional cost impact Quality impact Other requirements affected Other tasks affected Integration issues Life-cycle cost issues Other components to examine for possible changes SE 555 Software Requirements & Specification

Tracing Requirements tracing documents the dependencies and logical links between individual requirements and other system elements, such as: n Requirements of various types (e. g. use cases) n Business rules n Architecture and design components n Source code modules n Test cases n Effective traceability is characteristic of an excellent SRS n Requirements need to be fine-grained – do not put too much functionally in a single requirement n SE 555 Software Requirements & Specification

Why Trace Requirements? n n n n Essential to assessing change impact Displays test coverage Enables reuse n “My new product needs this feature that is already implemented, so I reuse this design, this code, this test, and this user guide statement” Drives process workflow in process management Enables predicting the estimated cost and tracking the actual cost of a feature etc. Benefits Do It! Risk Do It! n The risk of not tracing requirements to other elements is much higher than the cost SE 555 Software Requirements & Specification

Traceability Matrix n A requirements traceability matrix is used to maintain and trace links between software requirements and related project elements SE 555 Software Requirements & Specification

Requirements Management: The Essential Activity n Make informed decisions in response to new or changed requirements n Defer lower-priority requirements n Increase staff time (overtime) n Slip the schedule n Let the quality suffer n Just say No! (and explain why) SE 555 Software Requirements & Specification

Requirements Management Tools n Tools help manage the multiple aspects and the scope of ever-changing requirements n Manage versions and changes n n n n n Fine-grained: requirement-level, not document-level Store and sort on requirements attributes Manage and display requirements tracing Facilitate impact analysis Track requirement status Control access Communicate with stakeholders Reuse requirements Link to design, test, project management, and other activities SE 555 Software Requirements & Specification

Some Tools Tool Active! Focus Caliber. RM C. A. R. E. (Computer. Aided Requirements Engineering) DOORS Requisite. Pro RMTrak RTM (Requirements & Traceability Management) Updated version of Wieger’s Table 21 -1 Vendor Falalfel Software http: //www. falafel. com/ Borland Software http: //www. borland. com/ SOPHIST Group http: //www. sophist. de Telelogic http: //www. telelogic. com/ IBM Rational Software http: //www 306. ibm. com/software/rational/ RBC, Inc. http: //www. rbccorp. com/ Serena Software http: //www. serena. com/ SE 555 Software Requirements & Specification Database-Centric or Document-Centric Database Document Database