There will be no surprises when the product is presented as complete. More importantly, the incidents of on-the-spot fixes that add up so quickly at the end of a project will be reduced significantly.
Determining Scope
The value of eliminating compound requirements can be seen at all levels, from upper management to project developers and from the customer to the quality assurance team. Only after compound requirements are eliminated can the true scope of the project be assessed, change control applied, testing be correctly managed, and meaningful metrics be collected.
A simple example of a compound requirement is: The user must be able to add, delete, and modify a row. What causes this to be a compound requirement are the multiple things that the user must be able to do. In determining the scope of the work, the compound requirement will be considered as one unit of work, when in fact to provide this capability within the system it may take three separate programs to make it happen. Additionally, if any portion of a compound requirement encounters a problem during testing, the entire requirement is shown as not satisfied. This can skew test result metrics.
To rid a project of compound requirements, identify the statements within each requirement, then make each statement a standalone requirement. This action not only helps to clarify the requirement, but it also provides a more accurate view of the size and scope of the project. The other thing that eliminating compound requirements does is allow requirement dependencies to be identified and tied together in a database.
ORGANIZING REQUIREMENTS
Now that the requirements are single-statement directives, it becomes easy to classify them by type. The three major types of requirements are:
§ Project requirements
§ System requirements
§ Subsystem requirements (also referred to as application, module, or functional requirements)
Project Requirements
Project requirements are the customer-imposed schedules, deliverables, and resources under which the project will operate. One example of a project requirement is “Each project will have an ABC company representative assigned to the production team.” Another might be: “The product will be delivered not later than (NLT) July 10, 199N.” Still another might be “Monthly Status Reviews will be conducted.”
System Requirements
System requirements are the performance, storage, protocols, standards, and conventions that must be met by the product. These requirements guide the development effort. Being able to reference easily the requirements list for system requirements ensures that decisions made by developers always will consider the goals for the product in setting down the development direction and methods.
Subsystem Requirements
Subsystem requirements are the product-specific content, capabilities, limitations, and look and feel of the planned end product. It is advisable to classify further functional requirements into logical groups of requirements, for example, purchasing and forecasting. Still further organizations may desire to ensure that art requirements, text requirements, and action requirements are identified and then arranged together in the flow of the logical grouping selected.
By classifying requirements, three very important things are accomplished. The first of these is staff composition because it should be clear what skill sets are needed.
The second is that it becomes easier to see what test scenarios need to be developed and when the test scenarios provide many (requirements) to one (test) opportunities and when multiple tests may be required to demonstrate the full capability of one requirement. This type of information helps in planning the overall testing effort because the scope of the effort can be predicted more accurately thus ensuring the machines, networks, and people needed for testing are in place when the system is ready to be tested.
The third thing classifying requirements is to simplify the change controls essential to managing requirements. The value in this is that during the course of the project should technology shift or requirements change, the total impact of the change can
be assessed because all components of the change will be identified early in the process. Neither the customer nor the developer will get to the end of the project thinking all is well only to find out that something fell through the cracks. The requirements list becomes easy to reference, maintain, and use when the requirements are classified by type.
Documenting Requirements
Documenting for maximum benefits means less work later. For example, when the different types of requirements are gathered and a numbering scheme ensuring distinction between the types of requirements is used, tracking and impact analysis is more easily performed. This distinction is important in tracking the requirements for compliance, gathering data related to the various types of requirements for analysis of performance, and quality. Being able to gather this information means developers readily and consistently can offer customers documented quality improvement on both technical and business fronts. Measurable data will become available from which determinations can be made regarding the size and scope of projects and the impact of technology issues.
Whether the classified requirements list is stored in a database, word processing tables, or a spreadsheet, it is important that it is located and formatted in such a way that it is accessible and useable to the majority of people on the team. The requirements list is a project asset and should be thought of as such. Management, the development team, and the customer have a ready tool for determining what is within the scope of the project and what is not.
REVIEWING REQUIREMENTS
When the requirements analysis has been completed and the requirements have been organized, then three types of reviews need to be conducted:
§ Peer reviews
§ Management reviews
§ Customer reviews
Peer Review
Peer review is made up of senior-level system designers and testers, preferably those who have had little or no involvement in the definition and analysis of the requirements for this project. They bring the objectivity needed at this point to identify ambiguous requirements, nontestable requirements and potential risks, and to make recommendations for imp rovement in the documentation of the requirements. Using the insight gained from the peer review, the system development team should get additional information from the customer as needed to develop corrections. When the proposed corrections have been developed, a management review should be conducted.
Management Review
Management review is the formal presentation of the requirements in terms of budget, schedule, and risks for the project. Executives, senior managers, marketing and account representatives, and quality assurance specialists need to participate in this review. The review itself should be structured to ensure that the output from it results in firm commitments to the creation and implementation of the detailed project plan for meeting the requirements. If this commitment is not strong at this point, it is an indication that one or more of the requirements needs to be further assessed for feasibility within the defined scope of the project budget and schedule.
This assessment must be made with the customer to achieve consensus on the requirements that will be met by the proposed system. When management has reviewed the requirements list and all modifications and adjustments have been made, a formal customer review should be scheduled and conducted.
Customer Review
Customer review should include the management review counterparts on the customer side, the customer project team, the development project team, and full quality assurance representation. The purpose of this review is to finalize the requirements list. This is accomplished by presenting the fully analyzed requirements list, presenting and explaining the differences between the requirements list and the initial wish list the customer presented, and providing the documentation that supports the information presented. The customer review should result in a requirements list that clearly states what the system will do, how it basically will operate, and what users can expect in terms of usability, ergonomics, and learning curves. At the conclusion of the customer review, all of the players who have a stake in the system development effort should be in agreement about what the project, system, and subsystem requirements are. The requirements list thus is finalized and baselined to ensure control of the requirements throughout the life of the project.
CONTROLLING REQUIREMENTS
Controlling the requirements may be the most important aspect of achieving success on a project and ensuring the full usability of the developed system. Control does not mean that there are never any changes to the original baselined requirements. It does mean that all of the stakeholders in the project are informed of and involved in a requirements control process that eliminates the single greatest threat to any system development project — requirements creeping.
Requirements creeping can and probably should be viewed as a villainous saboteur who, like a chameleon, takes on many different colors. This villain strikes out with only one purpose: get someone, anyone on the project, to make a change in the baselined requirements without assessing the impact and logical disposition of the change and informing all parties of the need for the change. To eliminate requirements creeping:
§ Make certain that there are baseline requirements.
§ Have a change control method in place for handling any type of modification to baselined requirements.