Scribd
Upload
9 views16 pages

Module 04

This document provides an overview of software requirement analysis. It discusses the characteristics of requirements engineering, functional and non-functional requirements, and the components of a software requirements document based on IEEE Std 830. The document also outlines the major activities in requirements engineering, including feasibility study, elicitation, specification, and validation. It describes challenges in eliciting requirements and techniques like scenarios and use cases.

Uploaded by

irunarara
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
9 views16 pages

Module 04

This document provides an overview of software requirement analysis. It discusses the characteristics of requirements engineering, functional and non-functional requirements, and the components of a software requirements document based on IEEE Std 830. The document also outlines the major activities in requirements engineering, including feasibility study, elicitation, specification, and validation. It describes challenges in eliciting requirements and techniques like scenarios and use cases.

Uploaded by

irunarara
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/ 16

CMP203

Introduction to Software Engineering


Module 04
Software Requirement Analysis

Main reference:
• Software Engineering: A Practitioner’s Approach by Roger S.
Pressman, 7th Edition, 2010, McGraw-Hill, Chapter 5 pp120-
133, Chapter 4)
• Software Engineering by Ian Sommerville, 9th Edition, 2011,
Addison-Wesley. Chapter 4, pp83-106)
Islamic Online University ©
Learning Outcomes
Explain the characteristics of requirements
1 engineering, stakeholders and eliciting requirements

Understand how requirements may be organized in a


2 software requirements document

Understand the difference between functional and


3 non-functional requirements

Identify the components of Software Requirement


4 Documents-IEEE Std 830

Islamic Online University ©


Introduction
• According to IEEE Recommended Practice for
Software Requirement Specifications, IEEE Std
830-1998, a well prepared SRS have several
benefits:-
– Establishes the basis for agreement between clients
and developers
– Reduces the development effort
– Provides a basis for estimating costs and schedules
– Provides a baseline for validation and verification
– Facilitates transfer
– Serves as a basis for enhancement
Islamic Online University ©
SRS IEEE Std 830-1998

Islamic Online University ©


Functional Requirements
• Concerned with the functionality or services that a
software system is expected to provide, and the
interaction between the system and its environment.
A Enter
B Verify
account C How may
your PIN XYZ I help
you?

1
4 2
7 5 63 1
8 4 2
0 9 7 5 63
8
0 9

Typing in XYZ valid. Withdraw


PIN number Balance: $60
… $100

D E XYZ
Please take
your cash withdrew
$60

1
4 2
7 5 63
8
0 9

Collecting
cash …
Acknowledged
Islamic Online University ©
Non-functional Requirements

Islamic Online University ©


Categories of Non-Functional
Requirements

1. Product requirements
2. Organizational requirements
3. External requirements

Islamic Online University ©


Requirement Engineering Process

Islamic Online University ©


4 Major Activities in Requirement
Engineering
a) Feasibility Study
b) Requirement Elicitation and Analysis
c) Requirements Specification
d) Requirement Validation

Islamic Online University ©


Establishing the Groundwork

i) Identifying stakeholders
ii) Recognizing Multiple Viewpoints
iii) Working toward Collaboration
iv) Asking the First Questions

Islamic Online University ©


Requirement Elicitation

• Also known as requirements gathering,


combines elements of
– problem solving,
– elaboration,
– negotiation, and
– specification.

Islamic Online University ©


Collaborative Requirements Gathering
Basic guidelines:

• Meetings are conducted and attended by both software


engineers and other stakeholders.
• Rules for preparation and participation are established.
• An agenda is suggested that is formal enough to cover all
important points but informal enough to encourage the
free flow of ideas.
• A “facilitator” (can be a customer, a developer, or an
outsider) controls the meeting.
• A “definition mechanism” (can be work sheets, flip charts,
or wall stickers or an electronic bulletin board, chat room,
or virtual forum) is used.

Islamic Online University ©


Requirement Discovery

• Interviews
• Scenarios
• Use cases
• Ethnography

Islamic Online University ©


Scenario
1. A description of what the system and users
expects when the scenario starts.
2. A description of the normal flow of events in the
scenario.
3. A description of what can go wrong and how this
is handled.
4. Information about other activities that might be
going on at the same time.
5. A description of the system state when the
scenario finishes.

Islamic Online University ©


Eliciting Requirements - Difficulties
• Stakeholders often don’t know what they want from a
computer system except in the most general terms;
• Stakeholders in a system naturally express requirements in
their own terms and with implicit knowledge of their own
work.
• Different stakeholders have different requirements and they
may express these in different ways.
• Political factors may influence the requirements of a system.
Managers may demand specific system requirements because
these will allow them to increase their influence in the
organization.
• The economic and business environment in which the analysis
takes place is dynamic.

Islamic Online University ©


Summary
• 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. These might be product requirements,
organizational requirements, or external requirements. They often relate to the
emergent properties of the system and therefore apply to the system as a whole.

• The software requirements document is an agreed statement of the system


requirements. It should be organized so that both system customers and software
developers can use it.

• The requirements engineering process includes a feasibility study, requirements


elicitation and analysis, requirements specification, requirements validation, and
requirements management.

• Requirements elicitation and analysis is an iterative process that can be


represented as a spiral of activities—requirements discovery, requirements
classification and organization, requirements negotiation, and requirements
documentation.
Islamic Online University ©

You might also like