1 Gathering Baseline Requirements For Project Success (and ulcer reduction)

1

Gathering Baseline Requirements

For Project Success

(and ulcer reduction)

2

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

3

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

4

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.

5

Big Picture

• Generic Lifecycle

Requirements define the necessary and desired capabilities of the proposed system - what is the thing suppose to do?

6

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 $$

7

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

8

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…”

9

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…”

10

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

11

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

12

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.

13

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.

14

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.

15

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”

16

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.

17

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.

18

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.

19

Storyboarding/PrototypingStoryboarding/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 storyboardsInteractive 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

20

Storyboarding/Prototyping Continued...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…”

21

Prototyping Continued...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.

22

QuestionnairesQuestionnaires• 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.

23

ModelsModels• Context Diagram

• Data Flow Diagram

• Entity Relationship Diagram

• Decision Tree

• State Transition Diagram

• Dialog Map

24

Models Continued ...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.

25

Tailoring Requirements/Idea ReductionTailoring 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.

26

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