Chapter 7 Identifying Needs and Establishing Requirements

1
Chapter 7 Identifying Needs and Establishing
Requirements

• By
• Wang, Miao
• Fan, Xiaona

2
Introduction

• Before establishing requirements, we need to
  fully understand
• Users and user needs
• Users capability
• Current task and goals
• Condition under which the product will be used
• Product performance constrains
• Nature of problem space

3
Definition of Requirements

• Requirement is
• A statement about an intended product that
  specified what it should do or how it should
  perform.
• Requirements should be
• Specific
• Unambiguous
• Clear
• Fit criterion quantifiable and measurable

4
Intertwined Activities
Requirements Activity
Design Activity
Evaluation Activity
5
Goals of Establishing Requirements

• Identify/ invent needs understand user, their
  work, context of that work
• Produce a set of stable requirements to move
  forward to design

6
Sequential Activities of Establishing Requirements

• Gather data
• Interpreting data
• Analyze data
• End goal Stable Requirements

7
Importance of Getting It Right

• One major cause of IT project failure -unclear
  objective and requirements
• Product should support stakeholders needs
• Product be ignored, despised
• Cause grief, anxiety, frustration
• Lose revenue, customer confidence

8
Different Kinds of Requirements (1)

• Functional requirements
• what the product/system should do
• Data requirements
• the type, volatility, size/ amount of the
  required data
• Environmental requirements
• Physical environment noise, heating, lighting
• Social environment collaboration and
  coordination
• Organizational environment training, job
  design, politics, roles
• Technical environment software compatibility

9
Different Kinds of Requirements (2)

• User requirements
• characters of the intended users group beginning
  vs. advanced user.
• User profile affects the way interaction is
  designed.
• Usability requirements
• Capture the usability goals and associate
  measures
• Specific measures of the usability goals are
  established and agreed early in the development
  process
• then revisited and used to track progress

10
Data Gathering

• Goals of data gathering
• Collect efficient relevant and appropriate data
  to produce stable requirements
• Expand clarify and confirm the initial
  requirements
• Data gathering techniques
• Questionnaires
• Interviews
• Focus groups/ workshops
• Observation
• Study documentation

11
Data Gathering Techniques (1)
12
Data Gathering Techniques (2)

• Questionnaires
• Admin at a distance
• Get answers for a specific question from a large
  group of people
• No geographical location limitation
• Design is crucial and low response rate
• Interviews
• Exploring issues and encourage response
• Time consuming, and not efficient to meet with
  all the people

13
Data Gathering Techniques (3)

• Focus groups/ workshops
• Good at gaining a consensus view point
• Highlight areas of conflict
• Helps users to meet designers and each other to
  express their view in public.
• Observation
• Spending time with user in the natural context of
  activity.
• Observe, take notes ask questions
• Gain insights, and overcome the limitation of
  other techniques

14
Data Gathering Techniques (4)

• Users cant explain accurately
• Fill in details not provided by other
• Good at understand the nature of the task and
  the context
• Time consuming and huge amount of data
• Study documentation
• Study the written down procedures and rules in
  manuals
• Study user dairies/ job logs
• Good for understand legislation and background
  info does not take time form users.

15
Issues Influence Choice of Techniques (1)

• The nature of techniques Olson and Moran (1996)
• The amount of time
• The level of detail
• The risk with the finding
• The scales of the task Olson and Moran (1996)
• Sequential steps vs. over-lapping steps
• High information content vs. low information
  content

16
Issues Influence Choice of Techniques (2)

• The knowledge required of the analyst
• Layman vs. practitioner
• The knowledge about basic cognitive processes
  analyst must have
• The point in development reached
• The available resource (money, time, people)
• Location and accessibility of stakeholders

17
Data Gathering Guidelines (1)

• Focus on identifying users needs
• Involve all the stakeholder groups
• Involve only one representative from each
  stakeholder group is NOT enough
• Combination of data gathering techniques 

18
Data Gathering Guidelines (2)

• Support the data gathering sessions with suitable
  props (task description to be reused.) 
• Run a pilot session  
• Make compromises because of pragmatic constraints
  (resource) 
• How to record the data during the face to face
  data gathering sessions

19
7.5 Data Interpretation and Analysis

• When?
• As soon after the gathering session
• Aim
• begin structuring and recording descriptions of
  the requirements
• Approaches
• Initial interpretation template
• More focused analysis of data

20
Example of Interpretation Template(The Volere
Shell for Requirements)

• 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?

21
Example of Interpretation Template(The Volere
Shell for Requirements) Continued

• Fit Criterion A quantification of the
  requirement used to determine whether the
  solution meets the requirement.
• Customer Satisfaction Measures the desire to
  have the requirement implemented
• Customer Dissatisfaction Unhappiness if it is
  not implemented
• Dependencies Other requirements with a change
  effect

22
Kinds of More Focused Analysis of Data

• Data-flow diagrams
• State charts
• Work-flow chart
• Class diagrams
• Scenarios
• Use cases
• Essential use cases
• Task analysis

23
7.6 Task Description

• Techniques of Task description
• Scenarios
• Use cases
• Essential use cases
• Relationships between different Techniques

24
7.6.1 Scenarios

• Definition
• Advantages
• Easy to understand by the stakeholders
• Concentrate on the human activity
• Good start point
• Characteristics
• Personalized account, offering only one
  perspective
• The level of detail present in a scenario varies
• Human activity may not be preserved in the future

25
Example of Scenarios(using library catalogs)

• I want to find a book by Charles Dickens. He was
  a British Writer. I remember the title is
  something like Christmas Carol, but not very
  sure if the author name and title are accurate.
  So I go to the website of library catalog. There
  are different kinds of Catalogs Author,
  Title/Journal Title, Keyword, Author/Title,
  Subject Heading, etc. Since I have unclear ideas
  of author and title, so I click author/title
  catalog. On the webpage of Author/Title Search,
  I type Dickens into the Author box, and
  Christmas Carol into Title box. Then the search
  result comes out. There are several editions of
  A Christmas Carol written by Charles Dickens. I
  choose my favorite edition, and get the call No.
  and location of the book.

26
7.6.2 Use Cases

• Characteristics
• emphasize on user-system interaction, stress is
  still very much on the users perspective, not
  the systems
• Associate with an actor (user)
• Normal course alternative course

27
Example of Use Case

• The user go to the catalog website
• The system prompts user for all kinds of
  catalogue
• The user chooses the Author/Title catalog
• The system prompts the user for Author/Title
  Catalog
• The user types the author name and book title in
  the appropriate boxes
• The system search the book

28
Example of Use Case (continued)

• 7. The system displays a list of potential books.
• 8.The user chooses one of the book
• 9.The system displays the detail information of
  the book
• 10.The user get the call No. and location of the
  book

29
Example of Use Case (continued)

• 7. If no book is matched the search criterion,
• 7.1 The system provide no match book
  information
• 7.2 The system returns to step2

30
Graphical Representation of Use Case
Locate book
Collect books
Update catalog
Use case diagram for the library automatic system
31
7.6.3 Essential Use Cases

• Characteristics
• abstract from scenarios, and try to avoid the
  assumptions of a traditional use case
• More general
• are associated with user roles
• Difference between actor and user roles
• Compositions
• A name which expresses the overall user intention
• A stepped description of user actions
• A stepped description of system responsibility

32
Example of an essential use case
User Intention System Responsibility
Request appropriate details
Offer known details
Offer search results
Note search results
Quit system
close
Note that it does not specify search options or details of how to initiate the search Note that it does not specify search options or details of how to initiate the search
33
7.7 Task Analysis

• Purpose Analyze the underlying rationale and
  purpose of what people are doing
• Definition An umbrella term that covers
  techniques for investigating cognitive processes
  and physical actions, at a high level of
  abstraction and in minute detail
• Widely used version
• HTA Hierarchical Task Analysis
• GOMS goals, operations, methods, and selection
  rules

34
7.7.1 Hierarchical Task Analysis

• How?
• Top-down approach
• Characteristics
• Focus on physical and observable actions
• Examples

35
A Graphical Representation of the Task Analysis
for Borrowing a Book
36
An HTA for borrowing a book from the library

• 0. In order to borrow a book from the library
• 1. Go to the library
• 2. Find the required book
• 2.1 access library catalog
• 2.2 access the search screen
• 2.3 enter search criteria
• 2.4 identify required book
• 2.5 note location
• 3. Go to correct shelf and retrieve book