UNIVERSITI TEKNOLOGI MARA

CSC565
SOFTWARE ENGINEERING LAB

UNDERSTANDING
REQUIREMENTS

Version 2.0

Fakulti Teknologi Maklumat & Sains Kuantitatif

SOURCE OF REQUIREMENTS
Initial requirements come from the customer,
through:
Documents (such as RFI,RFP), meetings, interviews,
reports, etc

Advanced/Detail requirements come from the

analysis, after studying:
Scope and price
Feasibility (technological software, hardware;
organizational, social
Prototypes

Final requirements are stabilized in an iterative

process
CSC565- SOFTWARE ENGINEERING

REQUIREMENTS vs DESIGN
Requirements:
What the
system should
do
More abstract

Design:
How the
system should
do it
More detail
CSC565- SOFTWARE ENGINEERING

TYPES OF REQUIREMENTS
Functional Requirements
Statements of services that the system should
provide, how the system should react to
particular inputs and how the system should
behave in particular situations

Non-Functional Requirements
Constraints on the services or functions offered
by the system such as timing constraints,
constraints on the development process,
standards, etc.
CSC565- SOFTWARE ENGINEERING

FUNCTIONAL REQUIREMENTS
Describe functionality or system service
Depend on the type of software, expected
users and the type of system where the
software is used
Functional user requirements may be
high-level statements of what the system
should do; functional system requirements
should describe the system services in
detail
CSC565- SOFTWARE ENGINEERING

FUNCTIONAL REQUIREMENTS :
EXAMPLE
The user shall be able to search either all
of the initial set of databases or select a
subset from it
The system shall provide appropriate
viewers for the user to read documents in
the document store
Every order shall be allocated a unique
identifier (ORDER ID) which the user shall
be able to copy to the account's
permanent storage area
CSC565- SOFTWARE ENGINEERING

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

CSC565- SOFTWARE ENGINEERING

NON-FUNCTIONAL
REQUIREMENTS

CSC565- SOFTWARE ENGINEERING

THE RESPONSES
Extensive requirements
gathering and formalization in
order to minimize chances of
change later
Planned but iterative. Understand
what is and is not known now,
and plan and adapt accordingly.

On the fly requirements

elicitation in close collaboration
with users and customers

CSC565- SOFTWARE ENGINEERING

FREEZE REQUIREMENTS
Requirements are determined completely
in an early phase of the project. They are
then frozen and form a contractual
agreement between the customer and the
supplier
Issues
Not always realistic
Doesnt support changing requirements
May lead to more expensive or brittle system
CSC565- SOFTWARE ENGINEERING

ON-THE-FLY REQUIREMENTS
Since requirements will change, determine any
requirement informally and then only right before
it is about to be implemented
Exemplified by agile development methods
XP User stories
Scrum Prioritize the product backlog for each sprint

Issues
Requires dedication to a particular way of working
Relies on skilled individuals
Needs constant interaction with the customer
Quality of the customer can make or break the project

CSC565- SOFTWARE ENGINEERING

BE FLEXIBLE
Different projects have different needs:
Scale
Safety
Complexity
Cost-sensitivity
Market-driven (innovation)

Compare
Digital camera
Desktop char client
Nuclear power station control system
Digital television studio

CSC565- SOFTWARE ENGINEERING

ALSO CONSIDER
The degree to which requirements can be
determined and at what stage of the development
process
The amount of effort that is cost-effectively put
into gathering and documenting requirements (vs.
benefits on terms of reliability and customer
satisfaction)
Notations that can be shared and understood
development teams, customers, marketing,
management
Notations that mesh well with design and
implementation activities
CSC565- SOFTWARE ENGINEERING

UNIVERSITI TEKNOLOGI MARA

Thank You
CSC565- SOFTWARE ENGINEERING