Requirements engineeringthe elicitation, documentation and validation of requirementsis 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, lets 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 patternsSpecify, Presentation and Prioritizethat 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 customers 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 Robertsons 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 processessuch as the waterfall approachand 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 aspectsthe 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 cant 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 teams 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 McConnells 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 Creels 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 firstname.lastname@example.org and Chris at Chris.Creel@trcinc.com 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 Robertsons 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 employinterviewing, use-case modeling, essential prototyping, Class Responsibility Collaborator (CRC) modelingthe 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 youll inevitably encounter.
Authors note: Special thanks to Chris Creel, who provided several key insights for this column.