Chapter 4:

Developing Requirements

Timing: 50 minutes
Question:

Scenario 1:You get an offer in 2 years by Boeing as a

Software Developer.
Scenario 2: You get an offer in 2 years by Google as a
Software Developer.
Both:
• pay the same amount of money
• are in the same city
• are equal distance from your house
Which job do you take and why?

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 2

4.1 Domain Analysis

The process by which a software engineer learns about

the domain to better understand the problem:
• The domain is the general field of business or
technology in which the clients will use the software
• A domain expert is a person who has a deep knowledge
of the domain

Benefits of performing domain analysis:

• Faster development
• Better system
• Anticipation of extensions

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 3

4.2 The Starting Point for Software Projects

Requirements Clients have produced

must be determined requirements

New
development A B
green field project

Evolution of
existing system
C D

Be careful with cases B and D, why?

Customer may not have done a good job (e.g. proposing a
system that is too large or does not address a clear problem)
© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 4
4.3 Defining the Problem and the Scope

A problem can be expressed as:

• A difficulty the users or customers are facing,
• Or as an opportunity that will result in some benefit such
as improved productivity or sales.

The solution to the problem normally will entail

developing software

A good problem statement is short and succinct

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 5

Defining the Scope

Narrow the scope by defining a more precise problem

• List all the things you might imagine the system doing
—Exclude some of these things if too broad
—Determine high-level goals if too narrow

Example: A university registration system

Initial list of problems Narrowed Scope of
with very broad scope scope another system

browsing courses browsing courses

room allocation room allocation
registering registering
exam scheduling exam scheduling
fee payment fee payment

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 6

4.4 What is a Requirement

Requirement: A statement about the proposed system

that all stakeholders agree must be made true in order
for the customer’s problem to be adequately solved.
• Short and concise piece of information
• Says something about the system
• All the stakeholders have agreed that it is valid
• It helps solve the customer’s problem
Describes either:
•An aspect of the what the proposed system must do
•A constraint on the system
A collection of requirements is a requirements document.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 7

4.5 Types of Requirements

Functional requirements
• Describe what the system should do

Non-functional requirements
• Constraints that must be adhered to during development

Question: A Functional Requirement for cs2212 project

might be: First Name must be 1-20 characters. Can
you figure out what might be a Non-Functional
Requirement that I have given you for your cs2212
project?
© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 8
Functional requirements

• What inputs the system should accept

• What outputs the system should produce

• What data the system should store that other systems

might use

• What computations the system should perform

• The timing and synchronization of the above

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 9

Non-functional requirements
All must be verifiable
Three main types (Quality  Q)
1. Categories reflecting: usability, efficiency, reliability,
maintainability and reusability
—Response time
—Throughput
—Resource usage
—Reliability
—Availability
—Recovery from failure
—Allowances for maintainability and enhancement
—Allowances for reusability

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 10

Non-functional requirements

2. Categories constraining the environment and

technology of the system. (Platform  PL)
—Platform
—Technology to be used

3. Categories constraining the project plan and

development methods (Process  PR)
—Development process (methodology) to be used
—Cost and delivery date
- Often put in contract or project plan instead

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 11

Question
Classify the following requirement statements into F for
functional, Q for quality, PL for platform, PR for
process and X for should not be a requirement: a) F
a) If the alarm system is ringing, then the elevator
doors will proceed to the ground floor, open doors
and suspend further operations b) Q
b) The student information system will provide output
from all commands within one second c) X
c) The system will use an array to hold the invoices
d) The java.util.Date class should be used to handle d) X
dates
e) The system must run under Linux and Windows e) PL
f) The system must be done by September 2008
g) The system should be able to be expanded in the f) PR
second release to handle new file formats for
graphics
h) All phone extensions must start with an 8 g) Q

h) F

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 12

4.6 Use-Cases describing how the user will
use the system
A use case is a typical sequence of actions that a user
performs in order to complete a given task
• The objective of use case analysis is to model the
system
… from the point of view of how users interact with
this system
… when trying to achieve their objectives.
• A use case model consists of
— a set of use cases
— an optional description or diagram indicating how
they are related

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 13

Use cases

• In general, a use case should cover the full sequence of

steps from the beginning of a task until the end.
• A use case should describe the user’s interaction with
the system ...
—not the computations the system performs.
• A use case should be written so as to be as independent
as possible from any particular user interface design.
• A use case should only include actions in which the
actor interacts with the computer.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 14

UML Use Case Diagram
What Are Your Users Goals?
Use case diagrams are a simple UML notation to
illustrate the goals of your users
Use cases
• Are created in the early stages of the project
• Are an effective means of communicating with your end users
• Allow you to model what happens in an existing system or what
the user can do in a new system
• Can be used as the basis for picking test cases during the testing
of the system.
A use case represents a sequence of actions (or goal) to
be performed by the system and the users/actors who
interacts with that use case

UWO Computer Science Use Case Diagrams 15

Simple Example
Suppose a gambler is playing a dice game where
if he/she roll 2 dice and the values of the dice
add up to 7 he/she wins, otherwise he/she loses.

Sample Use Case Diagram:

Roll A Die

Gambler

UWO Computer Science Use Case Diagrams 16

Terminology
Use Case: a goal to be accomplished, a sequence of activities that
achieve that goal

Normally a verb followed by a noun, for example:

• Process Sale
• Add Customer

E.g. Bad Use Case: Log In (the goal is not really to log in!)
E.g. Good Use Case: Authentic User
Notation:

Process Sale

UWO Computer Science Use Case Diagrams 17

Terminology

Actor: people/systems that interact with use cases

• Human Actors: Clients, Customers, Employees
—Pick clear names such as Hotel Desk Clerk, Librarian, Head
Librarian.
—Don’t pick names based just on job titles: for example if the
clerk, the secretary and the receptionist all do the same
operations on the telephone answering system you are writing,
pick one name for all 3, not 3 different actor names,e.g. phone
operator
—Notation:

Gambler
UWO Computer Science Use Case Diagrams 18
– Non-Human Actors: External systems that communicate with
the system being designed
• e.g. Credit Card Authorization, Web Server
• Ignore internal components, only model external other
systems as actors, not internal parts of your system. For
example, your internal database should NOT be an actor.
• Notation:
• <<Actor>>
Credit Card Authorization System
Or
•

Credit Card Authorization System

UWO Computer Science Use Case Diagrams 19

Suggestions for Designing Use Cases
Choose a good name
• e.g. Add Appointment rather than Make Time
Show a complete and completable behaviour
• e.g. Add Appointment rather than Add Appointment Location
• e.g. Add Appointment rather than Adding Appointment
Show inverse use cases if applicable
• e.g. Add Appointment AND Delete Appointment
Limit a use case to ONE behaviour
• e.g. Add Appointment, Update Appointment AND Delete
Appointment rather than Manage Appointments
Write the use case from the actors point of view
• e.g. Sell Stock rather than Delete Stock

UWO Computer Science Use Case Diagrams 20

Use case diagrams

Register in Course
Add Course Offering

Registrar Actor Add Course

Enter Grade
for Course
Student

Find information about course

Professor Actor

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 21

Use Case Example
Design the use case diagram for the following situation:
• Suppose we are re-designing a system for BustBlocker Video
Stores. Currently, a customer picks a video off a shelf and brings it
to the clerk. The clerk logs in once in the morning and during the
rest of the day must check out the video to a customer or check in
videos that are returned by customers. The clerk or the store
manager must also be able to add new copies of movies and delete
copies of movies. When a customer pays for a video, the clerk will
use the check credit card system to check the user’s credit card. The
clerk and the store manager must be able to add and delete and
update customer information. Customers want to have a printed list
of the movies they have rented within a given time frame, the clerk
must print this list.

UWO Computer Science Use Case Diagrams 22

Video Use Case Diagram 1

UWO Computer Science Use Case Diagrams 23

Video Use Case Diagram 2

• How would your diagram change if you were going

to allow customers to do self check out and self
check in of movies and print their own list.

UWO Computer Science Use Case Diagrams 24

Inclusions (Called Uses In MS Visio)

• Allow one to express commonality between several

different use cases.

• Are included in other use cases

—Even very different use cases can share sequence of
actions.
—Enable you to avoid repeating details in multiple use
cases.

• Represent the performing of a lower-level task with a

lower-level goal.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 25

Use Cases that can be reused <<include>>
Try to factor out common behaviour from 2 or more
use cases, a subscenario of a use case
Example:

Book Room <<include>>

Guarantee
Guest
Reservation
Book Hall <<include>>

Event Organizer

UWO Computer Science Use Case Diagrams 26

Advantages
• Helps to avoid documenting the same information in more
than 1 detailed use case
• Helps identify common functionality for later coding
decisions

Disadvantages
• Might cause UML designers to start looking to early for
common functionality rather than just identifying the use
cases.
• Not as easy to read for non-UML users so it may make
diagrams more confusing for users

UWO Computer Science Use Case Diagrams 27

Identifying Different Scenarios <<extend>>

•If a use case has a complex or unusual scenario, you might

want to make it a separate use case
•If there is some point where the behaviour diverges, you
might want to make this a separate use case

UWO Computer Science Use Case Diagrams 28

Example

Note: the arrow goes from the more exceptional case to the
normal case

<<extend>> Rental Refused

Rent Video
Overdue videos still on loan

Customer

UWO Computer Science Use Case Diagrams 29

Extensions

• Used to make optional interactions explicit or to handle

exceptional cases.
• By creating separate use case extensions, the description
of the basic use case remains simple.
• A use case extension must list all the steps from the
beginning of the use case to the end.
—Including the handling of the unusual situation.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 30

Generalizations

• Much like superclasses in a class diagram.

• A generalized use case represents several similar use
cases.
• One or more specializations provides details of the
similar use cases.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 31

Example of generalization, extension and
inclusion

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 32

<<include>> vs. <<extend>>

• <<include>> use when one use case one cannot live without the other
use case. The use case must include another use case. The one use
case can NOT be completed without the other use case.
—For example when you create an order you always must verify
name. NOTE: used to be called <<Uses>>
• <<extend>> use when one use case can live without the other in some
instances. The use case will extend to another use case to do some
stuff occasionally but not always.
—For example, you can create an order but if the order is for a new
customer you may have to do additional check which you do not
have to do for existing customers. In that case you can have an
extend use case.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 33

Another Example

<<include>> Select Text

Bold Text

Print Word <<extend>> Print Preview

Document Word Document

QUESTION: Often, in the project, you will be required

to DELETE something and LIST all the somethings.
How does the <<extend>> apply in this scenario (for
example  deleting a file and listing all the files)?

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 34

Other Things to Remember
• At this early point in requirements analysis, DO NOT
attempt to design screens for your use cases, just
identify them. i.e. don’t worry about how the use cases
work, just worry about what the use cases are.
• Match the actors name to how he/she interacts with the
system, not to his/her job title
• Use cases should be easy for your users to understand,
again remember they tell what the user must accomplish
NOT how to accomplish it!

UWO Computer Science Use Case Diagrams 35

Case Study

Design a Use Case Diagram for the following requirements:

A camping reservation system for multiple campgrounds.

Each campground has a manager and rangers. Managers and rangers can
enter information such as campsite info, and which sites are useable and
which sites are undergoing repair/regrowth. Campers can use the system to
select and reserve camping locations.
Identify the actors
Identify the use cases
Look for any include use cases
Look for any extend use cases
Which use case might you want to expand to a DETAILED USE CASE?

UWO Computer Science Department 36

Your Answer
Check Availability
Cancel booking
Modify booking
<<include>>
Search sites
<<include>>

Book site
Camper
Add Site

Modify Site <<include>>

List Sites
<<include>>
Ranger
Delete Site

UWO Computer Science Department 37

The modeling processes: Choosing use
cases on which to focus
• Often one use case (or a very small number) can be
identified as central to the system
—The entire system can be built around this particular
use case
• There are other reasons for focusing on particular use
cases:
—Some use cases will represent a high risk because for
some reason their implementation is problematic
—Some use cases will have high political or
commercial value
• Create a detailed use case for the central use cases

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 38

The “Guts” of Use Cases

– We can now supply the details of a use case

1. Define use cases (as done above)
2. Give a simple sentence to explain each use case
3. Give a detailed narration of what the use case does, in paragraph
form
4. Describe the main course scenario (main success scenario, main
flow)
5. Set pre and post conditions
6. Identify, then describe alternate scenarios with post and pre
conditions
7. List any additional requirements that must be met
– The users should be allowed to review the narrative to
see if it clearly reflects the goal the user is trying to
accomplish

UWO Computer Science Use Case Diagrams 39

Example
1. Use Case Name: Check out video
2. Description: This use case allows the actor, clerk, to rent out a video to a
particular customer
3. Narrative: This use case starts with the clerk entering in the video id
number of the video to be rented. The system displays the video title
and how many copies are available. If no copies are available, the
action is cancelled. If there is at least one copy available, the system
prompts for customer’s id number. If the name displayed matches the
customer name the system prompts for the payment information. The
clerk enters in the customers credit card number which is authorized
by the credit card authorization system, if the card is not valid, the
customer is asked if he/she wishes to pay with cash, if he/she says no,
the action is cancelled. Otherwise the system displays the return date
for the video and gives a confirmation message that the video was
rented.
Review this narrative with your users before continuing!

UWO Computer Science Use Case Diagrams 40

4. Main Course:
Actor: Clerk System Actor: Credit Card
Authorization
System

1. The clerk enters the video 2. The system displays the name
id number of the movie of the movie and the
to be rented. number of copies available
3. The clerk enters the
customer id number 4. The system displays the
5. The clerk enters the customers name.
customers credit card 7. Reports card is
6. The system sends the card accepted.
number number to the credit card
authorization system and
8.The clerk confirms the waits for confirmation
checking out of the 9. The system displays that the
movie video was rented and
displays the return date

UWO Computer Science Use Case Diagrams 41

5. Pre Condition: At least one copy of the movie to be rented is available.
Post Condition: The video copy is rented to the customer
6. Alternate Course 1: There are no copies of movie available

Actor: Clerk System

1. The clerk enters the video id number of 2. The system displays the name of
the movie to be rented. the movie and that there are
3. The clerk cancels the check out operation ZERO copies available

Pre Condition: At Step 1 of main course, the actor enters a movie where
all the copies have been rented
Post Condition: Video is not rented to the customer

7. Other Design Considerations:

1. If 2 or more clerks try to rent the same copy at the same time, the
system should allow only one of them to rent it

UWO Computer Science Use Case Diagrams 42

Another Example of a Detailed Use Case

Example from http://breathingtech.com/2009/writing-

use-cases-for-agile-scrum-projects/

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 43

The benefits of basing software
development on use cases
• They can help to define the scope of the system

• They are often used to plan the development process

• They are used to both develop and validate the

requirements

• They can form the basis for the definition of testcases

• They can be used to structure user manuals

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 44

Problems with Use Cases

Try to describe a use case for adjusting the wake-up

time of an alarm clock.

If you were writing this use case, what is the problem

that would likely occur?

HINT: almost everyone has an alarm clock, what does

this imply about how YOU would design it?
You would probably describe the way your own clock does
it, rather than thinking of a more efficient and/or
innovative way to do it!
http://www.casecomplete.com/Video/Default.aspx?a=1
© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 45
Use cases must not be seen as a panacea

• The use cases themselves must be validated

—Using the requirements validation methods.

• There are some aspects of software that are not covered

by use case analysis.

• Innovative solutions may not be considered.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 46

User Stories

There are problems with drawing a Use Case Diagram

based on the initial requirements that were given you.
Can you guess what some of the problems are?

The initial requirements might be wrong OR incomplete

OR change during the project.
I.e. the user changes his/her mind or thinks up new
features.
Called: Scope Creep

So….. How can we keep our requirements “Agile”?

Chapter 4: Developing requirements 47

User Stories

Who should write the features? The business side or the

developer side? Any thoughts?

Business Side Development Side

Pros • knows exactly what is • can roughly gage how long it will
needed take to write the code

Cons • doesn’t really understand • starts thinking about HOW to do it

(or care) how long it takes rather than what needs to be done
to develop a feature and starts using technical jargon
• isn’t sure the developer • doesn’t get at chance to listen to
really understood what was figure out what is really needed
wanted/needed

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 48

User Stories

Business Person might write the feature:

 Manage appointment

Developer might write the feature:

 Use date/time field for storing appointment start time

What is the solution then? WHO should write the

feature list?
BOTH the business people and the developers MUST be
involved with writing of requirements!

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 49

User Stories
User Story: describes functionality valuable to a
user/customer. (should be able to fit on a recipe card)
Format should be: As a <type of user-ACTOR>, I want
<some goal-ACTION> so that <some reason-
ACHIEVEMENT>.

Examples:
As a customer I want to see the most popular blu-ray
discs sold so that I can order one or many of them
As a customer I want to sort the most sold blu-rays by
price so that I can see the expensive ones first.
Good site with tips on User Stories:

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 50

User Stories

Decide if these stories are good user stories or bad ones:

A. As a user I can add a new appointment
B. As a user I can set the time of a new appointment
C. The system will run on Unix and Linux
D. As a scheduler, I want to add an appointment to a
calendar so that I can keep track of my schedule
E. While building the scheduling system we will use a
Gantt chart to monitor the programmers progress
F. The GUI needs to be built

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 51

User Stories

Notice that “as the user I can add a new appointment” is

a bit vague.

Need to have a conversation with the business people to

see is need to make a complete appointment.

The user story is a reminder to have the conversation,

we can discuss the details with the user when they
become important (“just in time” requirements
analysis)

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 52

User Stories

Usually ONE user story should fit on a recipe card. If it

takes up more space, then it should be broken down.
Put the test cases on the back of the card.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 53

User Stories – more detailed example

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 54

User Stories – Top 3 mistakes

Too formal / too much detail. Product owners with good intentions
often try to write extremely detailed user stories. If a team sees
a story at iteration planning that looks like an IEEE
requirements document, they'll often assume that all the details
are there and they'll skip the detailed conversation.
Technical tasks masquerading as stories. A lot of the power of Agile
comes from having a working increment of software at the end
of each iteration. If your stories are really just technical tasks,
you often don't end up with working software at the end of each
iteration, and you lose flexibility in prioritization.
Skipping the conversation. Stories are intentionally vague before
iteration planning. If you skip the acceptance criteria
conversation, you'll risk moving in the wrong direction, missing
edge cases or overlooking customer needs.
From this site: https://help.rallydev.com/writing-great-user-story

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 55

User Stories: Estimation

Who decides how long it takes to complete a user story?

Developer or Business Person?

DEVELOPER!

Each story is assigned an estimate in story points

• Describes the amount of work, NOT a length of time!

How long would it take you to show

shovelthe
thelittle
big pile
of this snow
compared to on
thethe
bigleft?
pile on the right?
© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 56
User Stories

Computer Scientists are excellent at telling which

feature would take the longest and which would take
the shortest amount of time, but they are very bad at
estimating the EXACT amount of time in hours or
days.

Thus we give User Stories points, an estimate of the

amount of work BUT not the amount of time.
e.g. An admin must be able to add a new customer
might be 1 story point but An admin must be able to
search for a customer might be 2 story points.

Note: only features get points, not bug fixes or chore

Chapter 4: Developing requirements
© Lethbridge/Laganière 2005 57
User Stories:

Iteration: a group of features that are FULLY

implemented, usable code for some subset of the
application. An iteration might be 1 week or 2 weeks, it
depends.

Velocity: Developers estimate in story points how long it

will take to complete an iteration.

Business people sort stories by priority, highest go into first

group, next highest go into second group, etc. Each
group is an iteration

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 58

User Stories

Developers might have a higher priority for something

because it is required to implement another feature
BUT the customer/business person must have final
say.

Try to avoid having one story depend on another story if

possible. •I ndependent
•N egotiable
Good User Stories INVEST  •V aluable
•E stimable
•S mall
•T estable

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 59

User Stories – Pivotal Tracker

Goal is to have a fully usable application at the end of

each iteration.
Create a public project on www.pivotaltracker.com
Your task is to:
• 1. Enter stories for every feature in the application
• 2. Add acceptance tests to the Description field of each
story (so that they know when the story is complete --
this would normally go on the back of a story card)
• 3. Assign each story to a group member
• 4. Estimate the length of each story in "story points”

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 60

User Stories

Watch this: http://vimeo.com/28217621

Then this:
http://www.youtube.com/watch?v=mTYcHg51sWY

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 61

4.13 Difficulties and Risks in Domain and
Requirements Analysis
• Lack of understanding of the domain or the real problem
—Do domain analysis and prototyping
• Requirements change rapidly
—Perform incremental development, build flexibility into the
design, do regular reviews
• Attempting to do too much
—Document the problem boundaries at an early stage, carefully
estimate the time
• It may be hard to reconcile conflicting sets of requirements
—Brainstorming, JAD sessions, competing prototypes
• It is hard to state requirements precisely
—Break requirements down into simple sentences and review
them carefully, look for potential ambiguity, make early
prototypes

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements 62