Identifying Needs and Establishing Requirements

1
Identifying Needs and Establishing Requirements

• Presenters
• Veronica Gasca
• Jennifer Rhough

2
Introduction The whys

• Users needs, requirements, aspirations, and
  expectations should be taken into consideration
• Rewards if established correctly
• Disadvantages if wrong or not done

3
Requirements

• Make it as clear, specific, and unambiguous as
  possible
• Abstract
• Web site should appeal to teenage girls
• Precise
• Search time for a query is less than 3 seconds
• Issue an auditory and visual alert when a
  download fails

4
Types of Requirements

• Functional
• Data (volatility, size, persistence, accuracy,
  value)
• User
• Usability
• Environment
• Physical
• Social
• Organizational
• Technical

5
Data Gathering Techniques

• Questionnaires
• Interviews
• Focus Groups/Workshops

• Naturalistic Observation
• Studying Documentation

6
Technique 1

• Questionnaires
• Elicit specific information
• Needs to be written well
• Good for large groups of people, spread
  geographically
• Often used in conjunction with other techniques

7
Technique 2

• Interviews
• In-person or phone
• Structured or Unstructured
• Good at getting people to explore issues
• More enjoyable
• Time consuming
• Not good for large groups of people

8
Technique 3

• Focus Groups/Workshops
• Consensus view
• Highlights conflicts/disagreements
• Structured or facilitator mediated
• Strong personalities can dominate discussions

9
Technique 4

• Naturalistic Observation
• Shadow day to day tasks
• More accurate, detailed descriptions
• Vary from outside to participant observation
• Time consuming
• Generates large amounts of data

10
Technique 5

• Studying Documentation
• Background legislation
• Previous software

11
Which one?

• Time
• Experience of analyst
• Nature of task
• Other resource availability
• stakeholders

12
Some Tips

• Involve all stakeholders
• Use combo of techniques
• Obtain diversity

• Props/prototypes
• Run pilot data gathering sessions

13
Data Interpretation and Analysis

• Interpretation Goal to structure and record
  descriptions of requirements.
• Start interpretation as soon after the gathering
  session as possible.
• Discuss the findings with others.

14
Requirements template (Volere, Atlantic Systems
Guild)

• Requirement Unique Id Requirement Type
  Template section
• Event/use case Origin of the requirement
•  
• Description A one-sentence statement of the
  intention of the requirement.
• Rationale Why is the requirement considered
  important or necessary?
• Source Who raised this requirement?
• Fit Criterion A quantification of the
  requirement used to determine whether the
  solution meets the requirement.

15
Techniques to understand users goals and tasks

• Task Description
• Task Analysis

Scenarios Use Cases Essential Use Cases
16
Scenarios

• Scenario Informal narrative description of
  human activities or tasks in a story that allows
  exploration and discussion of contexts, needs,
  and requirements.
• Concentrate on the human activity rather than
  interaction with technology.

17
Sample scenario

• Mary needs to send some documents to her boss,
  who is currently in France.
• She scans the documents and places the
  electronic copies into her working directory and
  then opens her eMail application to send the
  information through electronic Mail. She creates
  a new memo and selects.

18
Advantages of using scenarios

• Scenarios help explain or discuss some aspect of
  the users goals.
• They can be used to imagine potential users of a
  device as well as to capture existing behavior.

• Capturing scenarios of existing behavior helps in
  determining new scenarios and hence gathering
  data for new requirements.

19
Use cases

• Also focus on user goals, but the emphasis here
  is on a user-system interaction rather than the
  users task itself.
• A use case is associated with an actor, and it is
  the actors goal in using the system that the use
  case wants to capture.

20
Creating use cases

• The main use case describes what is called the
  normal course through the use case
• To develop a use case
• First, identify the actors (people or systems
  that will be interacting with the system under
  development).
• Examine these actors and identify their goals or
  goals in using the system.
• Each of these will be a use case.

21
Sample use case

• The user chooses the option to arrange a meeting.
• The system prompts user for the names of
  attendees.
• The user types in a list of names.
• The system checks that the list is valid.
• The system prompts the user for meeting
  constraints.
• The user types in meeting constraints.
• Alternative course
• 5. If the list of people is invalid, display an
  error message and return to step 2.

22
Use case diagram
Arrange a meeting
23
Essential use cases

• They represent abstractions from scenarios, and
  consist of
• Name to express overall user intention
• Stepped description of user actions
• Stepped description of system responsibility
• Instead of actors, essential use cases are
  associated with user roles.

24
Sample essential use case

• User Intention System responsibility
• Arrange a meeting
• request meeting attendees
• Identify meeting attendees
• Identify meeting constraints
• suggest potential dates

25
Task analysis

• Its used to analyze the underlying rationale and
  purpose of what people are doing.
• The most widely used version is known as HTA
  (Hierarchical Task Analysis)
• HTA involves breaking a task down into subtasks
  and then
• Into sub-subtasks
• And so on.
• The starting point is a user goal

26
Sample task analysis

• 0. In order to arrange a meeting
• 1. compile a list of meeting attendees
• 2. compile a list of meeting constraints
• 3. find a suitable date
• 3.1 identify potential dates from departmental
  calendar
• 3.2 identify potential dates from each
  individuals calendar
• 3.3
• 4. enter meeting into calendars

27
For more information

• Interaction Design (Preece, Rogers, Sharp)
• Chapter 7, Identifying needs and establishing
  requirements.