Software requirements and analysis

UNIT-II
SOFTWARE ENGINNERING
V-SEMESTER UNIT-II
PRESENTED BY CH.PHANINDRA

UNIT II
REQUIREMENTS ANALYSIS
Requirement Engineering Processes
Feasibility Study
Problem of Requirements
Software Requirement Analysis
Analysis Concepts and Principles
Analysis Model
Analysis Process
V-SEMESTER UNIT-II

V-SEMESTER UNIT-II

->The software requirements are
description of features and functionalities
of the target system.
->Requirements convey(tells) the
expectations of users from the software
product.
Like known or unknown, expected or
unexpected from client’s point of view.
V-SEMESTER UNIT-II

Requirement Engineering
-> The process to gather the software
requirements from client, analyze and
document them is known as requirement
engineering.
-> The goal of requirement engineering is to
develop and maintain descriptive ‘System
Requirements Specification’ document.
V-SEMESTER UNIT-II

Requirement Engineering
Software engineering task that bridges the gap
between system level requirements engineering
and software design.
Provides software designer with a
representation of system information, function,
and behavior that can be translated to data,
architectural, and component-level designs.
Expect to do a little bit of design during analysis
and a little bit of analysis during design.SOFTWARE ENGINNERING
V-SEMESTER UNIT-II

V-SEMESTER UNIT-II

V-SEMESTER UNIT-II
Software Requirements Analysis Phases
Begins with System Specification and Software
Project Plan
Five Areas of effort
Problem recognition
Evaluation and synthesis (focus is on what not how)
Modeling
Specification
Review
Goal: recognition of the basic problem elements as
perceived by the customer/users.

V-SEMESTER UNIT-II
Software Requirements Analysis Phases
Customer meetings are the most commonly used
technique.
Use context free questions to find out:
customer's goals and benefits
identify stakeholders
Who is behind the request for this work?
Who will use the solution?
What will be the economic benefit of a successful
solution?
Is there another source for the solution that you
need?
gain understanding of problem

Requirement Engineering Process
It is a four step process, which includes –
Feasibility Study
Requirement Gathering
Software Requirement Specification
Software Requirement Validation
V-SEMESTER UNIT-II

Feasibility study
When the client approaches the organization
for getting the desired product developed, it
comes up with rough idea about what all
functions the software must perform and which
all features are expected from the software.
This feasibility study is focused towards goal of
the organization.
V-SEMESTER UNIT-II

Requirement Gathering
gathering requirements from the user.
Analysts and engineers communicate with the
client and end-users to know their ideas on
what the software should provide and which
features they want the software to include.
V-SEMESTER UNIT-II

Software Requirement Specification
->SRS is a document created by system analyst
after the requirements are collected from
various stakeholders.
->SRS defines how the intended software will
interact with hardware, external interfaces,
speed of operation, response time of system,
Security, Quality, Limitations etc.
->The requirements received from client are
written in natural language.SOFTWARE ENGINNERING
V-SEMESTER UNIT-II

SRS should come up with following features:
User Requirements are expressed in natural language.
Technical requirements are expressed in structured
language, which is used inside the organization.
Design description should be written in Pseudo code.
Format of Forms and GUI screen prints.
Conditional and mathematical notations for DFDs etc.
V-SEMESTER UNIT-II

Software Requirement Validation
After requirement specifications are developed, the
requirements mentioned in this document are
validated.
Requirements can be checked against following
conditions -
If they can be practically implemented
If they are valid and as per functionality and domain of
software
If there are any ambiguitiesSOFTWARE ENGINNERING
V-SEMESTER UNIT-II

Requirement Elicitation Process
Requirement elicitation process can be depicted
using the folloiwng diagram:
V-SEMESTER UNIT-II

Requirements gathering - The developers discuss
with the client and end users and know their
expectations from the software.
Organizing Requirements - The developers prioritize
and arrange the requirements in order of importance,
urgency and convenience.
Negotiation & discussion - If requirements are
ambiguous or there are some conflicts in
requirements of various stakeholders.
V-SEMESTER UNIT-II

The requirements come from various
stakeholders. To remove the ambiguity and
conflicts, they are discussed for clarity and
correctness.
Documentation - All formal & informal,
functional and non-functional requirements are
documented and made available for next phase
processing.
V-SEMESTER UNIT-II

Requirement Elicitation Techniques:
Requirements Elicitation is the process to find
out the requirements communicating with
client, end users, system users and others in the
software system development.
V-SEMESTER UNIT-II

Interviews
To collect requirements. Organization may
conduct several types of interviews such as:
Oral interviews
Written interviews
One-to-one interviews which are held between two
persons across the table.
Group interviews which are held between groups of
participants SOFTWARE ENGINNERING
V-SEMESTER UNIT-II

Software Requirements
Broadly software requirements should be categorized
in two categories:
Functional Requirements Examples -
Search option given to user to search from various
invoices.
User should be able to mail any report to management.
Users can be divided into groups and groups can be
given separate rights SOFTWARE ENGINNERING
V-SEMESTER UNIT-II

Non-Functional Requirements
Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
Accessibility
V-SEMESTER UNIT-II

Requirements are categorized logically as
•Must Have: Software cannot be said
operational without them.
•Should have: Enhancing the functionality of
software.
•Could have: Software can still properly
function with these requirements.
•Wish list: These requirements do not map to
any objectives of software.
V-SEMESTER UNIT-II

User Interface requirements
UI is an important part of any software or hardware
or hybrid system. A software is widely accepted if it is
easy to operate
quick in response
effectively handling operational errors
providing simple yet consistent user interface
V-SEMESTER UNIT-II

Software System Analyst
It is the responsibility of analyst to make sure that the
developed software meets the requirements of the
client.
Identify sources of requirement.
Validation of requirement.
Develop and implement requirement management
plan.
Documentation of business, technical, process and
product requirements.
Finalizing acceptance criteria with client and other
stakeholder .
V-SEMESTER UNIT-II

FEASIBILTY STUDY
Feasibility is defined as the practical extent to which a project
can be performed successfully
Types of Feasibility
Technical feasibility
Operational feasibility
Economic feasibility
Schedule Feasibility
V-SEMESTER UNIT-II

Technical feasibility also performs the
following tasks.
Analyzes the technical skills and
capabilities of the software development
team members
SOFTWARE ENGINNERING V-SEMESTER UNIT-II PRESENTED BY CH.PHANINDRA

Operational feasibility
performs a series of steps to solve business
problems and user requirements. Operational
feasibility also performs the following tasks.
Determines whether the solution
suggested by the software
development team is acceptable
V-SEMESTER UNIT-II

Economic feasibility
financial gains for an organization
estimated cost of hardware and software, cost
of performing feasibility .
Schedule Feasibility –
Does the company currently have the time
resources to undertake the project? Can the
project be completed in the available time?
V-SEMESTER UNIT-II

PROBLEMS OF REQUIRMENTS
Problem 1: Customers don't (really) know what
they want
Problem 2: Requirements change during the
course of the project
Problem 3: Customers have unreasonable
timelines
Problem 4: Communication gaps exist between
customers, engineers and project managers
V-SEMESTER UNIT-II

SOFTWARE REQUIREMENTS ANALYSIS
Requirements Analysis
Requirements Analysis is the process of
understanding the customer needs and
expectations from a proposed system or
application and is a well-defined stage in
the Software Development Life Cycle
model.
V-SEMESTER UNIT-II

Software requirements analysis may be divided
into give areas of effort
Problem recognition
Evaluation and synthesis
Modeling
Specification
Review
V-SEMESTER UNIT-II

Requirements Elicitation for Software
Elicitation is the practice of researching and
discovering the requirements of a system from
users ,customers and stack holders like
Requirements Elicitation for Software
Initiating the Process
Facilitated Application Techniques
V-SEMESTER UNIT-II

Quality Function Deployment
A technique that translates the needs of the customer into
technical requirements for software
QFD identifies three types of requirements
Normal requirements –
Expected requirements –
Exciting requirements – these features go beyond the
customer’s expectations and prove to be very satisfying when
present
Interviews
Use-Cases
Prototype A valuable tool for clarifying unclear requirements
V-SEMESTER UNIT-II

ANALYSIS PRINCIPLES
All analysis methods are related by a set of operational principles
The information domain of a problem must be represented and understood
The functions that the software is to perform must be defined
The behaviour of the software must be represented
The models that depict information, function, and behaviour must be divide
in a manner that uncovers detail in a layered fashion
The analysis process should move from essential information toward
implementation detail
V-SEMESTER UNIT-II

The software requirements specification
Format of software requirements specification:
Introduction
Information description
Functional description
Behavioural description
Validation criteria
Bibliography and appendixSOFTWARE ENGINNERING
V-SEMESTER UNIT-II

ANALYSIS MODEL
Analysis Model is a technical representation of the
system. It acts as a link between system description
and design model. In Analysis Modelling,
information, behavior and functions of the system is
defined and translated into the architecture,
component and interface level design in the
design modeling.
V-SEMESTER UNIT-II

ANALYSIS MODEL
V-SEMESTER UNIT-II

Elements of the analysis model
1.Scenario based element
->This type of element represents the system
user point of view.
->Scenario based elements are use case
diagram, user stories
V-SEMESTER UNIT-II

Use case diagram is a behavioral UML diagram
type and frequently used to analyze various
systems.
They enable you to visualize the different types
of roles in a system and how those roles
interact with the system.
V-SEMESTER UNIT-II

Use Case Diagram objects
Use case diagrams consist of 4 objects.
-Actor
-Use case
-System
-Package
V-SEMESTER UNIT-II

Actor
Actor in a use case diagram is any entity
that performs a role in one given system.
This could be a person, organization or an
external system and usually drawn like
skeleton shown below.
V-SEMESTER UNIT-II

Use Case
A use case represents a function or an action
within the system. It’s drawn as an oval and
named with the function.
System
The system is used to define the scope of the use
case and drawn as a rectangle.
Package
The package is another optional element that is
extremely useful in complex diagrams.
V-SEMESTER UNIT-II
Use case
Package name

2. Class based elements
The object of this type of element manipulated by the
system.
It defines the object, attributes and relationship.
V-SEMESTER UNIT-II

.
3. Behavioural elements
Behavioural elements represent of the system and how it is
changed by the external events.
The behavioural elements are sequenced diagram, state
diagram.
V-SEMESTER UNIT-II

A sequence diagram shows object
interactions arranged in time sequence.
sequence of messages exchanged between
the objects needed to carry out the
functionality of the scenario .
Sequence diagrams are sometimes
called event diagrams or event scenarios.
V-SEMESTER UNIT-II

A sequence diagram shows, as parallel vertical lines (lifelines), different
processes or objects that live simultaneously, and, as horizontal arrows, the
messages exchanged between them, in the order in which they occur.
V-SEMESTER UNIT-II

a state diagram describes the behavior of a single object in response to a series of
events in a system. ... This UML diagram models the dynamic flow of control
from state to state of a particular object within a system.
V-SEMESTER UNIT-II

4.Flow oriented elements
The flow elements are data flow diagram, control flow
diagram
V-SEMESTER UNIT-II

ANALYSIS PROCESS
The objective of requirements analysis then, is
to create a “requirements specification
document ” or a “ target document ”, that
describes in as much detail and in an
unambiguous a manner as possible, exactly
what the product should do
V-SEMESTER UNIT-II

A Project plan including details of delivery
times and cost estimates.
V-SEMESTER UNIT-II

THANK YOU
V-SEMESTER UNIT-II

Software requirements and analysis

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Software requirements and analysis

Similar to Software requirements and analysis (20)

Recently uploaded

Recently uploaded (20)

Software requirements and analysis