Transcript Gathering Baseline Requirements

Gathering Baseline Requirements
For Project Success
(and ulcer reduction)
1
Startling Statistics
• 2 million people working on 300,000
software projects in the US.
• 1/3 to 2/3 of the projects will exceed their
schedule and budget.
• 1/2 will be canceled for being out of
control.
* Caper Jones, “Applied Software Measurement: Assuring Productivity and Quality”, 2ed, 1997
* Leland L. Beck and Thomas E. Perkins, “A Survey of Software Engineering Practice:Tools….”, 1983
* Caper Jones,”Patterns of Software Systems Failure and Success”, 1996
2
Why? Some major reasons:
Corporate
• The project team does not have the skills to conduct a
successful project.
• The project team are constrained by unrealistic top-down
decisions.
– Team members not signed on - low morale
Contractor
• Misunderstood business rules - major structure changes
• No defined set of requirements - feature creep and gold
plating
3
How much of this is requirements
related?
• Lack of user input - 13%
• Incomplete requirements and specifications
-12%
• Changing requirements and specifications 12 %
• It is hard to hit a moving target.
The Standish Group (1994) study.
4
Big Picture
• Generic Lifecycle
Requirements define the necessary and desired
capabilities of the proposed system - what is the
thing suppose to do?
5
What can a good requirement
specification do for you?
• They can help reduce defects.
– It costs 5 to 10 times more fix a defect during or after
implementation versus correcting it in the planning stage.
– “If you didn’t have 5 hours to fix it the first time, where are you
going to find 50 hours to fix it later.”
•
•
•
•
•
Provide tighter estimates and reduce schedule slippage.
Decrease budget overruns.
Increase project team member morale.
Increase stakeholder morale.
Increase Profits $$
6
Before you start gathering
requirements...
• Identify Stakeholders
• Develop a problem statement
• Develop a “vision” - The project vision aligns all project participants
in a common and clearly expressed direction. The vision describes
what the project is about and what the product could ultimately
become in a perfect world. *
Make sure stakeholders are working toward the same goal.
* Karl E. Wiegers, “Software Requirements”, 1999
7
What are some common software
requirements?
•
•
•
•
•
•
•
•
•
Business rules - “Inventory shipments come on the 25th”
Budget - “We only have $1,000 for this project”
Interface - “We need a web enabled sales entry system”
Reports or outputs - “Stock check; monthly or weekly
summaries on ...”
Performance - “There might be 5000 concurrent users …”
Project Completion Date - “Oh, I need that next week …”
Security - “Everyone must have their own login and can see..”
Hardware - “We don’t want to buy additional hardware…14’’
screens will have to do.”
Software - “Everything must coded in Java and XML…”
8
Requirements Continued...
•
•
•
•
Error - Embedded system for the fire sprinklers; financial.
User level - “Mary has been dying to learn Windows...”
System maintenance - “Jack, our stock guy, he can…”
System location - “The server is located in Dallas and we
connect using this here modem. Just wiggle the cord...”
• No subcontracting - “Due to confidentiality, we ask…”
9
Who is going to define these
requirements?
• All Stakeholders
– Strategic management
– Product champions - chosen representative for a
particular group that can make project decisions with
regard requirements; often acting as tiebreakers.
• Senior employees
• Hired consultants to represent the customers.
– Project team
10
How can we elicit requirements?
• Review current system input and outputs
• Review data
• Joint Application Development (JAD) sessions - techie
term. Requirements Workshop - non-techie
• Person to person interviews
– Role playing
– Observation
• Prototyping
– Storyboarding - business flow, proposed interfaces and reports
– Empty Shell - no code
• Send out questionnaires (not a substitute for interviews)
• Design models
11
Review Current System(s)
• Paper trail
• Current computer system - take the best, scrap the rest
– Data Entry. Enter data for an hour.
– Reports
– Logic components
• Review source code
• Don’t get caught up with a specific function.
– Performance
• How long does it take to produce X?
– All the requirements listed previously.
12
Review the Historical DB Data or
Logs
• Which tables are used frequently? How many records?
• Does the table have any data?
• Which fields are filled in? Is there a field that contains
null values throughout the recordset?
• Are there any consistent data entry errors?
• Are there duplicate values in a lookup table?
Misspellings?
• Are there any major database design flaws? Poor indexing
choices or none at all.
Reviewing the data sometimes helps determine real or
overlooked requirements.
13
Joint Application Development Sessions/
Requirement Workshops
• All key stakeholders (product champions) brought together to hammer
out critical requirements. Avoid the word, “meeting”.
• Sell the workshop - communicate the benefits - ignore the nay sayers
– Benefits - effective team, committed to one common purpose
– Everyone gets a say; exposes and reduces political maneuvering that
interferes with project progress and success.
– You get the big picture feature set immediately. No running from one
department to another. Reduces schedule for large projects.
• Poorly organized workshop is not going to achieve the desired results.
Make sure logistics have been taken care of well in advance.
• Provide Warm-Up materials for all attendees 1 - 2 weeks before the
workshop. They probably won’t read it until an hour before, but that is
OK. Send reminder emails.
– Draft of requirements.
– Encourage people to think outside of the box. No wrong answers.
14
Joint Application Development Sessions/
Requirement Workshops Continued...
• Facilitator - personable, good communicator, strong personality,
consensus building or team building skills, and well respected by
internal as well as external team members.
– Make sure you have an experienced facilitator.
– Use 3rd party, if possible.
– Cannot add input for requirements. Has to be impartial to resolve
disputes.
– Encourages free flowing ideas. Asks questions. Puts the kibosh on
criticism. “That is stupid.” “We already have that idea on the wall.”
– Establishes professional and objective tone of the meeting.
– Starts and stops the meeting on time.
– Enforces workshop rules. Controls disruptive or unproductive behavior.
– Introduces the goal and agenda for the meeting.
– Keeps the team “on track”
15
Joint Application Development Sessions/
Requirement Workshops Continued...
• Brain storming secretary
– Capture ideas on a flip chart or legal pad.
• Workshop Schedule
– Based on the needs of the project
– Include breaks and lunch
• No pagers or phones allowed in the room.
16
Interviewing
• What role do they play? Managers and clerks may view the system
completely different.
• Prepare yourself as well as the user. Send them warm-up materials.
• Depending on their role and availability, meet in a neutral place.
– Meeting room or closed off room. Reduces distractions for both
parties. No email or ringing phones. Turn off your phone/pager.
• Bring:
– tape recorder
– Polaroid
– legal pad for both of you
– colored pens
– business cards
– laptop. Be careful not to use your computer if it cannot be seen by
all attendees. Don’t hide behind it.
17
Interviewing Continued...
• Give yourself enough time for the interview and plan for
breaks.
• Role play if the user’s explanation is unclear.
– Users cannot articulate the procedures they follow
– The management says one thing, operational reality is completely
different.
– Impossible for you to ask every possible question and for any user
to know questions the developer should be asking.
– Enter data for an hour using their current system.
– Discomfort factor with large groups.
• Draw simple diagrams or decision trees. Complex
diagrams will turn off key non-technical users.
• Send a summary as soon as possible to the interviewees.
18
Storyboarding/Prototyping
• Passive storyboards - sketches, pictures, screenshots, Powerpoint
presentations, or sample outputs. Use stick figures.
• Active storyboards - automated slide presentation or movie describing
the way the system behaves.
• Interactive storyboards - require participation by the user. Throw
away code. Sample interface or reporting outputs; very close to a
throwaway prototype.
• Storyboard elements:
– Who are the players
– What happens to them
– How it happens
19
Storyboarding/Prototyping Continued...
• Don’t invest too much in the prototype. A throwaway prototype
shouldn’t take more than a week to build. Customers will be
intimidated to make changes if it looks to close to the real thing.
• “If you didn’t change anything, you didn’t learn anything.”
• If the prototype looks too good, customers will want it now or assume
that you are almost done. “So you are pretty much done, right?”
• Have backup plans. Bring a paper version of a interactive prototype.
– What prevents a client from taking your code and giving to another
developer? “Here is what we want and you can do this for a better price,
right?”
– Hardware presentation problems - no outlet, machine lockup, screen can’t
be seen by everyone, software not cooperating, etc.
– Make sure the prototype is portable.
• Sized to fit screen.
• Basic colors.
• Can it run without special software? “Let me just load this calendar
control…”
20
Prototyping Continued...
• Good way to demonstrate project feasibility. If it has never been done
it before, how do you know it will work or that YOU can develop it?
AKA proof of concept.
• Helps combat the, “Yes, but…” people. Once the system is built, “Yes
that is nice, but can you make it do this…” This response is inevitable.
However, you should catch them in the prototyping stage and not the
rollout.
• Prototype fuzzy requirements.
21
Questionnaires
• Good for large groups
• An average response level is usually around 10%, if there is no threat
from the boss.
• When you used correctly, questionnaires can be an excellent
supplement to interviewing data.
• A user can’t tip you off to explore different problem areas with a
questionnaire easily. They will want to get through with it as soon as
possible, not to mention subjective answers will usually be too brief.
22
Models
•
•
•
•
•
•
Context Diagram
Data Flow Diagram
Entity Relationship Diagram
Decision Tree
State Transition Diagram
Dialog Map
23
Models Continued ...
• Use Case Model
– Ivar Jacobson introduced use cases to the world in his famous book
"Object-Oriented Software Engineering" (OOSE). It soon became obvious
that this simple idea was an important technique for writing software
requirements. Use cases are now an important feature of the Unified
Modeling Language (UML).
– Use cases are a means of describing the functionality of a system in
object-oriented software development. Each use case represents a specific
flow of events in the system. The description of a use case defines what
happens in the system when the use case is performed.
• Unified Modeling Language (UML)
– The Unified Modeling Language (UML) is the industry-standard language
for specifying, visualizing, constructing, and documenting the artifacts of
software systems. It simplifies the complex process of software design,
making a "blueprint" for construction. The UML definition was led by
Rational Software's industry-leading methodologists: Grady Booch, Ivar
Jacobson, and Jim Rumbaugh.
24
Tailoring Requirements/Idea Reduction
• Unfortunately, is very unlikely that all suggested requirements or ideas
will make it into any particular release. You must tailor the
requirements as well as prioritize them. Try to use:
–
–
–
–
•
•
•
•
Committed
Time Permitting
Future Release
Rejected
in place of high, medium, and low.
The Forest - The vision document specifies, in general, the features of
the system.
The Tree - Software Requirements Specification (SRS) documents the
details of the features.
Make sure to document all changes to the baseline requirement
document. Keep historical records.
The bigger and more complex the project, the more formal your
requirement gathering methods need to be. Small projects - reduce.
25
References
• Dean Leffingwell and Don I. Widrig, “Managing Software
Requirements: A Unified Approach”, October 1999
• Steve McConnell, “Rapid Development: Taming Wild Software
Schedules”
• Karl E. Wiegers, “Software Requirements”, 1999
• Deborah J. Mayhew, “The Usability Engineering Lifecycle”, 1999
• http://www.pols.co.uk/usecasezone/index.htm
• http://www.rational.com/uml/index.jtmpl
26