Requirements Checklist

Requirements Checklist:   Definition   Classification   Responsibilities   Questions   Guidelines


Requirements Checklist
an inspection checklist for use when evaluating the quality of the requirements


Requirements Checklist in the OPF Method Component Inheritance Hierarchy

As illustrated in the preceding figure, Requirements Checklist is part of the following inheritance hierarchy:


The typical responsibilities of a Requirements Checklist is to:


The Requirements Checklist includes the following types of questions:


Individual requirements should be cohesive, although the type of cohesion varies with the different type of requirements being specified:


individual requirements should also be complete. This is often a problem because subject matter experts (SMEs) who specify requirements often take certain information for granted and omit it, even though it is not obvious to other stakeholders of the requirement.


Because collections of inconsistent requirements are impossible to implement, individual requirements should be consistent:


Defects in requirements will naturally lead to corresponding defects in the resulting architectures, designs, and implementations. Thus, individual requirements should obviously be correct:


All too often, requirements specifications are not updated when requirements change. They are also frequently not updated as the architecture is produced, sometimes resulting in changes in the underlying requirements. Both of these problems make testing and maintenance much more difficult. Thus, individual requirements should not become obsolete:

Customer/User Orientation

Too often, requirements (especially derived requirements) are specified by developers who use their technical jargon that is not understandable to other stakeholders, especially customers, users, and managers. But individual requirements should be oriented around the needs of stakeholders other than customers and users if they are to be understandable and validatable:

External Observability

Requirements should not unnecessarily specify the internal architecture and design of a system, application, or component. Thus, individual requirements should only specify behavior or characteristics that are externally observable:


Requirements are of no value if the development team cannot implement them. Thus, individual requirements should be feasible given all relevant constraints:

Lack of Ambiguity

Individual requirements for a system, application, or component should never be ambiguous. Even if the requirement is intended to be highly reusable (e.g., across a product line) and therefore general, it should still be unambiguous although it may well have precise flexibility points (e.g., it can contain parameters that must be filled in with specific values when being reused). Yet, this critical characteristic of a good requirement is often missing, resulting in requirements that are subject to misinterpretation and that are therefore inherently not verifiable (e.g., they are untestable).


Although requirements can and should be prioritized to help negotiate and schedule them, individual requirements should by their very nature be mandatory (i.e., required):


Each requirement should have metadata (i.e., ancillary attributes or annotations) that characterizes it:


Some identified and specified “requirements” actually turn out to be outside of the scope of the current endeavor. Thus, it is important to ensure that individual requirements are relevant:


Just like systems, applications, and components, requirements have many users (e.g., management, customer representatives, marketing representatives, user representatives, architects, developers, testers, support personnel) that use them for many purposes. Thus, individual requirements should be usable by their numerous stakeholders:


Individual requirements must actually fulfill the needs and desires of their primary stakeholders. Individual requirements should be validatable:


Requirements always have sources, and it is important that requirements are consistent with them. Similarly, requirements need to be consistent with the standards, guidelines, and templates that are used in their preparation. Thus, individual requirements should be verifiable: