Startling Statistics
The significance of requirement can be best realized by looking at the failed endeavors which happened in software cycle.
- 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
Why? Some major reasons:
The reasons of an IT project failure can be because of multiple reasons which can happen at any stage of the project. Some of the key reasons for failure can be because of issues related to Requirements Gathering, Application Design, Poor Development, Limited or not testing. Other than this the contributors can be because of improper planning – ranging from scheduling to risk management. Since the focus of the current paper is primarily restricted to requirements gathering we are going to concentrate on the failure causes related to Requirements Gathering.
Customer Issues
- The project team does not have the skills to conduct a successful project
- The project team is constrained by unrealistic top-down decisions
- Team members not signed on - low morale
- Improper Change Management Planning from the management
- Lack of buy-in within the customer organization
Vendor Issues
- Misunderstood business rules - major structure changes
- No defined set of requirements - feature creep and gold plating
- Skills issues from the vendor’s team
How much of this is requirements related?
According to the Standish Group’s latest Extreme Chaos Report of 2000 the findings are:
- Two thirds of all projects studied were either failures or what they call “challenged”
- Only half of the desired features made it into the finished product
- Cost overruns happened on nearly half of all projects, although the good news here is that cost containment has been substantially reduced over the 189% reported in their 1994 study
- Time overruns occurred 82% of the time, or on nearly every single project. Equally disturbing is that the trend has been worsening, since time overruns occurred only 63% of the time in their 2000 study.
What can a good requirement specification do for you?
A good requirement specification is like a food recipe, if all key ingredients are properly specified, process all defined then the output will be of a real good taste. However, a word of caution – food is always subjective to individual’s taste bud. Just like people have their own liking for spices, hotness etc, it’s practically impossible to create a recipe which can suit to user’s taste bud. Similarly while doing requirements gathering it is impossible to keep all stakeholders requirements in the scope. The best way it can be addressed is by making a recipe which can handle most of their requirements.
Some of the advantages of having clear requirements are:
- 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 $$
What are some common software requirements?
People express requirements often is very high level terms which in most cases turns out to be the objective of a given IT initiative. The high level objective needs to be properly analyzed before recommending an appropriate solution.
Some of the standard ways through which people express their high level requirements are:
- 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…”
- 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…”
No comments:
Post a Comment