Requirements,

Domain Properties,
Assumptions and Definitions
Type of Statements in RE
Descriptive Statements
• Descriptive statements state properties about the system that hold
regardless of how the system behaves. Such properties hold typically
because of some natural law or physical constraint.
• Example:
• If train doors are open, they are not closed.
• The same book copy cannot be borrowed by two different people at the same
time.
• A person cannot physically attend two meetings on different continents on
the same day.
Prescriptive Statements
• Prescriptive statements state desirable properties about the system
that may hold or not depending on how the system behaves. Such
statements need to be enforced by system components.
• Example:
• Train doors shall always remain closed when the train is moving.
• A patron may not borrow more than three books at the same time.
• The meeting date must fit the constraints of all important participants.
• The distinction between descriptive and prescriptive statements is
essential to make in the context of engineering requirements.
• We may need to negotiate, weaken, change or find alternatives to
prescriptive statements.
• We cannot negotiate, weaken, change or find alternatives to
descriptive statements.
• A phenomenon is owned by the software-to-be, by its environment, or shared
among them. The environment includes the machine's input/output devices such
as sensors and actuators.
• The RE process involves statements about the system-to-be that differ in scope.
• Some statements may refer to phenomena owned by the environment without
necessarily being shared with the software-to-be. Other statements may refer to
phenomena shared between the environment and the software-to-be; that is,
controlled by the software and observed by the environment, or vice versa.
Requirements
What is a requirement?
• It may range from a high-level abstract statement of a service or of a
system constraint to a detailed mathematical functional specification.

• This is inevitable as requirements may serve a dual function

• May be the basis for a bid for a contract - therefore must be open to
interpretation;
• May be the basis for the contract itself - therefore must be defined in detail;
• Both these statements may be called requirements.
Types of requirement
• User requirements
• Statements in natural language plus diagrams of the services the system
provides and its operational constraints. Written for customers.

• System requirements
• A structured document setting out detailed descriptions of the system’s
functions, services and operational constraints. Defines what should be
implemented so may be part of a contract between client and contractor.
User Requirement
• User requirements are to be understood and agreed by all parties
concerned with the system-to-be (stakeholder).
• Their formulation in terms of environmental phenomena, in the
vocabulary used by such parties, will make this possible.

• Also called as “customer requirement”

• Notes: many 'user requirements' do not come only from any software
user; a 'system' does not merely consist of software
System Requirement
• A system requirement is a prescriptive statement to be enforced by
the system-to-be, possibly in cooperation with other system
components, and formulated in terms of environmental phenomena.

• Satisfying system requirements may require the cooperation of other

system components
• Technoware: H/W, S/W, Communication Network
• Infoware: Data & Information
• Brainware: User/Stakeholder
• Organoware: Organization, Procedure, Rules/Regulation, Reward &
Punishment Mechanisms
• System requirements are to be used by developers; they are
formulated in the vocabulary of developers, in terms of system
input/output variables.

• Also called as “product requirement”, “specification”,

• A software requirement is a prescriptive statement to be enforced

solely by the software-to-be and formulated only in terms of
phenomena shared between the software and the environment.
• Also for hardware requirement, communication requirement, information
requirement, etc (just change the word ☺)
Example:

User Requirement System Requirement (Software)

• All train doors shall always remain closed • The doorsState output variable shall
while a train is moving. always have the value 'closed' when the
measuredSpeed input variable has a non-
null value.

• Patrons may not borrow more than three • The recorded number of loans by a
books at a time. patron may never exceed a maximum
number 3.

• The constraints of a participant invited to • A request for constraints shall be e-

a meeting should be known as soon as mailed to the address of every participant
possible. on the meeting invitee list.
Domain Property
What is Domain Property?
• A domain property is a descriptive statement about the problem
world.
• It is expected to invariably regardless of how the system will behave -
and even regardless of whether there will be any man-made-system
or not.
• Domain properties typically correspond to physical laws that cannot
be broken.
Example
• A train is moving if and only if its physical speed is non-null.

• A book may not be borrowed and available at the same time.

• A participant cannot attend multiple meetings at the same time.

Assumption
What is Assumption?
• An assumption is a statement to be satisfied by the environment and
formulated in terms of environmental phenomena.
Example
• A train's measured speed is non-null if and only if its physical speed is non-null.

• The recorded number of loans by a borrower is equal to the actual number of

book copies physically borrowed by him or her.

• Borrowers who receive threatening reminders after the loan deadline has expired
will return books promptly.

• Participants will promptly respond to e-mail requests for constraints.

• A participant is on the invitee list for a meeting if and only if he or she is invited to
that meeting.
• Assumptions are generally prescriptive, as they constrain the
behaviour of specific environmental components.

• For example, the first assumption in the previous example constrains

speedometers in train control system.
Definition
What is Definition?
• Definitions are the last type of statement involved in the RE process.

• They allow domain concepts and auxiliary terms to be given a precise,

complete and agreed meaning - the same meaning for everyone.

• Unlike statements of other types, definitions have no truth value. It makes

no sense to say that a definition is satisfied or not.

• However, we need to check definitions for accuracy, completeness and

adequacy.
Example
• TrainMoving is the name for a phenomenon in the environment that
accounts for the fact that the train being considered is physically
moving on a block.

• A patron is any person who has registered at the corresponding

library for the corresponding period of time.

• A person participates in a meeting if he or she attends that meeting

from beginning to end.
Relation Between
System Requirements and
Software Requirements
Four-variable model
(Parnas and Madey, 1995)
• Monitored variables are environmental quantities that the system
monitors through input devices such as sensors.

• Controlled variables are environmental quantities that the system

controls through output devices such as actuators.

• Input variables are data items that the software needs as input.

• Output variables are quantities that the software produces as output.

• A system requirement SysReq is a relation between a set M of
monitored variables and a corresponding set C of controlled variables:
SysReq  M x C

• A software requirement SofReq is a relation between a set I of input

variables and a corresponding set O of output variables:
SofReq  I x 0
Example

A software requirement SofReq 'translates' the corresponding system requirement

SysReq in the vocabulary of the software's input/output variables.
Satisfaction Arguments
• Translation of a system requirement into a software requirement is
not a mere reformulation obtained by mapping the environment's
vocabulary into the software's one.

• Domain properties and assumptions are often required to ensure the

'correctness' of the translation; that is, the satisfaction of the system
requirement when the corresponding software requirement holds.
 The assumptions in Asm are examples of
accuracy statements, to be enforced here by
the speedometer and door actuator,

Example respectively.
Accuracy requirements and assumptions
form an important class of non-functional
statements to be considered in the RE
process.
• System Requirements: Overlooking them or formulating wrong ones
(SysReq:) TrainMoving → DoorsClosed has sometimes been the cause of
major software disasters.
• Software Requirements:
(SofReq:) measuredSpeed  0 → doorsState = 'closed’

• To ensure that the software requirement SofReq correctly translates the system
requirement SysReq in this simple example, we need to identify the domain
property Dom and the assumptions Asm, and make sure that those statements
are actually satisfied.
(Dom:) TrainMoving  trainSpeed  0
(Asm:) measuredSpeed  0  trainSpeed  0
doorsState ='closed'  DoorsClosed
• Our job as requirements engineers is to elicit, make precise and consolidate
requirements, assumptions and domain properties. Then we need to provide satisfaction
arguments taking the following form:

{SOFREQ,ASM, DOM} I= SysReq

IF
the software requirements in set SOFREQ are satisfied by the software,
the assumptions in set ASM are satisfied by the environment,
the domain properties in set DOM hold and all those statements are consistent with each other,
THEN
the system requirements SysReq are satisfied by the system.
• Satisfaction arguments require environmental assumptions and
domain properties to be elicited, specified and validated

• Satisfaction arguments play an important role in managing the

traceability among requirements and assumptions for requirements
evolution
Thank You