SYSTEM 1

A system is defined as a group of related

things with a common purpose.

A system has:
§ A boundary
§ An environment / context
§ Stakeholders
§ Relationships with this environment
§ Internally, it has subsystems

The concept is used in very diverse fields:

ICT, Biology, Physics, Economics, …
SOFTWARE (INTENSIVE) SYSTEM 2

Software Intensive System = Software + Hardware + Context

Example:
SOFTWARE DEVELOPMENT 3

Software Process

Abstract Idea Concrete System

Systematic
Standard
SYSTEM DEVELOPMENT LIFE CYCLE (SDLC) 4

Also known as:

§ Software Development Life Cycle

§ Application Development Life Cycle

There are many variants of SDLC models.

It is composed of a few clearly defined and

distinct work phases which are used by
systems engineers and systems
developers to plan for, design, build, test,
and deliver information systems.
SOFTWARE DEVELOPMENT PHASES 5
REQUIREMENTS ENGINEERING 6

Requirements Engineering is the process of establishing the needs of

stakeholders that are to be solved by software.

WHAT HOW
 RE – Definitions 7

quality means fitness- not just a

for-purpose. We Requirements Engineering is a set of activities phase or a
cannot say anything stage
about quality unless we concerned with identifying and communicating
understand the
purpose.
the purpose of a software intensive system and
communication is as
designers, analysts,
the context in which it will be used. important as the
analysis
need to know how and
where the system will be
used.

Requirements engineering acts as the bridge

between the real-world needs users, Requirements are
partly about what is
customers, and other constituencies affected needed …
Needed to identify
all the stakeholders, by a software system and the capabilities and
not just the opportunities afforded by software-intensive … and partly
about what is
customer and user
technologies. possible
REQUIREMENTS 8

Setting: A System Development Process

§ A business context
§ A problem (or opportunity)
§ Stakeholders
§ Some idea of a target system that addresses the problem Context
A requirement is a properly formulated statement about some desired
capability or property of the target system.
provided with a number of tags:
§ the stakeholder from which it originates,
§ its importance and its priority (MoSCoW),
§ its type,
§ relationships with other requirements, etc.
A REAL-WORLD EXAMPLE: POS 9

A POS (Point-Of-Sale) system is a computer system typically

used to manage the sales in retail stores.
It includes hardware components such as a computer, a barcode
scanner, a printer and also software to manage the operation of
the store.
The most basic function of a POS system is to handle sales.

When a customer arrives at a POS counter with goods to purchase, the cashier will start
a new sale transaction.
When the barcode of a good is read by the POS system, it will retrieve the name and
price of this good from the backend catalogue system and interact with inventory system
to deduce the stock amount of this good.
 10

When the sale transaction is over, the customer can pay in cash or
credit card. After the payment is successful, a receipt will be
printed.
Note that for promotion, the store frequently issue gift coupons.
The customer can use the coupons for a better price when
purchasing goods.
 11

A user must log in to use the POS.

The users of a POS system are the

employees of the store including cashiers
and the administrator.

The administrator can access the system

management functions of the POS
system including user management and
security configuration that cashiers
cannot do.
POS: (partial) List of requirements (an example) 12

Requirement ID Short Description

F1 Handle Sales
F1.1 Retrieve name and price of good
F1.2 Handle payment
F1.2.1 Handle payment cash
F1.2.2 Handle payment check
F1.3 Print receipt
F1.4 Read bar code of good
F1.5 Deduce stock amount of good
F1.6 Compute total amount
F2 Handle Coupon
F2.1 Issue coupon
F2.2 Make discount to coupon owner
F3 Manage Users
F3.1 Handle login
F3.2 Handle logout
F3.3 Define user and user rights
… …
NF1 Each function less than ½ sec
NF2 Secure payments (F1.2 to F1.2.2)
NF3 Warranty access to functions only to authorized users (F3)
… …
TYPES OF REQUIREMENTS: FUNCTIONAL / NON-FUNCTIONAL 13

Functional requirements have to do with the functionality of the system, with

what the system does with the computation.

§ For example:

§ the elevator shall take people to the floor they select.

§ the system has to output the square root of the number.

√n
These kind of requirements have in general well defined satisfaction criteria.
TYPES OF REQUIREMENTS: FUNCTIONAL / NON-FUNCTIONAL 14

Non-functional requirements refer to a system’s non-functional properties

(systems qualities).
§ Security
§ Accuracy
§ Performance
§ Cost
§ Usability
§ Adaptability
§ Interoperability
§ Reusability
§ …

Non-functional requirements DO NOT always have clear satisfaction criteria.

§ For example: the elevator must be fast!
 POS: Functional or non-functional requirements? 15

Requirement ID Description
F1 Handle Sales
F1.1 Retrieve name and price of good
F1.2 Handle payment
F1.2.1 Handle payment cash
F1.2.2 Handle payment check
F1.3 Print receipt
F1.4 Read bar code of good
F1.5 Deduce stock amount of good Functional
F1.6 Compute total amount
F2 Handle Coupon
F2.1 Issue coupon Functional
F2.2 Make discount to coupon owner Or
F3 Manage Users Non-functional
F3.1 Handle login
F3.2 Handle logout
F3.3 Define user and user rights
… …
NF1 Each function less than ½ sec
NF2 Secure payments (F1.2 to F1.2.2) Non-functional
NF3 Warranty access to functions only to authorized users (F3)
… …
 Exercise: Functional or Non-Functional? 16
Type of
Requirement Quality
The system shall be completely operational at least 99% of the time. Non-functional Reliability
The system should be able to support 100 simultaneous users. Non-functional Performance
The system shall provide shipping with accurate order data. Functional
The system shall provide password protected access to web pages that are to Non-functional Security
be viewed only by employees.
The system shall provide marketing with customer navigation information. Functional
Transaction data must be transmitted in encrypted form. Non-functional Security
A sales agent should be able to use the system in his job after 5 days of Non-functional Usability
training.
The system shall allow employees to view the owner of any product. Functional
The system shall allow a customer to directly contact the nearest sales office Functional
in his region.
Down time after a failure shall not exceed 2 hours. Non-functional Reliability
The system shall make whitepapers available from the product page. Functional
The system shall allow the user's status to be stored for the next time they Functional
return to the web site.
TYPES OF REQUIREMENTS: USER / BUSINESS / SYSTEM 17

User requirements Often functional

§ often referred to as user needs, describe what the user does with the
system, such as what activities that users must be able to perform.
§ written for customers
§ often in natural language, no technical details

The purpose of user requirements is to allow

customers, stakeholders, to check that the system
will do what they intended.

It is a way for the analyst, the developers, to

communicate with the customers, with the
TYPES OF REQUIREMENTS: USER / BUSINESS / SYSTEM 18

Business requirements

§ describe why the organization is Usually non-functional

undertaking the project.

§ state some benefits that the developing

organization or its customers expect to
receive from the product.

The purpose of the business process

analysis is to determine how the business
process will work.
TYPES OF REQUIREMENTS: USER / BUSINESS / SYSTEM 19

System requirements Often non-functional

§ are the building blocks developers use to build the system.

§ are the traditional “shall” statements that describe what the system “shall
do.”
§ written for developers
§ contain detailed functional and non-functional requirements.
The purpose of the system requirements is to tell
developers what to build.

They must contain enough details so the developers can

take them and use them to design and then develop a
system.
TYPES OF REQUIREMENTS: USER / BUSINESS / SYSTEM 20
TYPES OF REQUIREMENTS: PRODUCTS / PROCESS 21

Product requirements:

§ Apply to the system to be delivered ("the product")

§ provides the specific properties or components that a product or system

must contain.

Process Requirements:

§ Apply to the building process for the system.

§ describes the activities that must be performed and constraints that must
be followed in the organization.
CONSTRAINTS 22

Constraints are a type of requirement that expresses some limitation, usually

imposed by the environment in which a system has to function.

§ Constraints are effectively global requirements, such as limited development

resources or a decision by senior management that restricts the way you develop a
system.

§ A constraint is a statement of restriction that modifies a requirement or set of

requirements by limiting the range of acceptable solutions.
§ Constraints can be economic, political, technical, or
environmental and pertain to your project resources,
schedule, target environment, or to the system itself.
REQUIREMENT ORIGINS 23

1. Stakeholders: Anybody who is effected by the system and

its functionality (Customers, users, and so on.).
2. Application domain:
Constraints that are characteristics of the
application domain that will affect the
functionality of the system (banking
regulations and school regulations, etc.).

3. Documentation:
Everything that refers to the functionality of
the system that we are going to build (notes,
papers, manuals, books, etc.).
REQUIREMENTS ENGINEERING PROCESS 24

Elicitation Analysis for

Verification

Analysis for Modeling

(Documentation)
Validation
ELICITATION TECHNIQUES 25

§ Background reading
involves collecting information by reading existing
documents such as company reports,
organizational charts, policy manuals, job descriptions, documentation of existing
systems, etc.

§ Hard data and Samples

- collect and choosing the sample of the
population for which to collect such data.

- hard data includes facts and figures such as

forms, invoices, financial information, survey
results, marketing, etc.
 Elicitation Techniques 26

§ Interviews
- Structured or Un(semi) - structured
- can collect a rich set of information (opinions and facts)
- requires special skills and experience

§ Survey
- can quickly collect information from a large number
- can be administered remotely (e.g., email, online, …)
- might miss opportunities to collect unforeseen
relevant information
 Elicitation Techniques 27

§ Meetings
- for summarization of findings and collection of feedback
- it is fundamental that have clearly stated objectives
and are planned carefully.
MODELING (DOCUMENT) REQUIREMENTS 28

After collection of needs, it should be modelled it in a

structured and clear way, so that it can be analysed and
refined.
Enterprise
System Qualities Enterprise Organization modelling: i*, SSM, ISAC
§ Security § Goals and objective Goal modelling: KAOS, CREW
§ Reliability § Organisational structure
§ Robustness
§ Tasks and dependencies
… § Agents, roles, intentionality System Qualities
Quality trade-offs:
QFD, win-win, AHP,
What? How?
Specific NFRs:
Timed Petri nets (performance)
Task models (usability)
Probabilistic MTTF (reliability)
Information and Behaviours
§ Information structure Information and Behaviours
§ Behavioural view Information modelling: E-R, Class Diagrams
– Scenarios and Use Cases Structured Analysis: SADT, SSADM, JSD
– State machine models Object Oriented Analysis: OOA, OOSE, OMT, UML
– Information flow
Formal Methods: SCR, RSML, Z, Larch, VDM
§ time/sequencing
ANALYZING THE REQUIREMENTS 29

§ Verification
developers will study the requirements to check whether they're correct, whether
they accurately reflect the customer needs as perceived by the developer.

Correctness Completeness Relevancy

§ can also check whether they are consistent, unambiguous, testable, etc.
 Analyzing the Requirements 30

§ Validation:
The goal of validation is to assess whether the collected requirements define the
system that the stakeholders really want.

§ The focus here is on the stakeholders.

Check the requirement: directly Prototype of the system Other techniques:

§ Surveys
§ Testing
§ …
 Analyzing the Requirements 31

§ Prioritization:
Sometimes, the available resources for the project are not
enough to satisfy all of them.
Limited Resources
§ For example, there's not enough time, not enough money, not
enough manpower.

Therefore, there are some requirements

that we won't be able to satisfy.

In these cases, we must prioritize Mandatory

our requirements. Nice to have
for instance, using MoSCoW.
Superfluous
 Analyzing the Requirements: Summary 32

In general, Analysis covers the following activities:

§ Properly formulating requirements: make them unambiguous and, if possible measurable
§ Prioritize requirements
§ Resolve contradictory requirements
§ May need interaction with stakeholders: this is done in Requirements Validation
§ Label requirements as functional/non-functional, Business/User/System, Product/Process
§ Organize the list of requirements, either by stakeholder
§ Assess how realistic each requirement is: can it be implemented? How expensive is it?

§ Put all this information into a document (or database): the Requirements Specification
SOFTWARE REQUIREMENT SPECIFICATION (SRS) 33

Domain
Properties Computer
Requirements
Specification Program

§ domain of the machine: the hardware, operating system, libraries and so

on, on which software will run.

§ domain of the application: a world in which the software will operate.

 34

§ SRS is a document or set of documentation that describes the features

and behaviour of a system or software application.
PITFALLS OF REQUIREMENTS ENGINEERING 35

§ Stakeholders are not illiterate, but often they have a background in fields
different from ICT…

§ Communication is as difficult as it is important …

§ Communication is key, from day 1 till the end of the project

§ Stakeholders don't know what they want.

§ Together you have to discover what is useful and feasible.

PITFALLS OF REQUIREMENTS ENGINEERING 36

§ Requirements must be formulated in a measurable, testable way.

§ But don't make them measurable in an artificial way, by filling in arbitrary
numbers.
§ It may take some iterations in a system to collect the necessary information for a
well-founded measurable formulation of a requirement.

§ Requirements can stand in the way of a proper understanding between

stakeholders and development team.

§ That happens if you think that the signature under the requirements document
is all you need to get from the client, in order to build an adequate system.
37