Channels ▼

Requirements Engineering Patterns

May 2000: Thinking Objectively: Requirements Engineering Patterns

Requirements engineering–the elicitation, documentation and validation of requirements–is a fundamental aspect of software development. Unfortunately, and to the detriment of everyone involved, requirements engineering efforts are often shortchanged or even completely forgone in favor of "getting the code out as soon as possible, at all cost." This month I share my experiences and observations regarding requirements engineering, present several requirements engineering patterns that you should find valuable to your software development efforts, and suggest several good books that describe how to successfully engineer requirements.

First, let’s define several important terms. A pattern is a solution to a common problem, taking relevant forces into account and enabling the reuse of proven techniques and strategies. Patterns can be described in template form (three patterns are presented in template form in the sidebar) or in degenerate form (that is, in prose). A pattern language is a collection of patterns that together describe how to completely address a large problem space, such as requirements engineering. A software process is the definition of the steps to be taken, the roles of the people performing those steps, and the artifacts being created or used by an organization to develop, operate and support a software product.

How do you go about defining requirements? In "Requirements by Pattern" (Dec. 1999), Christopher Creel, of TRC Inc., presented three patterns–Specify, Presentation and Prioritize–that encapsulate three strategies for documenting requirements. The intent of the Specify requirement pattern is to specify how an actor can identify an object, reducing the coupling between the method to find an object and the operations that are performed on that object. For example, in Windows Explorer, selecting its name from a list specifies a file. The intent of the Presentation requirement pattern is to describe the data that an application must present, enabling you to focus on the information to display, not how to display it.

Creating a Summary Report

Thus, to create a customer summary report, you would indicate that it presents the customer’s name, phone number and address; you would not state that the customer name is shown in an Acme Corp. text widget for Java. The intent of the Prioritize requirement pattern is to communicate the urgency of one application aspect over another without specifying the exact implementation for communicating that priority. For example, items in a list may be color-coded to indicate priority or sorted in a defined order. Although these patterns do not form the basis for a complete requirements engineering pattern language, they do reveal that patterns are a viable approach for describing common approaches to requirements engineering.

Why requirements engineering? My experience is similar to Suzanne and James Robertson’s statement in Mastering the Requirements Process (ACM Press, 1999): "If you do not have the correct requirements, you cannot design or build the correct product, and consequently the product does not enable the users to do their work." In fact, this concept is one of the main motivational factors behind the Requirements First pattern described in the sidebar. Requirements engineering is a fundamental aspect of traditional software processes–such as the waterfall approach–and of modern-day processes, such as the Unified Process. Figure 1 depicts the enhanced life cycle for the Unified Process, described in greater detail in The Unified Process Elaboration Phase (R&D Books, 2000), and, as you see, its Requirements workflow is an important aspect of the Inception, Elaboration, Construction and Transition phases of a software project. The implication is that you ignore requirements engineering at your own peril.

Figure 1. The Enhanced Life Cycle for the Unified Process

The requirements workflow is an important aspect of the Inception, Elaboration, Construction and Transition phases of a software project.

There is more to requirements engineering than its technical aspects–the politics are just as crucial to your success. I would love to live in a world in which I could focus on the technical nuances of a software development project, but, unfortunately, I just can’t seem to find that mystical nirvana that all techies seem to seek.

Competing for Resources

Every project on which I have worked has had to compete for resources, fend off "attacks" from groups with different agendas and, more often than not, work through its own internal team politics. Over time, I have applied two patterns to overcome a wide range of political challenges: Requirements As Shield and Requirements As Stick. I apply Requirements As Shield whenever someone is criticizing the work of my team, ideally showing that the criticisms are not relevant to the problem at hand, based on our defined requirements. Sometimes we discover that our requirements are not complete, which is likely what my team’s detractors were hoping for. However, this is a good result, because we want to discover any defects early in our project so we can correct them while they are still inexpensive to fix.

Refer to Steve McConnell’s Rapid Development (Microsoft Press, 1996) or my own Process Patterns (Cambridge University Press, 1998) for discussions of the rising cost of fixing defects the later they are found.

Conversely, I apply Requirements As Stick to counteract any approaches or strategies proposed by developers or teams that I believe are not in the best interest of my organization: By evaluating these proposals against accepted requirements, you can quickly see any weaknesses.

I apply this pattern so often that my coworkers know they are in trouble whenever I ask the question, "So, do you have any requirements for that?" Taken with Creel’s initial requirements patterns, we have a bare-bones start at a pattern language for requirements engineering. Our hope is that others will add to this collection of patterns over time, evolving it into a full-fledged pattern language. In fact, feel free to e-mail me at [email protected] and Chris at [email protected] with any suggestions.

Good References Available

Fortunately, there are many good requirements engineering books available. The book I would suggest is Software For Use by Larry Constantine and Lucy Lockwood (ACM Press, 1999), which focuses on usage-centered design techniques such as essential user-interface prototyping and essential use-case modeling.

A close second is Software Requirements by Karl Wiegers (Microsoft Press, 1999), in which he presents a broad overview of requirements engineering best practices.

As I mentioned, I also like Suzanne and James Robertson’s Mastering The Requirements Process and Managing Software Requirements by Dean Leffingwell and Don Widrig (Addison Wesley Longman, 2000); both books are good resources for anyone interested in learning about a wide range of new or traditional requirements techniques.

Finally, to learn more about use-case modeling in particular, I highly suggest Applying Use Cases by Geri Schneider and Jason P. Winters (Addison Wesley Longman, 1998) and Use Case Driven Object Modeling With UML by Doug Rosenberg and Kendall Scott (Addison Wesley Longman, 1999). Both books are short, to the point and easy to understand.

Requirements engineering is an important and fundamental aspect of software development. Regardless of the techniques you employ–interviewing, use-case modeling, essential prototyping, Class Responsibility Collaborator (CRC) modeling–the basics still remain the same.

You should start any development or development-related effort by identifying requirements: those that you will not only use to ensure that you are building or buying the right thing, but also those that will help you overcome the political roadblocks that you’ll inevitably encounter.

Author’s note: Special thanks to Chris Creel, who provided several key insights for this column.

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.