|
Many process models and methodologies for requirements development have been proposed over the years. Such process models are all intended to help project practitioners deal with the difficult challenges of eliciting, analyzing, specifying, and validating requirements. The models identify a series of steps that the analyst might go through when exploring requirements or a set of activities to perform. They might also propose a rich template for organizing and recording the information that comes out of requirements development. Some of the models introduce novel ways of thinking about requirements, which can be difficult for some analysts and organizations to adopt even if they have merit.
A variety of models have been published in research and professional journals (often labeled with clever acronyms), but to my knowledge most of these are not widely applied in industrial practice. The Volere method from James and Suzanne Robertson (www.volere.co.uk; Mastering the Requirements Process, Second Edition (Addison-Wesley, 2006)) is one of the best known of the pragmatic requirements development process models. Two others are:
- The problem frames technique proposed by Michael Jackson (Software Requirements and Specifications, Addison-Wesley, 1995). Practical Software Requirements by Benjamin Kovitz (Manning Publications, 1999) provides an example of how to apply the problem frames approach).
- The Zachman information systems architecture developed by John Zachman (zifa.com). Patricia Ferdinandi's book A Requirements Pattern (Addison-Wesley, 2002) provides an illustration of how to apply the Zachman framework.
I don't consider techniques such as use cases, the UML (Unified Modeling Language), or agile development to be requirements process models. Certainly, these encompass practices that can fruitfully be applied to appropriate project situations, but they don't represent cohesive requirements process models.
Any model or methodology needs to be adapted to best suit the needs of your project and organizational culture. A methodology or process model is not a script to be followed blindly. Rather, it's a guide that reminds the practitioner to consider whether certain activities might contribute to the project's success. I use the term "shrink to fit" when discussing processes and templates. The concept is that you start with a comprehensive process or template and then shrink it to suit the nature and size of your project, using the parts that add value.
|
|
 |
My own approach to requirements development has three components, as described in Software Requirements, 2nd Edition (Microsoft Press, 2003). First, I describe a simple process framework that identifies requirements development activities that most projects should consider performing. These include defining the vision and scope, identifying user classes and their representatives, identifying use cases, modeling requirements, prioritizing requirements, developing prototypes, and others. Second, I provide a tool kit of several dozen "good practices" that teams can use to perform the various activities in the process framework. Third, I offer a set of templates (www.processimpact.com/goodies.shtml) for recording the information that comes out of requirements development. I prefer this process framework and tool kit approach to requirements development over the methodology or formal process model approach.
|
