1. Requirements analysis, representation and validation
T Software Development Project I
Laura Lehtola
TKK/SoberIT/CORE

2. 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

3. 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

4. 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

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

6. 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

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

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

9. 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

10. T : 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