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.