General Requirement Statement Notes

A software requirement is a property that must be exhibited by something in order to solve some problem in the real world.

It is essential that they are verifiable. Needs to have a priority rating to enable tradeoffs in face of finite resources and a status value to enable project progress to be monitored.

Uniquely identified so that they can be subjected to software configuration management over the entire life cycle of the feature and of the the software.

Product and Process Requirements

A product requirement is a need or constraint on the software to be developed.

Example: “The software shall verify that a student meets all prerequisites before he or she registers for a course.”

A process requirement is essentially a constraint on the development of the software.

Example: “The software shall be developed using a RUP process.”

Functional and Nonfunctional Requirements

Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They sometimes know as capabilities or features. A functional requirement can also be described as one for which a finite set of test steps can be written to validate its behavior.

Nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes know as constraints or quality requirements. They can be further classified according to whether they are performance requirements, maintainability requirements, safety requirements, reliability requirements, security requirements, interoperability requirements or one of many other types of software requirements.

Requirements Construct

29148-2018.pdf

• Requirements are mandatory binding provisions and use ‘Shall’
• Non-requirements, such as descriptive text, use verbs such as ‘are’, ‘is’, and ‘was’. It is best to avoid using the term ‘must’, due to potential misinterpretation as a requirement.
• Statements of fact, futurity, or declaration of purpose are non-mandatory, non-binding provisions and use ‘Will’. ‘Will’ can also be used to establish context or limitations of use.
• Preferences or goals are desired, non-mandatory, non-binding provisions and use ‘Should’. They are not requirements.
• Suggestions or allowances are non-mandatory, non-binding provisions and use ‘May’
• Use positive statements and avoid using negative requirements such as 'Shall Not'
• Use active voice: avoid using passive voice such as 'it is required that'.
• Avoid using terms such as ‘shall be able to’.

Characteristics of individual requirements

29148-2018.pdf

Necessary The requirement defines an essential capability, characteristic, constraint, and/or quality factor. If it is not included in the set of requirements, a deficiency in capability or characteristic will exist, which cannot be fulfilled by implementing other requirements.

Appropriate The specific intent and amount of detail of the requirement is appropriate to the level of the entity to which it refers (level of abstraction). This includes avoiding unnecessary constraints on the architecture or design to help ensure implementation independence to the extent possible. Unambiguous The requirement is stated in such a way so that it can be interpreted in only one way.

Complete The requirement sufficiently describes the necessary capability, characteristic, constraint, or quality factor to meet the entity need without needing other information to understand the requirement.

Singular The requirement should state a single capability, characteristic, constraint, or quality factor.

Feasible The requirement can be realized within entity constraints (e.g., cost, schedule, technical, legal, regulatory) with acceptable risk.

Verifiable The requirement is structured and worded such that its realization can be proven (verified) to the customer’s satisfaction at the level the requirements exists.

Correct The requirement must be an accurate representation of the entity need from which it was transformed.

Conforming The individual requirements should conform to an approved standard template and style for writing requirements, when applicable.

Requirements language criteria

29148-2018.pdf

Vague and general terms shall be avoided. They result in requirements that are often difficult or even impossible to verify or may allow for multiple interpretations. The following are types of unbounded or ambiguous terms:

• superlatives such as ‘best’ and 'most'

• subjective language such as ‘user friendly’ , ‘easy to use’, and ‘cost effective’

• vague pronouns such as ‘it’, ‘this’, and ‘that’

• ambiguous terms such as adverbs and adjectives such as ‘almost always’, ‘significant’, ‘minimal’, and ambiguous local statements such as ‘or’ , ‘and/or’.

• Open-ended, non-verifiable terms such as ‘provide support’, ‘but not limited to’, 'and as a minimum'.

• comparative phrases such as ‘better than’ and ‘higher quality’

• loopholes such as ‘if possible’, ‘as appropriate’, and ‘as applicable’

• terms that imply totality such as ‘all’, ‘always’, ‘never’, and ‘every’

• Incomplete references not specifying the reference with its date and version number; not specifying just the applicable parts of the reference to restrict verification work.

Requirements attributes

29148-2018.pdf

• Identification: It must be uniquely identified so that it can be subjected to software configuration management over the entire life cycle of the feature and of the software. (If the requirement is related to making a payment on an order for example, the unique identifier could be words, like Order. Pay, or numbers, like 1., or a combination, like Order-1.)

• Version Number: This is to make sure that the correct version of the requirement is being implemented as well as to provide an indication of the volatility of the requirement. A requirement that has a lot of change could indicate a problem or risk to the project.

• Owner: The person or element of the organization that maintains the requirement, who has the right to say something about this requirement, approves changes to the requirement, and reports the status of the requirement.

• Stakeholder Priority: It must have a priority rating to enable tradeoffs in the face of finite resources and a status value to enable project progress to be monitored.

• Risk: A risk value assigned to each requirement based on risk factors. Requirements that are at risk include requirements that fail to have the set of characteristics that well-formed requirements should have.

• Rationale: The rationale for establishing each requirement should be captured. The rationale provides the reason that the requirement is needed and points to any supporting analysis, trade study, modelling, simulation or other substantive objective evidence.

• Difficulty: The assumed difficulty for each requirement should be noted. This provides additional context in terms of requirements breadth and affordability. It also helps with cost modelling

• Type: Identify and justify whether your requirement is a product requirement or process requirement. Identify and justify if your requirement is a functional requirement or nonfunctional requirement.

Important examples of the requirements type attribute include:

• Functional/Performance: Functional requirements describe the system or system element functions or tasks to be performed by the system. Performance is an attribute of function. A performance requirement alone is an incomplete requirement

• Interface: Interface requirements are the definition of how the system is required to interact with external systems , or how system elements within the system, including human elements, interact with each other.

• Process Requirements: These are stakeholder, usually acquirer or user, requirements imposed through the contract or statement of work. Process requirements include: compliance with national, state or local laws, including environmental laws, administrative requirements, acquirer/supplier relationship requirements and specific work directives. Process requirements may also be imposed on a program by corporate policy or practice. System or system element implementation process requirements, such as mandating a particular design method, are usually captured in project agreement documentation such as contracts, statements of work and quality plans

• Quality (Non-Functional) Requirements: Include a number of the 'ilities' in requirements to include, for example, transportability, survivability, flexibility, portability, reusability, reliability, maintainability and security.

• Usability/Quality-in-Use Requirements (for user performance and satisfaction) : Provide the basis for the design and evaluation of systems to meet the user needs. Usability/Quality-in-Use requirements are developed in conjunction with, and form part of, the overall requirements specification of a system

• Human Factors Requirements: State required characteristics for the outcomes of interaction with human users (and other stakeholders affected by use) in terms of safety, performance, effectiveness, efficiency, reliability, maintainability, health, well-being and satisfaction

Sample Requirement Statement

(Withdraw-1)If an withdrawal is to occur, when the customer enters amount, the ATM system shall only withdraw in multiples of 20.00. Priority: 1

Characteristics of this individual requirement

The type of this requirement is product because it is a need or constraint on the software to be developed not a constraint on the development of the software.

The type of this requirement is functional because it has to do with something that the software is to execute.

Necessary The requirement defines an essential capability, characteristic, constraint, and/or quality factor. If it is not included in the set of requirements, a deficiency in capability or characteristic will exist, which cannot be fulfilled by implementing other requirements.

This requirement is necessary because it is a business rule.

Appropriate The specific intent and amount of detail of the requirement is appropriate to the level of the entity to which it refers (level of abstraction). This includes avoiding unnecessary constraints on the architecture or design to help ensure implementation independence to the extent possible.

This requirement is appropriate because it does not impose constraints on the architecture or design.

Unambiguous The requirement is stated in such a way so that it can be interpreted in only one way.

This requirement is stated in an unambiguous way because it does not use vague language.

Complete The requirement sufficiently describes the necessary capability, characteristic, constraint, or quality factor to meet the entity need without needing other information to understand the requirement.

This requirement is complete because nothing more is needed to implement the requirement.

Singular The requirement should state a single capability, characteristic, constraint, or quality factor.

This requirement is stated in a singular way because it only has one constraint.

Feasible The requirement can be realized within entity constraints (e.g., cost, schedule, technical, legal, regulatory) with acceptable risk.

This requirement is feasible because it can access the customer account for withdrawal.

Verifiable The requirement is structured and worded such that its realization can be proven (verified) to the customer’s satisfaction at the level the requirements exists.

This requirement is verifiable because it can be verified by customer use of the withdrawal system.

Correct The requirement must be an accurate representation of the entity need from which it was transformed.

This requirement is correct because it was transformed from: A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00

Conforming The individual requirements should conform to an approved standard template and style for writing requirements, when applicable.

This requirement is conforming because it follows [Condition] [Subject] [Action] [Object] [Constraint of Action] stated in 229148-2018 5.2.4 Figure 1 — Examples of functional requirements syntax.

Requirements language criteria

The requirement meets the language criteria because it does not use vague pronouns, superlatives, subjective language, ambiguous terms, Open-ended, non-verifiable terms, comparative phrases, loopholes, terms that imply totality, and Incomplete references.

Requirements attributes

The requirement has a unique identifier. (Withdraw-1)

The requirement has the Stakeholder Priority.(1) The type of this requirement is product because it is a need or constraint on the software to be developed not a constraint on the development of the software.

The type of this requirement is functional because it has to do with something that the software is to execute.