Requirements Analysis
 Requirements analysis is the process of elaborating and
clarifying the requirements
 This involves:
 Identifying all functions of the software



In RUP, the artifact produced is a use case diagram (each
function is a use case)
In XP, the artifacts are user stories
Identifying how the users and the software interact to
accomplish a software function


In RUP, the artifacts produced are use case descriptions
In XP, details about user stories are captured by the customer
iteratively by giving the customer progressive versions of the
software that implements them
RUP: Use Cases
 A use case is a description of a unit of functionality in a system
 For a travel kiosk:

Take a virtual tour of travel destinations


See maps of travel destinations
See pictures of monuments in travel destinations
Examine travel packages
 Find your ideal trip, using the customized vacation wizard
 Obtain contact information for ordering vacations
 For a classroom desk:
 Learn



Nap


Take notes
Snore
Doodle
RUP: Use Case Boundaries
 A use case is some activity for which a user would potentially
use a system
 If an activity is not something a user would do by itself, it is
part of a larger use case


e.g. In a bank system, generate transaction record is not useful
by itself, but is useful as part of the withdrawal use case (&
others)
If part of an activity is something a user would do by itself,
then that part is a use case by itself

e.g. In a department store, shop is made up of a few use cases,
each of which could be done separately:
 Browse products
 Purchase products
RUP: Use Case Diagrams
 A use case diagram give three important pieces of information:



A list of all use cases
Relationships between use cases
Participation between actors (normally, users) and use cases
Use Case (Usage case) – a reason to
use the system
Use case scenario :
When a cardholder tries to withdraw cash from
an ATM, it doesn’t always turn out the same
way . Sometimes





He gets his money
He might have insufficient funds
ATM may be out of cash ..
All relate to the same goal &
All are triggered by the same need
Use case scenarios for withdrawing
cash from an ATM machine :
ATM : Use case scenarios
Example :
Use cases (Warning!)
 Use cases must be independent of the technical
implementation :

Instead of saying , ‘ the user presses the enter button’ ,
it is appropriate to say ‘ the user confirms his/her
choice ‘
 High-level interaction designs and
 Use cases are not system requirement documents
RUP: Use Case Diagrams
Travel Kiosk Functions
Take Virtual Tour
View Photos
Customer
View Map
View Packages
Find Ideal Trip
View Contact Info
XP: User Stories
 User stories in XP serve a similar purpose to use cases

In XP, a user story is normally written on a small index card,
including:

1 or 2 sentences describing the user story
 If the user story cannot be described in 1-2 sentences, it is likely
too large and should be separated into parts

The priority of the user story
 Highest priority (i.e. priority: 1) user stories are worked on first

An identifier for the user story
 User stories are sequentially numbered
 User stories can describe:





Functions provided by the software
Improvements to functions
Improvements to user interfaces
Improvements to performance
Bug fixes
XP: User Story Size
 A user story will typically take about one week to implement in
software
 The use of XP makes the possibility of having to change how
it was implemented more likely
 However, customers see an implementation very quickly
 One technique for estimation involves assigning user story
points to each user story
 More points means it should take longer to implement
 Estimation can start with rough estimates (per user story
point)
 As time goes by, estimation of project velocity can influence
the hours per user story point ratio to make better estimates
XP: User Stories
#32
Customer can change his/her address in the system.
Priority: 5
User story points: 5
XP: User Story Guidelines
 User stories are described as benefits to the customer
Good example: The tax calculator should correctly calculate
the total balance for a married couple, independent of the
status of their individual files
 Bad example: The stock ticker data structure should use an
AVL tree internally to improve performance of lookups
 User stories should be verifiable
 XP practitioners believe in acceptance tests, which are tests
that verify the correct implementation of a user story

Case Study: ATCSoft
 The ATCSoft project was launched, and steady progress was
made
 When the team set out to integrate the ATCSoft application with
existing RADAR equipment, however, they hit a snag
 The team members could not figure out how to integrate the
systems



The RADAR system did not have appropriate physical
connections, nor was there an appropriate driver for the
interconnection
The project manager had to hire engineering consultants to
work out the integration details
This diversion took 2 months and cost a significant amount
of money (additional labour, consultancy fees, and business
value)
Case Study: PathFinder 2.0
 The PathFinder project was started in August

Rory Thompson was the star developer




His knowledge of neural nets inspired him to suggest that a
neural net implementation of a PathFinder would be a good
idea
He wrote up much of the foundation code for the neural
network
Initial tests showed a definite improvement in the PathFinder
performance, and more realistic, human-like, decisions
Despite the large salary increase he was offered, Rory took
a good offer with another firm



When some tests showed that the neural net was not fast
enough to make real-time decisions, the team had no
immediate answers
A bug was found that sent the avatars wandering aimlessly
around the maze in a circuit, when certain rare conditions were
present
Again, the team had no idea how to approach the problem
What happened?
 What happened in both of these case studies?
What happened?
 What happened in both of these case studies?
 In the ATCSoft scenario, a technical problem ended up
stalling development
 This could easily have become a complete disaster, if
it were not possible to integrate the systems
What happened?
 What happened in both of these case studies?
 In the ATCSoft scenario, a technical problem ended up
stalling development
 This could easily have become a complete disaster, if
it were not possible to integrate the systems
 In the PathFinder scenario, a personnel problem was
at fault
 The team’s over-reliance on a hero was their downfall
 Taking the hero out of the equation stalled
development
What happened?
 What happened in both of these case studies?
 In the ATCSoft scenario, a technical problem ended up
stalling development
 This could easily have become a complete disaster, if
it were not possible to integrate the systems
 In the PathFinder scenario, a personnel problem was
at fault
 The team’s over-reliance on a hero was their downfall
 Taking the hero out of the equation stalled
development
 In both scenarios, the team neglected their risks
 It is critical for a project team to understand and plan
for risks
Risk Mitigation
 In the ATCSoft project, the team should have investigated the
integration of various systems at the start of the project
 Given adequate time, the integration could have been
worked out before it was needed
Risk Mitigation
 In the ATCSoft project, the team should have investigated the
integration of various systems at the start of the project
 Given adequate time, the integration could have been
worked out before it was needed
 In the PathFinder project, Rory should have been the project’s
neural network consultant
 He could have thoroughly documented the neural network
code as it was developed
 He could have had seminars for team members, explaining
the concepts of neural networks
 Understanding neural networks, the team would have a
better chance of carrying on without Rory
Risk Assessment
Risk Assessment
 The following describes the risk assessment process:
1. Identifying risks
2. Estimating a risk’s cost/effects
3. Estimating a risk’s likelihood
4. Identifying alternatives
5. Evaluating/comparing alternatives
 Once risks are assessed, a project manager should plan for
them
Risk Assessment
Risk Identification
Risk Identification
 The first step in risk analysis is to identify the
project’s risks

Each project has its own set of unique risks
 Identifying risks seems like a dark art
 How do you identify something that could potentially be
hidden until it is too late?
 However, risk identification can be made easier using
categories of risk
 This leverages the knowledge of many project
managers who have experienced risks
Categories of Risk
 Here is one way to categorize risks:

Technical risks (related to using a particular technology)





Project management risks




Performance
Reliability
Availability
Complexity
Poor resource allocation
Poor planning
Poor prioritization
Organizational risks



Lack of support or resources
Inadequate or inefficient management
Interference from other projects & management agendas
p.65
Categories of Risk
 Here is one way to categorize risks (continued):

Constraint risks



Business risks





Deadlines
Resources
Marketability
Timing
Vendor delays
Economic conditions
External risks


Changing laws and regulations
Dependence upon suppliers and contractors
p.65
When do we identify risks?
 There are a two major approaches to risk identification

Identify risks before the planning phase


Some risks may be difficult to spot when looking at
requirements at a high level
Identify risks after the planning phase

It is useful to know risks before the planning phase, so that
extra time can be dedicated to their mitigation
 A good compromise is to perform risk identification during the
planning phase:
 After creating the work breakdown structure
 Before creating the schedule
Common Risks
 These risks are related to schedule:

Feature creep


Requirements gold-plating


Developers are working at a less-than-optimal pace
Silver-bullet syndrome


Management pushed schedules down, rather than schedules work their
way upward from developers
Poor motivation/weak personnel


Too little attention has been paid to design
Overly optimistic schedules


Developers are working on the perfect implementation
Inadequate design


Too much documentation
Implementation gold-plating


New features are frequently added after development has started
A trendy technology was expected to produce the equivalent to 10,000
lines of code in only 50 lines of code
Contractor failure

A contractor lacked expertise/commitment needed to do the job on
schedule
Risk Assessment
Estimating Risk Cost & Effects
Estimating Risk Costs & Effects
 Estimating the costs & effects of a risk is dependent
upon the risk

e.g. A project using a new technology might realize that
the technology is inadequate or unreliable
 Now, the application must be retrofitted to another
(trusted) technology
 Much of the software may need to be replaced
 The cost in this case is the cost of developing the
obsolete components
 In addition, there may be hidden costs due to delays
(such as customer confidence or personnel
availability)
Estimating Risk Costs & Effects
 Estimating the costs & effects of a risk is dependent
upon the risk

e.g. In some projects there is a risk that a key
developer will leave the project
 If the key developer leaves, what will it take to replace
her?
 Given market conditions, you might estimate a
replacement in 2 months
 Some project deliverables might be delayed by up to
that amount in her absence
 Also, you may have to consider signing bonuses,
relocation expenses, travel expenses, and other hiring
costs
 It depends on the project whether or not these costs
How to estimate cost?
 To estimate the cost, imagine a scenario where the
event occurs

e.g. Ok, Sarah has left the company. What do we do
now?
 We could promote Gerard to team leader
 We would need one more developer with technological
expertise
 Our corporate headhunter estimates hiring will take 10
weeks

e.g. PHP didn’t solve the problem. What now?
 We could use Ruby on Rails
 We would need to send our developers to training
courses
 In-depth RoR training courses are 4 months
Risk Assessment
Estimating Risk Likelihood
Estimating Risk Likelihood
 Like risk cost, risk likelihood also depends on the risk






e.g. The likelihood that a technology will fail can usually be
estimated accurately
Tristan: “How likely is it that the technology (e.g. PHP) will
fail to meet our expectations?”
Carlos: “PHP has been used for many projects successfully.
There have been many failed PHP projects, but very few cite
the technology as the cause of the failure. On the other
hand, there have been many very high-profile PHP projects.”
Carlos: “Consider FaceBook, which has similar (but more
complex) functionality to our GroupWare application.”
Tristan: “FaceBook uses PHP? That is similar to our
project.”
Carlos: “I can’t forsee any features we will need that will be
impossible in PHP.”
Estimating Risk Likelihood
 Like risk cost, risk likelihood also depends on the risk

e.g. How likely is it that Sarah Windermere will leave the project?



Her project manager may be aware of her job satisfaction, or her peers
However, a face-to-face meeting to assess her job satisfaction has no
substitute
Example:







Tristan: “Sarah, we’ve been very happy with your performance on
previous projects. You will be an integral part of this upcoming project.
Are there any concerns you have about this project or your job?”
Sarah: “Not really. I like the challenges.”
Tristan: “If you do have any concerns, I want you to tell me right away.
Your satisfaction and motivation are very important to me.”
Sarah: “Actually, I have been having a tough time working with Gerard.
He doesn’t respect my leadership, and tries to rally the team against
me.”
Tristan: “How does the rest of the team feel about his actions?”
Sarah: “Many of them either have confronted him about or have told
me they don’t agree with him.”
Tristan: “I’ll have a talk with your team to confirm what you’ve said, but
it sounds like Gerard and I need to have a talk about each of your
responsibilities.”
How to estimate likelihood?
 The best way to estimate is to ask the people closest
to the problem


e.g. For Sarah, the best person to ask would be her
(followed by her direct supervisor)
e.g. For PHP technology, anyone who has used PHP
for a previous project
Risk Assessment
Identifying Alternatives
Identifying Alternatives
 e.g. What are the alternatives to PHP?
 JSP/J2EE
 ASP.NET
 Ruby/ROR
 Perl
Identifying Alternatives
 e.g. Are there alternatives to Sarah?
 Gerard Lepalme: Has leadership, but lacks the
technological expertise
 Helen Driskoll: Knows some of the technology, but is
very inexperienced
Risk Assessment
Evaluating & Comparing Alternatives
Evaluating & Comparing Alternatives
 e.g. Let us examine the alternatives to PHP:

JSP/J2EE




ASP.NET




We have no in-house personnel trained in this technology
Using this technology would require at least one month of
training
Development of user interfaces, however, should be made
easier
Ruby/ROR





Much of our existing staff is familiar with this technology
Using this technology would require a few days of training
Architecture should be more robust
We have only a few in-house developers trained in this
technology
Using this technology would require weeks of training
Development should be made easier
Architecture should be more robust
Perl

We have no in-house personnel trained in this technology
Evaluating & Comparing Alternatives
 e.g. Let us examine alternatives to Sarah:

Gerard Lepalme: Has leadership, but lacks the technological
expertise




Gerard is a take charge kind of person
He is also a get it done kind of person
However, he is not familiar with XML and many other
technologies we plan to use
Helen Driskoll: Knows some of the technology, but is very
inexperienced





Helen knows XML and a few other technologies we plan to use
However, Helen is just starting her career
She has difficulty being assertive and taking charge
She doesn’t command respect from her colleagues
Her development itself is slow
Assigning Probabilities
 There are many approaches to assigning probabilities
It often doesn’t matter if you only care about the value
relative to other risks
 However, this is a good rule of thumb:
 Very low:
0.05
 Low:
0.20
 Medium:
0.40
 High:
0.60
 Very High:
0.80

Risk Assessment
Bringing It All Together
Risk Assessment
 Ok, we’ve collected data
 What is next?
 We need to crunch some numbers to determine which
option is the best
 Qualitative assessment
 Risks are evaluated and planned for if they have significant
likelihood and significant costs

Dynamic risk assessment
 Risks are given a score for each development phrase
 The stage scores are totaled to calculate the risk’s score

Risk exposure assessment
 The risk likelihood is expressed in percentages
 The risk cost is expressed in weeks
 These two are multiplied to calculate an expected loss

Risk impact assessment
 Similar to risk exposure, but percentages are also used for
cost
Qualitative Risk Assessment
Low
Medium
High
Low
Ignore
Ignore
Consider
Medium
Ignore
Consider
Take action
Consider
Take action
Take action
High
Dynamic Risk Assessment
A
B
C
Score
Requirements
1
3
1
5
Design
2
2
2
6
Implementation
3
1
2
6
Testing
3
1
4
8
Integration
2
1
4
7
Score
11
8
13
32
Risk Exposure Assessment
Probability of
Loss
Technology
Failure
Key Developer
Attrition
…etc…
Cost
Risk
Exposure
5%
20 weeks
1 week
40%
10 weeks
4 weeks
Risk Impact Assessment
Probability of
Loss
Impact
Risk
Exposure
Technology
Failure
0.05
0.60
0.03
Key Developer
Attrition
0.40
0.40
0.16
…etc…
Evaluating Alternatives
 When considering alternatives, you can apply the same techniques to all
alternatives
 e.g. J2EE vs. ASP.NET vs. RoR
Probability of
Failure
Cost
Risk Exposure
J2EE
0.05
1 week
0.05 weeks
ASP.NET
0.05
5 weeks
0.25 weeks
RoR
0.05
3 weeks
0.15 weeks
Risk Planning
1. Learn about the risk
2. Plan to avoid the risk
3. Move the risk
4. Create a risk-management plan
5. Mitigate and control the risk
6. Tolerate the risk
7. Document the risk
8. Monitor the risk
Common IT Project Risks












Feature creep
Requirements gold-plating
Developer gold-plating
Shortchanged quality
Overly optimistic schedules
Inadequate design
Silver-bullet syndrome
Research-oriented development
Weak personnel
Demotivated personnel
Contractor failure
Friction between developers and customers
Adapted from Rapid Development, by Steve McConnell
Master Risk Identification List
Number
Originator
Open Date
Risk
Description
Probability
Impact
Respond?
Number
Originator
Open Date
Risk Description
1
Course
Developer
10/1
There are 5 of us set up to
do the work for this project
What happens if one of us
gets sick ?
2
CSR
Supervisors
10/1
When the CSRs go
through new training, there
is always a spike in the
time it takes to handle a
customer while the new
training is learned . Will
this spike create customer
complaints > 2 % ?
3
Reproduction
facilities
10/1
We’ve been having
problems with our paper
supply. We might not be
able to have enough paper
on hand to create the
textbooks in the time frame
you want.
4
Reproduction
facilities
10/1
We are planning a
remodeling project of our
facilities during the time u
are requesting the creation
of textbooks. We might not
be able to meet the time
frames you are requesting.
5
Graphic artist
10/1
I’m pregnant and due right
after the 1st class is
scheduled
Probability
Impact
Respond?
Number
Originator
Open Date
Risk Description
Probability
Impact
1
Course
Developer
10/1
There are 5 of us set up to do
the work for this project What
happens if one of us gets sick ?
3
5
2
CSR Supervisors
10/1
When the CSRs go through new
training, there is always a spike
in the time it takes to handle a
customer while the new training
is learned . Will this spike create
customer complaints > 2 % ?
4
5
3
Reproduction
facilities
10/1
We’ve been having problems
with our paper supply. We might
not be able to have enough
paper on hand to create the
textbooks in the time frame you
want.
2
2
4
Reproduction
facilities
10/1
We are planning a remodeling
project of our facilities during the
time u are requesting the
creation of textbooks. We might
not be able to meet the time
frames you are requesting.
5
2
5
Graphic artist
10/1
I’m pregnant and due right after
the 1st class is scheduled
4
1
Respond?
Number
Originator
Open Date
Risk Description
Probability
Impact
Respond?
1
Course
Developer
10/1
There are 5 of us set up to do the
work for this project What happens
if one of us gets sick ?
3
5
Mitigate - be ready to
hire a contract course
developer to work with
the other course
developers.
2
CSR Supervisors
10/1
When the CSRs go through new
training, there is always a spike in
the time it takes to handle a
customer while the new training is
learned . Will this spike create
customer complaints > 2 % ?
4
5
Transfer – Develop an
agreement with the
outsourced call center
for overflow calls on
Mondays for 6 months
3
Reproduction
facilities
10/1
We’ve been having problems with
our paper supply. We might not be
able to have enough paper on
hand to create the textbooks in the
time frame you want.
2
2
4
Reproduction
facilities
10/1
We are planning a remodeling
project of our facilities during the
time u are requesting the creation
of textbooks. We might not be able
to meet the time frames you are
requesting.
5
2
Avoid – Find another
reproduction vendor .Be
sure to test their quality
of work
5
Graphic artist
10/1
I’m pregnant and due right after the
1st class is scheduled
4
1
Mitigate : Hire a
contract course
developer with Graphic
skills.