Documente Academic
Documente Profesional
Documente Cultură
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
Supplier
Order of Supplies
customer
Final bills
Served food
Existing Restaurant Management
Supplier Sales Register
supplies
Food detiails
Sales details
Customer receipt
money details
Proposed Restaurant Management
Supplier Sales Register
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
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