Web development .. presentation for IT students

1
Lecture
Lecture
Requirement Engineering
Requirement Engineering
Instructor: prof. Humaira

2
–
– Software Requirements –
Software Requirements –
Descriptions and specifications of a system
Descriptions and specifications of a system
Objectives:

To introduce the concepts of user and system requirements

To describe functional / non-functional requirements

To explain two techniques for describing system requirements

To explain how software requirements may be organised in a
requirements document

3
Topics covered
Topics covered
–
– Functional and non-functional requirements
Functional and non-functional requirements
–
– User requirements
User requirements
–
– System requirements
System requirements
–
– The software requirements document
The software requirements document

4
Software Requirement Engineering
Software Requirement Engineering
 This knowledge area is concerned with the
This knowledge area is concerned with the acquisition
acquisition,
, analysis
analysis,
, specification
specification,
,
validation
validation and
and management
management of software requirements
of software requirements
 It is widely acknowledged within the software industry that software projects are
It is widely acknowledged within the software industry that software projects are
critically vulnerable when these activities are performed poorly
critically vulnerable when these activities are performed poorly
 This has led to the widespread use of the term
This has led to the widespread use of the term ‘requirements engineering’
‘requirements engineering’ to
to
denote the systematic handling of requirements
denote the systematic handling of requirements
 One of the main objectives of requirements engineering is to discover how to
One of the main objectives of requirements engineering is to discover how to
partition the system; to identify which requirements should be allocated to which
partition the system; to identify which requirements should be allocated to which
components
components
 Software requirements are one of the products of the requirements
Software requirements are one of the products of the requirements
engineering process
engineering process

5
Requirements vs. Requirement Engineering
Requirements vs. Requirement Engineering
The descriptions of the
services and constraints
are the requirements
for the system
The process of finding out,
analyzing, documenting
and checking these
is called
requirements engineering
Focus on user defined tasks in order to fulfill the business requirements
Focus on user defined tasks in order to fulfill the business requirements

6
Requirements engineering
Requirements engineering
Requirements engineering is the process of establishing

the services that the customer requires from a system

the constraints under which it operates and is developed
Requirements
The descriptions of the system
that are generated during the
requirements engineering
process

7
What is a Requirement
What is a Requirement
 A condition or capability
A condition or capability needed by a user to solve problem or achieve an
needed by a user to solve problem or achieve an
objective [IEEE]
objective [IEEE]
 Requirements
Requirements are
are capabilities
capabilities and
and conditions
conditions to which the system - and
to which the system - and
more broadly the project must conform [JBR99]
more broadly the project must conform [JBR99]
 Software requirements express the
Software requirements express the needs
needs and
and constraints
constraints that are placed
that are placed
upon a software product that contribute to the satisfaction of some real
upon a software product that contribute to the satisfaction of some real
world application [Kot00].
world application [Kot00].
 Requirements describe how a system should act, appear or perform
Requirements describe how a system should act, appear or perform

8
What is a requirement?
What is a requirement?
 It may range from a
It may range from a high-level
high-level abstract statement
abstract statement of a
of a
service or of a system constraint to a
service or of a system constraint to a detailed
detailed mathematical
mathematical
functional specification
functional specification
 This is inevitable as requirements may serve a
This is inevitable as requirements may serve a dual
dual
function
function
 May be the basis for a bid for a contract
May be the basis for a bid for a contract -
- therefore must
therefore must
be open to interpretation
be open to interpretation
 May be the basis for the contract itself
May be the basis for the contract itself -
- therefore must
therefore must
be defined in detail
be defined in detail
 Both these statements may be called requirements
Both these statements may be called requirements

9
Overview
Overview
 What is it?
What is it?
 Who does it?
Who does it?
 Why is it important?
Why is it important?
 What are the tasks?
What are the tasks?

10
What is it?
What is it?
 Helps software engineer to better understand the
Helps software engineer to better understand the
problem they will work to solve
problem they will work to solve
 What the business impact of the software will be
What the business impact of the software will be
 What the customer wants
What the customer wants
 How end-user will interact with the software
How end-user will interact with the software

11
Who does it?
Who does it?
 Software engineers
Software engineers
 System engineers or analysts
System engineers or analysts
 Project stakeholders
Project stakeholders
 Anyone who has a direct interest in or benefits from the system
Anyone who has a direct interest in or benefits from the system
that is to be developed
that is to be developed
 Manages
Manages
 Customer
Customer
 End-users
End-users

12
Role of a system analyst
 The following basic questions pertaining to the project should be clearly understood by
the analyst in order to obtain a good grasp of the problem:

What is the problem?
 Why is it important to solve the problem?
 What are the possible solutions to the problem?
 What exactly are the data input to the system and what exactly are the data
output by the system?
 What are the likely complexities that might arise while solving the
problem?
 If there are external software or hardware with which the developed
software has to interface, then what exactly would the data interchange
formats with the external system be?

13
 Are you going to design and building an elegant
Are you going to design and building an elegant
software that is not what the customer wants?
software that is not what the customer wants?
 It establishes a solid base for design and construction
It establishes a solid base for design and construction
 It is a bridge to design and construction
It is a bridge to design and construction

14
Types of requirement
Types of requirement
 User requirements
User requirements
 Statements in natural language plus diagrams of the services the system
Statements in natural language plus diagrams of the services the system
provides and its operational constraints. Written for customers.
provides and its operational constraints. Written for customers. Focus
Focus
on user defined tasks in order to fulfill the business requirements
on user defined tasks in order to fulfill the business requirements
 System requirements
System requirements
 A structured document setting out detailed descriptions of the system
A structured document setting out detailed descriptions of the system
services. Written as a contract between client and contractor.
services. Written as a contract between client and contractor. “functional
“functional
specification”
specification”
 Software Design specification
Software Design specification
 A detailed software description which can serve as a basis for a design
A detailed software description which can serve as a basis for a design
or implementation. Written for developers
or implementation. Written for developers to
to add further details to the
add further details to the
system requirements specification
system requirements specification

15
Requirements readers
Requirements readers
Client managers
System end-users
Client engineers
Contractor managers
System architects
System end-users
Client engineers
System architects
Software developers
Client engineers (perhaps)
System architects
Software developers
User requirements
System requirements
Software design
specification

16
Levels of Software Requirements
Levels of Software Requirements
 Functional Requirements
Functional Requirements
 Non-Functional Requirements
Non-Functional Requirements

17
 Functional requirements
Functional requirements
 Statements of services the system should provide, how the
Statements of services the system should provide, how the
system should react to particular inputs and how the system
system should react to particular inputs and how the system
should behave in particular situations.
should behave in particular situations.
 Non-functional requirements
Non-functional requirements
 constraints on the services or functions offered by the system
constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
such as timing constraints, constraints on the development
process, standards, etc.
process, standards, etc.
 Domain requirements
Domain requirements
 Requirements that come from the application domain of the
Requirements that come from the application domain of the
system and that reflect characteristics of that domain
system and that reflect characteristics of that domain

18
Functional
Functional Requirements
Requirements
Describe functionality or system services
Describe functionality or system services
 Depend on the type of software
Depend on the type of software,
, expected users and the
expected users and the
type of system where the software is used
type of system where the software is used
 Functional user requirements may be high-level
Functional user requirements may be high-level
statements of what the system should do
statements of what the system should do BUT
BUT
functional system requirements should describe the
functional system requirements should describe the
system services in detail
system services in detail

19
Functional requirements
 Statements of services the system should provide, how the system
should react to particular inputs and how the system should behave
in particular situations.
 Describes the interaction of software with its environment and
specify the inputs, outputs, external interfaces, and the function that
should not be included.
View of a system performing a set of functions

20
Examples of functional requirements
Examples of functional requirements
 The user shall be able to search either all of the initial set
The user shall be able to search either all of the initial set
of databases or select a subset from it.
of databases or select a subset from it.
 The system shall provide appropriate viewers for the
The system shall provide appropriate viewers for the
user to read documents in the document store.
user to read documents in the document store.
 Every order shall be allocated a unique identifier
Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to copy to the
(ORDER_ID) which the user shall be able to copy to the
account’s permanent storage area.
account’s permanent storage area.

21
Contd……
Contd……
 The user of the bank should be able to search the desired
The user of the bank should be able to search the desired
services from the available ones.
services from the available ones.
 There should be appropriate documents for users to
There should be appropriate documents for users to
read. This implies that when a user wants to open an
read. This implies that when a user wants to open an
account in the bank, the forms must be available so that
account in the bank, the forms must be available so that
the user can open an account.
the user can open an account.
 After registration, the user should be provided with
After registration, the user should be provided with
unique acknowledgement number so that he can later be
unique acknowledgement number so that he can later be
given an account number.
given an account number.
!... Functional requirements should be Complete and Consistence…!z

22
Requirements imprecision
Requirements imprecision
 Problems arise when requirements are not precisely
Problems arise when requirements are not precisely
stated
stated
 Ambiguous requirements may be interpreted in different
Ambiguous requirements may be interpreted in different
ways by developers and users
ways by developers and users
 Consider the term ‘appropriate viewers’
Consider the term ‘appropriate viewers’
 User intention
User intention - special purpose viewer for each different
- special purpose viewer for each different
document type
document type
 Developer interpretation
Developer interpretation - Provide a text viewer that
- Provide a text viewer that
shows the contents of the document
shows the contents of the document

23
Requirements
Requirements C
Completeness
ompleteness and
and C
Consistency
onsistency
 In principle
In principle requirements should be both
requirements should be both complete
complete
and
and consistent
consistent
Complete
Complete
 They should include descriptions of all facilities required
They should include descriptions of all facilities required
Consistent
Consistent
 There should be no conflicts or contradictions in the descriptions
There should be no conflicts or contradictions in the descriptions
of the system facilities
of the system facilities
 In practice
In practice, it is
, it is very difficult
very difficult or
or impossible
impossible to
to
produce
produce a complete
a complete and
and consistent
consistent requirements
requirements
document
document

24
STEP 1
STEP 1
 Identifying functional requirements from a problem
description
 The high-level functional requirements often need to be identified
either from an informal problem description document or from a
conceptual understanding of the problem.
 There can be many types of users of a system and their requirements
from the system may be very different.
 Functional requirements actually describe a set of high-level
requirements, where each high-level requirement takes some data from
the user and provide some data to the user as an output.
 Each high-level requirement might consist of several other functions.

25
We list all functions {fi} that the system performs. Each function fi as shown
in fig.3.2 is considered as a transformation of a set of input data to some
corresponding output data.

26
 Example:- Consider the case of the library system, where
–
 F1: Search Book function (fig. 3.3)
 Input: an author’s name
 Output: details of the author’s books and the location of
these books in the library

27
STEP 2
STEP 2
 Documenting functional requirements
 Example: - Withdraw Cash from ATM
 R1: withdraw cash
 Description: The withdraw cash function first determines the type of account that the
user has and the account number from which the user wishes to withdraw cash. It
checks the balance to determine whether the requested amount is available in the
account. If enough balance is available, it outputs the required cash, otherwise it
generates an error message.
 R1.1 select withdraw amount option
 Input: “withdraw amount” option
 Output: user prompted to enter the account type
 R1.2: select account type
 Input: user option
 Output: prompt to enter amount
 R1.3: get required amount
 Input: amount to be withdrawn in integer values greater than 100 and less than 10,000
in multiples of 100.
 Output: The requested cash and printed transaction statement.
 Processing: the amount is debited from the user’s account if sufficient balance is
available, otherwise an error message displayed.

28
Nonfunctional requirements
 Non functional requirements deal with the characteristics of the system
which can not be expressed as functions - such as the maintainability of
the system, portability of the system, usability of the system, etc.
 constraints on the services
constraints on the services or functions offered by the system such as timing
or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.
constraints, constraints on the development process, standards, etc.
 Nonfunctional requirements may include:
 reliability issues
 performance issues,
 interface with other external systems,
 accuracy of results
 human - computer interface issues
 constraints on the system implementation.
 security and maintainability of the system, etc.

29
Define system properties and constraints e.g.
Define system properties and constraints e.g. reliability,
reliability,
response time
response time and
and storage requirements
storage requirements. Constraints are
. Constraints are
I/O device capability
I/O device capability,
, system representations
system representations, etc.
, etc.
 Process requirements
Process requirements may also be specified mandating a
may also be specified mandating a
particular CASE system, programming language or
particular CASE system, programming language or
development method
development method
 Non-functional requirements
Non-functional requirements may be more critical than
may be more critical than
functional requirements. If these are not met, the system
functional requirements. If these are not met, the system
is useless
is useless

30
Non-functional classifications
Non-functional classifications
 Product requirements
Product requirements
 Requirements which specify that the
Requirements which specify that the delivered product
delivered product
must behave in a particular way
must behave in a particular way e.g. execution speed,
e.g. execution speed,
reliability, etc.
reliability, etc.
 Organisational requirements
Organisational requirements
 Requirements which are a
Requirements which are a consequence of organisational
consequence of organisational
policies and procedures
policies and procedures e.g. process standards used,
e.g. process standards used,
implementation requirements, etc.
implementation requirements, etc.
 External requirements
External requirements
 Requirements which arise from factors which are
Requirements which arise from factors which are external
external
to the system and its development process
to the system and its development process e.g.
e.g.
interoperability requirements, legislative requirements, etc.
interoperability requirements, legislative requirements, etc.

31
Non-functional requirement types
Performance
requirements
Space
requirements
Usability
requirements
Efficiency
requirements
Reliability
requirements
Portability
requirements
Interoperability
requirements
Ethical
requirements
Legislative
requirements
Implementation
requirements
Standards
requirements
Delivery
requirements
Safety
requirements
Privacy
requirements
Product
requirements
Organizational
requirements
External
requirements
Non-functional
requirements

32
Performance
requirements
Space
requirements
Usability
requirements
Efficiency
requirements
Reliability
requirements
Portability
requirements
Interoperability
requirements
Ethical
requirements
Legislative
requirements
Implementation
requirements
Standards
requirements
Delivery
requirements
Safety
requirements
Privacy
requirements
Product
requirements
Organizational
requirements
External
requirements
Non-functional
requirements

33
Examples of non-functional Requirements
Examples of non-functional Requirements
 Product requirements
Product requirements
 The user interface for library system shall be implemented as
The user interface for library system shall be implemented as
simple HTML without frames or java applets
simple HTML without frames or java applets
 Organisational requirements
Organisational requirements
 The system development process and deliverable documents
The system development process and deliverable documents
shall conform to the process and deliverables defined in
shall conform to the process and deliverables defined in
XYZCo-SP-STAN-95
XYZCo-SP-STAN-95
 External requirements
External requirements
 The system shall not disclose any personal information about
The system shall not disclose any personal information about
system users apart from their name and library reference
system users apart from their name and library reference
number to the library staff who use the system
number to the library staff who use the system

34
Domain requirements
Domain requirements
 Derived from the application domain
Derived from the application domain and
and describe system
describe system
characteristics and features
characteristics and features that reflect the domain
that reflect the domain
 May be new functional requirements, constraints on existing
May be new functional requirements, constraints on existing
requirements or define specific computations
requirements or define specific computations
 If domain requirements are not satisfied,
If domain requirements are not satisfied, the system may be
the system may be
unworkable
unworkable
 Include any constraint present in the existing functional
requirements.
 It may contain a design constraint that describes the user interface.
 Copyright restrictions and security mechanism for the files and
documents used in system

35
Library system domain requirements
Library system domain requirements
 There shall be a standard user interface to all databases which shall
There shall be a standard user interface to all databases which shall
be based on the Z39.50 standard.
be based on the Z39.50 standard.
 Because of copyright restrictions, some documents must be deleted
Because of copyright restrictions, some documents must be deleted
immediately on arrival. Depending on the user’s requirements,
immediately on arrival. Depending on the user’s requirements,
these documents will either be printed locally on the system server
these documents will either be printed locally on the system server
for manually forwarding to the user or routed to a network printer.
for manually forwarding to the user or routed to a network printer.

36
Contd…..
Contd…..
 When domain requirements are not expresses clearly, it
When domain requirements are not expresses clearly, it
can result in various difficulties such as:
can result in various difficulties such as:
 Problem of Understandability
Problem of Understandability
 Difficult to understand when specified in the language of
Difficult to understand when specified in the language of
application domain (Such as mathematical expressions)
application domain (Such as mathematical expressions)
 Problem of implicitness
Problem of implicitness
 Due to incomplete information (not express clearly) creates
Due to incomplete information (not express clearly) creates
problem for development team
problem for development team

37
User requirements
User requirements
 Should describe functional and non-functional
Should describe functional and non-functional
requirements
requirements so that they are understandable by system
so that they are understandable by system
users who don’t have detailed technical knowledge
users who don’t have detailed technical knowledge
 User requirements are defined using
User requirements are defined using natural language
natural language,
,
tables
tables and
and diagrams
diagrams

38
Problems with natural language
Problems with natural language
 Lack of clarity
Lack of clarity
 Precision is difficult without making the document
Precision is difficult without making the document
difficult to read
difficult to read
 Requirements confusion
Requirements confusion
 Functional and non-functional requirements tend to
Functional and non-functional requirements tend to
be mixed-up
be mixed-up
 Requirements amalgamation
Requirements amalgamation
 Several different requirements may be expressed
Several different requirements may be expressed
together
together

39
Decision tree representation

41
Guidelines for writing requirements
Guidelines for writing requirements
 Invent a standard format and use it for all requirements
Invent a standard format and use it for all requirements
 Use language in a consistent way. Use
Use language in a consistent way. Use
shall
shall for mandatory requirements
for mandatory requirements,
,
should
should for desirable requirements
for desirable requirements
 Use let highlighting to identify key parts of the requirement
Use let highlighting to identify key parts of the requirement
Avoid the use of computer jargon !!!
Avoid the use of computer jargon !!!

Web development .. presentation for IT students

More Related Content

Similar to Web development .. presentation for IT students (20)

Recently uploaded (20)

Web development .. presentation for IT students