Channels ▼


So What Are Requirements?

Karl E. Wiegers

Principal Consultant with Process Impact and author of several books on requirements, including Software Requirements, Second Edition (Microsoft Press, 2006).

DDJ: When it comes to software development, what are "requirements"?

KW: Ahh, this is where the problems begin. Different people have many different ideas of what requirements are and are not. Debates rage over the distinction between requirements and design and about what to call requirements of different types. A colloquial definition from my friend and colleague Brian Lawrence provides a good starting point: A requirement is anything that drives design choices.

But to be a bit more thorough, it's important to put some adjectives in front of the word "requirements." I think in terms of three levels of requirements for a software project. At the top level are the business requirements, which describe the business objectives for the project and address the question of why we're undertaking the project. Next, we have user requirements, which describe what users will be able to do with the product. Use cases are one good way—but not the only way—to represent user requirements. Functional requirements, the third level, describe what the developer must implement.

Besides these three primary levels...other kinds of requirements include quality attributes (also called quality-of-service requirements), design and implementation constraints, external interface requirements, data definitions, and more. Requirements information, then, encompasses a broad range of knowledge. It's important to distinguish these different types of requirements rather than just speaking of (or arguing about) "the requirements."

DDJ: Who defines a project's requirements?

KW: Requirements development must be a collaborative activity. I don't use the term "gathering requirements" because it implies that requirements elicitation is a collection process. In reality, it is a collection process, a discovery process, and an invention process. No single individual is likely to have all the knowledge that leads to defining a clear set of requirements for any project. Instead, you need to identify various stakeholders who can contribute to the gathering, the discovery, and the invention.

The key players, though, generally consist of one or more requirements analysts working with one or more customer representatives. The requirements analyst leads the requirements development activities. The analyst function is a project role, not necessarily a job title...On the customer side, I like to identify a small number of "product champions" who can serve as the literal voice of the customer for specific user classes. In addition, subject matter experts and other key stakeholders could participate in requirements development. Customer representatives must be involved on an ongoing basis throughout the project. Requirements development demands an iterative and incremental approach; hence, the need for a close collaborative partnership between analysts and customer representatives.

DDJ: You've identified 10 traps to avoid when collecting, documenting, or managing software requirements ( Is there any one of these that stand out in your mind?

KW: Two, actually. One of the most serious traps is inadequate customer involvement. Sometimes, customer representatives aren't included at all; a product manager or developer team just decides what to build. In other cases, the wrong individuals serve as customer representatives[and] don't do a good job of identifying needs. Another aspect of "inadequate customer involvement" is that users participate only at the very beginning of the project, rather than on an ongoing basis. The developers need many contact points with appropriate customer representatives during the course of the project. A second common trap is the problem of vague and ambiguous requirements. Many of the requirements specs I read have grammatical problems, missing information, incorrect word usage, boundary value problems, confusing use of negative requirements, and other ambiguities. These problems can lead various readers to come to diverse interpretations of the requirements, which is not a formula for successful software development.

DDJ: What are some ways requirements change over the life of a project?

KW: The biggest change is likely to be growth in the set of known requirements. This is the dreaded "scope creep" that affects so many projects...stakeholders will remember things they forgot to mention earlier, change their minds, discover previously hidden business rules, and so on. Therefore, it's essential to build contingency buffers into your schedule to accommodate requirements growth.

Requirements can also change if the business changes during the course of the product development. New laws, regulations, external standards, business policies, and operating environments can force requirements changes.

DDJ: How has the growth of off-shore outsourcing impacted the requirements process?

KW: Requirements engineering is primarily a communication activity, and it takes surprisingly little geographic separation to impede effective communication. When design and construction are going to be performed elsewhere, there are fewer opportunities for the day-to-day interactions that are needed to clarify and refine requirements issues. This separation increases the cycle time for answering questions, resolving ambiguities, and filling gaps in the documented requirements. It also leads to more guessing on the part of the off-shore developers, potentially slower development, and extensive rework...If you plan to outsource development, think carefully about how detailed the documented requirements need to be. One approach is to write more detailed documentation than you might if customer representatives were readily available to quickly resolve issues. A contrarian option is not to write comprehensive requirements, but rather, to leave a lot of the requirements details up to the off-shore development team. This can work in certain situations, but it will be a disaster in others. A third strategy is to make a knowledgeable customer representative available on-site at the off-shore location to provide that necessary quick turnaround on questions.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.