Unit - 2: Requirements Analysis and Specification

UNIT – 2
REQUIREMENTS ANALYSIS AND SPECIFICATION

UNIT II REQUIREMENTS ANALYSIS AND SPECIFICATION
Software Requirements:
Functional and Non-Functional
User requirements
System requirements
Software Requirements Document
Requirement Engineering Process:
Feasibility Studies
Requirements elicitation and analysis
requirements validation
requirements management
Classical analysis:
Structured system Analysis
Petri Nets
Data Dictionary.
Requirement Types:
•User Requirements
•System requirements
•Functional Requirements
•Non-functional Requirements
•Domain Requirements
1.Software Requirements
•Functional Requirements
•Non-Functional Requirements
1.a.Functional Requirements
•Functional aspect of software
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.
Non-Functional Requirements
•Not related to functional aspect of software
Non-functional requirements include -
•Security
•Storage
•Cost
•Flexibility
•Disaster recovery
•Accessibility
1.b.User Interface requirements
A software is widely accepted if it is -
easy to operate
quick in response
effectively handling operational errors
providing simple and consistent user interface
1.c.Software requirements
A System Requirements Specification (SRS) (also known as a Software
Requirements Specification) is a document or set of documentation
•Business Drivers
•Business Model
•Technical Requirements
•System Qualities
•Constraints and Assumptions
1.d.Software requirements document
A document or set of documentation
2.Requirement Engineering
Requirement Engineering Process
•Feasibility Study
•Requirement Gathering
•Software Requirement Specification
•Software Requirement Validation
2.a.Feasibility study
Requirements are categorized logically as
Must Have
Should have
Could have
Wish list
2.b.Requirement Elicitation Process
Requirement Elicitation Techniques
There are various ways to discover requirements
Interviews
several types of interviews such as:
•Structured (closed) interviews
•Non-structured (open) interviews
•Oral interviews
•Written interviews
•One-to-one interviews
•Group interviews
Surveys
Questionnaires
Task analysis
Domain Analysis
Brainstorming
Requirement Engineering
Process
2.c.Software Requirement Validation
•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 they are complete
If they can be demonstrated
3.Classical Analysis
3.a.Structured analysis
•The analyst to understand the system.
•Analyze and refine the objectives of an existing system and
develop a new system specification
Structured Analysis Tools
During Structured Analysis, various tools and
techniques are used for system development. They
are −
•Data Flow Diagrams
•Data Dictionary
•Decision Trees
•Decision Tables
•Structured English
•Pseudo code
DFD : A Data Flow Diagram (DFD) is a traditional visual representation
of the information flows within a system.
EXAMPLE
Types of DFD
DFDs are of two types: Physical DFD and Logical DFD. The following table lists the
points that differentiate a physical DFD from a logical DFD.
Physical DFD Logical DFD

It is implementation It is implementation
dependent. It shows which independent. It focuses only
functions are performed. on the flow of data between
processes.
It provides low level details of It explains events of systems

hardware, software, files, and and data required by each
people. event.
It depicts how the current It shows how business

system operates and how a operates; not how the system
system will be implemented. can be implemented.
Context Diagram- level 0 data-flow diagram-It identifies the
flows of information between the system and external entities.
.
Data Dictionary
Sr.No. Data Name Description No. of

Characters
1 ISBN ISBN Number 10
2 TITLE title 60
3 SUB Book Subjects 80
4 ANAME Author Name 15

Decision Trees
Decision Tables-describing the complex logical
Components of a Decision Table
• Condition Stub -part lists the individual inputs upon which
the decision depends
• Action Stub -lists the alternative actions
• Condition Entry -phrase the conditions as questions that can
be answered with a Y for yes and an N for a no.
• Action Entry -simply represent whether an action is to be
performed
CONDITIONS Rule 1 Rule 2 Rule 3 Rule 4
Advance Y N N N
payment made
Purchase - Y Y N
amount = Rs
10,000/-
Regular - Y N -
Customer
ACTIONS
Give 5% discount X X - -
Give no discount - - X X
Structured English
if customer pays advance then Give 5% Discount

else if purchase amount >=10,000
then if the customer is a regular customer
then Give 5% Discount
else No Discount
end if
else No Discount
end if
end if
Pseudocode
•Plain English.
•It is used in conjunction with structured
programming.
•It replaces the flowcharts of a program.
End of UNIT -2

Unit - 2: Requirements Analysis and Specification

Uploaded by

Copyright:

Available Formats

Unit - 2: Requirements Analysis and Specification

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit - 2: Requirements Analysis and Specification

Uploaded by

Copyright:

Available Formats

UNIT – 2

REQUIREMENTS ANALYSIS AND SPECIFICATION

Physical DFD Logical DFD

It provides low level details of It explains events of systems

It depicts how the current It shows how business

Sr.No. Data Name Description No. of

1 ISBN ISBN Number 10

3 SUB Book Subjects 80

4 ANAME Author Name 15

if customer pays advance then Give 5% Discount

You might also like