Chapter Four
Gathering User Requirements
Contents
Putting together requirements gathering team
Fundamental requirements gathering techniques
Essential Use Case Modeling
Essential User Interface Prototyping
Domain modeling with class responsibility collaborator (CRC) cards
Developing a supplementary Specification and Identifying Change
Cases
Ensuring Your Requirements Are correct: Requirement Validation
Techniques
Testing Early and Often
Use Case Scenario Testing
Putting together requirements gathering team
• Your requirement team will be composed of SME. Who will provide you
with detail information.
• These people are responsible for:
Requirement gathering
Documenting
Validation
• Formal requirement team often includes:
Facilitator: some one responsible for managing modelling session
Scriber: responsible for recording information as it is identified
Con’d
• The first step to put together a requirement team is to identify your project
stakeholders.
• Project stockholder are any one who could be materially affected by the
implementation of a new system or application.
• Project stockholder includes:
Direct user of the system
The customer /payer of the system
Any one who will affected by the output of the system products.
Any one who will evaluated
Any internal or external user
Any who will operate and support the system once it is in production
Con’d
• The Next step to put together a requirement team is to identify who will be on your
requirements modeling team.
You may want to distinguish b/n active members of your team such as full time
requirement analysis and key SME and supporting members.
• Most software project focus one of two problems when defining requirement modeling
team.
1. There are too many peoples who want to be member of team
2. They have too few people
In general: Putting together a requirement team has to be:
1. Choosing Good subject mater experts:
Good SME have the following qualities:
To know the business: they understand one or more aspect of the business.
Con’d
They think logically: not only the SME to understand the business but also able to think
logically.
They can communicate well : will be working as a team to develop the requirement
modeling . So, they must have good communication skill.
They are willing to invest their time in software development
Most, but not all ,of the SME come from the user community : you must have real user of
the system who know the business
2. Choosing Good facilitator : Good facilitator have the following quality
They have good meeting skills
They understand the requirement modeling process: understand the entire software
process, principally the portion of the process(in this case requirement gathering)
They ask valid, Intelligent questions
Con’d
3. Choosing Good Scriber:
Good scriber have the following quality:
They listen well: they listen and record business logics and rules. therefore,
they need good listening skills
They have good written communication skills
They have good oral communication skills
They have an ear for business logic
Fundamental requirements gathering techniques
1) Interviewing
Interview is common technique used for gather data or information.
Face-to-face contact with users through individual interviews is the primary source of
requirements and an important way to gather and validate their requirements.
The main benefit of conducting Interviews
To broaden your understanding of the application
To determine who to invite to requirements modeling sessions
To identify new or existing requirements directly for your application
8
Con’d
Pointers for Interviewing
Send ahead agenda
Verify the Schedule
Thank the person
Let the person know his input is important
Summarize issues
Ask for missing information
Don’t Shut down users – “ I have already heard this before
End by summarizing
Thank the person again
9
Listen than talking
Con’d
2) Observation
A habit to spend a day or two with direct end users simply to sit and observe
what they do.
One of the problems with interviewing people is they leave out important details,
details that you may not know to ask about because they know their jobs so well.
Another advantage of observing your users is you see the tools they use to do
their jobs.
10
Con’d
3) Brainstorming
Is group discussion in which members shares their ideas and find out the solution
of specific problem.
Brainstorming is a short group session where all participants are allowed to say
whatever they feel is important to the topic of discussion.
Brainstorming generates or gathers new ideas rather than its quality.
This technique is more popular because of it is a group activity all the members
share own idea.
It is more productive for the reason that groups. When members generate idea it
is more value able as of group product and members enjoy the group activity.
11
Con’d
Potential Issues to discuss in Brainstorming
Who is this system for?
What will they do with the system?
Why do we do this?
Why do we do this the way we do?
What business needs does this system support?
What do/will our customers want/demand from us?
How is the business changing
What is our competition doing? Why? And how can we do it better?
Do we need to do this?
Is the work being performed where it makes most sense?
How will peoples jobs be affected? How
12 can we do this BFC?
Essential Use Case Modeling
To model behavioral requirements
It describes the goals of the users, the interactions between the users and the
system, and the required behavior of the system in satisfying these goals.
It is one of the two basic flavors
Essential Use Case: Business/Abstract Use Case
System Use Case: Concrete/Detailed Use Case
Intended to capture the essence of problems through technology free, idealized and
abstract descriptions
13
Use Case Diagram for a Simple University
14
Drawing Use Case Diagrams
Use cases:
A use case describes a sequence of actions that provide something of measurable value to
an actor. Drawn as a horizontal ellipse.
Actors:
An actor is a person, organization, or external system that plays a role in one or more
interactions with your system. Actors are drawn as stick figures.
Associations:
Associations between actors and use cases are indicated in use case diagrams by solid
lines.
System boundary boxes:
You can draw a rectangle around the use cases
to indicate the scope of your system.
Anything within the box represents functionality
15 that is in scope, and anything outside
the box is not.
Identifying Actors
Anything or anyone that interfaces with your system
This may include people, external systems, and other organizations
Questions help to find actors
Customer?
Who obtains information?
Who provides information?
Who installs the system?
Who operates the system?
Who shuts down the system?
What other system interacts with our system?
Who will supply, use or remove information?
Where does the system get information?
Things to consider
Actors should model roles and not the physical, real world people.
16
Describe an actor by actually reflecting its role.
Document Use Cases
Sections
Name – Name of the use case
Description – summary of a use case
Actors (optional) – associated with the use case
Use Case Id– A unique number for every case
Precondition – conditions that must be met
Post condition – effect of a use case action
Extension Points (optional) – covered later
Included Use Cases (optional) – covered later
Basic Course of Action – logic followed
Alternate Course of Action – Infrequently used path
17
Identifying Use Cases
Answer the following questions
What are users trying to accomplish
To fulfill this role, what do users need to be able to do?
What are the main tasks of users in this role?
What information do users in this role need to examine, create or change?
What do users in this role need to be informed of by the system and inform
the system about?
18
10 Things to know about Use Cases
As you continue to model, you will re factor existing use cases, break them
apart, combine them, introduce new use cases, and remove ones that do not make
sense.
No time ordering is indicated between use cases
Customer actors are usually involved in may use cases
Use Cases are not functions
No arrowheads are on the associations
The diagram is too big not prefer.
Should be functionally cohesive
Should be temporally cohesive
Every actor is involved with at least one-use case and vice versa
I chose not to include a system boundary19
box
Essential Use Case Description Example
Name: Enrol in Seminar
Description: Enrol an existing student in a seminar for which he/she is eligible
Preconditions: The Student is registered at the university
Post conditions: The Student will be enrolled in the course he/she wants if she is
eligible and room is available
Basic course of Action:
1.A Students wants to enroll in a seminar
[Link] Student submits his/her name and student number to the registrar
[Link] registrar verifies the student is eligible to enroll in semesters at the
university according to some rule
[Link] student indicates, from the list of available seminars, the seminar in which
he/she wants to enroll 20
Cont’d
5. The registrar validates the student is eligible to enroll in the semester according
to the business rule
6. The registrar validates the semester fits into the existing schedule of the student
7. The registrar calculates the fees for the seminar,
8. The registrar informs the student of the fees
9. The registrar verifies the student still wants to enroll in the seminar
10. The student indicates he wants to enroll in the seminar
[Link] registrar enrolls the student in the seminar
12. The registrar adds the appropriate fees to the student's bill
13. The registrar provides the student with a confirmation that he is enrolled
14. The use case ends
21
Alternate Course of Action
Infrequently used path of logic in a use case
Exception or error condition that must be handled
Style issues
Includes the descriptions of actions that must be met to invoke the
alternate course
Identification and numbering scheme is used
Each step starts with the letter of the alternate course, followed by the
number of the step in the basic course of the use case it replaces
The last step in each alternate course of should indicate either that the use
case ends or goes to the last step of the Basic Course of Action
22
Example of Alternate Courses of Actions
Alternate course A: The student is Not Eligible to Enrol in Seminars
A.3. The registrar determines that student is not Eligible to Enrol in Seminar
A.4 The registrar informs the student she/he is not eligible to enrol
A.5 The use case ends
Alternate Course B: The Student Does Not Have the Prerequisites
B.5 The registrar determines the student is not eligible to enrol in the seminar she choose
B.6 The registrar informs the student she does not have the prerequisite
B7. The registrar informs the student of the prerequisites she needs
B8. The use case continues at Step 4 in basic course of action
Alternate Course C: The student decides not to enrol in an available seminar
C4. The student views the list of seminars and does not see one in which she wants to enrol
C5. The use case ends
23
Exercise 1.
Select one system as your needs
Name the Actors for your system
Identify use cases
Draw use cases
Describe the use cases
24
Essential User Interface Prototyping
Place where user directly interacts with systems
It represents the general ideas behind the UI, but not the exact details
Represents user interface requirements in a technology-independent manner
Beginning point of the user interface prototype for your system
25
Differentiating facts about essential UI prototyping
Focus on your users and their usage of the system, not system features
Simple tools including whiteboards, flip chart paper and sticky notes
Don’t focus on the design
26
Tasks in Essential UI Prototyping
Explore system usage
Use white boards to discuss initial drawings
Work iteratively
Model major UI elements – flip chart paper
Potential screens and reports
Model minor UI elements (input fields, lists and containers) – sticky notes
Explore the usability of your UI
Learnable, increase user productivity, easy to remember, supportable
Explore the relationship between UI elements
User interface flow diagramming
27
Example for essential UI
Student Help
Number
Course Details Requester
Student
Name
Course Seminar Seminar
Display Number Location Availability
Requester
Course
Course Searcher Name
Enrollment
Requester
Course
Number Course
Description
Course
Name
Search Details Professor
Requester Requester
Prototype for a Student Transcript
Student Information
Student Number
Student
Student Phone Number Student Full Name
Address
Student Email Period Student Status Payment Status
Amount Owed
Seminars the student has taken during period of the
transcript
Informational Message Footer Information
29
29
Ensuring System Usability
Five factors affect usability
Access : A system should be usable with out help from a person
Efficacy: System not interfere with or impede use by a skilled worker
Progression: facilitating advancement in knowledge, skill and facility
Support: easy, simple, fast and fun
Context : Real condition and actual environment
Usability is important because
By focusing on use and usability your system can be simpler, smaller and
less expensive
Best systems give pleasure and satisfaction
Unusable systems lead to request for change
User are less patient with poorly developed applications
30
User Interface Flow Diagramming
Helpful to see the bigger picture
High level interaction between the UI elements of you application
Also called windows navigation diagrams and context navigation maps
Use notations that is a combination of the notation for UML activity diagram
and UML collaboration diagram
Used for one of the two purposes
Model the interactions that users have with your software, as defined in a
single use case.
Gain a high level overview of the UI of your application.
Derived from your use cases
Gain an understanding of how the system is expected to work
31
Example
: Main Menu
Use enrollment Use Transcript
requester Requester
:Enroll in :Obtain Use
Transcript :Transcript
Seminar Transcript
Requester
Use Professor Use Prerequisite
Information Details
Requester Requester
Use
:Professor Seminar :Seminar
Information Informatio Information
n
Domain Modeling with Class Responsibility Collaborator (CRC) Cards
CRC card are well suited for domain modeling during requirement gathering
Fundamental techniques employed for design in the eXtreme programming (XP) software
process.
Extreme Programming (XP) is an agile software development methodology that
emphasizes frequent releases, customer collaboration, and a set of specific practices to
produce high-quality software quickly and adapt to changing requirements.
Class-Responsibility-Collaborator cards also known as CRC cards are a useful tool for
organizing classes during analysis and design of a system
A CRC card is a physical card representing a single class
Each cards lists the class name, attributes and method (its responsibilities) and class
associations (collaborations)
33
Layout of a CRC card
CLASS NAME
Responsibilities Collaborators
CLASS
Represents a collection of similar objects like Person, Place, Thing, Event or
Concept
Eg. University System
Students, professors, seminars
Singular noun or singular noun phrase
Class names should also be simple
35
Responsibility
Anything a class knows or does
Eg.
Students have names, addresses and phone numbers. (KNOWS)
Students also enroll in seminars, drop seminars and request transcripts
(DOES)
Responsibilities are shown on the left hand column of a CRC card
36
Collaboration
It is another class that a class interacts with to fulfills its responsibility
The collaborators of a class are shown in the right-hand column of a CRC card.
Eg. The card “Student” requests an indication from the card “Course”
A request for information
A request to do something
37
STUDENT
Student Number COURSE
Name
Address
Phone Number
Enroll in Course
Drop a Course
Request Grade
CRC Model
The collection of these CRC cards is the CRC Model
Using CRC cards is a straight forward addition to object-oriented analysis and
design:
Identify the classes
List responsibilities
List collaborators
CRC cards can be used during analysis and design while classes are being
discovered in order to keep track of them.
39
Simple Inventory Control System
40
40
Steps in Domain Modeling by CRC cards
Prepare to CRC Model
Put together a modeling group of SMEs
Brainstorm
Explain the CRC modeling technique
Iteratively Model CRC
Find classes
Find responsibilities
Define collaborators
Define use cases
Move the cards around
Prototype 41
Finding Classes
Actors are potential classes
Identify the customer
Concepts and Events are potential classes
Major UI elements are potential classes
Look for three to five main classes right away
When you think you have identified a class, create a new card for it
immediately
42
The three types of classes
[Link] Classes: actors that appear in your use case
People, external system or organization
[Link] Classes: places, things, concepts, and events that describe what the
business is all about
Concept Course
Event Registration
Place Room
[Link] Classes: screens, menus, and reports
The Major UI elements
Eg. Student editing screen, registration page, student transcript
43
Finding Responsibilities
Ask yourself what a class does
Actor Class – Identify the way in which the actor interacts with your system
UI Class – accept input from users, retrieve business objects, enable users to
manipulate the business objects, support creation, update, deletion, and saving
of business objects into the system
Business Class – derived from UI classes or other business classes (remember
the context of your domain)
Ask yourself what information you need to record about a class
Actor Class – don’t need to identify information they know about themselves
because they are represented by their corresponding Business Class
UI Class – prototype describes all
44
Defining Collaborators
Collaboration must occur
when a class needs information it doesn’t have
When a class needs to modify information it doesn’t have because any given
classes can update only the information it knows
Things to consider
There will always be at least one initiator of any given collaboration
Sometimes the collaborator does the bulk of the work
New responsibilities may be created to fulfill the collaboration
45
Con’d
Student Enroll in course <<UI>>
Name
Address
Phone number
Email address Enrollment **See the prototype**
Enrollment
Student number
Average Mark
Record Record
Validate Info
Provide list of course
Advantages and Disadvantages of CRC Modeling
User participation in system
dev’t is increased
• Threatening to
CRC modeling improves
communications between users systems developers
and developers • Limited
CRC cards are simple and
inexpensive • You still need to do
CRC modeling is nonthreatening to class modeling
users • You need management
CRC cards are quick and portable
support
CRC modeling goes hand in hand
with essential use case modeling
and essential UI prototyping
Gives you good overview of a
system
Leads directly into class modeling
Enables you to deal with system 47
complexity one class at a time
Developing a supplementary Specification
A supplementary specification is a Rational Unified Process (RUP)
document that contains requirements not contained directly in your use
cases.
The Rational Unified Process (RUP) is an iterative software development
process framework designed to be adaptable and tailored to specific project
needs.
This often includes business rules, technical requirements, and constraints.
The best way to think of a supplementary specification is that it is a
container into which you place other requirements.
48
Con’d
1) Business Rules
A business rule defines or constrains one aspect of your business that is intended to assert
business structure or influence the behavior of your business.
Business rules often focus on access control issues; for example, professors are allowed
to input and modify the marks of the students taking the seminars they instruct, but not the
marks of students in other seminars.
Business rules may also pertain to business calculations, for example, how to convert a
percentage mark (for example, 91 percent) that a student receives in a seminar into a letter
grade (for example, A-).
Some business rules focus on the policies of your organization; perhaps the university
policy is to expel for one year anyone who fails more than two courses in the same
semester.
49
Con’d
Notice how each business rule has a unique identifier. My convention is to use
the format of BR#, but you are free to set your own numbering approach.
The unique identifier enables you to refer easily to business rules in other
development artifacts, such as class models and use cases.
Examples of business rules.
• BR123 Tenured professors may administer student grades.
• BR124 Teaching assistants who have been granted authority by a tenured
professor may administer student grades.
• BR177 Table to convert between numeric grades and letter grades.
• BR245 All master's degree programs must include the development of a
thesis.
50
Con’d
Description of business rule
Name: The name should give you a good idea about the topic of the business rule.
Description: The description defines the rule exactly.
Example (optional): An example of the rule is presented to help clarify it.
Source (optional): The source of the rule is indicated so it may be verified (it is quite
common that the source of a rule is a person, often one of your project stakeholders, or a
team of people).
Related rules (optional): A list of related business rules, if any, is provided to support
traceability between rules.
Revision history (optional): An indication of the date a change was made, the person who
made the change, and a description of the change.
51
Con’d
Example a fully documented business rule
52
Con’d
2) Technical Requirements
A technical requirement pertains to the technical aspects that your system
must fulfill, such as performance-related issues, reliability issues, and
availability issues.
These types of requirements are often called service-level requirements or
nonfunctional requirements.
Technical requirements are summarized in a manner similar to that of
business rules: they have a name and a unique identifier (my convention is
to use the format TR#, where TR stands for technical requirement).
You document technical requirements in the same manner as business rules,
including a description, an example, a source, references to related
technical requirements, and a revision
53 history.
Con’d
Example of Potential technical requirements for the university system.
TR34 The system shall be available 99.99 percent of the time for any 24- hour period.
TR78 A seminar search will occur within less than three seconds 95 percent of the
time.
TR79 A seminar search will occur within no more than ten seconds 99 percent of the
time.
54
Con’d
3) Constraints
A constraint is a restriction on the degree of freedom you have in
providing a solution.
Constraints are effectively global requirements, such as limited
development resources or a decision by senior management that restricts
the way you develop a system.
Constraints can be economic, political, technical, or environmental and
pertain to your project resources, schedule, target environment, or to the
system itself.
Like business rules and technical requirements, constraints are documented
in a similar manner.
55
Con’d
Examples of several potential constraints for the university system
C24: The system will work on our existing technical infrastructure—no
new technologies will be introduced.
C56: The system will only use the data contained in the existing corporate
database.
C73: The system shall be available 99.99 percent of the time for any 24-
hour period.
C76: All master's degree programs must include the development of a
thesis.
56
Identifying Change Cases
Change case should be developed as part of your overall modeling efforts
particularly during requirements gathering but also during analysis and
design .
Change case is the result of brainstorming by your SME, where questions
such as:
How can the business change
What technology can change
What legislation can change
What is your computation doing
What system will we need to interact with
Who else might use the system & how are explored
57
Con’d
Documenting change case:
Change case :The university will open a new campus
Likelihood: it has been announced that a new campus will opened in two
years across town.
Impact: Large students will be able to register in class at either campus. Some
instructor will teach in both campus. Some department such as CS,IS
are stated to move their entire program to the new campus. The likelihood
is great that most student will want to schedule courses at only one of the
two campuses. So, we will need to make this easy to support.
58
Requirements Validation Techniques
It is not enough to gather requirements; you also need to verify that they are
correct
The most common error made in the dev’t of a system are analysis errors: user
requirements that are either missing or misunderstanding
What is the implication of analysis error for object oriented development
artifacts ? With respect to CRC model.
You would be missing user requirements if you are missing few
responsibilities for a class, attributes of class or one or more collaborators .
For your essential user interface prototype you would have incomplete
screen and report or even be missing some.
59
Cont’d
Requirement can be misunderstood in three ways:
by user,
by analyst
by designer
The most serious problem is when user misunderstood a requirement. This is
why when you build a requirement team you want SME from a variety of
background.
You can reduce the risk of both analysis and designers misunderstanding
requirements by producing model that is simple and unambiguous.
60
Testing Early and often
If you make an analysis error and find it during:
Requirement: it is inexpensive to fix.
If you don’t find until Design stage: it is more expensive to fix not only
you have to change your analysis you also have to evaluate and potentially
modify the section of your design.
If you don’t find until programming: you need to update analysis, design
and scrap potion of your code.
To test your requirement models you can apply one or more of the following
techniques
Use case scenario testing
User Interface walkthroughs
Requirement reviews
61
Use Case Scenario Testing
Used to test domain models,(either CRC or class model) if it accurately
reflects the aspects of the business that you are modeling
Steps
1. Perform domain modeling: create either CRC or Class modeling
2. Create the use case scenarios
3. Assign classes to your SMEs: one or more CRC model
4. Describe how to act out a scenario:
5. Act out the scenarios
6. Update the domain model
7. Save the Scenarios
62
62
Create Use Case Scenarios
Conceptually similar to use cases
A use case describes the logic including the basic and alternate courses of
action, for a single cohesive task
A use case scenario describes a single path of logic through one or more
use cases
When you describe a use case scenario, you want to give it a name and short
description and then a description of the steps to take to fulfill the scenario.
Helps to catch unusual scenarios
You can identify new scenarios in several ways
Consider tasks the system should and shouldn’t be able to handle
Explore business rules
Do some more brainstorming
63
63
Example of a Use Case Scenario
Imagine a Library Management System where users can borrow books.
Use Case Scenario: Borrowing a Book
Actor: Library member (the user).
Goal: Borrow a book.
Steps:
The user logs into their library account.
They search for the book they want to borrow.
They check if the book is available.
They select "Borrow" to reserve the book.
The system updates the inventory to show the book is on loan.
64
Advantages of use Case Scenario Testing
Use case scenario testing helps you to Your SMEs must make the time
find and fix analysis errors
to do the testing
inexpensively Managers often feel real work
Use case Scenario testing provides you
isn’t being accomplished
with a detailed descriptions of the Developers are often skeptical
business logic of the system
(doubtful )
Use case scenario testing is simple and
it works
Scenarios help to define how people
interact with the system
65
User Interface Walkthroughs
Similar to use case scenario testing sessions, the only difference being
your system’s user interface is being tested instead of your domain model
66
Requirement Reviews
The requirement team prepares for review
The team indicates it is ready for review
The review facilitator performs a cursory review
The review facilitator plans and organizes the review
The reviewers review the package prior to the review
The review takes place
The review results are acted on
67
Thank y u…!