CS 691z / 791z Topics on Software Engineering

1. CS 691z / 791zTopics on Software Engineering Software Requirements Based on Chapter 3: The Requirements Workflow [Arlow & Neustadt, 2002] February 6, 2007

2. Outline • Requirements: • 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, 2002] 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 2002]

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 2002]

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 a 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. • 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 • “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 • Distortion • Generalization • 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