SE 555 Software Requirements & Specification Requirements Management

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

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

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

SE 555 Software Requirements & Specification Managing Change 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. Change always has a price An effective change management process ensures that: Before committing to proposed requirements changes, they are carefully considered and the appropriate decision makers are part of the approval process Approved changes are communicated to everyone Changes are carried out in a consistent and efficient manner The change process is as simple as possible (but no simpler) The requirements documentation/model will accurately describe the delivered product

SE 555 Software Requirements & Specification A Change Control Procedure 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 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 Change control board identifies affected parties for review Each party assesses costs and benefits from their viewpoint Change control board makes a decision and notifies all concerned parties [McConnell 1997]

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

SE 555 Software Requirements & Specification Change Request Data 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 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 Identify all the code, data, models, documents, tests, etc. that might be impacted Identify the indirect impact of change 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 Change request ID Title/summary Description Assigned analyst Date of response Prioritization estimates Relative Benefit (1-9) Relative Penalty (1-9) Relative Cost (1-9) 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 Requirements tracing documents the dependencies and logical links between individual requirements and other system elements, such as: Requirements of various types (e.g. use cases) Business rules Architecture and design components Source code modules Test cases Effective traceability is characteristic of an excellent SRS Requirements need to be fine-grained – do not put too much functionally in a single requirement

SE 555 Software Requirements & Specification Why Trace Requirements? Essential to assessing change impact Displays test coverage Enables reuse “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! The risk of not tracing requirements to other elements is much higher than the cost

SE 555 Software Requirements & Specification Traceability Matrix 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 Make informed decisions in response to new or changed requirements Defer lower-priority requirements Increase staff Increase staff time (overtime) Slip the schedule Let the quality suffer Just say No! (and explain why)

SE 555 Software Requirements & Specification Requirements Management Tools Tools help manage the multiple aspects and the scope of ever-changing requirements Manage versions and changes 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 ToolVendorDatabase-Centric or Document-Centric Active! FocusFalalfel Software Database CaliberRMBorland Software Database C.A.R.E. (Computer- Aided Requirements Engineering) SOPHIST Group Database DOORSTelelogic Database RequisiteProIBM Rational Software ibm.com/software/rational/ Document RMTrakRBC, Inc. Document RTM (Requirements & Traceability Management) Serena Software Database Updated version of Wieger’s Table 21-1