It Is Still The Requirements

[article]
Getting Software Requirements Right
Summary:

Why are information systems requirements so difficult to define? What causes the yawning chasm between documented requirements and the actual implemented system? Requirements definition is difficult for two major reasons. First, the customer may have only the vaguest idea of what an information system should look like prior to implementation and use. Second, system developers lack sufficient knowledge of the business functions a system must support.

Four Requirements Definition Assumptions

According to a recent article by Ed Yourdon in "Computerworld," software engineering literature and most requirements management methodologies often assume users understand their requirements perfectly; they just can't articulate or document them. The analyst needs only to clarify ambiguity to elicit the requirements. This prescription causes constant change, frustration, and failure to deliver systems that remotely address customer requirements.

Software development personnel who are responsible for requirements "elicitation" often start with four basic--usually erroneous--assumptions:

  1. Customers can define their systems requirements.
  2. The software development organization is a "customer"--not the "owner" of the process.
  3. Requirements management starts after requirements have been defined.
  4. The customer "owns" the requirements.

The dichotomy between those analysts who believe the customer is responsible for requirements definition and those who believe the customer is not capable of providing this information, at least to the level of detail and precision that is required, leads to widely divergent courses of action.

If you believe that customers are responsible for defining their requirements, you will primarily employ interviewing and "elicitation" techniques to obtain requirements. The definition of elicit is "to draw or bring out or forth; educe; evoke." The customer often perceives this as "extraction" or even "extrusion."

Using this method, you are at your customers' mercy--you know only what they tell you. Requirements will almost certainly be incomplete. Even if customers appear unable to define their requirements, you may believe that they are not only able to do so, but that they are responsible for doing so. You may believe that the correct elicitation tools and techniques will achieve success.

The same dichotomy exists between systems analysts who believe they are "customers" of the requirements definition process, accepting and documenting the output of that process, and those analysts who believe they must "own" the process, taking responsibility for defining the completeness, consistency, and quality of the requirements.

Too many organizations that produce and market requirements management tools self-servingly insist that requirements management begins after requirements have been identified. Requirements management begins at project inception, starting with problem identification, and continuing through a request or feasibility process. What problem are you trying to solve? What business need are you addressing? These questions determine your requirements. Problem definition must be managed.

Requirements belong to the software developers. The developers, not the customers, must develop systems that meet those requirements. The customer must ultimately "own" the product, the deliverable system, but only if it meets their requirements.

What Are The Customer's Requirements?
Defining customer requirements is the most difficult task we face; it is also the most error prone. Over fifty percent of all errors enter the process at the requirements definition phase. How can information systems professionals meet customer requirements when no one--including the customers--knows exactly what these requirements are?

A sincere software developer once told me, "You never know what the user's requirements are until the testing phase, so let's code something and see what happens." Fortunately, we have tools and techniques that assist in properly and completely defining customer requirements prior to the testing phase.

I use and recommend a six-step approach to make this process easier and less error prone.

Step 1: Know Your Markets
World class organizations are proficient at satisfying and delighting customers. They intensively study their customers. They develop joint-problem solving teams. They collaborate with customers in product design and development. They conduct extensive surveys. They are aware of their customers' strategic direction. And, importantly, they have excellent intelligence about their organization's competitors.

You cannot invest too much time in learning about your customers and their business. If information system organizations primarily

Pages

About the author

James A. Ward's picture James A. Ward

James A. Ward is a management consultant specializing in project management, PMO implementation, interim IT management, implementation of quality, and process improvement initiatives in IT organizations. He offers seminars and workshops in project management, quality improvement, requirements definition, risk management, and Microsoft Project.

James is a PMP certified project manager. He resides in Richmond, Virginia, and can be reached at (804) 303-4755 or via e-mail at soozward@earthlink.net. Further information is available on his web site at www.JamesAWard.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03