Food for Thought: The Importance of Having Good Requirements
An e-newsletter published by Software Quality Consulting, Inc.
September 2004, Vol. 1 No. 1

To view a web version of this newsletter, click on the following link:
http://www.swqual.com/newsletter/vol1/no1/vol1no1.html.

------------------------------------------------------------------------ 
 
***In This Issue***

Welcome to Food for Thought(TM), a free monthly newsletter from Software 
Quality Consulting (http://www.swqual.com/). I've added you to this 
subscription list because you are one of my valued business contacts. 
I hope you will find it informative and useful. And of course, please 
feel free to share this newsletter with your colleagues by clicking the 
Forward Email link at the bottom of this newsletter.

If you wish to continue receiving this newsletter, you need do nothing-it 
will arrive in your in-box every month. If would rather not receive it, 
simply click the SafeUnSubscribe(TM) link at the bottom of this newsletter, 
and we won't bother you again.

Your feedback on this newsletter is most welcome. Please send your 
comments and suggestions to [email protected].

Each month, Food for Thought(TM) 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.

---------------------------------------------------------------------------

***Monthly Morsel***

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

Goldsmith, R., Discovering the REAL Business Requirements for Software 
Project Success, Artech House, 2004.

Wiegers, K., Software Requirements, Microsoft Press, 1999.

Gause, D. and Weingberg, G., Exploring Requirements: Quality Before 
Design, Dorset House, 1989.

Articles

Robertson, S., "Requirements and the Business Case", IEEE Software, 
Sept-Oct 2004, pp. 93-95.

Salit, R., "Requirements are Corporate Assets", IEEE Software, May-June 
2003. pp. 86-88.

Anton, A., "Successful Software Projects Need Requirements Planning", IEEE 
Software, May-June 2003, pp. 44-47.

Neill, C., and Laplante, P., "Requirements Engineering: The State of the 
Practice", IEEE Software, November-December 2003, pp. 40-45.

Robertson, J., "Eureka! Why Analysts Should Invent Requirements", IEEE 
Software July-August 2002, pp. 20-23. 

Conferences 

12th Annual International Conference on Requirements Engineering 

Proceedings of 11th Annual International Requirements Engineering 
Conference

---------------------------------------------------------------------------

***Calendar***

Every month, you'll find news here about local and national events that 
are of interest to the software engineering community.

-----------------------

InfoXchange 2004 - September 30, 2004 Nashua, NH 

The Software Association of New Hampshire (SwANH) is sponsoring the 10 th 
Annual Conference in Nashua, NH on September 30, 2004. This year's theme 
is the value of technology in business. Learn more.

-----------------------

ASQ Software Division Postpones 14 th International Conference on Software 
Quality

The Software Division of the American Society for Quality recently 
announced that 14 th International Conference on Software Quality has been 
postponed from October 4-6, 2004 to March 21-23, 2005. The conference will 
be held at the Wyndham Orlando Resort. Learn more.

-----------------------

Software Quality Calendar

There are many organizations that sponsor monthly meetings, workshops, and 
conferences. Find out what's happening.

-----------------------

Public Workshops Offered by IEEE Boston Section

Are you interested in a workshop or short course on cutting edge topics? 
Learn more.

-----------------------

Public Workshops Offered by Software Quality Consulting

If you are interested in information about public workshops presented by 
Software Quality Consulting, Learn more.

-----------------------

If you know of an organization or event that isn't listed here and would 
be of general interest, please send me an e-mail with the details. 

---------------------------------------------------------------------------

***About SPC***

Software Quality Consulting provides consulting, training, and auditing 
services tailored to meet the specific needs of clients. We help clients 
fine-tune their software development processes and improve the quality of 
their software products. The overall goal is to help clients achieve 
Predictable Software Development(TM) - so that organizations can consistently 
deliver quality software with promised features in the promised timeframe. 
To learn more about us and how we can help your organization, visit our 
web site or send us an email.

Thanks for reading,
Steve Rakitin

Copyright (c) 2004. Software Quality Consulting, Inc. All rights reserved.