1. Identifying Needs and Establishing Requirements John Thiesfeld Jeff Morton Josh Edwards

2. Chapter Goals Describe different kinds of requirements. Enable you to identify examples of different kinds of requirements from a simple description. Explain how different data­gathering techniques may be used, and enable you to choose among them for a simple description. Enable you to develop a "scenario,'' a "use case,'' and an "essential use case'' from a simple description. Enable you to perform hierarchical task analysis on a simple description

3. Two Aims Identifying Needs Produce a set of stable requirements

4. How to get requirements Gather Data Interpret and Analyze Capture Findings

5. Why Bother? Requirements issues lead to project failures –Requirements definition –Unclear objectives and requirements Project needs to support stakeholders Stakeholders don’t know exactly what they want

6. Requirements? A requirements is a statement about an intended product that specifies what it should do or how it should perform. Specific Unambiguous Clear as possible

7. Different Kinds of Requirements Traditional types of Requirements Functional – what the system should do Non-Functional – what constraints there are on the system and its development

8. Different Kinds of Requirements Functional Requirements Data Requirements Environmental Requirements –Physical environment –Social environment –Organizational environment –Technical environment User requirements Usability requirements

9. Data Gathering Purpose – collect sufficient, relevant and appropriate data so that a set of stable requirements can be produced

10. Data Gathering Techniques Questionnaires Interviews Focus groups Workshops Naturalistic Observation Studying Documentation

11. Questionnaires Series of questions designed to elicit specific information Usually not interactive Yes/No or short answer Good for large geographically diverse group

12. Interviews Interviews involve asking someone a set of questions, usually face to face Interviewees like to use artifacts to help explain to interviewer Structured/Unstructured/Semi-Structured Time consuming Hard to reach a broad group

13. Focus Groups and Workshops A group of stakeholders discuss issues and requirements together. Facilitator guides group. Easier to find areas of conflict and disagreement A small group can dominate discussion

14. Naturalistic Observation Observing a person do the task you are trying to build your product around. Humans might have difficulty explaining what they do Good for understanding the nature of the tasks and the context in which they are performed

15. Studying Documentation Looking through procedures and rules written down in manuals Shouldn’t be used by itself

16. Choosing between techniques Initially interviews are usually best Resources available Location and accessibility of stakeholders

17. Guidelines Focus on identifying the stakeholders’ needs Involve all the stakeholders Involve multiple representatives from each group Use a combination of data gathering techniques Use props to support data-gathering sessions Run a pilot session Know what kind of information you want to gather How data is recorded is important (written reports/video recording)

18. Data interpretation and analysis Start immediately after gathering session Begin structuring and recording descriptions of requirements Maintain traceability Analysis is iterative

19. Task Description Scenarios Use Cases Essential Use Cases

20. Scenarios Describes human activities or tasks in a story that allows exploration and discussion of contexts, needs and requirements Does not describe the use of software or other technological support

21. Use Cases Focus on user-system interaction Capture actor’s goal in using system

22. Calendar Program 1.The user chooses the option to arrange a meeting 2.The system prompts user for the names of attendees 3.The user types in a list of names 4.The system checks that the list is valid 5.The system prompts the user for meeting constraints If List is invalid a.The system displays an error message b.The system returns to step 2 6.The user types in meeting constraints 7.The system searches the calendars for a date that satisfies the constraints 8.The system displays a list of potential dates If no potential dates are found a.The system displays a suitable message b.The system returns to step 5 9.The user chooses one of the dates 10.The system writes the meeting into the calendar 11.The system emails all the meeting participants informing them of the appointment

23. Essential Use Cases Represent abstraction from scenarios, and try to avoid the assumptions of a traditional use case. Associated with user roles Users IntentionSystem Responsibility Arrange a meetingRequest meeting attendees and constraints Identify meeting attendees and constrainsSuggest potential Dates Choose preferred dateBook meeting

24. Task Analysis Used mainly to investigate an existing situation, not to envision new systems or devices. What people are trying to achieve? Why are they trying to achieve it? How are they going about it?

25. Hierarchical Task Analysis Break down tasks Group together as plans that specify how a task could be performed Focus on the physical and observable actions Start at the user goal