Software Engineering I

Instructor:

Reham Adel

Ahram Canadian University- Faculty of Computers and Information

Technology
2

Chapter 4 – Requirements Engineering

Chapter 4 Requirements Engineering

 Topics covered
3

❑ What are Requirements ? Why are they important ?

❑ Criteria of a Good Requirement
❑ Requirements Completeness, & Consistency
❑ Project Failure / Success Factors
❑ Requirements Classifications and the Requirements
Engineering Process
❑ Defining Requirements Engineering

Chapter 4 Requirements Engineering

 What is a Requirement?
4

“.. A requirement is a necessary attribute in a system,

a statement that identifies a capability, characteristic,
or quality factor of a system for it to have value and
utility to a customer or user”

“.. A statement that identifies a product or process

operational, functional, or design characteristic or
constraint, which is unambiguous, testable or
measurable, and necessary for product or process
acceptability (by consumers or internal quality
assurance guidelines)”

Chapter 4 Requirements Engineering

 What is a Requirement?
5

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

Chapter 4 Requirements Engineering

 Requirements .. Why are they important ?
6

“ .. Requirements are important because they provide

the basis for all the development work that follows.
Once the requirements are set, developers initiate the
other technical work system design, development,
testing, implementation, and operation.”

“Without requirements or design, programming is the

art of adding bugs to an empty text file.”
Louis Srygley
Chapter 4 Requirements Engineering
 Requirements .. Why are they important ?
7

Requirements therefore form the basis for:

❑ Project Planning;

❑ Risk Management;

❑ Trade-Off;

❑ Change Control.

❑ Acceptance Testing;

Chapter 4 Requirements Engineering

 Requirements completeness and consistency
8

❑ Theoretically 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.
❑ Actually because of system and environmental
complexity, it is impossible to produce a complete
and consistent requirements document.
Chapter 4 Requirements Engineering
 Other Criteria of Good Requirements
9

Chapter 4 Requirements Engineering

 Requirements .. Why are they important ?
10

The most common reasons for project failure are not

technical.
1

Chapter 4 Requirements Engineering

 Requirements .. Why are they important ?
11

The most common reasons for project failure are not

technical.

Chapter 4 Requirements Engineering

 Requirements .. Why are they important ?
12

The most common reasons for project failure are not

technical.

Chapter 4 Requirements Engineering

 Requirements Abstraction
13

“ 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 documents may be called the requirements
document for the system”.

Chapter 4 Requirements Engineering

 Views of Requirements Classifications [ i.e., Types
of Requirements
14

Common Requirements Classifications include:

❑ Business REQs: The essential activities of an enterprise
(the reason for developing the software in the first
place).
❑ User REQs: Describes for the customers/users. The
services the system provides and its operational
constraints.
❑ Functional REQs: Describes what the software should do.

❑ Non Functional REQs: Describes software properties.

❑ Domain REQs: Describes constraints on the system from

the domain of operation.

Chapter 4 Requirements Engineering

 Defining Requirements Engineering
15

“ .. The subset of systems engineering concerned with

discovering, developing, tracing, analyzing,
qualifying, communicating, and managing
requirements that define the system at successive
levels of abstraction.”

Chapter 4 Requirements Engineering

 Defining Requirements Engineering
16

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.

Chapter 4 Requirements Engineering

 Requirements Engineering. Why?
17

“.. It’s not just a simple matter of writing down what the
customer says (s)he wants.”
❑ A fundamental problem in business is that requirements
are inherently dynamic; they will change over time as
our understanding of the problem we are trying to
solve changes.
❑ The importance of good requirements and the
underlying dynamic nature of the process mean that we
must be (1) as accurate as possible, and yet be (2)
flexible (i.e., we have a process for developing
requirements accommodating changed requirements as
we clarify the real requirements of customers).

Chapter 4 Requirements Engineering

 Requirements Engineering. Why?
18

“.. Too often, there is a tendency to want to start what is

often referred to as “the real work” (developing, or
programming, the software) too quickly.’’
❑ Many customers and project managers (PM) seem to
believe that actual programming work (“coding”)
indicates that progress is being made.
❑ According to industry experience, insufficient time and
effort are spent on the requirements related activities
associated with system development.
❑ Industry experience confirms that a better approach is
to invest more time in requirements gathering, analysis,
and management activities.

Chapter 4 Requirements Engineering

 Stated vs. Real Requirements
19

Stated Requirements are provided by a user/customer

at the beginning of a software development effort.
Real Requirements reveal the verified needs for a
particular system or capability (i.e., some real
requirements may be identified that the customer and
users omitted in the stated requirements). Actually,
identifying omitted requirements is a key task of the
Requirements Analysts (RA).

Chapter 4 Requirements Engineering

 Requirements Engineering Process
20

The processes used for Requirements Engineering (RE) vary

widely depending on the application domain, the people
involved and the organisation developing the
requirements. But, there are a number of generic activities
common to all processes:
Requirements elicitation
Requirements analysis
Requirements validation
Requirements management
In practice, RE is an iterative activity in which these
processes are interleaved.

Chapter 4 Requirements Engineering

 Requirements Engineering Process
21

A Spiral View

Chapter 4 Requirements Engineering