Requirements Planning: A Little-Used But Valuable Technique
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
It's well known and understood by most people that a bit of planning goes a long way. Yet we frequently charge ahead with the "doing" with little or no planning, don't we? It's human nature to want to get on with the "real work."
Systems-development and software-development managers and practitioners are typically familiar with several types of plans: project plan, systems-engineering management plan, quality assurance plan, configuration management plan, software development plan, and so on. However, the concept of a requirements plan (see Figure 1) is probably new.
){kind=link}
Table of contents for a requirements plan.
Note that this plan calls for a "suggested strategy." The strategy might include the following steps:
-
Identify subject matter experts (or "domain experts") to perform requirements-related activities.
-
Consider alternative industry-strength automated requirements tools and select one.
-
Study how to evolve the real requirements from the stated requirements.
-
Identify a few useful measures (or "metrics") for use in managing the requirements process.
-
Utilize a set of mechanisms for facilitating the needed work.
Industry experience indicates that you get the best results by investing 8-14% of the total projected project costs in requirements activities throughout the development effort. (See Effective Requirements Practices page 62.) These activities might include the following:
-
Understanding the customers' needs
-
Identifying requirements
-
Clarifying and restating requirements
-
Analyzing requirements
-
Defining requirements
-
Prioritizing requirements
-
Deriving requirements
-
Partitioning requirements
-
Allocating requirements to the components of the system
-
Tracking and managing requirements
-
Testing and verifying requirements
-
Validating requirements
The Process Approach
These activities should be crafted into an organizational requirements process that's tailored for specific projects. This approach enables reuse and continuous improvement of the process. It should be apparent to both managers and practitioners that this is a valuable, highly leverageable investment.
The Software Engineering Institute (SEI) has documented the benefits of a process approach. Over an average time of five years, typical improvements are a 200% increase in productivity, a 46% reduction in cycle time, and a 90% reduction in defects (SEI Technical Report, CMU/SEI-94-TR13, August 1994).
A process approach implies the following:
-
Establishing a set of organizational and project policies.
-
Documenting a process for each process area; for example, requirements, project planning, project tracking, quality assurance, configuration management, and peer reviews. The documented policy might include a flowchart accompanied by a narrative process description that explains relevant aspects. The flowchart would provide the project with a documented way of performing these tasks. It would serve as a base to start continuous improvement. It could even become the organizational standard for that process, with each project being expected to tailor it to meet individual project needs.
-
Providing training for developers so that they become familiar with policies and processes.
-
Creating a set of reusable assets or artifacts to facilitate reuse, reduce costs, and enable evolution of an organizational approach.
-
Establishing ethics of quality improvement and continuous improvement. Institutionalization of these values will help your project and organization with retention and reduce personnel turnover and its associated disruption and costs.