University of Umm Al-Qura - - College of Computers - - Department of Computer Science and Artificial Intelligence

Course Title
Software Engineering (SE3037)

Chapter 1
Software requirements fundamentals

Dr. Mohamed TOUNSI

Third Term: 2023/2024
Objectives
● To introduce software engineering and to explain its importance

● To introduce the concepts of user and system requirements

● To describe functional and non-functional requirements

2
History of software engineering
● The notion of software engineering was first proposed in 1968 at a
conference held to discuss what was then called the software crisis
(Naur and Randell 1969).
● It became clear that individual approaches to program development
did not scale up to large and complex software systems. These were
unreliable, cost more than expected, and were delivered late.
● Throughout the 1970s and 1980s, a variety of new software
engineering techniques and methods were developed, such as
structured programming, information hiding, and object-oriented
development.
● Tools and standard notations were developed which are the basis of
today’s software engineering.

http://software-engineering-book.com/web/history
3
 Frequently asked questions about software
engineering

1. What is software?

Computer programs and associated documentation. Software products may be

developed for a particular customer or may be developed for a general market.

2. What are the attributes of good software?

Good software should deliver the required functionality and performance to the
user and should be maintainable, dependable, efficient and acceptable.

3. What is software engineering?

Software engineering is an engineering discipline that is concerned with all

aspects of software production from initial conception to operation and
maintenance.

4. What are the fundamental software engineering activities?

Software specification, software development, software validation and software

evolution.
4
 Frequently asked questions about software
engineering

5. What is the difference between software engineering and

computer science?

Computer science focuses on theory and fundamentals; software engineering is

concerned with the practicalities of developing and delivering useful software.

6. What is the difference between software engineering and system

engineering?

System engineering is concerned with all aspects of computer-based systems

development including hardware, software and process engineering. Software
engineering is part of this more general process.

7. What are the key challenges facing software engineering?

Coping with increasing diversity, demands for reduced delivery times and
developing trustworthy software. 5
 Frequently asked questions about software
engineering

8. What are the costs of software engineering?

Roughly 60% of software costs are development costs, 40% are testing costs.
For custom software, evolution costs often exceed development costs.

9. What are the best software engineering techniques and methods?

While all software projects have to be professionally managed and developed,

different techniques are appropriate for different types of system.

For example, games should always be developed using a series of prototypes

whereas safety critical control systems require a complete and analyzable
specification to be developed.

There are no methods and techniques that are good for everything.

6
kinds of software product
● Two kinds of software product:

○ Generic products: Stand-alone systems that are produced to be

sold on the open market to any customer who can buy them.
■ Apps for mobile devices and software for PCs, such as word
processors and drawing tools.

○ Customized (or bespoke) software: Systems that are

developed for a particular customer.

■ Control systems for electronic devices and air traffic control

systems.

7
Essential attributes of good software
The software should deliver the required functionality and performance to
the user and should be maintainable, dependable, efficiency and
acceptable.
● Maintainability
○ Software should be written in such a way that it can evolve to
meet the changing needs of customers.
○ This is a critical attribute because software change is an inevitable
requirement of a changing business environment.
● Dependability and security
○ Software dependability includes a range of characteristics
including reliability, security, and safety.
○ Dependable software should not cause physical or economic
damage in the event of system failure.
○ Software has to be secure so that malicious users cannot access or
damage the system.
8
Essential attributes of good software (cont.)

● Efficiency

○ Software should not make wasteful use of system resources such

as memory and processor cycles.
○ Efficiency therefore includes responsiveness, processing time,
resource utilization, etc.
● Acceptability

○ Software must be acceptable to the type of users for which it is

designed.
○ This means that it must be understandable, usable, and
compatible with other systems that they use.

9
Software engineering
● Software engineering is an engineering field that is concerned with all
aspects of software production.
● Software engineers should adopt a systematic and organized approach
to their work and use appropriate tools and techniques depending on
the problem to be solved. Four fundamental activities are common to
all software production.

1. Software specification, where customers and engineers define the

software that is to be produced and the constraints on its operation.

2. Software development, where the software is designed and

programmed.

3. Software validation, where the software is checked to ensure that it

is what the customer requires.

4. Software evolution, where the software is modified to reflect

changing customer and market requirements.
10
Requirement
● The requirements for a system are the descriptions of the services that
a system should provide and the constraints on its operation.
● These requirements reflect the needs of customers for a system that
serves a certain purpose such as controlling a device, placing an order,
or finding information.
● The process of finding out, analyzing, documenting and checking these
services and constraints is called requirements engineering (RE).
● It is about WHAT not HOW.

● Nothing can be said obvious.

● It may range from a high-level abstract statement to a detailed

mathematical specification. (It may be as complex as a 500 pages of
description.)
● It may serve as the basis for a bid for a contract or the basis for the
contract itself.
11
Why requirements?

● The advantages of a complete set of documented requirements:

○ Ensures the user (not the developer) drives system functionalities
○ Helps avoiding confusion and arguments.
○ Helps minimizing the changes.
● Changes in requirements are expensive. It costs:
○ 3 x as much during the design phase.
○ 5-10 x as much during implementation.
○ 10-100 x as much after release.
● 2/3 of finished system errors are requirements and design errors.
● A careful requirements process doesn’t mean there will be no changes
later.
○ Average project experiences about 25% changes in the
requirements. 12
Types of Requirements
● User requirements

○ Statements, in a natural language plus diagrams, of what services

the system is expected to provide to system users and the
constraints under which it must operate.
○ The user requirements may vary from broad statements of the
system features required to detailed, precise descriptions of the
system functionality.
● System requirements

○ More detailed descriptions of the software system’s functions,

services, and operational constraints.
○ The system requirements document (sometimes called a
functional specification) should define exactly what is to be
implemented.
○ It may be part of the contract between the system buyer and the
13
software developers.
 An example of User and system requirements

This example from the mental health care patient information system
(Mentcare) shows how a user requirement may be expanded into several
system requirements.

14
Readers of different types of requirements
specification

15
Functional and Non-functional requirements

● Software system requirements are often classified as functional or non-

functional requirements:

1. Functional requirements These are statements of services the

system should provide, how the system should react to particular
inputs, and how the system should behave in particular situations.

In some cases, the functional requirements may also explicitly

state what the system should not do.

2. Non-functional requirements These are constraints on the

services or functions offered by the system. They include timing
constraints, constraints on the development process, and
constraints imposed by standards.

Non-functional requirements often apply to the system as a whole

rather than individual system features or services.

16
Functional Requirements
● Describe what the system should do.

● Depend on the type of software being developed, the expected users of

the software, and the general approach taken by the organization when
writing requirements.
● When expressed as user requirements, functional requirements should
be written in natural language so that system users and managers can
understand them.
● Expand the user requirements and are written for system developers.

● They should describe the system functions, their inputs and outputs,
and exceptions in detail.
● Vary from general requirements covering what the system should do to
very specific requirements reflecting local ways of working or an
organization’s existing systems.

17
Functional Requirements (.cont)
● For example, here are examples of functional requirements for the
Mentcare system, used to maintain information about patients
receiving treatment for mental health problems:

1. A user shall be able to search the appointments lists for all

clinics.

2. The system shall generate each day, for each clinic, a list of
patients who are expected to attend appointments that day.

3. Each staff member using the system shall be uniquely identified

by his or her eight-digit employee number.

18
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 ‘appropriate viewers’

○ User intention - special purpose viewer for each different

document type;
○ Developer interpretation - Provide a text viewer that shows the
contents of the document.

19
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.

20
Non-functional Requirements
● They define system properties and constraints e.g. reliability,
response time, maintainability, scalability, portability, 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.
● Often internal to an organization or required for fit /
compatibility with other comparable systems.
● Non-functional requirements may be more critical than
functional requirements. If these are not met, the system may
be useless.
21
Types of Non-functional Requirements
● Product requirements

○ Requirements which specify that the delivered product must

behave in a particular way.
○ e.g., execution speed, reliability, etc.

● Organizational requirements

○ Requirements which are a consequence of organizational 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.

22
Types of Non-functional Requirements

23
Examples of possible non-functional requirements
for the Mentcare system

● Product requirement

○ The Mentcare system shall be available to all clinics during normal

working hours (Mon–Fri, 08:30–17:30). Downtime within normal
working hours shall not exceed 5 seconds in any one day.
● Organizational requirement

○ Users of the Mentcare system shall identify themselves using their

health authority identity card.
● External requirement

○ The system shall implement patient privacy provisions as set out

in HStan-03-2006-priv.

24
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.

25
Metrics for specifying non-functional requirements

26
Domain requirements

● Derived from the application domain and describe system

characteristics and features that reflect the domain.
● Domain requirements be new functional requirements, constraints on
existing requirements or define specific computations.
● If domain requirements are not satisfied, the system may be
unworkable.

27
Domain requirements problems

● Understandability

○ Requirements are expressed in the language of the application

domain;
○ Application written for mortgage banking people need to express
functionality in terms of home loans, mortgage balances, escrow,
investor accounting, foreclosure, etc.
○ 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.
○ And this is often a major problem in communications!!!

28
Summary
● Software engineering is an engineering discipline that is concerned
with all aspects of software production.
● Software products consist of developed programs and associated
documentation. Essential product attributes are maintainability,
dependability, efficiency and usability.
● The software process consists of activities that are involved in
developing software products. Basic activities are software
specification, development, validation and evolution.
● Requirements for a software system set out what the system should do
and define constraints on its operation and implementation.
● Functional requirements are statements of the services that the system
must provide or are descriptions of how some computations must be
carried out.
● Non-functional requirements often constrain the system being
developed and the development process being used. 29
Questions

30