requirement engineering for software engineers

1. Chapter 2
Types of Requirements
1

2.  User Requirements
 System Requirements
 Software Design Specification Requirements
 Functional Vs Non-Functional Requirements
 Domain Requirements
 Classification of NFRs
 Some NFRs
 Deriving NFRs
 Stakeholder Concerns
 Goal-based derivation
 Testable NFRs
Contents
2

3.  Should describe functional and non-functional
requirements so that they are understandable by
system users who don’t have detailed technical
knowledge
 They are called user requirements because they are
written from a user’s perspective
 User requirements are defined using statements in
natural language, tables, diagrams.
 Written primarily for customers
User Requirement Readers
User Requirements
3

4. Problems with Natural Language
 Lack of clarity
Sometimes natural language statements be clear to read,
understand and interpret
 Requirements confusion
Functional and non-functional requirements tend to be
mixed-up
 Requirements amalgamation
Several different requirements may be expressed together
User Requirement Specification
4

5.  are expanded versions of the user requirements that are used by
software engineers as the starting point for the system design.
 They add detail and explain how the user requirements should be
provided by the system
 capture the vision of the customer, enable defining the scope of the
system, and allow estimating the cost and schedule required to build
the system.
 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.
 May serve as a contract between client and developer.
System Requirement Readers
System Requirements
5

6. System Requirements Specification
6

7.  Implementation oriented abstract description of software
design which may utilize formal (mathematical)
notations.
 Written for developers.
Software Design Specification Readers
Software Design Specification
Requirements
7

8. 8
 Functional requirements
 Non functional requirements - Quality Attributes
 Domain requirements
Functional requirements
 Describes system services or functions which are expected by the
users of the system.
 How it should react to particular inputs,
 How it should behave in particular situations.
 Examples:
• The user shall be able to search either all of the initial set of
databases or select a subset from it.
• The system shall provide appropriate viewers for the user to
read documents in the document store.
 Functional requirements describe what the system or software must do and sometimes called
behavioral or operational requirements.
 In order to find out functional requirements of a system try to answer the questions below
 What inputs the system should accept?
Types of requirements

9. 9
 Functional requirements
 Non functional requirements - Quality Attributes
 Domain requirements
Functional requirements
 Describes system services or functions which are expected by the
users of the system.
 How it should react to particular inputs,
 How it should behave in particular situations.
 Examples:
• The user shall be able to search either all of the initial set of
databases or select a subset from it.
• The system shall provide appropriate viewers for the user to
read documents in the document store.
 Functional requirements describe what the system or software must do and sometimes called
behavioral or operational requirements.
Types of requirements

10.  In order to find out functional
requirements of a system try to answer
the questions below
 What inputs the system should accept?
 What outputs the system should produce?
 What data the system should store that
other systems might use?
 What computations the system should
perform?
10
Types of requirements

11.  Non- Functional requirements
 define the overall qualities or attributes of the resulting system like:
(security), Usability, Reliability, Performance & Supportability
 NR specify system properties, such as reliability and safety.
 NFRs are often called “quality attributes”
 More critical than functional requirements.
 Represents 20% of the requirements of a system
 Hardest to elicit and specify
 Defining good NFRs requires not only the involvement of the
customer but the developers too
 All requirements must be verifiable
– If not ‘verifiable’ then there is no indications that these requirements
have been satisfied.
 Some must also be measured.
– Some may be directly measured; some measured via simulation.
If not met, the system may be useless.
(They are not “second class” requirements.)11
Types of requirements

12. 12
 NR place restrictions on the product being developed, the
development process, and specify external constraints
that the product must meet.
 Example
 The product must be available at the beginning of the next
year
 The product shall operate on a 3G mobile telephone.
 The system shall be easy to use
 The system should not fail more than twice in a week.
 The system shall respond to every user action in less than
3 seconds
Types of requirements…

13. 13
 Functional Vs Non-Functional Requirements
 There is no a clear distinction between functional and non-
functional requirements.
 Whether or not a requirement is expressed as a
functional or a non-functional requirement may depend:
 on the level of detail to be included in the requirements
document
 The degree of trust which exists between a system
customer and a system developer.
Types of requirements…

14. 14
 Example: The system shall ensure that data is protected
from unauthorised access.
 Conventionally, this would be considered as a non-
functional requirement because it does not specify specific
system functionality which must be provided. However, it
could have been specified in slightly more detail as
follows:
 The system shall include a user authorisation procedure
where users must identify themselves using a login name
and password. Only users who are authorised in this way
may access the system data.
 In this form, the requirement looks rather more like a
functional requirement as it specifies a function (user
login) which must be incorporated in the system.
Types of requirements…

15. 15
 Requirements that come from the application domain of the system and that
reflect characteristics of that domain.
 Functional or non-functional requirements derived from application domain
(e.g., legal requirements or physical laws).
 Derived from the application domain rather than user needs.
 May be new functional requirements or constraints on existing
requirements.
 If domain requirements are not satisfied, the system may be unworkable.
For example,
A train control system has to take into account the braking characteristics in
different weather conditions. This is a domain requirement for a train
protection system.
Domain requirements problems
 Understandability
 Requirements are expressed in the language of the application domain;
 This is often not understood by software engineers developing the
system.
 Implicitness
 Domain specialists understand the area so well that they do not think of
making the domain requirements explicit.
Domain Requirements

16.  Non-functional requirements (NFR) define the
overall qualities of the resulting system;
 They are global constraints on a software system , on the
development process or external constrains outside the
enterprise
 Importance
 All functional requirements may be satisfied, but if
nonfunctional requirements are overlooked, the system will
fail.
 Non-functional properties may be the difference between
an accepted, well-liked product & unused one.
 Though all NFRs are important their relative importance
differs from stakeholder to stakeholder and from system to
system.
 Reliability, Performance, Security, Usability, Safety NFRs
NFRS
16

17.  The challenge of NFRs
 Hard to model
 Usually stated informally, and so are:
 often contradictory,
 difficult to enforce during development
 difficult to evaluate for the customer prior to delivery
 Hard to make them measurable requirements
 We’d like to state them in a way that we can measure
how well they’ve been met
 Different people and organizations use different
terminologies and different definition (though basically the
definitions have the same meaning)
NFRs…
17

18. Non-functional
requirements
Process
requirements
Product requirements External
requirements
Delivery
requirements
implementation
requirements
standards
requirements
Usability requirements
Reliability requirements
Safety requirements
Efficiency requirements
Performance requirements
Capacity requirements
Legal
constraints
Economic
constraints
Interoperability
requirements
Classification of NFRs…
A more general classification distinguishes between product,
process and external requirements is recently proposed by
Sommerville [2007]
18

19.  Product requirements
 specify that the delivered product must behave in
a particular way e.g. execution speed, reliability,
etc.
 Examples
 The System service X shall have an availability of
999/1000 or 99%.
 System Y shall process a minimum of 8 transactions per
second.
 The executable code of System Z shall be limited to
512Kbytes.
19
Non-functional classifications

20.  are a consequence of organizational policies and
procedures e.g. process standards used,
implementation requirements, etc.
 are constraints placed upon the development process of
the system
 Process requirements include:
 Requirements on development standards and methods which must
be followed
 CASE tools which should be used
 The management reports which must be provided
 Examples
 The development process to be used must be explicitly defined and
must be conformant with ISO 9000 standards
 The system must be developed using the XYZ suite of CASE tools
 Management reports setting out the effort expended on each
identified system component must be produced every two weeks
20
Organisational requirements

21.  arise from factors which are external to the system and its
development process e.g. interoperability requirements,
legislative requirements, etc.
 External requirements are based on:
 application domain information
 organisational considerations
 the need for the system to work with other systems
 health and safety or data protection regulations
 or even basic natural laws such as the laws of physics
 Examples
 Medical data system - The organisation’s data protection
officer must certify that all data is maintained according to
data protection legislation before the system is put into
operation21
External requirements

22. Examples of nonfunctional requirements in the MHC-
PMS
 Product requirement
 The MHC-PMS shall be available to all clinics
during normal working hours (Mon–Fri, 0830–
17.30). Downtime within normal working hours
shall not exceed five seconds in any one day.
 Organizational requirement
Users of the MHC-PMS system shall authenticate
themselves using their health authority identity
card.
 External requirement
The system shall implement patient privacy
provisions as set out in HStan-03-2006-priv.22

23.  A set of constraints the system must satisfy and the
standards which must be met by the delivered
system.
Performance, Reliability, Usability, Efficiency,
Maintainability, Portability, Scalability, Security, Integration etc.,
 Describes “how” the system achieves its
 functional requirements
What are Quality Attributes…?
23

24.  Response time
 Definition : particularly important for processes that process
a lot of data or use networks a great deal.
 Example
– Requirements might stipulate < two second response.
– Might use a Timing bar indicating progress…
– Response time may be considered a functional requirement for
some ‘real time systems.
Deadline:
Definition : ‘Something must be completed before some specified
time’
Example :
 Payroll system must complete by 2am so that electronic
transfers can be sent to bank
 Weekly accounting run must complete by Monday 6am -so
Performance
24

25.  Definition : The extent to which the software system
consistently performs the specified functions without failure.
 Example
 No more than 10 claim assignments out of 5000 can be
“unassigned” because of system failures.
 Reliability Criteria
 Maturity: Capability of the software to avoid failure as a result of
faults in the software.
 Fault tolerance: Capability of the software to maintain a
specified level of performance in cases of software faults.
 Recoverability: Capability of the software to re-establish its level
of performance and recover the data directly affected in the case
of a failure.
 Availability: Capability of the software to be in a state to perform
a required function at a given point in time. The Automated Teller
Machine shall be at least 99.5 percent available on weekdays between 6:00 a.m
Reliability
25

26.  Definition : The capability of the software to be understood,
learned, used and liked by the user, when used under
specified conditions.
 Example:A trained order-entry clerk shall be able to submit a
complete information in a maximum of 7 minutes
 Usability Criteria
 Understandability: capability of the software product to
enable the user to understand whether the software is
suitable, and how it can be used for particular tasks and
conditions of use.
 Learnability: capability of the software product to enable the
user to learn its application
 Operability: capability of the software product to enable the
user to operate and control it.
 Likeability: capability of the software product to be liked by the
user.
Usability
26

27.  Definition :The capability of the software to provide the
required performance relative to the amount of resources
used, under stated conditions
 Resources may include other software products, hardware
facilities, materials, (e.g. print paper, diskettes).
 The extent to which the software system handles capacity,
throughput, and response time.
 Example - The system must download the new rate
parameters within ten minutes of a non-scheduled rate
change.
Efficiency Criteria
 Time behaviour: The capability of the software to provide
appropriate response and processing times when performing its
function, under stated conditions.
 Resource utilisation: The capability of the software to use
appropriate resources in an appropriate time when the software
performs its function under stated conditions.
Efficiency
27

28.  Definition :
 The capability of the software to be modified.
 Modifications may include corrections, improvements or
adaptation of the software to changes in environment, and in
requirements and functional specifications.
 the ease in finding and fixing faults in the software system.
 Example - The application development process must have a
regression test procedure that allows complete re-testing within 2
business days.
Maintainability Criteria
 Changeability: The capability of the software product to enable a
specified modification to be implemented.
 Stability: The capability of the software to minimise unexpected
effects from modifications of the software
 Testability: The capability of the software product to enable
modified software to be validated.
Maintainability
28

29.  Definition :The capability of software to be transferred from
one environment to another. The environment may include
organisational, hardware or software environment.
 Example - The system is designed to run in business
offices, but the intent is to have a version which will run in
manufacturing assembly plants.
Portability Criteria
 Adaptability: The capability of the software to be modified for
different specified environments without applying actions or
means other than those provided for this purpose for the software
considered.
 Installability: The capability of the software to be installed in a
specified environment.
 Conformance: The capability of the software to adhere to
standards or conventions relating to portability.
 Replaceability: The capability of the software to be used in place
of other specified software in the environment of that software.
Portability
29

30.  Definition :
 “How well a solution to some problem will work when the
size of the problem increases.”
 the degree in which the software system is able to expand its
processing capabilities upward and outward to support
business growth.
 Example - Any increase in the number of customers shall
not degrade system availability to an extent noticeable by any
users.
 4 common scalability issues in IT systems:
• Request load
• Connections
• Data size
• Deployments
Scalability
30

31.  Definition:
 The extent to which the system is safeguarded against
deliberate and intrusive faults from internal and external
sources.
Quality attribute for security
 Authentication: Applications can verify the identity of their users
and other applications with which they communicate.
 Authorization: Authenticated users and applications have
defined access rights to the resources of the system.
 Encryption: The messages sent to/from the application are
encrypted.
 Example - Employees shall be forced to change their
password the next time they log in if they have not changed it
within the length of time established as “password expiration
duration.”
Security
31

32.  Definition:the degree to which the data maintained by the software
system is accurate, authentic, and without corruption.
 Example - The integrity of the system data area must be checked
by the internal audit system twice per second; if inconsistencies in
the data are detected, the system operation should be disabled.
 Typically achieved by:
 Programmatic APIs
 Data integration
Integration
32

33.  Survivability
 Definition - the extent to which the software system
continues to function and recovers in the presence of a
system failure.
 Example - All policy statement parameters shall have
default values specified, which the Report Writer system
shall use if a parameter’s input data is missing or invalid.
 Flexibility
 Definition — the ease in which the software can be
modified to adapt to different environments.
 Example - It shall be possible to add a new delivery
option for customer mailing method by developing and
“plugging in” the functionality necessary to support that
delivery option.
33

34.  Scalability
 Definition — the degree in which the software
system is able to expand its processing
capabilities upward and outward to support
business growth.
 Example - Any increase in the number of
customers shall not degrade system availability
to an extent noticeable by any users.
34

35.  Verifiability
 Definition — the extent to which tests, analysis,
and demonstrations are needed to prove that the
software system will function as intended.
 Example - The maximum number of test cases
to cover testing of any particular source code
module shall be 20.
 Interoperability
 Definition — the extent to which the software
system is able to couple or facilitate the interface
with other systems.
 Example - The system must be able to interface
with any HTML (HyperText Markup Language)
browser.35

36.  Correctness
 Definition - Deals with the extent to which the
software design and implementation conform to
the stated requirements
 Example - The requirements can be e.g. time
limits, effort constraints, development techniques
to be used etc.
 Safety
 Definition - meant to eliminate conditions
hazardous to equipment as a result of errors in
process control software.
 Example - The system shall not operate if the
external temperature is below 4 degrees Celsius
36

37.  Expandability
 Definition - refer to future efforts that will be needed
to serve larger populations, improve services, or add
new applications in order to improve usability.
 Example - The Automated Money Machine (AMM)
System shall be designed in such a manner as to
allow for future addition of 4 user buttons and 4
additional banking services.
 Manageability
 Definition - refer to the administrator tools that
support software modification during the software
development and maintenance periods.
 Example - the system must be self-configure with
respect to load and data distribution and self-heal
with respect to failure and recovery37

38.  Non-functional requirements are difficult to
express
 A number of important issues contribute to the
problem of expressing non-functional
requirements:
 Certain constraints are related to the design
solution that is unknown at the requirements
stage (response time to failure)
 Certain constraints, are highly subjective and
can only be determined through complex
empirical evaluations (associated with human
beings)
 Non-functional requirements tend to be related
to one or more functional requirements
Deriving NFRs
38

39. Contd…
 Non-functional requirements tend to conflict
and contradict
 There are no ‘universal’ rules and guidelines
for determining when non-functional
requirements are optimally met.
 In spite of the fact, two different ways of
driving NFRs are discussed here: Stakeholder
concerns & goal-based derivation
Stakeholder concerns
 Stakeholders normally have a number of
‘concerns’
 Concerns are typically non-functional
 Vaguely defined user concerns may be related
39

40.  What are Concerns?
 A way of expressing critical ‘holistic’ requirements
which apply to the system as a whole rather than
any specific sub-set of its service or functionality.
 Concerns may be broken down into sub-concerns
and finally into specific questions
 Questions act as a check list to ensure that
specific requirements do not conflict with global
priorities
 The concerns may lead directly to system
requirements or to questions which must be
answered during the requirements engineering
process.40

41. Stakeholder concerns…
To illustrate this approach the following figure shows the
decomposition of safety & compatibility concerns for train
protection system
Relationships between user needs, concerns and
NFRs
41

42. CompatibilitySafety
Collision Derailment
Personal
accident
Hardware Software Physical
Excess speed
for track conditions
Track damage
System must be able to
detect and avoid excess
speed
Under what conditions
can excess speed cause
derailment?
What information about
track damage is required by
the system? How is this
provided?
InterfaceExecution
Environment
Timing
Will a requirement affect
the performance of the
existing software?
Does a requirement need
data that isn't available
through the HST interface?
System must execute in the trusted
Ada execution environment
Can this function be
provided on the existng
execution environment?
What does 'excess speed' mean in reality?
Concern decomposition
42

43.  Relates non-functional requirements to the goals of
the enterprise
 Goal-based NFR derivation is a 3 step approach:
 Identify the enterprise goals
 Decompose the goals into sub-goals
 Identify non-functional requirements.
 One advantage of this approach is that it provides
a means of tracing non-functional requirements to
originally stated , vague expressions in the
enterprise domain
 The approach is illustrated using a requirement
drawn from the air traffic domain, on the next slide
Goal-based derivation
43

44. Example of goal-based derivation
44

45.  Stakeholders may have vague goals which cannot be
expressed precisely - Vague and imprecise
‘requirements’ are problematic
 NFRs should satisfy two attributes; must be objective
and testable (Use measurable metrics)
Testable NFRs
Property Metric
Performance 1. Processed transactions per second
2. Response time to user input
Reliability 1. Rate of occurrence of failure
2. Mean time to failure
Availability Probability of failure on demand
Size Kbytes
Usability 1. Time taken to learn 80% of the facilities
2. Number of errors made by users in a given time
period
Robustness Time to restart after system failure
Portability Number of target systems45

46. Use a template to document the nonfunctional
requirements.
46

47. THANK Y
47