Sunday, February 19, 2012

The Essential Software Requirement-Chapter 1 part 2

Statistics form NIST :

NIST (National Institute of Standards and Technology) has published a comprehensive (309 pages) and very interesting report on project statistics and experiences based on data from a large number of software projects1
§70% of the defects are introduced in the specification phase
§30% are introduced later in the technical solution process
§Only 5% of the specification inadequacies are corrected in the specification phase
§95% are detected later in the project or after delivery where the cost for correction on average is 22 times higher compared to a correction directly during the specification effort
§The NIST report concludes that extensive testing is essential, however testing detects the dominating specification errors late in the process.

______________________________________________________
Why Focus on Requirements ?



CHAOS Report (2004)1




Progression since 1994

Success Factors 



Problem Causes

Evolution of Success Factors


Keep Users and Other Stakeholders Involved?


_____________________________________________________
End of Some Realities :


"Hello, Phil? This is Maria in Human Resources. We're having a problem with the employee system you programmed for us. An employee just changed her name to Sparkle Starlight, and we can't get the system to accept the name change. Can you help?"
"She married some guy named Starlight?"
"No, she didn't get married, just changed her name," Maria replied. "That's the problem. It looks like we can change a name only if someone's marital status changes."
"Well, yeah, I never thought someone might just change her name. I don't remember you telling me about this possibility when we talked about the system. That's why you can get to the Change Name dialog box only from the Change Marital Status dialog box," Phil said.
"I assumed you knew that people could legally change their name anytime they like," responded Maria. "We have to straighten this out by Friday or Sparkle won't be able to cash her paycheck. Can you fix the bug by then?"
"It's not a bug!" Phil retorted. "I never knew you needed this capability. I'm busy on the new performance evaluation system. I think I have some other change requests for the employee system here, too." [sound of rustling paper] "Yeah, here's another one. I can probably fix it by the end of the month, but not within a week. Sorry about that. Next time, tell me these things earlier and please write them down."
"What am I supposed to tell Sparkle?" demanded Maria. "She's really going to be ticked if she can't cash her check."
"Hey, Maria, it's not my fault," Phil protested. "If you'd told me in the first place that you had to be able to change someone's name at any time, this wouldn't have happened. You can't blame me for not reading your mind."
Angry and resigned, Maria snapped, "Yeah, well, this is the kind of thing that makes me hate computer systems. Call me as soon as you get it fixed, will you?"
Many software problems arise from shortcomings in the ways that people gather, document, agree on, and modify the product's requirements.
As with Phil and Maria, the problem areas might include:
§informal information gathering, implied functionality, erroneous or uncommunicated assumptions, inadequately defined requirements, and a casual change process.
Most people wouldn't ask a construction contractor to build a custom $300,000 house without extensively discussing their needs and desires and refining the details progressively.


No comments:

Post a Comment