W@rfi Blog

Have you ever wondered or even thought about that how many defects are being produced by requirements? If your answer is no, then read on, you should read even if your answer is yes

Here we go, more than two third defects are produced just because of requirements. Developer produced errors account for a small fraction only. But we tend to put more efforts on coding instead of requirements.

As a reference, do read this journal article:
http://www.springerlink.com/content/m9404w6639063h7g/

For managers, see what is the value of poor requirements analysis with respect to cost (managers would definitely be attracted when shown something associated with cost
Requirements analysis on basis of ROI

As per Fred Brookes:

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part of the system is more difficult to rectify later.”

Brooks, F., “No Silver Bullet: Essence and Accidents of Software Engineering”, IEEE Computer, Vol. 20, No. 4, April 1987, p. 10-19.

Coming back to our point, who should take the action ? Of course the decision makers who decide how much time to put on requirements analysis & what methodologies to adopt for requirements gathering, analysis and management. If managment itself does not know the importance of requirements and its impact, then how the choas created by the end of the project will be overcomed.

As a first step, we need to know ourselves what impact requirements have on projects. There’s a wealth of historical information that proves that projects started without written requirements are doomed to fail. As Jones said:

“A significant and important aspect of requirements errors is that if they are not prevented or removed, they tend to flow downstream into design, code, and user manuals. Historically, errors which originate in requirements tend to be the most expensive and troublesome to eliminate later.”

Jones, C., Software Quality: Analysis and Guidelines for Success, International Thomson Computer Press, 1997

The next step is to get Management to understand the importance of requirements and to require that requirements are a mandatory part of your development process, a step that can’t be skipped no matter how intense the pressure is. Management commitment to having well-written requirements is essential.

The most neglected part is our lack to learn from our past mistakes. We do not do post mortem of past projects to learn from them and not to repeat the same mistakes. Offshore companies are always eager  to find short cuts to reduce time and in turn cost. The first approach they adopt is to spend as little time on requirement gathering, analysis and management as possible that in turn produces problems by the end of the project.

To conclude, getting the requirements right is the key to getting the software right. With poorly written, incomplete, and ambiguous requirements, it’s difficult  for software guys to know what to build & for QA guys to know what to test.

admin Management Conceptual Work, Cripples, Decision Makers, Historical Information, Impact Requirements, Methodologies, requirements, requirements analysis, Requirements Management, Software Engineering, Software System, Software Systems

I have always wondered why producing an error is sometimes OR often treated as a sin. One of the major reason is the illusion that software development is somewhat similar to production. On the basis of this illusion, it is considered that:

• Errors can be eliminated.
• Humans can be treated as interchangeable parts.
• Processes can be followed blindly

The above and a lot more illusions can be associated within a production environment but not within development environment. For a thinking worker, making an occasional mistake is natural and healthy as well. But an error on job should be discriminated from a sin. One very clear definition says that errors can be recovered but a sin is not reversible. So if something is reversible that should not be considererd a sin.

For instance, if a product is designed and somehow design changes are required such that the older design need to be thrown away. Management tend to be very strict about it but it needs to understand that it is part of the design activity and that is what design phase is all about. Managers feel this would pose an impossible  political problem for them. They seem to believe that they’d be better off using the same defective version even though it might cost more in the long run. Prevailing an environment that does not allow for error simply makes people defensive. They stop doing any experimentation and looking for new horizons. It happens usually when strict methodologies are imposed. Rather the people should be encouraged to make some errors by asking them what dead end roads they have been throw in their career. Think if any of your people says they have not produced any errors, it will make you feel the opponenet is either a dumb or making you a fool. All those dead end roads make up your experience after all.

Managers need to understand that they can kick the asses to make people active but not to make them creative. Creativity is required in every job that requires head rather than hand. Managers tend to adopt an attitude that everyone is replaceable. Using this mentality, it seems like manager may place an order in store like: “Send me a new Grady but make him less arrogant”.

admin Management Creativity, Defective Version, Design Changes, Design Phase, Development Environment, Job, Methodologies, New Horizons, Occasional Mistake, People, Production Environment, Sin, Software Development