The concept of requirements plan is on the right side. 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. Requirements change and intellectual rework are largely the result of lack of planning that include defining requirements quality and a sound methodology.
A plan communicates
a shared vision, expectations, timeline, understanding, and deliverables.
The project background identifies, among other things, the type of
software from which methodology is conceived. A methodology
covers
(1) key disciplines, (2) a number of method packages each
of which falls within one discipline, (3) a set of elements that consist
of work products and work product descriptions (i.e. templates), and
(4) reusable roles responsible for work products. The methodology addresses questions concerning the nature of the problem space. |
|
Table of Content
Purpose
Project Background
Methodology
Requirements Architecture
Suggested Strategy
Requirements Process
Industry Requirements Best Practices
Appendices:
- Disciplines
- Quality of Requirements
- Roles and Descriptions
- Work products template
|
|
Requirements architecture is the project database architecture that defines the overall requirements artifacts and their relationships. The plan calls for a "suggested strategy." The strategy might include the following steps:
- Identify subject matter 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 for use in managing the requirements process.
- Utilize a set of mechanisms for facilitating the needed work.
|
A process comprises a set of interrelated process components each of which consists of set of methods, elements, and process owners. 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. Industry requirements best practices should be considered for use on your project. Examples include partnering, having a requirements policy and process, discovering the real requirements, having an organizational requirements working group, and measuring the return on investment (ROI) of using these best practices.
The plan should not be complete at start but contains some workable elements for general guidance for a project. The plan shall evolve into an organizational standard template over time. |
