Requirements Checklist

Definition

Requirements Checklist

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

Classification

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

• Type: Concrete
• Superclass: Inspection Checklist
• Subclasses:
  • None

Responsibilities

The typical responsibilities of a Requirements Checklist is to:

• Improve the effectiveness of the requirements evaluation in terms of defects found (e.g., % of defects found).
• Improve the productivity of the requirements evaluation team when performing an requirements evaluation (e.g., average number of defects per inspector hour).
• Train the requirements team by clarifying to them the important quality characteristics their requirements will need (i.e., helping them prepare their requirements for the coming requirements evaluation).
• Thereby improve the quality of the resulting requirements.
• Thereby improve the quality of the resulting system.

Questions

The Requirements Checklist includes the following types of questions:

• Cohesiveness
• Completeness
• Consistency
• Correctness
• Currency
• Customer/User Orientation
• External Observability
• Feasibility
• Lack of Ambiguity
• Mandatory
• Metadata
• Relevance
• Usability
• Validatability
• Verifiability

Cohesiveness

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

• Does each requirement specify only one thing?
• Do all parts of the requirement belong together:
  • Do all parts of each data requirement involve the same data abstraction?
  • Do all parts of each functional requirement involve the same functional abstraction?
  • Do all parts of each interface requirement involve the same interface?
  • Do all parts of each quality requirement involve the same quality factor or subfactors of the same quality factor?

Completeness

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.

• Is each requirement self contained with no missing information?
  • Does each requirement contain all relevant information?
    • Does each requirement state all of the preconditions (e.g., system mode, environmental state, and operational profile) under which it is mandatory?
    • Does each functional requirement state the trigger that causes the function to be executed?
    • Does each quality requirement state the minimum acceptable amount of quality in terms of a threshold on an associated measurement scale that must be achieved?
    • Does each requirement state all of the postconditions that must hold if it is implemented correctly?
    • Does each requirement state all of the invariants (if any) that it guarantees if it is implemented correctly?
  • Does each requirement need no further amplification or clarification?
  • Does each requirement provide sufficient information to avoid ambiguity?
• If the requirement is not a part of the current release, then is it specified as completely and as thoroughly as is currently known?
• Are separate requirements specified separately?
  • Does each sentence specify only a single textual requirement?
  • Is each identified “requirement” a single requirement and not actually multiple requirements?
  • Is the use of conjunctions (“and” and “or”) restricted to conditions (i.e., preconditions, postconditions, and invariants)?

Consistency

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

• Is each requirement externally consistent?
  • Is each derived requirement externally consistent with its documented sources such as higher-level goals and requirements?
  • Is each requirement externally consistent with all other related requirements of the same type or specified in the same requirements specification? For example, two requirements should neither be contradictory nor describe the same concepts using different words.
• Is each requirement internally consistent?
  • Are the constituent parts of each requirement internally consistent? For example, are all parts of a compound precondition or postcondition consistent?

Correctness

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

• Is each requirement semantically correct (i.e., have the correct meaning) ?
  • Does each requirement meet all or part of an actual need of its relevant stakeholder(s)?
  • Is each requirement an accurate elaboration of a documented business objective or goal?
  • Is each derived requirement an accurate elaboration of a higher-level requirement?
  • Do all numbers (e.g., thresholds) associated with each requirement have correct values?
  • Is each requirement truly mandatory? (see below)
• Is each requirement syntactically correct (i.e., have the correct form)?
  • Does each requirement use the proper standard format (if any) for its requirement type? For example, quality requiremens consist of three parts: (1) conditions of applicability, (2) quality criterion, and (3) threshold on a quality scale of measure.
  • Does each requirement properly use the words “shall” or “must” rather than “will” or “may”?
  • Are all words used in each requirement correctly spelled?
  • Is each textual requirement correct in terms of:
    • Grammar?
    • Spelling?
    • Punctionation?

Currency

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:

• Is each requirement a specification of a current or anticipated customer or user need?
• Has each requirement not been obsoleted (e.g., due to changing business goals)?

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:

• Is each requirement phrased in the language of the appropriate stakeholders (e.g., members of the customer and user organizations)?
• Does each requirement avoid the technical jargon of the development organization?

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:

• Does each requirement only specify behavior and/or characteristics that are externally observable when treating the system, application, or component under development as a black-box?
• Does each requirement avoid specifying any internal architecture, design, implementation, or testing decisions (i.e., constraints)?
• If a requirement does specify one or more internal architecture, design, implementation, or testing decisions, is the requirement clearly identified as a constraint rather than as a pure requirement?

Feasibility

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

• Can each requirement be implemented given the existing hardware or software technology?
• Can each requirement be implemented given the endeavor’s:
  • Budget?
  • Schedule?
  • Constraints on staffing (e.g., staff size, expertise, and experience)?
• Can each requirement be implemented given the limitations of the physical universe (e.g., physics, chemistry, etc)?

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).

• Clear and precise meaning
  Is each requirement clear (i.e., not vague) and precise?
• Objective meaning
  Is the meaning of each requirement objective rather than subjective?
• Concise specification
  Is each requirement concise, succinct, simple, and straightforward (i.e., without unnecessary and irrelevant information)?
• Single interpretation
  Does each requirement have only a single interpretation? In other words, will the interpretation of each requirement be the same for the people who:
  • Wrote the requirement,
  • Evaluate the requirement,
  • Approve the requirement, and
  • Are members of the different audiences who will read and use it?
• Obvious interpretation
  Is the interpretation of each requirement obvious?
• Understandable meaning
  Requirements should be easy to understand:
  • Is each requirement understandable to its intended audiences?
  • Are textual requirements specified using short sentences and paragraphs?
  • Are textual requirements specified using active rather than passive voice?
• Concrete terms
  Does each requirement use specific concrete terms?
• Avoid vague words and phrases
  Does each requirement avoid the use of inherently or potentially ambiguous words such as:
  • Vague subjects that can refer to multiple things:
    • Nouns that may be too general such as “user”? Is there more than one type of user, whereby the requirement only applies to certain types of user?
    • Pronouns such as “it” or “they”?
  • Vague adjectives that may mean different things to different readers:
    • Demonstrative adjectives such as “this”, “these”, “that”, and “those”?
    • Intrinsic characteristics such as “soft”, “hard”, “fast”, “rapid”, “quick”, “slow”, “hot”, “cold”, “strong”, and “weak”?
    • Judgmental characteristics such as “easy”, “simple”, “difficult”, “hard”, “clear”, “efficient”, “acceptable”, “adequate”, “good”, “bad”, “reasonable”, “sufficient”, “useful”, “significant”, “adequate”, “improved” (if not explicitly associated with a previous level on some measurable scale), and “user-friendly”?
    • Location characteristics such as “near”, “far”, and “close”?
    • Numbering adjectives such as “few”, “many”, “some”, and “several”?
    • Ordering adjectives such as “first”, “last”, “previous”, “preceding”, “next”, and “following”?
    • Temporal characteristics such as “new”, “old”, “recent”, “future”, “past”, “soon”, and “today”?
  • Vague prepositions:
    • Prepositions such as “above”, “below”, “in front of”, “in back of”, “over”, “under”, “high”, and “low”?
  • Vague verbs that are more qualitative than quantitative:
    • Prepositions such as “increase”, “decrease”, “maximize”, and “minimize”?
  • Subjective phrases:
    • “If possible”, “when cost-effective”, “state-of-the-art”, and “where appropriate”?
• Quantitative rather than qualitative
  Is each requirement specified in a quantitative manner whenever possible and practical?
• Necessary conditions
  Does each requirement include all necessary conditions:
  • Preconditions (e.g., system state or environmental state)?
  • Postconditions?
  • Invariants?
  • Operational profile?
• Quality requirements
  Does each quality requirement go beyond merely “requiring” that the system, application, or component exhibit the associated quality factor? Thus, it is inadequate to merely state that the system, application, or component shall be portable; one must be explicit and specify how portable (e.g., maximum amount of effort to port) and portable to what (e.g., operating system, hardware platform, or infrastructure including version)?
• Abbreviations, acronyms, and/or technical terms
  If a requirement includes abbreviations, acronyms, and/or technical terms:
  • Are they defined in an associated endeavor or specification glossary?
  • Do they have only a single definition in the glossary?
  • Are they used consistently?
• References
  If a requirement contains a reference (e.g., to a table, diagram, or separate document), is the reference explicit, precise, and unique (e.g., to a specific cell in a specific table, to a specific paragraph in a specific version of a specific document)?
• Diagram legends
  Does each diagram associated with a requirement include a legend that defines its icons (e.g., nodes and arcs)?

Mandatory

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):

• Is each requirement essential to the success of the system, application, or component under development?
• Is each requirement truly necessary (i.e., a true requirement that must be met and implemented)?
• Is each requirement truly required by a legitimate stakeholder that is authorized to mandate requirements (e.g., the customer or user organization, a governmental or regulatory body)?
• Is each requirement free from unnecessary constraints (e.g., architecture, design, implementation, testing, and other technology decisions)?
• Does each requirement specify a “what” (e.g., functional, data, or interface requirement) or “how well” (e.g., quality requirement) rather than unnecessarily specifying a “how” (i.e., constraint)?
• Is each requirement clearly differentiated from:
  • A “nice to have” item on someone’s wish list (i.e., gold-plating)?
  • Constraints?

Metadata

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

• Acceptance Criteria:
  • Does each requirement have associated acceptance criteria?
  • Is this acceptance criteria clear and objective?
• Allocation:
  • Is each requirement allocated to the team or individual who will implement it?
  • Is each system requirement allocated to the system architectural elements that will fulfill it?
  • Is each software requirement allocated to the software architectural elements that will fulfill it?
• Assumptions:
  • Are all significant assumptions associated with each requirement properly documented?
• Identification:
  • Does each requirement have its own unique identifier that can be used for tracing purposes?
  • When lists should be used, are numbered lists used instead of bulleted lists?
  • Is each requirement not redundant with any other requirement at the same level of abstraction (e.g., within the same requirements specification)?
• Prioritization:
  • Is each requirement prioritized for scheduling and trade-off purposes?
  • Is the prioritization of the requirement based on the:
    • Criticality of the requirement to its stakeholders (e.g., customer, marketing, and user organizations)?
    • Scheduling from an architectural standpoint?
    • Implementation precedence?
    • The minimization of project risk?
• Rationale:
  • Does each requirement have a reasonable rationale associated with it that justifies it being specified as a requirement?
• Schedule:
  • Is each requirement scheduled for implementation by a specific milestone or release?
  • Is this schedule based on the priority of the requirement?
• Status:
  • Does each requirement have an associated status (e.g., identified, analyzed, specified, approved, and frozen)?
  • Is this status updated as the requirements goes through its lifecycle?
• Trace:
  • Is each requirement traced to its source goal, document, person, team, and/or organization?
  • Does each requirement include both forward and backward tracing information?
  • Does each system requirement include a trace back to system goals?
  • Does each system requirement include traces down to data, hardware, personnel, and software:
    • Components?
    • Requirements?
  • Does each software requirement include a trace back to its system component and system requirements?
  • Does each software requirement include traces down to data, hardware, personnel, and software components?

Relevance

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:

• Is each requirement within the scope of the business, system, application, or component being specified? For example, is each requirement within the scope of the associated statement of work, the mission statement, and/or the vision statement?
• Does each system, application, or component requirement avoid specifying the behavior and characteristics of the associated users? When engineering the requirements of a system, specify what a system must do in response to a user’s actions, but do not specify what a user does because you cannot place requirements on users (although user workflows can and should be documented in user manuals). For example when doing use case modeling of functional requirments:
  • Do not specify “The user shall do X.”
  • Instead, specify “When the user does X, the system shall do Y.”
• Does each system, application, or component requirement avoid specifying the behavior and characteristics of the associated external systems (except for mandatory interfaces)?

Usability

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:

• Is each requirement usable by the customer representatives and user representatives who must use it for scope control and evaluation?
• Is each requirement usable by managers who must use it for scope control as well as cost, schedule, and progress metrics?
• Is each architecturally-significant requirement usable by the architects who will base the architecture on it?
• Is each requirement usable by the designers and programs who must implement it?
• Is each requirement usable (e.g., testable) by the testers who must verify and validate it?

Validatability

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

• Is it possible to ensure that each requirement is:
  • Actually needed by some legitimate stakeholder?
  • Acceptable to the customer representatives?
  • Acceptable to regulators (e.g., safety certifiers)?

Verifiability

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:

• Is there an appropriate verification method (e.g., demonstration, evaluation, testing) for each requirement?
• Can each requirement be verified against its source?
• Can each requirement be verified against its associated standards (e.g., content and format), guidelines, and/or templates?

Guidelines

• To be practical as a checklist for actual use during a requirements evaluation, the checklist must be limited to a reasonable number of questions. However, the preceding checklist has far too many questions to be used in practice for this purpose. This checklist has been purposely made too large for the following reasons:
  • The relative effectiveness of different questions for identifying requirements defects during different endeavors at different times will vary based on the training, experience, and skill levels of the different members of the requirements evaluation teams. Thus, it is impossible for a generic requirements inspection such as this one to be optimal for all endeavors at all times during the endeavor. This checklist is therefore intended to be tailored to meet the specific needs of the specific endeavor, primarily by tailoring out (i.e., deleting) those questions that are neither necessary nor cost-effective.
  • During an endeavor when resources (e.g., schedule and experienced staff), it is easier to tailor out those questions that are inappropriate than it is to come up with new questions.
  • By being comprehensive, the checklist can also be used by the requirements team as they develop the requirements as a training aid so that fewer defects are incorporated into and remain in the requirements when the requirements evaluation team evaluates the requirements.
• This checklist has been developed for use with large, complex, business-critical systems or applications, and is therefore very complete.
• When used on an actual endeavors, this checklist should be a treated as a living document containing (i.e., emphasizing) questions based on those areas that previous evaluations have found most defects. As members of the requirements team learn to avoid certain types of requirements defects, questions relating to those types of defects can be removed.
• A simple pattern matching tool could be used to identify the ambiguous words. After fixing these defects (a.k.a., obtaining a “clean compile” of the requirements, human evaluators could evaluate the requirements more efficiently so that they would not be side tracked by identifying such obvious defects.