Scribd
Upload
16 views20 pages

Chapter 3 Rerquirements Engineering

Uploaded by

enereznixonjames
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
16 views20 pages

Chapter 3 Rerquirements Engineering

Uploaded by

enereznixonjames
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

LECTURE AND LABORATORY

Subject Code: CS6209

SOFTWARE
ENGINEERING
INSTRUCTOR: ELLEN M. GUIÑARES
TABLE OF CONTENT
REQUIREMENTS ENGINEERING
01 REQUIREMENTS ENGINEERING
05 PROCESSES

FUNCTIONAL AND NON-


02 FUNCTIONAL REQUIREMENTS 06 REQUIREMENTS ELICITATION AND ANALYSIS

THE SOFTWARE
03 REQUIREMENTS DOCUMENT 07 REQUIREMENTS VALIDATION

04 REQUIREMENTS SPECIFICATION 08 REQUIREMENTS MANAGEMENT


INTRODUCTION
The requirements for a system are the descriptions of
what the system should do— the services that it
provides 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.
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 predefined.
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 of these documents may be called
the requirements document for the system.
REQUIREMENTS
USER REQUIREMENTS
: User requirements are 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.

SYSTEM REQUIREMENTS
:System requirements are 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 software developers.
REQUIREMENTS

USER REQUIREMENTS
REQUIREMENTS
SYSTEM REQUIREMENTS
READERS OF THE
REQUIREMENTS
SOFTWARE
SYSTEM
CLASSIFICATION

FUNCTIONAL NON-FUNCTIONAL
REQUIREMENTS REQUIREMENTS
SOFTWARE SYSTEM CLASSIFICATION

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.
SOFTWARE SYSTEM CLASSIFICATION

FUNCTIONAL REQUIREMENTS

Ex: 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 eight-digit
employee number.
SOFTWARE SYSTEM CLASSIFICATION

NON-FUNCTIONAL REQUIREMENTS

are requirements that are not directly concerned with


the specific services delivered by the system to its
users.
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.
SOFTWARE SYSTEM CLASSIFICATION

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.
often apply to the system as a whole, rather
than individual system features or services.
REASONS OF
DIFFUSION
The implementation of these requirements may be diffused throughout the system.
There are two reasons for this:
MAY AFFECT THE OVERALL ARCHITECTURE OF A SYSTEM RATHER THAN THE
INDIVIDUAL COMPONENTS.

A SINGLE NON-FUNCTIONAL REQUIREMENT, SUCH AS A SECURITY REQUIREMENT,


MAY GENERATE A NUMBER OF RELATED FUNCTIONAL REQUIREMENTS THAT DEFINE
NEW SYSTEM SERVICES THAT ARE REQUIRED. IN ADDITION, IT MAY ALSO GENERATE
REQUIREMENTS THAT RESTRICT EXISTING REQUIREMENTS.
TYPES OF NON-FUNCTIONAL
REQUIREMENTS
PRODUCT REQUIREMENTS
These requirements specify or constrain the behavior of
the software.

Examples include performance requirements on how fast


the system must execute and how much memory it
requires, reliability requirements that set out the
acceptable failure rate, security requirements, and
usability requirements.
The MHC-PMS shall be available to all clinics during normal working hours (Mon–
Fri, 08.30–17.30). Downtime within normal working hours shall not exceed five
seconds in any one day.
ORGANIZATIONAL REQUIREMENTS
These requirements are broad system requirements
derived from policies and procedures in the customer’s
and developer’s organization.
Examples include operational process requirements that
define how the system will be used, development process
requirements that specify the programming language, the
development environment or process standards to be
used, and environmental requirements that specify the
operating environment of the system
Users of the MHC-PMS system shall authenticate themselves using their
health authority identity card.
EXTERNAL REQUIREMENTS
This broad heading covers all requirements that are
derived from factors external to the system and its
development process.
Examples These may include regulatory requirements that
set out what must be done for the system to be approved
for use by a regulator, such as a central bank; legislative
requirements that must be followed to ensure that the
system operates within the law; and ethical requirements
that ensure that the system will be acceptable to its users
and the general public.
The system shall implement patient privacy provisions as set out in
HStan-03-2006-priv.
LET’S TAKE
A BREAK
THANK
YOU
FOR YOUR INTEREST
IN THIS SUBJECT!

You might also like