SE 555 Software Requirements & Specification Beyond Requirements Based on Weigers Chapter17

SE 555 Software Requirements & Specification Requirements Drive Project Planning, Design, Coding, and Testing Activities Use requirements to size the project Base estimates on product size Update plans as requirements change Use requirement priorities to drive iterations Have developers review requirements Use quality attributes to drive architecture design Allocate requirements to components Trace requirements to designs and code Start test design early Use requirements to drive system testing Have users develop acceptance tests Trace requirements to tests Baselined Requirements Project Plans Designs & Code Tests

SE 555 Software Requirements & Specification From Requirements to Project Plans Requirements are a guide to success But meeting business objectives is more important than implementing all the initial requirements Update plans to reflect evolving requirements Update requirements scope and release schedule to reflect evolving business objectives A rough estimate is that 10% - 20% of total development effort should be requirements engineering effort This effort will accelerate other efforts and save wasted effort Good return on investment The requirements effort need not be (should not be) all up-front effort

SE 555 Software Requirements & Specification Use Requirements Metrics in Cost/Time Estimation Metrics Number of individually testable requirements Function points, feature points, etc. Number, type, complexity of graphical user interfaces Estimated lines of code to implement specific requirements Object class counts and association counts Effort and velocity of user stories Number of acceptance test cases Include risk factors, such as volatility, domain experience Expect scope growth (scope rarely shrinks) Gather actuals and compare to estimates to fine-tune estimation models

SE 555 Software Requirements & Specification Requirements and Scheduling Plan and fund a project in stages Unified Process: Inception, Elaboration, Construction, Transition Inception: business objectives, project scope, technical approach, risk, initial cost/time Elaboration: remove risk in scope and technology Cancel at any time business objectives are not being met 5% 20% 65% 10% Construction 50% Elaboration 30% Inception 10% Transition 10% time resources

SE 555 Software Requirements & Specification Failure: Poor Planning, Not Poor Engineering Software projects fail more often due to poor planning than to poor software engineering Project planning and management must be a core software engineering activity Effective planning requires Estimated product size Development team productivity, based on history Knowledge of the engineering activities needed to completely specify, implement, and verify a feature or use case Reasonably stable requirements Experience Don’t succumb to pressure to make commitments that you know are unachievable. Don’t succumb to pressure to commit to estimates before the necessary information is available.

SE 555 Software Requirements & Specification From Requirements to Designs and Code Boundary between requirements and design is not a sharp line Keep requirements specification free from implementation bias unless there is an explicit constraint Include designers/developers in requirements review to detect inadvertent design Functional requirements, quality attributes, and user characteristics drive architecture Use a development perspective to validate requirements “If I understand the requirements correctly, this approach I’m reviewing is a good way to satisfy them.” “Now that I have a preliminary architecture (or prototype) in hand, does it help me better understand the requirements?” Design perspective clarifies requirements Iterate requirements and design

SE 555 Software Requirements & Specification Requirements Analysis is a Design View of Requirements Requirements analysis is a developer’s perspective (from within the system/solution) of the requirements Identify classes (data and behavior) and collaborations that can realize the requirements If I cannot fully specify the classes and collaborations, then the requirements are incomplete or unclear, so fix the requirements The focus of requirements analysis is functional requirements Focus on functional architecture – identification and decomposition of functional concerns identified in requirements Can ignore most technology details until addressing quality requirements Keep the analysis model (and design model) separate from the requirements model The requirements should not expose or require internal system structure After the requirements are validated, look at the analysis model from a technical design perspective Add to it, refine it, throw it out and start over, etc. The requirements model is the final answer on what must be done

SE 555 Software Requirements & Specification Architecture Design in Analysis Architecture is especially critical for Hardware/software systems Complex, software-intensive systems Hard-to-meet quality requirements An essential requirements analysis step is to allocate system requirements to subsystems and components Including allocation of requirements to hardware vs. to software

SE 555 Software Requirements & Specification Guidelines for Analysis/Initial Design Since analysis is design to some extent, do good design Develop a solid architecture of subsystems and components Identify key classes or functional modules, including interfaces, responsibilities, and collaborations For distributed systems, understand the planned execution threads and allocation of functionality to concurrent processes Seek strong cohesion, loose coupling, information hiding, etc. Make sure all functional requirements are met and no unnecessary functions are added Make sure all exceptional conditions and alternate flows are met Ensure that the design will meet performance, robustness, reliability, and other quality requirements.

SE 555 Software Requirements & Specification Requirements to Tests Testing and requirements engineering are synergistic Good requirements engineering produces better tests; good test analysis produces better requirements [Dorothy Graham 2002] Test the product against what it is intended to do (requirements) not against its design or code Tests based on code are self-fulfilling: the test verifies that the code does what it is written to do, but is that what it is functionally supposed to do? Include testers in requirements review to confirm the requirements are testable If testers find they are testing developers assumed requirements, then validate these requirements (remove the gold plating, document the clarification) and update the SRS or remove the gold plating from the code Note: requirements provide system-level and acceptance tests Also develop unit-level and subsystem integration tests

SE 555 Software Requirements & Specification Verifying the System Against Requirements Testers need to decide how to verify the system against each requirement Test Execute the software to look for defects Inspection Examine the design and code to ensure that it satisfies the requirements Demonstration Show that the product works as expected Analysis Reason through how the system should work under certain circumstances Each functional requirement should trace to at least one test case Formal requirements specifications can be used to automatically generate test cases

SE 555 Software Requirements & Specification Conclusions The ultimate deliverable is software that meets the customers’ needs and expectations The requirements are an essential step on the path from business need to satisfied customers Don’t become a slave to your requirements process Don’t generate unnecessary documents and hold ritualized meetings that get in the way of getting software written Strive for a sensible balance between rigorous specification and off- the-top-of-the-head coding that will reduce to an acceptable level the risk of building the wrong product