1. Requirements Engineering How do we keep straight what we are supposed to be building?

2. Starter Questions  What is a "requirement"?  How do we determine the requirements?  Why is requirements engineering difficult? 2

3. Why good Specs are Essential: $  It is VERY expensive to fix problems late in the process. It is very cheap to rewrite or clarify a written spec.  What costs $1 to fix at ReqGathering $5 in the design stage $10 in the coding stage $20 in the unit testing phase $200 after delivery 3

4. Types of Requirements  Functional ex - it must email the sales manager when an inventory item is "low"  Non-Functional ex - it must require less than one hour to run report #5  Explicit ex – required features  Implied ex – software quality  Forgotten ex – exists in current process  Unimagined 4

5. Requirements of Requirements  Clear  Measurable  Feasible  Necessary  Prioritized  Concise 5

6. Ambiguousness – example one The control total is taken from the last record. 1. The total is taken from the record at the end of the file. 2. The total is taken from the latest record. 3. The total is taken from the previous record. IEEE 830-1984

7. Ambiguousness – example two All customers have the same control field. 1. All customers have the same value in their control field. 2. All control fields have the same format. 3. One control field is issued for all customers. IEEE 830-1984

8. Why Req Eng is Difficult 8

9. Requirements Engineering Tasks 1.Inception 2.Elicitation 3.Elaboration 4.Negotiation 5.Specification 6.Validation 7.Management Software Engineering: A Practitioner’s Approach by Roger Pressman 9

10. Inception  Project starts due to a business decision  Software Engineer Asks: Why do you want this What is the basic problem Who wants a solution  who wants this  who will use this Nature of solution  economic benefit of success? 10

11. Requirements Engineering Tasks 1.Inception 2.Elicitation 3.Elaboration 4.Negotiation 5.Specification 6.Validation 7.Management 11/32

12. Elicitation via Interviews Difficulties  Ill-defined project scope  Unnecessary details that confuse  Not sure what they need  Poor understanding of capabilities  Omitting the “obvious”  Requirements that conflict with other people’s requirements  Requirements Change!!! 12

13. Elicitation via Interviews Recommendations 1. The list of involved stakeholders must be broad include end-users, managers, etc include the software developers 2. Use agendas that cover the important points yet encourage flow of ideas 3. Ahead of time, the participants should build a partial list of the functions, performance criteria, environment factors, … 4. Start with scope and context, move to functions 5. Use visuals such as wall-stickers, flip-charts, … 13

14. Elicitation via Use Cases http://www.evanetics.com/Articles/ar_usecases/uc_valueofucd.htm

15. Elicitation via QFD Since 1966, Quality Function Deployment (QFD) has been used world wide in nearly every industry and sector to: 1. Prioritize spoken and unspoken customer wows, wants, and needs; 2. Translate these needs into actions and designs such as technical characteristics and specifications; and 3. Build and deliver a quality product or service by focusing various business functions toward achieving a common goal and customer satisfaction. www.qfdi.org  QFD uses interviews, surveys, and data (problem reports) to build a table of requirements called the Customer Voice Table.  Functional Deployment – value of each function  Information Deployment – identify the input and output  Task Deployment – examine system behavior  Value Analysis – prioritize the requirements 15

16. Requirements Engineering Tasks 1.Inception 2.Elicitation 3.Elaboration 4.Negotiation 5.Specification 6.Validation 7.Management 16/32

17. Elaboration model  Goal is to create a model that defines: 1. information 2. functions  Models could be ER Diagrams Use Cases Data Flow Diagrams all of the above http://www.camsp.com/cornerstone/assets/images/resources/when_use_maps_sm.png 17

18. System Modeling  Function & Information Flow Model what we will do with the data  Data Model structure of the information  Behavior Model how we interact with the system

19. Data Modeling  Data Objects, Attributes, Relationships Formatted as Lists or Tables  Entity Relationship Diagrams security system sensor monitors enables/disables tests programs is programmed by

20. Behavior Modeling State Transition Diagram 1 3 2 4 start read msg save msg file name done compose send

21. Requirements Engineering Tasks 1.Inception 2.Elicitation 3.Elaboration 4.Negotiation 5.Specification 6.Validation 7.Management 21/32

22. Negotiation  Goal is to resolve requirements that are Conflicting Costly Unrealistic 1.Identify the subsystem’s stakeholders 2.Determine their win conditions 3.Negotiate their win conditions into win- win conditions for everyone 22

23. Requirements Engineering Tasks 1.Inception 2.Elicitation 3.Elaboration 4.Negotiation 5.Specification 6.Validation 7.Management 23/32

24. Technically Speaking, "requirement" ≠ "specification"  Requirement – understanding between customer and supplier  Specification – what the software must do  Requirements that are not in the SRS Costs Delivery dates Acceptance procedures etc 24

25. IEEE 830 Characteristics of a Good SRS 1.Unambiguous 2.Complete 3.Verifiable 4.Consistent 5.Modifiable 6.Traceable 7.Usable during the Operation and Maintenance Phase 25

26. IEEE 830 Role of SRS 1. “The SRS must correctly define all of the software requirements, but no more.” 2. “The SRS should not describe design, verification, or project management details, except for required design constraints.” 26

27. SRS Table of Contents 1.Introduction 1.Purpose 2.Scope 3.Definitions 4.References 5.Overview 2.General Description 1.Product Perspective 2.Product Functions 3.User Characteristics 4.General Constraints 5.Assumptions and Dependencies 3.Specific Requirements IEEE 830-1984

28. 3. Specific Requirements 3.1 Functional Requirements 3.1.1 Func Req 1 3.1.1.1 Introduction 3.1.1.2 Inputs 3.1.1.3 Processing 3.1.1.4 Outputs 3.1.2 Func Req 2 … 3.2 External Interface Requirements 3.2.1 User Interface 3.2.2 Hardware Interfaces 3.2.3 Software Interfaces 3.2.4 Communication Interfaces 3.3 Performance Requirements 3.4 Design Constraints 3.4.1 Standards Compliance 3.4.2 Hardware Limitations 3.5 Attributes 3.5.1 Security 3.5.2 Maintainability 3.6 Other Requirements 3.6.1 Database IEEE 830-1984

29. Non-830-Style Requirements User stories encourage the team to defer collecting details. An initial place-holding goal-level story ("A Recruiter can post a new job opening") can be written and then replaced with more detailed stories once it becomes important to have the details. This technique makes user stories perfect for time-constrained projects. A team can very quickly write a few dozen stories to give them an overall feel for the system. They can then plunge into the details on a few of the stories and can be coding much sooner than a team that feels compelled to complete an IEEE 830–style software requirements specification. Quote from "Advantages of User Stories for Requirements" By Mike Cohn http://www.awprofessional.com/articles/article.asp?p=342885&seqNum=3

30. Other Specification Techniques  Use Cases  Formal Specification Languages e.g. Petri Nets http://www.cs.indiana.edu/classes/p465/Lect/Images/petri-img-10.jpg

31. Requirements Engineering Tasks 1.Inception 2.Elicitation 3.Elaboration 4.Negotiation 5.Specification 6.Validation 7.Management 31

32. Next Classes  Risk Analysis and Management  Metrics  Managing the Testing Process