SOFTWARE

ENGINEERING
CO3001

CHAPTER 3 – REQUIREMENTS Anh Nguyen-Duc

ENGINEERING Tho Quan Thanh

Adapted from https://iansommerville.com/software-engineering-book/slides/

 TOPICS COVERED

 Functional and non-functional requirements

 Requirements engineering processes
 Requirements elicitation
 Requirements specification
 Requirements validation
 Requirements change

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 2

 REQUIREMENTS

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 3

 EFFECTS OF INADEQUATE REQUIREMENTS
DEVELOPMENT – AIRBUS
 Requirement: Reverse thrust may only be used when the airplane is landed.
 Translation: Reverse thrust may only be used while the wheels are rotating.
 Implementation: Reverse thrust may only be used while the wheels are
rotating fast enough.

• Situation: Rainstorm – aquaplaning

• Result: Crash due to overshooting the runway!

• Problem: Erroneous in the requirement phase

 The Ariane 5 accident – 1
 Single root cause failure!
 The ”bug”: attitude deviation
stored as 2-byte integer (max value
65,535) instead of 4-byte (max value
4,294,967,295)
 SW module was reused from Ariane 4
 Insufficient V&V of detailed
requirements: larger attitude deviation
tolerated in Ariane 5 than in Ariane 4
 Ariane 5 production cost 10 years and
$7 billion; luckily, no victims because it
was unmanned.
65,535 = 00000000 00000000 11111111 11111111
65,536 = 00000000 00000001 00000000 00000000
 OTHER SOFTWARE RELATED ACCIDENTS &
INCIDENTS
 Accidents & incidents
 Alarm flooding, power distribution failure, BP Grangemouth
Scotland, 29th May - 10th June 2000
 failure in a data bus + faulty logic in the software => engine
power loss, Airbus A340-642, 2005
 failed accelerometer + software bug => Faulty airspeed
metering, Boeing 777-200, 2005
 Software bug => shutdown of radio communication between Korean Air 747 in Guam,
ATC and aircraft, 2004. disrupted 800 flights 200 deaths (1997):
 Safety-related software flaws => recall of 200,000 incorrect configuration of
pacemakers in 1990-2000 ”minimum altitude” warning
 radiotherapy machines attacked by computer viruses, 2005 system
 Buggy software incorporate computer + connection between
corporate and control systems networks => shutdown of the
nuclear power plant, USA 2008
 Many software failures are actually ”bugs” in the detailed
requirement specifications, i.e., poor understanding of
the very detailed requirements
Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 7
 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.

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 8

 Requirement engineering =
establishing the services that the
WHAT IS A REQUIREMENT? customer requires from a system
and the constraints under which it
operates and is developed.

 Requirement = the descriptions of

 the system services
 and constraints
 It may range
 from a high-level abstract statement
 to a detailed mathematical functional specification.
 May serve a dual function
 The basis for a bid for a contract - must be open to
interpretation;
 The basis for the contract itself - must be in detail;
Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 9
 TYPES OF REQUIREMENT

 Requirements definition
 A statement in natural language plus diagrams of the
services the system provides and its operational
constraints. Written for customers
 Requirements specification
 A structured document setting out detailed descriptions
of the system services. Written as a contract between
client and contractor
 Software specification
 A detailed software description which can serve as a
basis for a design or implementation. Written for
Sep 2019
developers CHAPTER 4. REQUIREMENTS ENGINEERING 10
 MENTCARE SYSTEM

 Mentcare (Medical practice management system):

manages the day-to-day operations of a clinic,
such as appointment scheduling, billing and other
administrative tasks.

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 11

 USER AND SYSTEM REQUIREMENTS
EXAMPLE

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 12

 READERS OF DIFFERENT TYPES OF
REQUIREMENTS SPECIFICATION

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 13

 SYSTEM STAKEHOLDERS

 Any person or organization who is affected by the

system in some way and so who has a legitimate
interest
 Stakeholder types
 End users
 System managers
 System owners
 External stakeholders

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 14

 STAKEHOLDERS IN THE MENTCARE SYSTEM
Stakeholde Why? - Role
r
Patients whose information is recorded in the system
Doctors responsible for assessing and treating patients
Nurses coordinate the consultations with doctors and
administer some treatments
Medical manage patients’ appointments
receptionists
IT staff responsible for installing and maintaining the
system
Medical ensure that the system meets current ethical
ethics guidelines for patient care
manager
Health care obtain management information from the system
managers
Medical responsible for ensuring that system information
Sep 2019 records staff can be maintained and preserved, and4. that
CHAPTER record
REQUIREMENTS ENGINEERING 15
 AGILE METHODS AND REQUIREMENTS

 Many Agile methods argue that producing

detailed system requirements is a waste of time
as requirements change so quickly.
 The requirements document is therefore always
out of date.
 Agile methods usually use incremental
requirements engineering and may express
requirements as ‘user stories’
 This is practical for business systems but
problematic for systems that require pre-delivery
Sep 2019
analysis (e.g. critical systems) or systems
CHAPTER 4. REQUIREMENTS ENGINEERING 16
 AGILE METHODS AND REQUIREMENTS –
USER STORY

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 17

 AGILE METHODS AND REQUIREMENTS –
USER STORY
 As a medical record stuff, I wish to view current
medication from primary care general practice
 As a medical receptionist, I want to search
appointments by patients’ first name, their
telephone number, their date of birth or their
prescribed medicine
 As a healthcare manager, I want to see the
monthly report including number of prescribed
medicines ordered by their categories, by weeks,
and by cost
Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 18
 FUNCTIONAL AND
NON-FUNCTIONAL
REQUIREMENTS

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 19

 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
 Constraints on 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
Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 20
 FUNCTIONAL REQUIREMENTS

 Describe functionality or system services.

 Functional user requirements may be high-level

statements of what the system should do.
 Functional system requirements should describe the
system services in detail.

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 21

 MENTCARE SYSTEM: FUNCTIONAL
REQUIREMENTS
 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.

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 22

 NON-FUNCTIONAL REQUIREMENTS

 Define system properties and constraints

 Properties: reliability, response time and storage
requirements.
 Constraints: I/O device capability, system
representations, etc.

 Non-functional requirements may be more critical

than functional requirements.
 If these are not met, the system may be useless.

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 23

 NON-FUNCTIONAL REQUIREMENTS
IMPLEMENTATION
 Non-functional requirements may affect the
overall architecture of a system
 rather than the individual components
 cross-cutting concern

 A single non-functional requirement

 may generate a number of related functional
requirements
 and may also generate requirements that restrict
existing requirements.
Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 24
 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.
Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 25
 EXAMPLES OF NONFUNCTIONAL
REQUIREMENTS IN THE MENTCARE SYSTEM
 Product requirement
 The Mentcare system 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 Mentcare 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.
Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 26
EXERCISE: 15 MINS (+ 10 MINS BREAK)

 Specify in a textual way the requirements for an ordering

support system in the restaurant
 It shall support the ordering of food and/or drinks in the restaurant
 You should have a concrete instance of such a system in mind
 You should specify all kind of requirements, constraints, etc. that
you have in mind.

Each one specify 03 functional requirement and 02 non-functional

requirement you can think of!
Document your answers:
https://
docs.google.com/spreadsheets/d/1VSkq6tS9IAuB7COSbkmexxXQAW
oNPu3hJ3ESBwp5Wf4/edit#gid=0
CHAPTER 4. REQUIREMENTS ENGINEERING 27
WHAT IS A GOOD REQUIREMENT?

 Precise/ Unambiguous
 Complete
 Consistent
 Correct
 Testable
 Ranked for importance and/or stability
 REQUIREMENTS IMPRECISION

 A software requirement is unambiguous, if and only if, every

requirement stated therein has only one interpretation
 Problems arise when requirements are not precisely stated.
 Ambiguous requirements may be interpreted in different ways by
developers and users.

 For 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.

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 29

 REQUIREMENTS COMPLETENESS AND
CONSISTENCY
 Requirements should be both complete and
consistent.

 Complete
 They should include descriptions of all facilities
required.
 All possible situations must be covered

 Consistent
 There should be no conflicts or contradictions in the
Sep 2019
descriptions of the system facilities.
CHAPTER 4. REQUIREMENTS ENGINEERING 30
TESTABLE REQUIREMENT

 If a method cannot
be devised to
determine whether
the software meets a
particular
requirement, then
that requirement is
not testable.
EXAMPLE OF NIGHTMARE REQUIREMENTS

 The system shall perform at the maximum rating at

all times except that in emergencies it shall be
capable of providing up to 125% rating unless the
emergency condition continues for more than 15
minutes in which case the rating shall be reduced to
105% but in the event that only 95% can be
achieved then the system shall activate a reduced
rating exception and shall maintain the rating within
10% of the stated values for a minimum of 30
minutes.
More than one requirement in a paragraph
Rambling: like a novel
Vague terms: emergencies
ANOTHER EXAMPLE OF NIGHTMARE
REQUIREMENTS
 The system shall provide general word processing
facilities which shall be easy to use by untrained
staff and shall run on a thin Ethernet Local Area
Network wired into the overhead ducting with
integrated interface cards housed in each system
together with additional memory if that should be
necessary.

More than one requirement in a paragraph

Rambling: like a novel
Let-out clauses: if that should be necessary
Vague words: be easy to use, additional memory
ISO/IEC 25010:2011 SOFTWARE QUALITY
(NON-FUNCTIONAL) REQUIREMENTS

CHAPTER 4. REQUIREMENTS ENGINEERING 34

 GOALS VS. REQUIREMENTS

 Goal
 A general intention of the user such as ease of use.

 Requirements are often

 Concrete
 Measureable
 Testable

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 35

 GOALS VS. REQUIREMENTS (CONT.)

Goal:
The system should be easy to use by
medical staff.

Non-functional requirement:
Medical staff shall be able to use all the system
functions after four hours of training.

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 36

 SOFTWARE
ENGINEERING
CO3001

CHAPTER 4 – REQUIREMENTS Anh Nguyen-Duc

ENGINEERING PROCESS Tho Quan Thanh

Adapted from https://iansommerville.com/software-engineering-book/slides/

 REQUIREMENTS ENGINEERING PROCESSES

 Processes to “generate” all requirements

 Generic activities common to all processes
 Requirements elicitation;
 Requirements analysis;
 Requirements validation;
 Requirements management.
 In practice, RE is an iterative activity

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 38

 A SPIRAL VIEW OF THE REQUIREMENTS
ENGINEERING PROCESS

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 39

 A AGILE VIEW OF THE REQUIREMENTS
ENGINEERING PROCESS

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 40

 REQUIREMENT
ELICITATION AND
ANALYSIS

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 41

 REQUIREMENTS ELICITATION AND ANALYSIS

 ~ requirements elicitation or requirements

discovery.

 Work with customers to find out:

 the application domain, the services and the
operational constraints (system performance, hardware
constraints, etc.).
 May involve
 end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These
Sep 2019 are called stakeholders. CHAPTER 4. REQUIREMENTS ENGINEERING 42
 PROBLEMS OF REQUIREMENTS ELICITATION

 Stakeholders don’t know what they really want.

 Stakeholders express requirements in their own
terms.
 Different stakeholders may have conflicting
requirements.
 Organisational and political factors may influence
the system requirements.
 The requirements change during the analysis
process.
Sep 2019
 New stakeholders may emerge and the business
CHAPTER 4. REQUIREMENTS ENGINEERING 43
 THE REQUIREMENTS ELICITATION AND
ANALYSIS PROCESS
Interacting with
stakeholders to
Requirements are discover their
documented and requirements.
input into the next
round

Groups related
requirements
and organises
Prioritising
them into
requirements and
coherent
resolving conflicts
clusters

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 44

 REQUIREMENTS DISCOVERY

 To gather information about the required and

existing systems and distil the user and system
requirements from this information.

 Main concerns:
 Stakeholders
 Discovery techniques/approaches/…

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 45

 DISCOVERY TECHNIQUE - INTERVIEWING

 Part of most RE processes.

 Types of interview
 Closed vs Open => mixed?
 Be effective
 Be open-minded, avoid pre-conceived ideas about the
requirements and are willing to listen to stakeholders.
 Prompt the interviewee to get discussions going using a
springboard question, a requirements proposal, or by
working together on a prototype system.

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 46

 DISCOVERY TECHNIQUE - ETHNOGRAPHY

 Observational technique
 used to understand operational processes and help
derive support requirements for these processes
 How
 A social scientist spends a considerable time observing
and analysing how people actually work.
 People do not have to explain or articulate their work.
 Social and organisational factors of importance may be
observed.

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 47

 STORIES AND SCENARIOS

 Scenarios and user stories are real-life examples

of how a system can be used.
 Stories and scenarios are a description of how a
system may be used for a particular task.
 Because they are based on a practical situation,
stakeholders can relate to them and can
comment on their situation with respect to the
story.

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 48

REQUIREMENT ELICITATION TECHNIQUES

Suggested elicitation techniques by project characteristics

 REQUIREMENTS
SPECIFICATION

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 50

 REQUIREMENTS SPECIFICATION

 The process of writing down the user and system

requirements in a requirements document.

 Notes:
 User requirements have to be understandable by end-
users and customers who do not have a technical
background.
 System requirements are more detailed requirements
and may include more technical information.
 The requirements may be part of a contract for the
Sep 2019
system development CHAPTER 4. REQUIREMENTS ENGINEERING 51
 WAYS OF WRITING A SYSTEM
REQUIREMENTS SPECIFICATION
Notation Description
Natural language Sentences in natural language. Each sentence should
express one requirement.
Structured natural Natural language statements on a standard form or
language template
Design Uses a language like a programming language, but with
description more abstract features
languages
Graphical Graphical models, supplemented by text annotations
notations (best for functional requirements); UML use case and
sequence diagrams are commonly used.
Mathematical Based on mathematical concepts such as finite-state
specifications machines or sets; Can reduce the ambiguity but hard to
understand (and hard to check manually)

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 52

 NATURAL LANGUAGE SPECIFICATION

 Used for writing requirements because it is expressive,

intuitive and universal.
 The requirements can be understood by users and customers.

 Problems
 Lack of clarity: Precision is difficult without making the
document difficult to read.
 Requirements confusion: Functional and non-functional
requirements tend to be mixed-up.
 Requirements amalgamation: Several different requirements
may be expressed together.
Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 53
 EXAMPLE REQUIREMENTS FOR THE INSULIN
PUMP SOFTWARE SYSTEM
 Req 3.2. The system shall measure the blood
sugar and deliver insulin, if required, every 10
minutes.

 Req 3.6. The system shall run a self-test routine

every minute with the conditions to be tested and
the associated actions defined in Table 1.

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 54

 STRUCTURED SPECIFICATIONS

 Writing on a standard form or template:

 Name
 Inputs, outputs
 The information needed for the computation
 Action
 Pre and post conditions (if appropriate)
 The side effects (if any)

 This works well for some types of requirements

e.g. requirements for embedded control system
Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 55
 Insulin Pump/Control Software/SRS/3.3.2
A STRUCTURED
Function
SPECIFICATION OF A
Compute insulin dose: safe sugar level
REQUIREMENT
Description FOR
Computes the dose ofANinsulinINSULIN PUMP
to be delivered when the current
measured sugar level is in the safe zone between 3 and 7
units.
Inputs Current sugar reading (r2); the previous two readings (r0 and
r1).
Source Current sugar reading from sensor. Other readings from
memory.
Outputs CompDose—the dose in insulin to be delivered
Destination Main control loop.
Action CompDose is zero if the sugar level is stable or falling or if the
level is increasing but the rate of increase is decreasing. If the
level is increasing and the rate of increase is increasing, then
CompDose is computed by dividing the difference between
the current sugar level and the previous level by 4 and
rounding the result. If the result, is rounded to zero then
CompDose is set to the minimum dose that can be delivered.
Requirement Two previous readings so that the rate of change of sugar
s level can be computed
Pre- The insulin reservoir contains at least the maximum allowed
CHAPTER 4. REQUIREMENTS ENGINEERING 56
condition single dose of insulin.
TABULAR SPECIFICATION

 Particularly useful when you have to define a

number of possible alternative courses of action.
 Example:

Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of CompDose = 0
increase decreasing ((r2 – r1) < (r1 – r0))
Sugar level increasing and rate of CompDose = round ((r2 – r1)/4)
increase stable or increasing ((r2 – r1) ≥ If rounded result = 0 then
(r1 – r0)) CompDose =
MinimumDose
CHAPTER 4. REQUIREMENTS ENGINEERING 57
USE CASES

 Use-cases are a kind of scenario

 identify the actors in an interaction and which describe the
interaction itself
 Included in the UML

 A set of use cases should describe all possible

interactions with the system.

 UML sequence diagrams may be used to add detail to

use-cases
 show the sequence of event processing in the system
CHAPTER 4. REQUIREMENTS ENGINEERING 58
 USE CASE DIAGRAM

• Actors
• Use cases
• Association
• System
boundary
boxes

Partial use case diagram for the Chemical Tracking

System (CTS)
USE CASE TEMPLATE AND EXAMPLE
USE CASE TEMPLATE AND EXAMPLE
(CONT’)
DATA FLOW DIAGRAM

 How data moves through a system

DECISION TABLE/DECISION TREE

 Complex logics
STATE-TRANSITION DIAGRAM

 A set of complex
state changes in
natural
language
creates a high
probability of
overlooking a
permitted state
change or
including a
disallowed
change.
THE SOFTWARE REQUIREMENTS DOCUMENT

 The software requirements document is the

official statement of what is required of the
system developers.
 Should include both a definition of user
requirements and a specification of the system
requirements.
 It is NOT a design document. As far as possible, it
should set of WHAT the system should do rather
than HOW it should do it.

CHAPTER 4. REQUIREMENTS ENGINEERING 65

 REQUIREMENT
VALIDATION

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 66

 REQUIREMENTS VALIDATION

 Requirements error can be costly !

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 67

 REQUIREMENTS CHECKING

 Validity.
 Does the system provide the functions which best support the
customer’s needs?
 Consistency.
 Are there any requirements conflicts?
 Completeness.
 Are all functions required by the customer included?
 Realism.
 Can the requirements be implemented given available budget and
technology
 Verifiability.
 Can the requirements be checked?
Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 68
 REQUIREMENTS VALIDATION TECHNIQUES

 Requirements reviews
 Systematic manual analysis of the requirements.
 Prototyping
 Using an executable model of the system to check
requirements.
 Test-case generation
 Developing tests for requirements to check testability.

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 69

 REQUIREMENTS CHANGE

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 70

 CHANGING REQUIREMENTS

 The business and technical environment of the

system always changes after installation.
 The people who pay for a system and the users of
that system are rarely the same people.
 Large systems usually have a diverse user
community, with many users having different
requirements and priorities that may be
conflicting or contradictory.

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 71

 REQUIREMENTS MANAGEMENT

 Requirements management is the process of managing

changing requirements during the requirements
engineering process and system development.
 New requirements emerge as a system is being
developed and after it has gone into use.
 You need to keep track of individual requirements and
maintain links between dependent requirements so that
you can assess the impact of requirements changes. You
need to establish a formal process for making change
proposals and linking these to system requirements.

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 72

 REQUIREMENTS MANAGEMENT PLANNING

 Establishes the level of requirements

management detail that is required.

 Requirements management decisions:

 Requirements identification
 A change management process
 Traceability policies
 Tool support

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 73

 REQUIREMENTS CHANGE MANAGEMENT

 Deciding if a requirements change should be

accepted
 Problem analysis and change specification
 Change analysis and costing
 Change implementation

Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 74

RESPONSE TO CHANGE: AGILE APPROACH!

CHAPTER 4. REQUIREMENTS ENGINEERING 75

 SUMMARY

 Requirements: what the system should do and

constraints on its operation and implementation.
 Functional requirements = the services
 Non-functional requirements = constraints
(development & use)
 apply to the system as a whole.
 The software requirements document (i.e. SRS) is
an agreed statement of the system requirements.
 The RE process is an iterative process
Sep 2019
 requirements elicitation, specification and validation.
CHAPTER 4. REQUIREMENTS ENGINEERING 76
 SUMMARY (CONT.)

 Requirements elicitation and analysis = iterative process

 requirements discovery, classification and organization,
negotiation and requirements documentation.
 Techniques for requirements elicitation
 interviews, scenarios, use-cases and ethnography, etc.
 Requirements validation = checking the requirements
 for validity, consistency, completeness, realism and verifiability.
 Business, organizational and technical changes inevitably
 => changes to the requirements for a software system.
 Requirements management = managing and controlling
the requirement changes.
Sep 2019 CHAPTER 4. REQUIREMENTS ENGINEERING 77