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
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
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
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
Different Kinds of Requirements
• Functional Requirements• Data Requirements• Environmental Requirements
– Physical environment – Social environment– Organizational environment– Technical environment
• User requirements• Usability requirements
Data Gathering
Purpose – collect sufficient, relevant and appropriate data so that a set of stable requirements can be produced
Data Gathering Techniques
• Questionnaires
• Interviews
• Focus groups
• Workshops
• Naturalistic Observation
• Studying Documentation
Questionnaires
• Series of questions designed to elicit specific information
• Usually not interactive
• Yes/No or short answer
• Good for large geographically diverse group
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
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
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
Studying Documentation
• Looking through procedures and rules written down in manuals
• Shouldn’t be used by itself
Choosing between techniques
• Initially interviews are usually best
• Resources available
• Location and accessibility of stakeholders
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)
Data interpretation and analysis
• Start immediately after gathering session
• Begin structuring and recording descriptions of requirements
• Maintain traceability
• Analysis is iterative
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
Calendar Program1. The user chooses the option to arrange a meeting2. The system prompts user for the names of attendees3. The user types in a list of names4. The system checks that the list is valid5. The system prompts the user for meeting constraints
If List is invalida. The system displays an error messageb. The system returns to step 2
6. The user types in meeting constraints7. The system searches the calendars for a date that satisfies the constraints8. The system displays a list of potential dates
If no potential dates are founda. The system displays a suitable messageb. The system returns to step 5
9. The user chooses one of the dates10. The system writes the meeting into the calendar11. The system emails all the meeting participants informing them of the appointment
Essential Use Cases
• Represent abstraction from scenarios, and try to avoid the assumptions of a traditional use case.
• Associated with user roles
Users Intention System ResponsibilityArrange a meeting Request meeting attendees and
constraints
Identify meeting attendees and constrains Suggest potential Dates
Choose preferred date Book meeting
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?