WARE ENGINEERING

Lecture 5
Teacher: Dr Brekhna
REQUIREMENTS
ENGINEERING
REQUIREMENTS
ENGINEERING
 The process of establishing the
services that the customer
requires from a system and the
constraints under which it
operates and is developed.
 The requirements themselves are
the descriptions of the system
services and constraints that are
generated during the
requirements engineering
process.
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 unavoidable 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.
 REQUIREMENTS
ABSTRACTION (DAVIS)
“If a company wishes to let a contract for a large software development
project, it must define its needs in a sufficiently abstract way that a
solution is not pre-defined. The requirements must be written so that
several contractors can bid for the contract, offering, perhaps, different
ways of meeting the client organization’s needs. Once a contract has
been awarded, the contractor must write a system definition for the
client in more detail so that the client understands and can validate what
the software will do. Both of these documents may be called the
requirements document for the system.”
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 AND SYSTEM
REQUIREMENTS (IMP)
READERS OF DIFFERENT
TYPES OF REQUIREMENTS
SPECIFICATION
SOCIO-TECHNICAL SYSTEM
CHARACTERISTICS
Emergent properties
 Properties of the system as a whole that depend on the system
components and their relationships.
Non-deterministic
 They do not always produce the same output when presented
with the same input because the system’s behaviour is partially
dependent on human operators.
Complex relationships with organisational objectives
 The extent to which the system supports organisational
objectives does not just depend on the system itself.
EMERGENT PROPERTIES
Properties of the system as a whole rather than properties that can be
derived from the properties of components of a system
Emergent properties are a consequence of the relationships between
system components
They can therefore only be assessed and measured once the
components have been integrated into a system
 EXAMPLES OF EMERGENT
PROPERTIES
Property Description

Volume The volume of a system (the total space occupied) varies depending on how
the component assemblies are arranged and connected.
Reliability System reliability depends on component reliability but unexpected
interactions can cause new types of failures and therefore affect the reliability
of the system.
Security The security of the system (its ability to resist attack) is a complex property
that cannot be easily measured. Attacks may be devised that were not
anticipated by the system designers and so may defeat built-in safeguards.
Repairability This property reflects how easy it is to fix a problem with the system once it
has been discovered. It depends on being able to diagnose the problem,
access the components that are faulty, and modify or replace these
components.
Usability This property reflects how easy it is to use the system. It depends on the
technical system components, its operators, and its operating environment.
TYPES OF EMERGENT
PROPERTY
Functional properties
 These appear when all the parts of a system work together to
achieve some objective. For example, a bicycle has the functional
property of being a transportation device once it has been
assembled from its components.

Non-functional emergent properties

 Examples are reliability, performance, safety, and security. These
relate to the behaviour of the system in its operational environment.
They are often critical for computer-based systems as failure to
achieve some minimal defined level in these properties may make
the system unusable.
FUNCTIONAL AND NON-
FUNCTIONAL REQUIREMENTS
Functional requirements
 Statements of services the system should provide, how the system should
react to particular inputs and how the system should behave in particular
situations.
 May state what the system should not do.

Non-functional requirements
 Constraintson the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.
 Often apply to the system as a whole rather than individual features or services.

Domain requirements
 Constraints on the system from the domain of operation
FUNCTIONAL
REQUIREMENTS
Describe functionality or system services.
Depend on the type of software, expected users and the
type of system where the software is used.
Functional user requirements may be high-level
statements of what the system should do.
Functional system requirements should describe the
system services in detail.
FUNCTIONAL
REQUIREMENTS FOR THE
MHC-PMS
A user shall be able to search the appointments lists for
all clinics.
The system shall generate each day, for each clinic, a list
of patients who are expected to attend appointments that
day.
Each staff member using the system shall be uniquely
identified by his or her 8-digit employee number.
REQUIREMENTS
IMPRECISION
Problems arise when requirements are not
precisely stated.
Ambiguous requirements may be interpreted
in different ways by developers and users.
Consider the term ‘search’ in requirement 1
User intention – search for a patient name across all
appointments in all clinics;
Developer interpretation – search for a patient name in an
individual clinic. User chooses clinic then search.
REQUIREMENTS
COMPLETENESS AND
CONSISTENCY
In principle, requirements should be both
complete and consistent.
Complete
 They should include descriptions of all facilities required.

Consistent
 There should be no conflicts or contradictions in the descriptions of the
system facilities.

In practice, it is impossible to produce a

complete and consistent requirements document.
NON-FUNCTIONAL
REQUIREMENTS
These define system properties and constraints e.g.
reliability, response time and storage requirements.
Constraints are I/O device capability, system
representations, etc.
Process requirements may also be specified mandating a
particular IDE, programming language or development
method.
Non-functional requirements may be more critical than
functional requirements. If these are not met, the system
may be useless.
TYPES OF NONFUNCTIONAL
REQUIREMENT
NON-FUNCTIONAL
REQUIREMENTS
IMPLEMENTATION
Non-functional requirements may affect the overall
architecture of a system rather than the individual
components.
 For example, to ensure that performance requirements are met, you may
have to organize the system to minimize communications between
components.

A single non-functional requirement, such as a security

requirement, may generate a number of related functional
requirements that define system services that are
required.
 It may also generate requirements that restrict existing requirements.
NON-FUNCTIONAL
CLASSIFICATIONS
Product requirements
 Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.

Organisational requirements
 Requirements which are a consequence of organisational policies
and procedures e.g. process standards used, implementation
requirements, etc.

External requirements
 Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.
 METRICS FOR SPECIFYING
NONFUNCTIONAL
REQUIREMENTS
Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
DOMAIN REQUIREMENTS
Domain requirements are the requirements which are characteristic of a
particular category or domain of projects. Domain requirements can be
functional or nonfunctional.
Domain requirements engineering is a continuous process of proactively
defining the requirements for all foreseeable applications to be developed in
the software product line.
The basic functions that a system of a specific domain must necessarily exhibit
come under this category.
For instance, in an academic software that maintains records of a school or
college, the functionality of being able to access the list of faculty and list of
students of each grade is a domain requirement.
These requirements are therefore identified from that domain model and are
not user specific.
SUCCESS CRITERIA
Complex systems are developed to address ‘wicked
problems’ – problems where there cannot be a complete
specification.
Different stakeholders see the problem in different ways
and each has a partial understanding of the issues
affecting the system.
Consequently, different stakeholders have their own
views about whether or not a system is ‘successful’
 Success is a judgment and cannot be objectively measured.
 Success is judged using the effectiveness of the system when deployed
rather than judged against the original reasons for procurement.
Thank You 