1. Identifying needs and establishing requirements Chapter 7b

2. Identifying needs and establishing requirements 7.1 Introduction 7.2 What, how, and why? What: To understand as much as possible about the users, tasks, and context in order to produce a stable set of requirements How: The more ways the better to a point Why: Requirements Engineering is the phase where failure most commonly occurs and is most costly 7.3 What are requirements? Different kinds of requirements 7.4 Data gathering techniques and guidelines 7.5 Data interpretation and analysis 7.6 Task description 7.6.1 Scenarios 7.6.2 Use cases 7.6.3 Essential use cases 7.7 Task analysis

3. Why is this important? Top 3 reasons why projects delivered late, over budget, with less functionality than planned, or cancelled: 3.

4. Why is this important? $$$ Cost to fix a requirements based problem

5. Different kinds of requirements Functional Non-functional Data Social –Physical Environment –Context of Use –Ethical, societal, privacy, security User –Computer literacy of user –Abilities of user –Frequency of use Usability –Easy to learn –Easy to remember –Pleasing to the eye

6. Data Gathering Techniques Interviews –Structured –Unstructured Questionnaires Focus Groups Naturalistic Observation Study Documentation Formal controlled studies

7. Some basic guidelines Focus on identifying the stakeholders’ needs Involve all the stakeholder groups Involve more than one representative from each stakeholder group Use a combination of data gathering techniques Support the process with props such as prototypes and task descriptions Run a pilot session

8. Software Engineering Process 1.Identify stakeholders and work together to negotiate product requirements 2.Build an analysis model 1.Data 2.Function 3.Behavior 3.Prototype areas of uncertainty 4.Develop a requirements specification document to guide design 5.Conduct a formal technical review

9. Dangers? 1.Customer has only a vague idea of what is required 2.Developer is willing to proceed with this vague idea on the assumption that we will fill in the details as we go 3.Customer keeps changing requirements

10. Dangers? Innovative Software Our new system is so wonderful that everyone will want to use it Who will use it? Build it and it will be useful to xyz How will it be useful? Good systems have often turned out to be useful in unexpected ways

12. Task Descriptions Scenarios Use Cases Essential Use Cases –Abstract away the details

13. Use Case Diagram

14. Scenario Use Case: Student Enrolls in Class 1.Jane Doe logs into Safari and identifies herself. 2.The computer gives a list of things that Jane can do to the system. 3.Jane asks for a list of sections in a course. 4.The computer shows Jane the sections she is interested in. 5.Jane selects one section to enroll in. 6.The computer records the enrollment and confirms the Jane is enrolled.