Why Requirements

Software development as a craft?

As with any profession we should continue to perfect our craft. I'll begin this blog with a discussion about requirements and see where this leads. While I have my opinion on certain matters, I honestly want to know what others think. I remain open to change myself as I know reads of this blog are. On with the journey...

Software requirements are the foundation of any software development effort. Regardless of whether you collect the requirements up front or through-out development, all requirements will be known. If documented they will remain known else they will be known in the form of tribal knowledge.

Why do some resist following process which includes requirement discovery while others embrace it? Is there a cowboy mentality in our community or is it simply more efficient to code a little, gather a few requirements, then code a little more? For those who embrace process, is it possible that a certain comfort is found in a predictable process oriented environment?

So is it worth the effort to develop our craft as software programmers? Should we mature beyond the technical skill set and venture into the unknown?

Requirement Statistics:

What is the unknown? In fact much of this process driven world provides imperial proof of its claims. Here are some facts.

Concerning defects injected into requirements:

Incorrect Facts: 40 percent
Omissions: 31 percent
Inconsistency: 13 percent
Ambiguity: 5 percent
Misplaced: 2 percent

Over 70 percent of defects are due to incorrect and omitted facts.

How much more misunderstanding do we have when no value is placed on gathering requirements?

This is a real problem in our industry and in my mind is part of why software development is not the respected craft it should be. We are often viewed as an expense and in many cases rightly so.

Source of Errors and Cost:

According to the "Software Project Management Course Workbook (Pittsburgh, PA.:CMU/SEI/September, 1992). the following facts are true.

The following are where defects are injected into applications:

Requirements definition: 50%
Software design: 35%
Coding: 15%

So if requirements analysis is not held as critical then you can expect your defect rate to be at least doubled.

The following is the cost of fixing a defect at each stage, according to the same study:

Requirements definition: $150 per defect
Software design: $500 per defect
Coding: $1,100 per defect
Testing: $1,200 per defect
Deployment: $7,500 per defect

Conclusion:

Nothing else we do seems to matter if requirements aren't collected, scrutinized, and documented. Yes, it can take time but can you afford to not take the time. You will never be the first to market with a quality product without a well defined process and a culture that can deliver it. A process alone cannot deliver on the promise of that process. Software developers must perfect their craft of which software process is a part and a culture of quality must be promoted.

I have been on both sides of this issue but admittedly I am much more comfortable in a predictable environment. So my tendency will always be to promote process and as a human I will seek proof that process is a necessary part of the craft. Having fully disclosed my tendency and bias, I welcome all comments and opinions.