Each month, Food for Thought™ will include articles on a variety of topics related to software development, software engineering, and software quality.

Included in this first issue is an article on the importance of good requirements.

Regular features to look for each month are:

• Monthly Morsel: Hints, tips, techniques and reference info related to this month’s topic

• Calendar: Conferences, workshops, and meetings of interest to software engineers, QA engineers and anyone interested in software development.

It’s the Requirements, Stupid!

As we enter the political season, I am reminded of a famous message from an earlier election year. “It’s the economy, stupid” was made famous by political strategist James Carville who hung a sign in Bill Clinton's Little Rock campaign office to keep everybody "on message" in the 1992 election.

Wouldn’t it be great if we could hang a sign that reads “It’s the requirements, stupid” and have everyone focus on that message?

Did you know that almost two-thirds of all software defects are related to requirements? Coding errors account for only a small fraction of the total defects found. Yet, we tend to expend several times more effort on coding than we do on requirements. Why?

For quite some time, we in the software engineering community have known that requirements are important. As Fred Brooks said:

“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.

When it comes to learning from past mistakes, we have failed miserably

Past performance is the best predictor of future performance. The problem is that all too often we ignore what we’ve learned from the past. We skip over the most important part of the process – figuring out what we need to do – and jump right into coding. Why does this continue to happen?

Management

A certain amount of blame for the current situation can be laid at the feet of Management. In many organizations, Management does not insist on getting the work right the first time. Yet, they are up in arms when this does not happen. In many software organizations, Managers have not been trained in basic quality methods. If these managers are not trained in these methods and as a result, do not believe that they are effective, how can organizations produce quality work? Is there anyone who doesn’t believe that doing quality work takes less time and money?

Software Engineers

Software engineers are partially to blame too. Many software engineers are most interested in coding and have little inclination to work on other tasks, like architecture and design. They are quick to give estimates based on sketchy, ill-thought out requirements. How often has a software engineer told a Manager, “I can’t tell you how long it will take without seeing the requirements.” I’m sure it happens, but not nearly as often as it should.

Academic Institutions

Universities deserve some blame too. They are not teaching students about the importance of process, about the importance of architecture and design, or about the importance of requirements. Many universities are focused on teaching programming skills not software engineering skills. For example, I dare you to find a course in software estimating that is required as part of an undergrad Computer Science or Software Engineering program.

Pressure to produce tangible results

Pressure to deliver products can also be blamed for ignoring the past. Most companies are under tremendous pressure to deliver. In order to deal with this pressure, many organizations look for short cuts – the most obvious short cut being – don’t waste time on requirements, start coding as soon as possible. This, even though we have decades of history that says you shouldn’t start coding if you don’t know what is you are being asked to build. “We never have time to do it right but always have time to do it over”. Does this sound familiar?

A Software House of Cards?

Imagine if instead of developing software, you are building an expensive house. Wouldn’t you expect that before you started pouring the foundation, you’d have detailed drawings that showed what the finished house should look like, inside and out? Of course you would. And why is that? Well, it’s because architects and general contractors have determined that having architectural drawings and blueprints is the most cost-effective way to build houses. Do you think they would go to all the trouble to create drawings and blueprints if they weren’t necessary?

Now you may ask, how does building houses relate to developing software? Well just think about it. When you build a house, there is usually a general contractor (on software projects we call this person the project manager), there are skilled trades people like carpenters, plumbers, electricians (on software projects there are developers, QA engineers, and tech writers). When building a house, it must pass several inspections to ensure that the work meets the national and local building codes (not unlike inspections on software projects). So, you can see that there are striking similarities between building houses and building software.

Getting the requirements right is the first step to getting the software right.

Without well-written, complete, and unambiguous requirements, it’s difficult to for software engineers to know what to build and for QA engineers to know what to test.

Getting the requirements right is also a Best Practice that has been recognized by the Software Engineering Institute (CMM SM Level 2 Key Practice Area), the Airlie Council, and hundreds of companies surveyed by Capers Jones.

What can you do? Well, start by educating yourself about the impact requirements have on projects. There’s a wealth of historical information that proves that projects started without written requirements are doomed to fail. For example,

“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.

Lastly you’ll also want to learn how to do a better job of writing requirements. For this, there are a few workshops that may be helpful. See the Calendar below for more details. For additional information on requirements, I’ve included some reference information in the Monthly Morsels below.

If you want to improve your software development process, the place to start is at the beginning – with the requirements.

One last thing, remember to vote on November 2nd.

Every month in this space you’ll find reference information related to this month’s topic. This information may include hints, tips, techniques, as well as reference information such as books and articles that are directly or indirectly related to this month’s topic…

Tips and Techniques

Two of the most useful techniques I’ve learned regarding requirements are:

1. Use Pictures— Pictures are truly worth thousands of words when it comes to requirements. They are much less ambiguous than words and can convey highly complex information more easily than words.

Examples of pictures you can use are: Use Case diagrams, work flow diagrams, state diagrams, data flow diagrams, etc.

2. Use Structured English—Structured English (also referred to as pseudocode) is English written within the basic structures common to most programming languages. The vocabulary used when writing requirements in structure English should be the vocabulary of the problem domain, not of the implementation domain.

For example, writing requirements in structured English would look something like this:

IF Hours worked this week > 40

THEN Compute overtime pay
Overtime Pay = (Hours worked -40) * overtime hourly rate

ELSE Compute regular pay
Regular Pay = (Hours worked) * regular hourly rate

ENDIF

Three basic constructs for control flow are sufficient to specify requirements:

SEQUENCE is a linear progression where one task is performed sequentially after another.

WHILE is a loop (repetition) with a simple conditional test at its beginning.

IF-THEN-ELSE is a decision (selection) in which a choice is made between two alternative courses of action.

Although these constructs are sufficient, it is often useful to include three more constructs:

REPEAT-UNTIL is a loop with a simple conditional test at the bottom.

CASE is a multiway branch (decision) based on the value of an expression. CASE is a generalization of IF-THEN-ELSE.

FOR is a "counting" loop.

Using structured English can help reduce or eliminate much of the ambiguity associated with requirements when written in narrative style.

Click here for more information on structured English and pseudocode.

Conferences

12th Annual International Conference on Requirements Engineering

Proceedings of 11th Annual International Requirements Engineering Conference