General Requirement Statement Notes

• Requirements can be described as the specific descriptions of a client's needs.
• Creating good requirements is vital to creating a successful product.

Product and Process Requirements

A product requirement is a requirement that focuses on the need or the constraints of the piece of software that is to be developed. A process requirement is a requirement that is focused on the development of a piece of software, typically regarding the constraints in development.

Functional and Nonfunctional Requirements

A functional requirement is a requirement that describes what the product/software should do. In other words, it describes what the features of the software can execute. A nonfunctional requirement is a requirement that specifies the constraints of the functional requirements. They often are related to topics such as maintainability, security, efficiency, reliability/dependability, usability, etc.

Requirements Construct

A good requirement typically has some of these attributes:

• it shall be used and completed to solve a problem specified by a stakeholder
• "it can be verified"
• it has constraints that it must follow
• it describes how the system should perform
• "it is qualified by measurable conditions"
  
  Requirements are typically written in the forms below:

[Condition][Subject][Action][Object][Constraint of Action]
or
[Subject][Action][Constraint of Action]

• Any terms specific to the requirements should be defined and used according to the stated definition.
• Make sure to use active voice when writing requirements.
• Use the word "shall", "are", "is", "was", "will", and "should", but avoid "must" and "shall be able to".
• Avoid negative wording of requirements.
  A condition can be defined as "measurable" attributes that are specified for the requirement. They are analogous to an "if" in an if-then statement; where if the condition occurs then the subject shall perform an action on an object under a constraint.
  
  Cited from ISO/IEC/IEEE 29148:2018 5.2.4

Characteristics of Individual Requirements

All requirements should possess the following characteristics:

Necessary

The requirement should be a vital aspect of defining a "capability, characteristic, constraint and/or quality factor" of the product. Without the requirement, the end product should result in a missing attribute, or capability, that is can not be fulfilled by implementing other requirements. In other words, the requirement is unique, specific, and vital in defining an aspect of the product.

Appropriate

The requirement should be specific enough to describe the "entity to which it refers", but not overly specific in adopting unnecessary constraints that will restrict the implementation of the software.

Unambiguous

The requirement is simply stated and specified so that it can only be perceived and understood in a specific way (the way that it was intended). In other words, the requirement is not left up to interpretation.

Complete

The requirement specifies the "capability, characteristic, constraint and/or quality factor" clearly, without any missing information needed to implement one of those entities. In other words, the requirement describes all the information needed to understand the requirement.

Singular

"The requirement states a single capability, characteristic, constraint or quality factor."

Feasible

The requirement can be completed given the system constraints.

Verifiable

The requirement can be used to check whether the software satisfies the requirement itself. In other words, the requirement should be written in a way that can verify that the requirement is achieved based on customer satisfaction and the details of the requirement. It helps when the requirement is measurable.

Correct

"The requirement is an accurate representation of the entity need from which it was transformed."

Conforming

All requirements follow a standard template and style. This ensures organization and aids in automation.

Cited from ISO/IEC/IEEE 29148:2018 5.2.5

Requirements language criteria

Requirements should focus on what is needed to be created, not how the software should be created. However, as requirements develop there can be some high-level decisions regarding the design of the system. Any assumptions or definitions should be clarified and specified.
"Vague and general terms shall be avoided". Examples include:

• "superlatives;
• subjective language;
• vague pronouns;
• adverbs and adjectives;
• ambiguous logical statements;
• open-ended, non-verifiable terms;
• comparative phrases;
• loopholes;
• terms that imply totality;
• incomplete references"
  
  Cited from ISO/IEC/IEEE 29148:2018 5.2.7

Requirements attributes

Examples of requirements attributes

• Identification
• Version Number
• Owner
• Stakeholder Priority
• Risk
• Rationale
• Difficulty Type

Examples of requirements type attribute

• Functional/Performance Requirements
• Interface Requirements
• Process Requirements
• Quality (Non-Functional) Requirements
• Usability/Quality-in-Use Requirements
• Human Factors Requirements
  
  Cited from ISO/IEC/IEEE 29148:2018 5.2.8

Sample Requirement Statement

The e-commerce website shall display previously created custom designs that are filtered by the date that they were created within a minute.

Characteristics of this individual requirement

• Necessary: The requirement has this characteristic because the gallery is one of the main pitfalls of the current system. The gallery is vital for displaying the work of the company.
• Appropriate: The requirement is specific enough to pinpoint what it should do, but it is not too specific in restricting the functionality or design of the site.
• Unambiguous: The requirement is clear and can not be misinterpreted as it does not use any ambiguous terms or descriptions.
• Complete: The requirement includes all information needed to satisfy the requirement.
• Singular: The requirement is specific and does not explain more than one capability of the system. There is simply a gallery that is sorted.
• Verifiable: After the feature is completed, the requirement can be used to check whether the requirement itself has been completed. In other words, after we create the site, we can use the site to verify that we have completed the requirement.
• Correct: The requirement is an accurate representation of what the business needs on its site. Customers need to have a way to look at designs for inspiration and to order more products.
• Conforming: The requirement uses the last template that was listed in section 5.2.4: Requirements Construct of the ISO/IEC/IEEE 29148:2018.

Requirements language criteria

The requirement strictly focuses on what needs to be created, the gallery, not how it should be created. The requirement also does not use any vague or general terms. Any terms that may be misinterpreted, like "filtered" are clarified in the requirement itself.

Requirements attributes

• Identification: The requirement can be named Gallery-1.
• Stakeholder Priority: Priority: High.
• Type: The requirement is a product requirement as it pertains to the software being created and its features. The requirement does not address how or how it should not be created. The requirement is a functional requirement as it specifies what the software should do. The requirement does not address any topics related to usability, efficiency, maintainability, etc.