Requirement analysis

By
Shilpa Bhalerao
 definition
What is system and why it
is required
• Requirement engineering is branch of
software engineering concerned with the real
world goals for, function of Basis
andforconstraints
analyzing,
on
software systems. validating, definingand
verifying
• It is also concerned with the relationship of
these factors to precise specifications of
software behavior, and to their evolution over
time and across software families
Reuse and emphasize on adaptability
 Feasibility Study
• Economical Feasibility
– Financial aspects
• Technical Feasibility
– How you are going to delivered the product or
services?
• operational Feasibility
– Ease to operate
 Types of requirements
• Functional Requirements
– Functionality or services that the system is
expected to provide.
– Functional requirements may also explicitly state
what the system shouldn’t do.
– Functional requirements specification should be:
• Complete: All services required by the user should be defined
• Consistent: should not have contradictory definition (also avoid ambiguity don’t leave room
for different interpretations)
• Non-functional Requirements
– Product requirements
• Efficiency
• Reliability
• Portability
• Usability
• Performance
• Space

– Organizational requirements
• Delivery
• Implementation
• Standards
– External requirements
• Interoperability
• Ethics
• Legislative
• Privacy
• Safety
• Domain Requirement
– Domain requirements are derived from the
application domain of the system rather than from the
specific needs of the system users.
– May be new functional requirements, constrain
existing requirements or set out how particular
computation must take place.
– Example: tolerance level of landing gear on an aircraft
(different on dirt, asphalt, water), or what happens to
fiber optics line in case of sever weather during winter
Olympics (Only domain-area experts know)
 Key activities in Requirement
Engineering
• requirements elicitation
• requirements analysis
• requirements specification or documentation
• requirements validation.
 Requirement Engineering
Requirement Development Requirement Management
Requirement •Establish & maintain an agreement
Elicitation with the customers & users on the
D requirements
e
Requirement f •Control the base lined requirements
Elicitation e
Process proposed changes to the
c
t requirements
&
Requirement g •Keep requirements consistent with
Elicitation a
p
plans & work products
s •Negotiate new commitments
Requirement based on impact of approved changes
Elicitation

Baseline Requirement
 Requirement Elicitation
• Identify System Boundaries
• Identifying Stakeholder
• Identifying the goals
• Domain understanding
• Requirements collection
• Classification
• Conflict resolution
• Prioritization
Requirement Elicitation Techniques
• Traditional techniques-
– use of questionnaires
– surveys, interviews, and analysis of existing
documentation such as organisational charts,
process models or standards
• Group elicitation techniques
– Brainstorming
– focus groups, as well as RAD/JAD workshops
(using consensus-building workshops with an
unbiased facilitator)
• Prototyping
• Model driven techniques
• Quality Function deployment
– Is technique that translates the needs of customer
into technical requirements
– Emphasizes on valuable requirements
– Identifies 3 type of requirements
• Normal requirements
• Expected Requirements
• Exciting requirements
• Steps in QFD
– Meeting with customer
– Identifies data object and events that software
must produce
– Behavior of system within context of environment
• Scenario based
– Use case

• View point based

 Requirement analysis
• Data flow modeling approach
– Shows flow of data
– Aims to capture the transformations that take
place within system from input to output.
E
Emp Re
* Overt Tax
Get Weekly G
A ime Deductio
file C pay
* * pay H n
J
D
F I
B Tax rate Issue pay
cheque
Worker L
M company Re
K
• A- emp details
• B- Emp id
• C – Pay Rate
• D- Regular Hours
• E- Over time rate
• F- over time hours
• G- pay
• H- total pay
• I – tax band
• J-net pay
• K- tax details of emp
• L- cheque details of emp
• M-cheque
 Data Dictionary
• Repository of various data flow in DFD
• Precise structure of data
Empname= Lastname + middle name+ firstname
Empid= first two letter of deptname+digit+digit
 0 Level DFD for Restaurant
Management

Supplier
Order of Supplies

Supplies Sales Information

Restaurant
Order
Supplier Information
Payment

customer
Final bills
Served food
Existing Restaurant Management
Supplier Sales Register

Supply order Sales details

Supply details Shortage
items

Receive Make Order Record

supplies dishes supplies sales

supplies
Food detiails

Sales details

order order details

Process Prepare
Take
order bill payments
order
Sales details
bill details
item details

Customer receipt

money details
Proposed Restaurant Management
Supplier Sales Register

Supply order Sales details

Supply details Shortage
items

Receive Make Order Record

supplies dishes supplies sales owner

supplies
Order file
Food details
Account
reports
Sales details
Acc file
order order details
Process Prepare
Take
order bill payments
order
item details Sales details
bill details

Customer receipt

Menu
money details
 Class Diagram
• Class model
Represents the static structure of data.
it is graph whose nodes are classes and arcs are
relationship among them.

Supplier items
• Generalization – “is- a relationship”
• Aggregation- “a part whole”
• Composition- Strong aggregation with
constraints
• Association
 Restaurant Management
Quantity

Supply Supply Items

Supply order
handling
1 n Name
Price
Supplyadd() Quantity
Supdeduct()
Issuecheck()
Place order()
Restuarant
Issuecheck()

Menu Item Order

Menu
Menu item
n 1
Item number
Price
Supplies
used Produce
Bill()

Quantity
 Requirement Specification
• What –final out put of RE
• Why
– as in modeling (DFD, DD, Class diagram ) focuses
on problem structure, not on external behavior.
– Behavior in erroneous situations is also identified
– Constraints (performance, design constraints,
standards compliance, recovery) are defined
 Characteristics of SRS
• Complete
• Correct
• Verifiable
• Consistent
• Modifiable
• Traceable
 Component
• Functional Requirements
– All operations to be performed to obtain desired
output
– Validity check on input data, equations, Formulas
used
– System behavior in abnormal situations
– System behavior where input is valid but
operation can not be performed
• Performance requirements
– Performance characteristics of system must be clearly
specified.
Two types
static- do not impose constraints on execution
characteristics of system. Examples (number of items
in menu, number of system in LAN etc..)
Dynamic- specify constraints on execution behavior of
the system (response time, throughput)
It should be specified in measurable terms
• Design Constraints
number of factors that may restrict designers must
be included in SRS
(operating environment, resource limitation etc…)
Standard Compliance
Hardware limitations
Fault tolerance
Reliability
Security
• External interaction
all interactions
user interfaces
hardware interfaces
 Structure of SRS
1. Introduction
1.1 purpose
1.2 Scope
1.3 Definition, Acronym, Abbreviations
1.4 References
1.5 Overview
2. Overall description
2.1 Product perspective
2.2 Product Functions
2.3 User Characteristics
2.4 General Constraints
2.5 Assumptions and dependencies
3. Specific requirements
3.1 External interface Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software interfaces
3.1.4 Communication Interfaces
3.2 Functional Requirements
3.2.1 Mode 1
3.2.1.1 FR 1.1
3.2.1.2 FR 1.2
.
.
3.2.n Mode n
3.3 Performance requirements
3.4 Design Constraints
3.5 Attributes
3.6 other Requirements
 Functional Specification using Use
cases
Terms used Description
Actors A person or a system which uses system
Primary Actor The main Actor who initiate the use case and whose goal
satisfaction is main objective of the use case
Scenario A set of actions that are performed to achieve a goal under
some specified condition
Main success Describes the interaction if nothing fails and all steps in
Scenario scenario succeeded
Extension Scenario Describe the system behavior, if some of the steps in Main
Scenario do not complete successfully.
Example : Restaurant management
• Use case 1: generate bill
precondition : order details from customer.
Main success scenario:
1. Items and their quantity entered
2. compute the cost of each item as per quantity and sum of
each amount as total.
3. ask for any discount benefits
4. Select discount benefit given to the customer
5 calculate the discount and net amount to be paid
6. generate bill and save record in sales file also.
Exception Scenario
there no item and their unit rate in list
Solution -system inform the user to enter item with details
 Requirement Validation
• It is an important activity as error in RE document
lead to extensive work at later stage.
• During the requirement validation process, check
should be carried out on requirement in RE
document
– Validity checks
– Consistency
– Completeness checks
– Realism checks
– verifiability
 Techniques used
• Requirement review
• Protoyping
• Test case generation
 Tools available for RE
– DOORS
– Requisite Pro
– Cradle