CS 426 Senior Projects

1. CS 426Senior Projects Chapter 3: The Requirements Workflow [Arlow & Neustadt, 2005] January 26, 2011

2. Outline • The requirements workflow • Metamodel for software requirements • Requirements workflow details • The importance of requirements • Defining requirements

3. The Requirements Workflow. Fig. 3.2 [Arlow & Neustadt 2005] shows that most of the work in requirements workflow occurs in Inception and Elaboration phases

4. .The Requirements Workflow • The purpose of the requirements workflow is to reach an agreement on what the system should do, expressed in a way accessible to the users of the system • Requirements engineering involves: elicitation, negotiation, conflict resolution, prioritization, documentation, and maintenance of requirements • Various stakeholders are involved in establishing the set of requirements for the system • UML uses cases describe functional requirements, but non-functional requirements need different description

5. Metamodel for Software Requirements Arlow & Neustadt’s approach for requirements engineering is shown in Fig. 3.3 [Arlow 2002]. Details can be found in Section 3.3

6. Requirements Workflow Detail. Specific tasks for UP (Unified Process) requirements workflow Fig. 3.4 [Arlow & Neustadt 2005]

7. .Requirements Workflow Detail Arlow and Neustadt extend slightly the UP requirements workflow with the addition of new tasks: find functional requirements, find non- functional requirements, prioritize requirements, &trace requirements to use cases. As such, non-functional requirements can be addressed as well, along with the traditional UP/UML treatment of functional requirements via use cases. Fig. 3.5 [Arlow & Neustadt 2005]

8. The Importance of Requirements • Requirements engineering is about establishing whatthe stakeholders need from the system • Requirements engineering encompasses elicitation, negotiation, conflict resolution, prioritization, documentation, and maintenance of requirements • Poor requirements engineering is the major cause of software project failure • The second major cause of software project failure is lack of user participation

9. Defining Requirements.… • Requirement: “a specification of what should be implemented” • There are two types of requirements: • Functional requirements: describe the desired behaviour of the system • Non-functional requirements: specify particular properties of or constraints on the system • In theory, the set of requirements should be only about “what” the system should do, but in practice it is not possible to avoid “how” aspects of the system

10. .Defining Requirements... • The SRS (Systems Requirements Specification) is the document that contains the set of requirements expected to be satisfied by the system, both functional and non-functional • There are many ways to write an SRS (“company dependent” ways) • The SRS provides the input for the analysis and design phases of the development process • The bottom line regarding the SRS is: “does it help me to understand what the system should do or not?”

11. ..Defining Requirements.. • Simple format recommended for well-formed requirements: <id> The <system> shall <function> • Examples of functional requirements (what the system should do): 1 The ATM shall check the validity of the ATM card inserted. 2 The ATM shall validate the PIN number entered by the client. 3 The ATM shall dispense no more than $500 against any ATM card in any 24-hour period • Examples of non-functional requirements (constraints on or properties of the system): 1 The ATM shall be written in C++. 2 The ATM shall validate the PIN in three seconds or less.

12. …Defining Requirements. • Organizing requirements: a more complex taxonomy can be used when there are many requirements, e.g. • Functional requirements • Customers • Products • Orders • Sales channels • Payments • Non-functional requirements: • Performance • Capacity • Availability • Compliance with standards • Security

13. ….Defining Requirements • Requirements may have attributes, e.g. • Must have • Should have • Could have • Want to have [the MoSCoW system] • Requirement attributes in RUP: • Status (proposed, approved, rejected, incorporated) • Benefit (critical, important, useful) • Effort (measured in person*day or function points) • Risk (high, medium, low) • Stability (high, medium, low) • TargetRelease (product version when implemented)

14. Finding Requirements.. • Requirements come from the context of the system: • Direct users • Other stakeholders (e.g., managers, maintainers, installers) • Other systems that interact with the system • Hardware devices attached to the system • Legal and regulatory constraints • Technical constraints • Business goals

15. .Finding Requirements • “The map is not the territory” (that is, a model is not the real thing). When modeling, we apply three cognitive filters that simplify our effort [Chomsky, 1975]: • Deletion (information is filtered out) • Distortion (information is modified) • Generalization (information is abstracted into rules, principles, etc) • In requirements specification we need to identify the application of the above filters and find “challenges” for them to recover information • In particular, universal quantifiers such as all, everyone, always, never, nobody, none should be inspected closely for accuracy

16. ..Finding Requirements • Interviews: • Don’t imagine a solution • Don’t mind read • Ask context-free questions • Listen • Have patience! • Questionnaire: they can supplement interviews. • Good at getting answers to closed questions • Requirements workshop • Participants: facilitator, requirements engineer, stakeholders, domain experts • Procedure: 1 Brainstorm (accept all ideas) 2 Identify key requirements 3 Iterate over, refine, and prioritize requirements