Chapter six

Gathering User Requirements

1
 Efficient Techniques for gathering
user requirements

2
 The first step to form a team is to identify project
stakeholders(any one who could material be affected by the
new system or the application which include:-)
-Customer of the system
-Any one which will be affected by the output the system produces
-Any one who will evaluate the system when it is delivered or
deployed
-Any internals or external users of the system whose needs must be
addressed/satisfied
-Any one who will operate or support the system once it’s in
production
- 3
 • They have bad experiences in the previous projects
• They directly jump to programming instead of spending more
time in requirement gathering
• They’ve their own better jobs
 The requirement team may include both active and supportive
members.
 Active members: - Full time requirement workers(Analysts)
- Key Subject Matter Experts(SMEs)
 Supportive members:
- Focused expertise who are available to your team as needed
- Actual users whom you can talk to or observe
4 or 5 active members are needed to ascertain the system
More than 5 is not good for managing
4
the system
 SME is a person who is responsible for providing pertinent
information about the problem/technical domain from personal
knowledge or research.
 Good SME have the following qualities
a. They know the business – understand one or more of the problem
domain
b. They think logically – able to describe about what they do
systematically.
As a rule of thumb, some one who finds computers easy to learn use is
most able to think logically.
c. They can communicate well – will be able to work in teams (Comm Skill)
d. They are willing to invest time in software development
e. Most SMEs come from user community
f. Good Subject Matter Expert(SME) are not narrowly focused - willing
to consider new approaches(Prioritize user needs)
5
Facilitator is some one who is responsible for planning,
running and managing modeling sessions.
Good Facilitator have the following qualities
•They’ve good meeting skills
•They understand the requirements modeling process
•They ask valid and intelligent questions – questions that
follow cause and effect issues
•Good Facilitators are made, not born!
Requirement Analyst
Requirement analyst is a person who is responsible for gathering or
elicitation documentation & requirement validation.

6
Brainstorming is a technique where group of people discuss a
certain topic (any thing that comes to their mind).
The goal of brainstorming is to generate and evaluate a large
number of solutions for a problem.
Brainstorming is usually done in face-to-face meeting but can be
also via E-Mail or Groupware.
The Rules of Brainstorming
a. All ideas are good – ideas are not judged by the group
b. All ideas are owned by the group not the individual
c. All ideas immediately become public property – Any body is
allowed to explain about it.
The facilitator leads the group through brainstorming
The facilitator starts by explaining the rules of brainstorming &
explain the issues to be discussed. 7
 The potential issues to discuss at requirement session
1. What is the system for?
2. What will they do with the system?
3. Why do we do this?
4. Why do we do this the way we do?
5. What business needs does this system support?
6. What do/will our customers want/demand from us?
7. How is business changing?
8. What is our competition doing? Why? How can do it better?
9. Do we even need to do this system?
10. If we were starting from the scratch? How would do this?
11. Just because we were successful in the past doing this, will we be successful
in the future?
12. Can we combine several jobs in to one? Do we want to?
13. Does the system support teamwork, or does it hinder it?
14. Do our users have the skills/education necessary to use this system? What
training will they need?
15. What are our organization’s strategic goals and objectives? Does this system
support them? 8

16. How can we do this faster, cheaper, and better?

 Use Case Modeling is applied to analyse the functional requirements of
the system.
 Functional requirements are functions/tasks that the system perform.
 It’s done in the early development of the system.
 It helps developers to understand the functional requirements of the
system.
 Users involve in the development process and finally come to
agreement.
 Use Case Modeling consists of Actors, Use Cases and Relationships
 Actor is external entity that interact or interface with the system.
 Use Cases represent a sequence of related actions initiated by actors.
 A Use Case is a methodology used in system analysis to identify, clarify
and organize system requirements.

9
 An actor is represented by stick man and name below
Actor

 A Use Case is represented by ellipse and name inside Use Case

Login

Search Item
Person

1. Preliminary Use Case: As you continue to model you may refactor the existing Use
Case, combine them, introduce new Use Case and remove the one that make no sense.
2. Customer actors may involve in many Use Cases
3. The diagram is too big. Should be drawn one by one.
4. Use Case should be functionally cohesive. It should provide one function to the user.
Example: Separate Use Cases exist for Login and Search Item which provides
10
meaningful function
5. Use Case may be temporally cohesive – should describe a service which
occur during contiguous period of time.
Example: Login occurs during short period of time may be few minutes
6. Every Actor is involved with at least one Use Case and every Use Case is
involved with at least one Actor
7. System boundary boxes are optional
Packages enable you to group similar model elements to simplify complex
diagrams. Example Use Case, Class Diagram, Component Diagram

Enrol in Teach
Course Course

Drop Evaluate
Student Course Instructor
Student

11
 Enrol in Teach
Course Course

Drop Evaluate
Course Student

Attend Compute
Student Course Grade Instructor

Drop Out Submit

of School Grade

Graduate
from School
Registrar
Produce
Grade
Report

Sample Use Case Diagram for University

12
 Asking SMEs the following questions from the point of view of the
Actors
1. What are functions that the users in this role wants a system to
accomplish?
2. To fulfil this role what do users need to be able to do?
3. What are the main tasks of users in this role?
4. What are the operations that create, read/search,
update/modify, delete/remove the information?
5. What do users in this role need to be informed by the system?
6. What do users in this role need to inform the system?

13
 Actor is any one/thing that interface or interact with the system.
 To determine who are the actors, the following questions are helpful
1. Who is the main Customer of the system?
2. Who gets/obtains the information from this system?
3. Who provides information to the system?
4. Who operates the system?
5. Who starts up, uses and shuts down the system?
6. who installs, maintains the system?
7. What other systems interacts with the system?
8. Does any thing happen automatically at present time?
9. Who will supply, use, remove information from the system?
10. Where does the system get information?
14
 An essential User Interface(UI) Models represent the UI requirements
of for the software in the technology independent manner.
 UI Prototyping tools including white board, flip chart, sticky notes.
 The Major UI elements – Major UI elements such as potential user
screens, HTML pages can be modelled using flip chart paper. Each flip
chart paper is given a name. The appropriate minor UI elements are
added to it as needed.
 The Minor UI elements such as input, fields, lists and containers(Minor
UI elements that aggregate other minor UI elements)

15
 Domain Modelling with Class Responsibility Collaborator(CRC)
 Classes have responsibilities(tasks) to be performed and they
Collaborate each other to get the job done.
 Domain Modelling means the task of discovering the class that
represent things and concepts pertinent to the problem space.
 Example: The Domain Model for University include concepts like
Student, Instructor, Course, Transcript, Registrar etc.
 Nouns and Phrases in use case model are good candidates for
concepts that should be included in the domain model.
 CRC Model is a collection of standard index card that have been
divided in to three parts: Class, Responsibility, Collaborator
 A Class is a collection of similar objects
 Responsibility is something a class knows or does.
 Collaborator is another class that a class interacts with to fulfill its
responsibilities. 16
 Class Name

Responsibilities Collaborators

 CRC Models are effective tools for working with users and SMEs
for requirement gathering where as UML Class Diagrams are
better choice for Domain Modeling during analysis.
Student

Student ID Course
Student Name Seminar
Enrol in Course
Drop Course
Enrol in Seminar
Drop Seminar

 Class name should be singular noun or non phrase.

17