Requirement Formulating

Engineering Requirement

Ts. Dr. Mohd Hafeez Bin Osman

Agenda

Formulating Requirements Construct

Requirements
Requirement Templates
Characteristics of Requirements
Requirement Language Criteria
Requirements Attribute
Documentation Overview
Requirements Construct

3
Requirements Construct

What is a requirement?
Translates or expresses a need and its associated constraints and conditions,

• Can be written in the form of a natural language or some other form of language,
• Natural language - should include a subject and a verb, together with other elements
necessary to adequately express the information content of the requirement. A requirement
shall state the subject of the requirement (e.g., the system, the software, etc.), what shall be
done (e.g., operate at a power level, provide a field for) or a constraint on the system.

* Source: ISO/IEC/IEEE 29148:2018

Requirements Construct

Conditions
• Measurable qualitative or quantitative attributes that are stipulated for a requirement.

• They further qualify a requirement that is needed, and provide attributes that
permit a requirement to be formulated and stated in a manner that can be validated
and verified.

5
* Source: ISO/IEC/IEEE 29148:2018
Requirements Construct

Constraints
• Restrict the design solution or implementation of the systems engineering process.

• May apply across all requirements, may be specified in a relationship to a specific

requirement or set of requirements, or may be identified as stand-alone requirements
(i.e., not bounding any specific requirement).

6
* Source: ISO/IEC/IEEE 29148:2018
Requirements Construct

Examples of constraints include:

• 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,

• user or operator capabilities and limitations.

7
* Source: ISO/IEC/IEEE 29148:2018
Requirements Construct

Well-formed specified requirement contains one or more of the following:

it shall be met or
possessed by a system to
qualified by measurable
solve a problem, achieve bounded by constraints;
conditions;
an objective or address a
stakeholder concern;

defines the performance

can be verified
of the system

8
Requirements Construct

A common approach is to stipulate the following:

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

• Use positive statements and avoid negative requirements such as ‘shall not’.

• Use active voice: avoid using passive voice, such as ’it is required that’.
9
* Source: ISO/IEC/IEEE 29148:2018
Requirements Templates

10
 Requirements Templates (ISO/IEC/IEEE
29148)
Functional requirements syntax (Example)*
[Condition] [Subject] [Action] [Object] [Constraint]

EXAMPLE: When signal x is received [Condition], the system [Subject] shall set [Action] the signal x received bit
[Object] within 2 seconds [Constraint].

[Condition] [Action or Constraint] [Value]

EXAMPLE: At sea state 1 [Condition], the Radar System shall detect targets at ranges out to [Action or Constraint]
100 nautical miles [Value].

[Subject] [Action] [Value]

EXAMPLE: The Invoice System [Subject], shall display pending customer invoices [Action] in ascending order [Value]
in which invoices are to be paid.

*Source: ISO/IEC/IEEE 29148:2018 11

 Requirements Templates (EARS)

*Source: EARS (Easy Approach for Requirement Syntax – Aalto University) 12

 Requirements Templates (Rupp’s)

Example:
1. The system shall be able to notify the IT-system of the contracted garages regarding the vehicle location.
2. If a client has reserved the vehicle only temporarily, the vehicle rental system shall provide the client with
the ability to cancel the reservation.
*Source: Rupp’s Template – [Link]
13
Requirements Templates (Agile)

Agile ‘requirement template’ : User Stories*

As a <person in role> I want to <goal> so that <the benefit>

Example:
1. As a teacher, I want to update grades online so that I no longer depend on
administrators to do it for me.
*Requirements in agile may use alternative formulations such as user stories without explicitly using the term ‘shall’.
14
Characteristics of
Requirements

15
 Characteristics of Individual Requirements

Each stakeholder, system and system element requirement shall possess the following characteristics:
1. Necessary
2. Appropriate
3. Unambiguous
4. Complete
5. Singular
6. Feasible
7. Verifiable
8. Correct
9. Conforming

*Source: ISO/IEC/IEEE 29148:2018 16

 Characteristics of Individual Requirements

1. Necessary
• The requirement defines an essential capability, characteristic, constraint and/or
quality factor.

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

*Source: ISO/IEC/IEEE 29148:2018 17

 Characteristics of Individual Requirements

Example (Necessary):

All desktop PCs for the project must be configured with 512MB of memory, DVD
ROM/CD-RW multifunction drive and a 21-inch flat screen monitor.

The desktop PCs for the developers on the project must be configured with 512MB of
memory, DVD ROM/CD-RW multifunction drive and 21-inch flat screen monitor.

Source: [Link] 18
 Characteristics of Individual Requirements

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

• Includes avoiding unnecessary constraints on the architecture or design while allowing

implementation independence to the extent possible.

*Source: ISO/IEC/IEEE 29148:2018 19

 Characteristics of Individual Requirements

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

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

*Source: ISO/IEC/IEEE 29148:2018 20

Characteristics of Individual Requirements

5. Singular.

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

NOTE - Although a single requirement consists of a single function, quality or constraint, it can
have multiple conditions under which the requirement is to be met. i.e. capability, characteristic,
constraint or quality factor.

21
 Characteristics of Individual Requirements

6. Feasible

The requirement can be realized within system constraints (e.g., cost, schedule, technical) with
acceptable risk.

7. 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. Verifiability is enhanced when the
requirement is measurable.

*Source: ISO/IEC/IEEE 29148:2018 22

 Characteristics of Individual Requirements

Example (Testable):

Each page of the system will load in an acceptable time-frame

Register student and enrol courses pages of the system will load within 5 seconds

Source: [Link]
23
 Characteristics of Individual Requirements

8. Correct

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

9. Conforming

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

*Source: ISO/IEC/IEEE 29148:2018 24

Characteristics of a set of Requirements

Each set of requirements for a system, software or service shall possess the following
characteristics:
1. Complete
2. Consistent
3. Feasible
4. Comprehensible
5. Able to be validated

25
 Characteristics of a set of Requirements

1. Complete
• it sufficiently describes the necessary capabilities, characteristics, constraints or quality
factors to meet entity needs without needing further information.

• Does not contain To Be Defined (TBD), To Be Specified (TBS), or To Be Resolved (TBR)

clauses.

• To improve completeness, the following practices can be adopted:

• include all requirements types relevant to the system under consideration;

• account for requirements in all stages/phases of the life cycle; and

• involve all stakeholders in the requirements elicitation, capture, and analysis activity.
*Source: ISO/IEC/IEEE 29148:2018 26
Characteristics of a set of Requirements

Example (Complete):

A professor user will log into the system by providing his username, password,
and other relevant information

A professor user will log into the system by providing his username, password
and department code

27
Characteristics of a set of Requirements

2. Consistent
• Contains individual requirements that are unique,

• do not conflict with or overlap with other requirements in the set, and

• the units and measurement systems are homogeneous.

• the terminology used within the set of requirements is consistent, i.e. the same
term is used throughout the set to mean the same thing.

28
Characteristics of a set of Requirements

Example (Consistent and Unambiguous):

A student will have either undergraduate courses or post-graduate courses but not
both. Some courses will be open to both under-graduate and post-graduate

A student will have either under-graduate or post graduates but not both

29
 Characteristics of a set of Requirements

3. Feasible*
• can be realized within entity constraints (e.g., cost, technical) with acceptable risk.
*Feasible includes the concept of ‘affordable’.

4. Comprehensible.
• it is clear as to what is expected by the entity and its relation to the system of which it is a
part.

*Source: ISO/IEC/IEEE 29148:2018 30

 Characteristics of a set of Requirements

Example (Feasible):

The replacement control system shall be installed with no disruption to production.

The replacement control system shall be installed causing no more than 2 days of
production disruption.

Source: [Link]
31
 Characteristics of a set of Requirements

5. Able to be validated.
• It is practicable that satisfaction of the requirement set will lead to the achievement of the
entity needs within constraints (e.g., cost, schedule, technical, and regulatory compliance).

*Source: ISO/IEC/IEEE 29148:2018 32

Requirements Language
Criteria

33
 Requirements Language Criteria

The following are types of unbounded or ambiguous terms:

a. superlatives (such as 'best', 'most');

b. subjective language (such as 'user friendly', 'easy to use', 'cost effective');

c. vague pronouns (such as 'it', 'this', 'that');

d. ambiguous terms such as adverbs and adjectives (such as 'almost always',

'significant', 'minimal’) and ambiguous logical statements* (such as ‘or’, ‘and/or’);

*Consider multiple requirements when encountering terms such as ‘or’, ‘and’, or ‘and/or’.

*Source: ISO/IEC/IEEE 29148:2018 34

 Requirements Language Criteria

e. open-ended, non-verifiable terms (such as 'provide support', 'but not limited to', 'as a

minimum');

f. comparative phrases (such as 'better than', 'higher quality');

g. loopholes (such as 'if possible', 'as appropriate', 'as applicable');

h. terms that imply totality (such as ‘all’, ‘always’, ‘never’, and ‘every’);

i. incomplete references (not specifying the reference with its date and version number).

All assumptions made regarding a requirement shall be documented and validated in one of the requirement's attributes (e.g., rationale)
associated with a requirement or in an accompanying document. Include definitions as declarative statements, not requirements.

*Source: ISO/IEC/IEEE 29148:2018 35

Requirements Attributes

36
 Requirements Attributes

• To support requirements analysis, well-formed requirements should include

descriptive attributes defined to assist in identifying relevant requirements and to
help in understanding and managing the requirements.

• The attribute information should be associated with the requirements in the

selected requirements repository.

*Source: ISO/IEC/IEEE 29148:2018 37

 Requirements Attributes

A. Examples of requirements attributes

Important examples of requirements attributes include:

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

*Source: ISO/IEC/IEEE 29148:2018 38

 Requirements Attributes

Example (Uniquely Identified):

1- Students shall be able to enroll to undergraduate courses

1- Students shall be able to enroll to post-graduate courses

1. Course Enrolment

1.1 Students shall be able to enroll to undergraduate courses

1.2 Students shall be able to enroll to post-graduate courses

Source: [Link] 39
 Requirements Attributes

2. Version Number (and indication of the version of the requirement)

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

*Source: ISO/IEC/IEEE 29148:2018 40

 Requirements Attributes

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

*Source: ISO/IEC/IEEE 29148:2018 41

 Requirements Attributes

4. Stakeholder Priority.
• The priority of each requirement should be identified.

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

*Source: ISO/IEC/IEEE 29148:2018 42

 Requirements Attributes

5. Risk
• A risk value assigned to each requirement based on risk factors.

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

*Source: ISO/IEC/IEEE 29148:2018 43

 Requirements Attributes

6. Rationale.
• The rationale for establishing each requirement should be captured.

• Provides the reason that the requirement is needed and points to any supporting
analysis, trade study, modelling, simulation or other substantive objective evidence.

*Source: ISO/IEC/IEEE 29148:2018 44

 Requirements Attributes

7. Difficulty
• The assumed difficulty for each requirement should be noted (e.g., Easy/Nominal/Difficult).

• Provides additional context in terms of requirements breadth and affordability.

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

*Source: ISO/IEC/IEEE 29148:2018 45

 Requirements Attributes

B. Examples of the requirements type attribute

1. Functional/Performance
• 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.

*There can be more than one performance requirement associated with a single function,
functional requirement or task.

*Source: ISO/IEC/IEEE 29148:2018 46

 Requirements Attributes

2. Interface
• Define 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.

*Source: ISO/IEC/IEEE 29148:2018 47

 Requirements Attributes

3. Process Requirements
• 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.

*Source: ISO/IEC/IEEE 29148:2018 48

 Requirements Attributes

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

*Source: ISO/IEC/IEEE 29148:2018 49

 Requirements Attributes

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

*Source: ISO/IEC/IEEE 29148:2018 50

 Requirements Attributes

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

*Source: ISO/IEC/IEEE 29148:2018 51

Documentation Overview

52
Documentation Overview

IEEE 830:1998

53
Documentation Overview

ISO/IEC/IEEE 29148:2018

54
Documentation Overview

ISO/IEC/IEEE 29148:2018

55
Documentation Overview

ISO/IEC/IEEE 29148:2018

BRS – Business Requirement

Specification

56
Documentation Overview

ISO/IEC/IEEE 29148:2018

StRS – Stakeholder Requirement

Specification

57
Documentation Overview

ISO/IEC/IEEE 29148:2018

SyRS – System Requirement

Specification

58
Documentation Overview

ISO/IEC/IEEE 29148:2018

SRS – Software Requirement

Specification

59
End. Terima Kasih.

60