Requirements analysis, representation and validation T-76.4115 Software Development Project I 4.10.2005 Laura Lehtola TKK/SoberIT/CORE

Requirements engineering circle (Kotonya et al.) Draft statement of requirements requirements analysis requirements elicitation requirements negotiation requirements problems requirements document © L. Lehtola Oct 4, 2005

Example: Analysing customer’s raw requirement A raw requirement given by a customer: “The stop –button should turn red when the system has only 10% of its memory space left” Analysis: Customer feels that she should stop using the system, because running out the memory space can cause problems. Real customer requirement: The problem concerning the challenges that may occur when the memory space runs out must be solved. © L. Lehtola Oct 4, 2005

Check list for requirements (Kotonya & Sommerville) Premature design Combined requirements Unnecessary requirements Use of non-standard hardware Conformance with business goals Requirements ambiguity Requirements realism Requirements testability “..uses Oracle database..” “..adds, removes and calculates..” “..counts the price by using 7 digits” … requires the year 1976-version of the Laskuri –software? … might make few grandmothers more interested of this trend product? “…might do this and a little bit that, maybe…” “… prints the result straight to the users brain” “… gives a lot of feedback …” © L. Lehtola Oct 4, 2005

Documenting the requirements (attributes) ID (Version) (Feature) Requirement Source Rationale Priority (Importance) Status Traces to use cases © L. Lehtola Oct 4, 2005

Requirements prioritization Prioritize requirements with the customer Analyse requirements from three viewpoints Importance for customer and users [Customer] Implementation effort needed [Project group] Architectural urgency [Project group] Document the decisions Communicate your estimates to customer Let the customer make the final decision Document the priorities Document the rationales © L. Lehtola Oct 4, 2005

Requirements validation Use teams to review requirements customer, designers, testers, project manager user (?) … Let the customer approve the requirements © L. Lehtola Oct 4, 2005

Requirements engineering during the iterations Keep status of requirements up-to-date Proposed Approved / Deleted Implemented Verified © L. Lehtola Oct 4, 2005

T-76.4115: Project planning -iteration Synthesize an initial draft of the requirements Business Goals Main Domain Concepts System Overview User Groups Functional and Non-Functional Requirements List of Use Cases Constraints Solution Ideas © L. Lehtola Oct 4, 2005

T-76.4115: Iterations 1 and 2 Choose a set of use cases to be implemented Complete use case descriptions Document functional requirements Document other requirements Update your data descriptions Prioritize Design user interfaces and navigation maps Design, code, test, deliver © L. Lehtola Oct 4, 2005