Requirements Analysis - PowerPoint PPT Presentation

About This Presentation
Title:

Requirements Analysis

Description:

Requirements Analysis Requirements analysis is the process of elaborating and clarifying the requirements This involves: Identifying all functions of the software – PowerPoint PPT presentation

Number of Views:125
Avg rating:3.0/5.0
Slides: 60
Provided by: ritu7
Category:

less

Transcript and Presenter's Notes

Title: Requirements Analysis


1
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

2
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
  • Take notes
  • Nap
  • Snore
  • Doodle

3
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

4
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

5
  • Use Case (Usage case) a reason to use the
    system

6
Use case scenario
  • When a cardholder tries to withdraw cash from an
    ATM, it doesnt 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

7
Use case scenarios for withdrawing cash from an
ATM machine
8
ATM Use case scenarios
9
Example
10
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

11
RUP Use Case Diagrams
Travel Kiosk Functions
Take Virtual Tour
View Map
View Photos
View Packages
Customer
Find Ideal Trip
View Contact Info
12
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

13
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

14
XP User Stories
32
Customer can change his/her address in the system.
Priority 5
User story points 5
15
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

16
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)

17
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

18
What happened?
  • What happened in both of these case studies?

19
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

20
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 teams over-reliance on a hero was their
    downfall
  • Taking the hero out of the equation stalled
    development

21
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 teams 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

22
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

23
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 projects 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

24
Risk Assessment
25
Risk Assessment
  • The following describes the risk assessment
    process
  • Once risks are assessed, a project manager should
    plan for them

1. Identifying risks
2. Estimating a risks cost/effects
3. Estimating a risks likelihood
4. Identifying alternatives
5. Evaluating/comparing alternatives
26
Risk Assessment
  • Risk Identification

27
Risk Identification
  • The first step in risk analysis is to identify
    the projects 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

28
Categories of Risk
  • Here is one way to categorize risks
  • Technical risks (related to using a particular
    technology)
  • Performance
  • Reliability
  • Availability
  • Complexity
  • Project management risks
  • 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
29
Categories of Risk
  • Here is one way to categorize risks (continued)
  • Constraint risks
  • Deadlines
  • Resources
  • Business risks
  • Marketability
  • Timing
  • Vendor delays
  • Economic conditions
  • External risks
  • Changing laws and regulations
  • Dependence upon suppliers and contractors

p.65
30
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

31
Common Risks
  • These risks are related to schedule
  • Feature creep
  • New features are frequently added after
    development has started
  • Requirements gold-plating
  • Too much documentation
  • Implementation gold-plating
  • Developers are working on the perfect
    implementation
  • Inadequate design
  • Too little attention has been paid to design
  • Overly optimistic schedules
  • Management pushed schedules down, rather than
    schedules work their way upward from developers
  • Poor motivation/weak personnel
  • Developers are working at a less-than-optimal
    pace
  • Silver-bullet syndrome
  • 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

32
Risk Assessment
  • Estimating Risk Cost Effects

33
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)

34
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 are considered high

35
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 didnt 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

36
Risk Assessment
  • Estimating Risk Likelihood

37
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 cant forsee any features we will need
    that will be impossible in PHP.

38
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, weve 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 doesnt 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 dont agree with him.
  • Tristan Ill have a talk with your team to
    confirm what youve said, but it sounds like
    Gerard and I need to have a talk about each of
    your responsibilities.

39
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

40
Risk Assessment
  • Identifying Alternatives

41
Identifying Alternatives
  • e.g. What are the alternatives to PHP?
  • JSP/J2EE
  • ASP.NET
  • Ruby/ROR
  • Perl

42
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

43
Risk Assessment
  • Evaluating Comparing Alternatives

44
Evaluating Comparing Alternatives
  • e.g. Let us examine the alternatives to PHP
  • JSP/J2EE
  • 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
  • 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
  • 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
  • Using this technology would require at least one
    month of training

45
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 doesnt command respect from her colleagues
  • Her development itself is slow

46
Assigning Probabilities
  • There are many approaches to assigning
    probabilities
  • It often doesnt 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

47
Risk Assessment
  • Bringing It All Together

48
Risk Assessment
  • Ok, weve 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
    risks 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

49
Qualitative Risk Assessment
Low Medium High
Low Ignore Ignore Consider
Medium Ignore Consider Take action
High Consider Take action Take action
50
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
51
Risk Exposure Assessment
Probability of Loss Cost Risk Exposure
Technology Failure 5 20 weeks 1 week
Key Developer Attrition 40 10 weeks 4 weeks
etc
52
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
53
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
54
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
55
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
56
Master Risk Identification List
Number Originator Open Date Risk Description Probability Impact Respond?








57
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 ?
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 gt 2 ?
3 Reproduction facilities 10/1 Weve 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 Im pregnant and due right after the 1st class is scheduled
58
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
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 gt 2 ? 4 5
3 Reproduction facilities 10/1 Weve 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 Im pregnant and due right after the 1st class is scheduled 4 1
59
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 gt 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 Weve 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 Im pregnant and due right after the 1st class is scheduled 4 1 Mitigate Hire a contract course developer with Graphic skills.
Write a Comment
User Comments (0)
About PowerShow.com