General Requirement Statement Notes

Product and Process Requirements (SWEBOK 1.2)

According to SWEBOK, a product requirement is a need or constraint on the software to be developed whereas a process requirement is essentially a constraint on the development of the software.

Functional and Nonfunctional Requirements (SWEBOK 1.3)

According to SWEBOK, functional requirements describe the functions that the software is to execute (ex: capabilities or features). On the other hand, nonfunctional requirements are the ones that act to constrain the solution (ex: constraints or quality requirements)

Requirements Construct (29148-2018 5.2.4)

A sufficiently created requirement include:

• it shall be met or possessed by a system to solve a problem, achieve an objective or address a stakeholder concern;
• it is qualified by measurable conditions;
• it is bounded by constraints;
• it defines the performance of the system when used by a specific stakeholder or the corresponding capability of the system, but not a capability of the user, operator or other stakeholder; and
• it can be verified (e.g., the realization of the requirement in the system can be demonstrated).

A requirement is a statement that describes a need and the constraints and conditions that come with it. This can be written in any language, natural or a structured language.

A requirement should include the subject of the requirement (e.g., the system, the software, etc.), what should be done (e.g., operate at a power level, provide a field for) or a constraint on the system.

Key words and terms to pay attention to (According to IEEE 29148-2018 5.2.4)

• 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 a 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 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’

Conditions are measurable qualitative or quantitative attributes that are set for a requirement.

Constraints limit the design solution/implementation of the SDLC process. They may apply across all requirements, be specified in a relationship to a specific requirement or set of requirements, or apply as requirements themselves (i.e., not bounding any specific requirement).

Examples of Constraints giving support to requirements according to IEEE:

• interfaces to already existing systems (e.g., format, protocol or content) where the interface cannot be changed;
• physical size limitations (e.g., a controller shall fit within a limited space in an airplane wing);
• laws of a particular country;
• available duration or budget;
• pre-existing technology platform;
• maintenance constraints; or
• user or operator capabilities and limitations.

Characteristics of individual requirements (29148-2018 5.2.5)

According to IEEE, Each stakeholder, system and system element requirement needs to be:

• 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. The requirement is currently applicable and has not been made obsolete by the passage of time. Requirements with planned expiration dates or applicability dates are clearly identified.
• 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 appropriate to the level of entity). This includes avoiding unnecessary constraints on the architecture or design while allowing 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. The requirement is stated simply and is easy to understand.
• Complete - The requirement effectively describes the necessary capability, characteristic, constraint or quality factor to meet every need without a lack of information.
• Singular. The requirement states a single capability, characteristic, constraint or quality factor.
• Feasible - The requirement can be completed with the given constraints (e.g., cost, schedule, technical) with manageable risk.
• Verifiable - The requirement is structured and worded such that its completion can be proven/measured (verified) to the client's satisfaction at the level the requirements exists. Verifiability is more effective if the requirement is measurable.
• Correct - The requirement is an accurate representation of the entity need from which it was transformed.
• Conforming - The individual items conform to an approved standard template and style for writing requirements, when applicable.

Requirements language criteria (29148-2018 5.2.7)

Requirements should mention what is needed for the system, not how it will be developed/designed

General terms should be avoided in requirements. They result in requirements that are impossible to verify or are interpreted in several different ways.

According to IEEE, these terms are examples of what to avoid

• superlatives (such as 'best', 'most');
• subjective language (such as 'user friendly', 'easy to use', 'cost effective');
• vague pronouns (such as 'it', 'this', 'that');
• ambiguous terms such as adverbs and adjectives (such as 'almost always', 'significant', 'minimal') and ambiguous logical statements (such as ‘or’, ‘and/or’);
• NOTE 1 Consider multiple requirements when encountering terms such as ‘or’, ‘and’, or ‘and/or’.
• open-ended, non-verifiable terms (such as 'provide support', 'but not limited to', 'as a minimum');
• comparative phrases (such as 'better than', 'higher quality');
• loopholes (such as 'if possible', 'as appropriate', 'as applicable');
• terms that imply totality (such as ‘all’, ‘always’, ‘never’, and ‘every’);
• NOTE 2 It is very difficult to verify such requirements.
• 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 5.2.8)

To make requirements analysis easier, well-made requirements should use descriptive attributes to help in identifying relevant requirements and to help in understanding/managing the requirements.

Most if not All of these examples are stated by IEEE (29148-2018 5.2.8)

Examples of Requirements Attributes

• Identification. Each requirement should be uniquely identified (i.e., number, name tag, mnemonic). Identification can reflect linkages and relationships, if needed, or they can be separate from identification. Unique identifiers aid in requirements tracing. Once assigned, the identification is unique - it is never changed (even if the identified requirement changes) nor is it reused (even if the identified requirement is deleted).
• Version Number (and indication of the version of the requirement). 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. The priority of each requirement should be identified. This may be established through a consensus process among potential stakeholders. As appropriate, a scale such as 1-5 or a simple scheme such as High, Medium or Low, could be used for identifying the priority of each requirement. The priority is not intended to imply that some requirements are not necessary, but it may indicate what requirements are candidates for the trade space when decisions regarding alternatives are necessary. Prioritization needs to consider the stakeholders who need the requirements. This facilitates trading off requirements and balancing the impact of changes among stakeholders.
• 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. Failing to have these characteristics can result in the requirement not being implemented (fails system verification) and entity needs not being realized (fails system validation). Risk can also address feasibility/attainability in terms of technology, schedule, cost, politics, etc. If the technology needed to meet the requirement is new with a low maturity the risk is higher than if using a mature technology used in other similar projects. Risk may also be inherited from a parent requirement.
• NOTE Additional guidance on risk factors can be found in ISO/IEC 16085.
• 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 (e.g., Easy/Nominal/ Difficult). This provides additional context in terms of requirements breadth and affordability. It also helps with cost modelling.
• Type. Requirements vary in intent and in the kinds of properties they represent. Use of a type attribute aids in identifying relevant requirements and categorizing requirements into groups for analysis and allocation.

Examples of Requirements Type Attributes

• 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. Performance is normally expressed quantitatively.
• NOTE 1 There can be more than one performance requirement associated with a single function, functional requirement or task.
• Interface. Interface requirements are the definition of how the system is required to interact with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). External interface requirements state characteristics required of the system, software or service at a point or region of connection of the system, software or service to the world outside of the item. They include, as applicable, characteristics such as location, geometry and what the interface is to be able to pass in each direction.
• 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. The kinds of quality requirements (e.g., "ilities") should be identified prior to initiating the requirements activities. This should be tailored to the system(s) being developed. As appropriate, measures for the quality requirements should be included as well.
• 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.
• NOTE 2 Additional guidance on software quality requirements can be found in the ISO/IEC SQuaRE standards, especially ISO/IEC 25030, and in ISO/IEC 25010.
• 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. These include characteristics such as measures of usability, including effectiveness, efficiency and satisfaction; human reliability; freedom from adverse health effects.

Sample Requirement Statement (Train/Subway system)

During Arrival at a train/metro station, the train system shall announce "Arrival at _________ station, please exit the train/metro" on the intercom within 5 seconds.

Characteristics of this individual requirement (29148-2018 5.2.5)

• Necessary - All necessary parts of this requirement is sufficiently covered. (condition)(subject)(Action)(Object)(Constraint)
• Appropriate - Doesn't bother with unnecessary info like how the voice will play, etc.
• Unambiguous - Requirement can easily be visualized.
• Complete - No other information is needed to fulfill the requirement.
• Singular - Each component of the requirement involves a single focus.
• Feasible - Requirement involves detection and projecting a prerecorded voice, This can be done
• Verifiable - Requirement can be physically tested.
• Correct - The Requirement accurately fulfills a need (passenger needs)
• Conforming - This requirement uses a syntax templates from 29148-2018 5.2.4

Requirements language criteria (29148-2018 5.2.7)

Requirement avoids generalization ambiguous terms. This requirement focuses on what happens (NOT how), and properly describes what is needed.

Requirements attributes (29148-2018 5.2.8)

Identification: StationAnnouncement_Audio

Stakeholder Priority: Priority - High (not only needed for passengers not paying attention but also blind passengers)

Type: This requirement is a product requirement. This is because this requirement shows a part of the software that needs to be developed. This requirement is also a functional requirement. This is because the requirement involves functions that need to be performed not limited.