SlideShare a Scribd company logo
1 of 101
 Requirement gathering and Analysis
 Software Requirement Specifications
 Formal Specification Technique
 Characteristics of good SRS
2
Requirement
Gathering
and Analysis
3
“Software requirements is one such area, to which
little importance was attached in the early days of
software development, as the emphasis was on
coding and design.”
“For large software systems, requirements
analysis is perhaps the most difficult and
intractable activity; it is also very error-prone.”
by Prof. Pankaj Jalote
4
 The requirements phase translates the ideas
in the minds of the clients (the input), into a
formal document (the output of the
requirements phase).
5
6
 A meeting is conducted at a neutral site and attended by both
software engineers and customers.
 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.
 The goal is to identify the problem, propose elements of the
solution, negotiate different approaches, and specify a
preliminary set of solution requirements in an atmosphere that is
conducive to the accomplishment of the goal.
7
 While reviewing the request in the days
before the meeting, each FAST attendee is
asked to make a list of objects that are part
of the environment that surrounds the
system, other objects that are to be
produced by the system, and objects that are
used by the system to perform its functions.
8
 In addition, each attendee is asked to make
another list of services (processes or functions)
that manipulate or interact with the objects.
Finally, lists of constraints (e.g., cost, size,
business rules) and performance criteria (e.g.,
speed, accuracy) are also developed.
 The attendees are informed that the lists are
not expected to be exhaustive but are expected
to reflect each person’s perception of the
system.
9
 Quality function deployment (QFD) is a quality
management technique that translates the
needs of the customer into technical
requirements for software.
 Originally developed in Japan and first used at
the Kobe Shipyard of Mitsubishi Heavy
Industries, Ltd.,
 In the early 1970s, QFD “concentrates on
maximizing customer satisfaction from the
software engineering process [ZUL92].”
10
 Normal requirements
 Expected requirements
 Exciting requirements
11
The objectives and goals that are stated for a
product or system during meetings with the
customer. If these requirements are present,
the customer is satisfied. Examples of normal
requirements might be requested types of
graphical displays, specific system functions,
and defined levels of performance.
12
These requirements are implicit to the product or
system and may be so fundamental that the
customer does not explicitly state them.
Their absence will be a cause for significant
dissatisfaction.
 Examples of expected requirements are: ease
of human/machine interaction, overall
operational correctness and reliability, and ease
of software installation.
13
These features go beyond the customer’s
expectations and prove to be very satisfying
when present.
For example, word processing software is
requested with standard features. The
delivered product contains a number of page
layout capabilities that are quite pleasing and
unexpected.
14
The requirements engineering process can be
described in five distinct steps-
 Requirements elicitation
 Requirements analysis and negotiation
 Requirements specification
 System modeling
 Requirements validation
 Requirements management
15
 Ask the customer, the users, and others
what the objectives for the system or product
are
 That is to be accomplished, how the system
or product fits into the needs of the business,
and finally
 How the system or product is to be used on
a day-to-day basis. But it isn’t simple—it’s
very hard.
16
Christel and Kang [CRI92] identify a number of
problems that help us understand why
requirements elicitation is difficult:
 Problems of scope
 Problems of understanding
 Problems of volatility
17
The boundary of the system is ill-defined or the
customers/ users specify unnecessary
technical detail that may confuse, rather than
clarify, overall system objectives.
18
The customers/users are not completely sure of
what is needed, have a poor understanding of the
capabilities and limitations of their computing
environment, don’t have a full understanding of
the problem domain, have trouble communicating
needs to the system engineer, omit information
that is believed to be “obvious,” specify
requirements that conflict with the needs of other
customers/users, or specify requirements that
are ambiguous or untestable.
19
 The requirements change over time.
To help overcome these problems, system
engineers must approach the requirements
gathering activity in an organized manner.
20
Sommerville and Sawyer [SOM97] suggest a set of detailed
guidelines for requirements elicitation
 Assess the business and technical feasibility for the
proposed system.
 Identify the people who will help specify requirements and
understand their organizational bias.
 Define the technical environment (e.g., computing
architecture, operating system, telecommunications
needs) into which the system or product will be placed.
 Identify “domain constraints” (i.e., characteristics of the
business environment specific to the application domain)
that limit the functionality or performance of the system or
product to be built.
21
Sommerville and Sawyer [SOM97] suggest a set of
detailed guidelines for requirements elicitation
 Define one or more requirements elicitation
methods (e.g., interviews, focus groups, team
meetings).
 Solicit participation from many people so that
requirements are defined from different points of
view; be sure to identify the rationale for each
requirement that is recorded.
 Identify ambiguous requirements as candidates for
prototyping.
 Create usage scenarios to help customers/users
better identify key requirements.
22
The work products produced as a
consequence of the requirements elicitation
activity will vary depending on the size of the
system or product to be built.
23
 A statement of need and feasibility.
 A bounded statement of scope for the
system or product.
 A list of customers, users, and other
stakeholders who participated in the
requirements elicitation activity.
24
 A description of the system’s technical
environment.
 A list of requirements (preferably organized by
function) and the domain constraints that apply
to each.
 A set of usage scenarios that provide insight
into the use of the system or product under
different operating conditions.
 Any prototypes developed to better define
requirements.
25
 Each of these work products is reviewed by
all people who have participated in the
requirements elicitation.
26
1. Requirement Gathering is important for
__________________
2. Requirement Analysis may be error-prone said
by _____________.
3. Prototype are developed in
_________________.
Put right words in blanks
 Software Development
 Requirement gathering
 Prof. Jalote
27
1. Requirement Gathering is important for
Software Development
2. Requirement Analysis may be error-prone
said by Prof. Jalote
3. Prototype are developed in Requirement
gathering.
28
Analysis categorizes requirements and
organizes them into related subsets; explores
each requirement in relationship to others;
examines requirements for consistency,
omissions, and ambiguity; and ranks
requirements based on the needs of
customers/users.
29
 Is each requirement consistent with the overall
objective for the system/product?
 Have all requirements been specified at the proper
level of abstraction?
 That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?
 Is the requirement really necessary or does it
represent an add-on feature that may not be
essential to the objective of the system?
 Is each requirement bounded and unambiguous?
30
 Does each requirement have attribution? That
is, is a source (generally, a specific individual)
noted for each requirement?
 Do any requirements conflict with other
requirements?
 Is each requirement achievable in the technical
environment that will house the system or
product?
 Is each requirement testable, once
implemented?
31
 Rough estimates of development effort are
made and used to assess the impact of each
requirement on project cost and delivery
time.
 Using an iterative approach, requirements
are eliminated, combined, and/or modified so
that each party achieves some measure of
satisfaction.
32
“A specification can be a written document, a
graphical model, a formal mathematical model,
a collection of usage scenarios, a prototype, or
any combination of these.” Pressman
33
 The System Specification is the final work
product produced by the system and
requirements engineer. It serves as the
foundation for hardware engineering,
software engineering, database engineering,
and human engineering.
 It describes the function and performance of
a computer-based system and the
constraints that will govern its development.
34
 Why requirement specification is important,
how requirements are analyzed and
specified?
 How requirements are validated, and some
metrics that can be applied to requirements?
35
 A condition of capability needed by a user to
solve a problem or achieve an objective;
 A condition or a capability that must be met
or possessed by a system ... to satisfy a
contract, standard, specification, or other
formally imposed document.
by IEEE
36
The goal of the requirements activity is to
produce the Software Requirements
Specification (SRS), that describes what the
proposed software should do without
describing how the software will do it.
37
A basic limitation for this is that the user needs
keep changing as the environment in which the
system is to function changes with time.
Even while accepting that some requirement
change requests are inevitable, there are still
pressing reasons why a thorough job should be
done in the requirements phase to produce a
high-quality and relatively stable SRS.
38
The origin of most software systems is in the
needs of some clients. The software system
itself is created by some developers.
39
There are three major parties interested in a
new system:
 the client,
 the developer,
 and the users.
40
 The problem is that the client usually does
not understand software or the software
development process,
 The developer often does not understand
the client's problem and application area.
This causes a communication gap between
the parties involved in the development
project.
41
In order to fully specify what is to be built, you
would need a meaningful model of the kitchen,
that is, a blueprint or three-dimensional
rendering that shows the position of the
cabinets and appliances and their relationship
to one another.
42
From the model, it would be relatively easy to
assess the efficiency of work flow (a
requirement for all kitchens), the aesthetic
“look” of the room (a personal, but very
important requirement).
43
It is important to evaluate the system’s
components in relationship to one another, to
determine how requirements fit into this
picture, and to assess the “aesthetics” of the
system as it has been conceived.
44
45
To develop the system model
 (1) user interface,
 (2) input,
 (3) system function and control,
 (4) output, and
 (5) maintenance and self-test.
46
The work products produced as a
consequence of requirements engineering (a
system specification and related information)
are assessed for quality during a validation
step.
47
Examines the specification to ensure that all
system requirements have been stated
unambiguously; that inconsistencies,
omissions, and errors have been detected and
corrected; and that the work products conform
to the standards established for the process,
the project, and the product.
48
 The primary requirements validation
mechanism is the formal technical review.
 The review team includes system engineers,
customers, users, and other stakeholders who
examine the system specification looking for
errors in content or interpretation, areas where
clarification may be required, missing
information, inconsistencies (a major problem
when large products or systems are
engineered), conflicting requirements, or
unrealistic (unachievable) requirements.
49
Following questions represent a small subset
 Are requirements stated clearly?
 Can they be misinterpreted?
 Is the source (e.g., a person, a regulation, a document) of
the requirement identified?
 Has the final statement of the requirement been examined
by or against the original source?
 Is the requirement bounded in quantitative terms?
 What other requirements relate to this requirement?
 Are they clearly noted via a cross-reference matrix or other
mechanism?
50
 Does the requirement violate any domain
constraints?
 Is the requirement testable? If so, can we
specify tests (sometimes called validation
criteria) to exercise the requirement?
 Is the requirement traceable to any system
model that has been created?
 Is the requirement traceable to overall
system/product objectives?
51
 Is the system specification structured in a way
that leads to easy understanding, easy
reference, and easy translation into more
technical work products?
 Has an index for the specification been
created?
 Have requirements associated with system
performance, behavior, and operational
characteristics been clearly stated?
 What requirements appear to be implicit?
52
Requirements management is a set of
activities that help the project team to identify,
control, and track requirements and changes to
requirements at any time as the project
proceeds.
53
Like SCM, requirements management begins with identification.
Each requirement is assigned a unique identifier that might take the
form
<requirement type><requirement #>
where requirement type takes on values such as
F = functional requirement,
D = data requirement,
B = behavioral requirement,
I = interface requirement,
P = output
Hence, a requirement identified as F09 indicates a functional
requirement assigned requirement number 9.
54
Among many possible traceability tables are
the following:
 Features traceability table
 Source traceability table
 Dependency traceability table
 Subsystem traceability table
 Interface traceability table
55
Shows how requirements relate to important
customer observable system/product features.
56
Identifies the source of each requirement.
57
Indicates how requirements are related to one
another.
58
 Shows how requirements relate to both
internal and external system interfaces.
59
Categorizes requirements by the subsystem(s)
that they govern.
60
61
62
63
 Major parties of SRS are ________ ,
_______ and ________.
 User interface, input, system function and
control, output, and maintenance and self-
test are in ________________
 _____________________ identifies the
source of each requirement.
64
 Major parties of SRS are Client , Developer
and User.
 User interface, input, system function and
control, output, and maintenance and self-
test are in System Modeling.
 Source Traceability Table identifies the source
of each requirement.
65
 The modeling is essentially a tool to help
obtain a thorough and complete knowledge
about the proposed system.
 The SRS is written based on the knowledge
acquired during analysis.
 As converting knowledge into a structured
document is not straightforward,
specification itself is a major task, which is
relatively independent.
66
 As the primary objective of analysis is
problem understanding, while the basic
objective of the requirements phase is to
produce the SRS, the complete and detailed
analysis structures are not critical.
67
 It is possible to develop the SRS without
using formal modeling techniques.
 The basic aim of the structures used in
modeling is to help in knowledge
representation and problem partitioning, the
structures are not an end in themselves.
68
To properly satisfy the basic goals, an SRS
should have certain properties and should
contain different types of requirements.
69
 1.Correct
 2. Complete
 3. Unambiguous
 4. Verifiable
 5. Consistent
 6. Ranked for importance and/or stability
 7. Modifiable
 8. Traceable
70
An SRS is correct if every requirement
included in the SRS represents something
required in the final system.
71
An SRS is complete if everything the software
is supposed to do and the responses of the
software to all classes of input data are
specified in the SRS.
72
 An SRS is unambiguous if and only if every
requirement stated has one and only one
interpretation.
 Requirements are often written in natural
language, which are inherently ambiguous. If
the requirements are specified in a natural
language, the SRS writer has to be
especially careful to ensure that there are no
ambiguities.
73
 An SRS is verifiable if and only if every
stated requirement is verifiable.
 A requirement is verifiable if there exists
some cost-effective process thatcan check
whether the final software meets that
requirement.
 This implies that the requirements should
have as little subjectivity as possible
because subjective requirements are difficult
to verify.
74
 An SRS is consistent if there is no
requirement that conflicts with another.
 Terminology can cause inconsistencies; for
example, different requirements may use
different terms to refer to the same object.
There may be logical or temporal conflict
between requirements that causes
inconsistencies.
75
Example-
 Suppose a requirement states that an event
e is to occur before another event / . But
then another set of requirements states
(directly or indirectly by transitivity) that event
/ should occur before event e.
Inconsistencies in an SRS can reflect of
some major problems.
76
 An SRS is ranked for importance and/or
stability if for each requirement the
importance and the stability of the
requirement are indicated.
 Stability of a requirement reflects the
chances of it changing in future. It can be
reflected in terms of the expected change
volume.
77
 An SRS is modifiable if its structure and style
are such that any necessary change can be
made easily while preserving completeness
and consistency.
 Presence of redundancy is a major
hindrance to modifiability, as it can easily
lead to errors.
78
 Example-
 assume that a requirement is stated in two
places and that the requirement
 later needs to be changed. If only one
occurrence of the requirement is
 modified, the resulting SRS will be
inconsistent.
79
 An SRS is traceable if the origin of each of its
requirements is clear and if it facihtates the
referencing of each requirement in future
development .
 Forward traceability means that each
requirement should be traceable to some
design and code elements.
 Backward traceability requires that it be
possible to trace design and code elements to
the requirements they support.
 Traceability aids verification and validation.
80
 Functionality
 Performance
 Design constraints imposed on an
implementation
 External interfaces
81
 Functional requirements specify which
outputs should be produced from the given
inputs.
 They describe the relationship between the
input and output of the system.
 For each functional requirement, a detailed
description of all the data inputs and their
source, the units of measure, and the range
of valid inputs must be specified.
82
 All the requirements relating to the
performance characteristics of the system
must be clearly specified.
There are two types of performance
requirements:
 Static
 Dynamic.
83
 Static requirements are those that do not
impose constraint on the execution
characteristics of the system.
 These include requirements like the number
of terminals to be supported, the number of
simultaneous users to be supported, and the
number of files that the system has to
process and their sizes. These are also
called capacity requirements of the system.
84
 Dynamic requirements specify constraints on the execution
behavior of the system.
 These typically include response time and throughput
constraints on the system.
 Response time is the expected time for the completion of an
operation under specified circumstances.
 Throughput is the expected number of operations that can be
performed in a unit time.
 For example, the SRS may specify the number of transactions
that must be processed per unit time, or what the response time
for a particular command should be.
 Acceptable ranges of the different performance parameters
should be specified, as well as acceptable performance for both
normal and peak workload conditions.
85
 There are a number of factors in the client's
environment that may restrict the choices of
a designer. Such factors include standards
that must be followed, resource limits,
operating environment, reliability and
security requirements, and policies that may
have an impact on the design of the system.
 An SRS should identify and specify all such
constraints.
86
 Standards Compliance
 Hardware Limitations
 Reliability and Fault Tolerance
 Security
87
 All the interactions of the software with
people, hardware, and other software should
be clearly specified.
 For the user interface, the characteristics of
each user interface of the software product
should be specified. User interface is
becoming increasingly important and must
be given proper attention.
88
 All the requirements for the system have to
be included in a document that is clear and
concise.
 For this, it is necessary to organize the
requirements document as sections and
subsections.
 There can be many ways to structure a
requirements document.
89
90
91
 Actors and goals
 Main success scenarios
 Failure conditions
 Failure handling
92
93
94
95
96
 Are all hardware resources defined?
 Have the response times of functions been specified?
 Have all the hardware, external software, and data
interfaces been defined?
 Have all the functions required by the client been
specified?
 Is each requirement testable?
 Is the initial state of the system defined?
 Are the responses to exceptional conditions specified?
 Does the requirement contain restrictions that can be
controlled by the designer?
 Are possible future modifications specified?
97
 Checklist are part of ________
 Functional Requirements are part
of________________
 ______________________ is part of Design
Constarints.
98
 Checklist are part of Review
 Functional Requirements are part of
Software Requirements Specifications
 Reliability and Fault Tolerance is part of
Design Constarints
99
 Software Engineering by Somerville
 Software Engineering-Pressman
 Software Engineering- Pankaj Jalote
 Software Engineering Tutorial Point
 Software Engineering Wikipedia
100
101

More Related Content

What's hot

Ch5- Software Engineering 9
Ch5- Software Engineering 9Ch5- Software Engineering 9
Ch5- Software Engineering 9
Ian Sommerville
 
Ch4-Software Engineering 9
Ch4-Software Engineering 9Ch4-Software Engineering 9
Ch4-Software Engineering 9
Ian Sommerville
 
User Interface Design in Software Engineering SE15
User Interface Design in Software Engineering SE15User Interface Design in Software Engineering SE15
User Interface Design in Software Engineering SE15
koolkampus
 
Ch2-Software Engineering 9
Ch2-Software Engineering 9Ch2-Software Engineering 9
Ch2-Software Engineering 9
Ian Sommerville
 

What's hot (20)

Requirements engineering
Requirements engineeringRequirements engineering
Requirements engineering
 
UI UX introduction
UI UX introductionUI UX introduction
UI UX introduction
 
Ch5- Software Engineering 9
Ch5- Software Engineering 9Ch5- Software Engineering 9
Ch5- Software Engineering 9
 
Ch1 introduction
Ch1 introductionCh1 introduction
Ch1 introduction
 
UI-UX Services | Web Designing Services
UI-UX Services | Web Designing ServicesUI-UX Services | Web Designing Services
UI-UX Services | Web Designing Services
 
Requirements Engineering
Requirements EngineeringRequirements Engineering
Requirements Engineering
 
Ch4-Software Engineering 9
Ch4-Software Engineering 9Ch4-Software Engineering 9
Ch4-Software Engineering 9
 
Requirement Engineering Lec.1 & 2 & 3
Requirement Engineering Lec.1 & 2 & 3Requirement Engineering Lec.1 & 2 & 3
Requirement Engineering Lec.1 & 2 & 3
 
Introduction to User Experience Design
Introduction to User Experience DesignIntroduction to User Experience Design
Introduction to User Experience Design
 
Hci in software process
Hci in software processHci in software process
Hci in software process
 
User Interface Design in Software Engineering SE15
User Interface Design in Software Engineering SE15User Interface Design in Software Engineering SE15
User Interface Design in Software Engineering SE15
 
Software Engineering (Introduction to Software Engineering)
Software Engineering (Introduction to Software Engineering)Software Engineering (Introduction to Software Engineering)
Software Engineering (Introduction to Software Engineering)
 
Introduction to Systems Engineering
Introduction to Systems EngineeringIntroduction to Systems Engineering
Introduction to Systems Engineering
 
Ian Sommerville, Software Engineering, 9th Edition Ch1
Ian Sommerville,  Software Engineering, 9th Edition Ch1Ian Sommerville,  Software Engineering, 9th Edition Ch1
Ian Sommerville, Software Engineering, 9th Edition Ch1
 
Lecture 1: Human-Computer Interaction Introduction (2014)
Lecture 1: Human-Computer Interaction Introduction (2014)Lecture 1: Human-Computer Interaction Introduction (2014)
Lecture 1: Human-Computer Interaction Introduction (2014)
 
UI/UX Design in Agile process
UI/UX Design in Agile process  UI/UX Design in Agile process
UI/UX Design in Agile process
 
UX Best Practices
UX Best PracticesUX Best Practices
UX Best Practices
 
Ch2-Software Engineering 9
Ch2-Software Engineering 9Ch2-Software Engineering 9
Ch2-Software Engineering 9
 
Ch3. agile sw dev
Ch3. agile sw devCh3. agile sw dev
Ch3. agile sw dev
 
Software Requirements and Specifications
Software Requirements and SpecificationsSoftware Requirements and Specifications
Software Requirements and Specifications
 

Viewers also liked

Requirement Analysis
Requirement AnalysisRequirement Analysis
Requirement Analysis
Webx
 
Software requirements specification
Software  requirements specificationSoftware  requirements specification
Software requirements specification
Krishnasai Gudavalli
 
Chapter 10 software certification
Chapter 10 software certificationChapter 10 software certification
Chapter 10 software certification
Piyush Gogia
 
Dms Research And Insights Jm
Dms Research And Insights JmDms Research And Insights Jm
Dms Research And Insights Jm
deb_underhill
 
Functional specification documents of
Functional specification documents ofFunctional specification documents of
Functional specification documents of
rtu
 

Viewers also liked (20)

Requirements analysis
Requirements analysisRequirements analysis
Requirements analysis
 
Requirement Analysis - Software Enigneering
Requirement Analysis - Software EnigneeringRequirement Analysis - Software Enigneering
Requirement Analysis - Software Enigneering
 
Requirement Analysis
Requirement AnalysisRequirement Analysis
Requirement Analysis
 
Requirement analysis and specification
Requirement analysis and specificationRequirement analysis and specification
Requirement analysis and specification
 
Requirement analysis with use case
Requirement analysis with use caseRequirement analysis with use case
Requirement analysis with use case
 
Software requirements specification
Software  requirements specificationSoftware  requirements specification
Software requirements specification
 
Requirement analysis
Requirement analysisRequirement analysis
Requirement analysis
 
Software testing-and-analysis
Software testing-and-analysisSoftware testing-and-analysis
Software testing-and-analysis
 
Chapter 10 software certification
Chapter 10 software certificationChapter 10 software certification
Chapter 10 software certification
 
Software testing and analysis
Software testing and analysisSoftware testing and analysis
Software testing and analysis
 
Dms 2.0 Plan Proposal
Dms 2.0 Plan ProposalDms 2.0 Plan Proposal
Dms 2.0 Plan Proposal
 
Dms Research And Insights Jm
Dms Research And Insights JmDms Research And Insights Jm
Dms Research And Insights Jm
 
Requirement and Specification
Requirement and SpecificationRequirement and Specification
Requirement and Specification
 
Leaky bucket A
Leaky bucket ALeaky bucket A
Leaky bucket A
 
Functional specification documents of
Functional specification documents ofFunctional specification documents of
Functional specification documents of
 
Document Management System(DMS)
Document Management System(DMS)Document Management System(DMS)
Document Management System(DMS)
 
business requirements functional and non functional
business requirements functional and  non functionalbusiness requirements functional and  non functional
business requirements functional and non functional
 
Functional specs
Functional specsFunctional specs
Functional specs
 
Requirements analysis lecture
Requirements analysis lectureRequirements analysis lecture
Requirements analysis lecture
 
FS for FICO
FS for FICOFS for FICO
FS for FICO
 

Similar to Requirement Analysis & Specification sharbani bhattacharya

Software engg. pressman_ch-6 & 7
Software engg. pressman_ch-6 & 7Software engg. pressman_ch-6 & 7
Software engg. pressman_ch-6 & 7
Dhairya Joshi
 

Similar to Requirement Analysis & Specification sharbani bhattacharya (20)

Software engg. pressman_ch-6 & 7
Software engg. pressman_ch-6 & 7Software engg. pressman_ch-6 & 7
Software engg. pressman_ch-6 & 7
 
Requirement Engineering.pdf
Requirement Engineering.pdfRequirement Engineering.pdf
Requirement Engineering.pdf
 
Unit 2
Unit 2Unit 2
Unit 2
 
Hci in-the-software-process-1
Hci in-the-software-process-1Hci in-the-software-process-1
Hci in-the-software-process-1
 
2nd MODULE Software Requirements _ SW ENGG 22CSE141.pdf
2nd MODULE  Software Requirements   _ SW ENGG  22CSE141.pdf2nd MODULE  Software Requirements   _ SW ENGG  22CSE141.pdf
2nd MODULE Software Requirements _ SW ENGG 22CSE141.pdf
 
Requirement Engineering Processes & Eliciting Requirement
Requirement Engineering Processes & Eliciting Requirement Requirement Engineering Processes & Eliciting Requirement
Requirement Engineering Processes & Eliciting Requirement
 
Requirements engineering
Requirements engineeringRequirements engineering
Requirements engineering
 
3. 1 req elicitation
3. 1 req elicitation3. 1 req elicitation
3. 1 req elicitation
 
SE UNIT-2.pdf
SE UNIT-2.pdfSE UNIT-2.pdf
SE UNIT-2.pdf
 
software engineering
software engineering software engineering
software engineering
 
Mingle box - Online Job seeking System
Mingle box - Online Job seeking SystemMingle box - Online Job seeking System
Mingle box - Online Job seeking System
 
A CASE Lab Report - Project File on "ATM - Banking System"
A CASE Lab Report - Project File on  "ATM - Banking System"A CASE Lab Report - Project File on  "ATM - Banking System"
A CASE Lab Report - Project File on "ATM - Banking System"
 
SE18_Lec 02_Software Life Cycle Model
SE18_Lec 02_Software Life Cycle ModelSE18_Lec 02_Software Life Cycle Model
SE18_Lec 02_Software Life Cycle Model
 
Unit2 Software engineering UPTU
Unit2 Software engineering UPTUUnit2 Software engineering UPTU
Unit2 Software engineering UPTU
 
Chapter 2 SRS_241222135554.ppt
Chapter 2 SRS_241222135554.pptChapter 2 SRS_241222135554.ppt
Chapter 2 SRS_241222135554.ppt
 
REQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGREQUIREMENT ENGINEERING
REQUIREMENT ENGINEERING
 
SRE.pptx
SRE.pptxSRE.pptx
SRE.pptx
 
Sdlc phases
Sdlc phasesSdlc phases
Sdlc phases
 
Sdlc phases
Sdlc phasesSdlc phases
Sdlc phases
 
Requirements engineering
Requirements engineeringRequirements engineering
Requirements engineering
 

More from Sharbani Bhattacharya

More from Sharbani Bhattacharya (20)

Biometric authentication green apple computer learning
Biometric authentication green apple computer learningBiometric authentication green apple computer learning
Biometric authentication green apple computer learning
 
Javascript
JavascriptJavascript
Javascript
 
PHP programmimg
PHP programmimgPHP programmimg
PHP programmimg
 
Sharbani Bhattacharya SE design & Implementation
Sharbani Bhattacharya SE design & ImplementationSharbani Bhattacharya SE design & Implementation
Sharbani Bhattacharya SE design & Implementation
 
Visual Basic –User Interface- V
Visual Basic –User Interface- VVisual Basic –User Interface- V
Visual Basic –User Interface- V
 
Visual Basic User Interface-VI
Visual Basic User Interface-VIVisual Basic User Interface-VI
Visual Basic User Interface-VI
 
Microsoft Front Page
Microsoft Front PageMicrosoft Front Page
Microsoft Front Page
 
Visual Basic User Interface-III
Visual Basic User Interface-IIIVisual Basic User Interface-III
Visual Basic User Interface-III
 
Visual Basic User Interface -IV
Visual Basic User Interface -IVVisual Basic User Interface -IV
Visual Basic User Interface -IV
 
Estimation sharbani bhattacharya
Estimation sharbani bhattacharyaEstimation sharbani bhattacharya
Estimation sharbani bhattacharya
 
Sharbani bhattacharya Visual Basic User Interface-ii
Sharbani bhattacharya  Visual Basic User Interface-iiSharbani bhattacharya  Visual Basic User Interface-ii
Sharbani bhattacharya Visual Basic User Interface-ii
 
Sharbani Bhattacharya VB User Interface1
Sharbani Bhattacharya VB User Interface1Sharbani Bhattacharya VB User Interface1
Sharbani Bhattacharya VB User Interface1
 
Sharbani bhattacharya VB Structures
Sharbani bhattacharya VB StructuresSharbani bhattacharya VB Structures
Sharbani bhattacharya VB Structures
 
Software Metrics & Measurement-Sharbani Bhattacharya
Software Metrics & Measurement-Sharbani BhattacharyaSoftware Metrics & Measurement-Sharbani Bhattacharya
Software Metrics & Measurement-Sharbani Bhattacharya
 
Slcm sharbani bhattacharya
Slcm sharbani bhattacharyaSlcm sharbani bhattacharya
Slcm sharbani bhattacharya
 
SE Introduction sharbani bhattacharya
SE Introduction sharbani bhattacharyaSE Introduction sharbani bhattacharya
SE Introduction sharbani bhattacharya
 
Sharbani bhattacharya Macromedia-flash
Sharbani bhattacharya Macromedia-flashSharbani bhattacharya Macromedia-flash
Sharbani bhattacharya Macromedia-flash
 
Sharbani bhattacharya Visual Basic
Sharbani bhattacharya Visual BasicSharbani bhattacharya Visual Basic
Sharbani bhattacharya Visual Basic
 
Sharbani bhattacharya gyanodya 2014
Sharbani bhattacharya gyanodya 2014Sharbani bhattacharya gyanodya 2014
Sharbani bhattacharya gyanodya 2014
 
Sharbani bhattacharya sacta 2014
Sharbani bhattacharya sacta 2014Sharbani bhattacharya sacta 2014
Sharbani bhattacharya sacta 2014
 

Recently uploaded

Artificial intelligence presentation2-171219131633.pdf
Artificial intelligence presentation2-171219131633.pdfArtificial intelligence presentation2-171219131633.pdf
Artificial intelligence presentation2-171219131633.pdf
Kira Dess
 
01-vogelsanger-stanag-4178-ed-2-the-new-nato-standard-for-nitrocellulose-test...
01-vogelsanger-stanag-4178-ed-2-the-new-nato-standard-for-nitrocellulose-test...01-vogelsanger-stanag-4178-ed-2-the-new-nato-standard-for-nitrocellulose-test...
01-vogelsanger-stanag-4178-ed-2-the-new-nato-standard-for-nitrocellulose-test...
AshwaniAnuragi1
 
21P35A0312 Internship eccccccReport.docx
21P35A0312 Internship eccccccReport.docx21P35A0312 Internship eccccccReport.docx
21P35A0312 Internship eccccccReport.docx
rahulmanepalli02
 

Recently uploaded (20)

Geometric constructions Engineering Drawing.pdf
Geometric constructions Engineering Drawing.pdfGeometric constructions Engineering Drawing.pdf
Geometric constructions Engineering Drawing.pdf
 
Dynamo Scripts for Task IDs and Space Naming.pptx
Dynamo Scripts for Task IDs and Space Naming.pptxDynamo Scripts for Task IDs and Space Naming.pptx
Dynamo Scripts for Task IDs and Space Naming.pptx
 
Artificial intelligence presentation2-171219131633.pdf
Artificial intelligence presentation2-171219131633.pdfArtificial intelligence presentation2-171219131633.pdf
Artificial intelligence presentation2-171219131633.pdf
 
Passive Air Cooling System and Solar Water Heater.ppt
Passive Air Cooling System and Solar Water Heater.pptPassive Air Cooling System and Solar Water Heater.ppt
Passive Air Cooling System and Solar Water Heater.ppt
 
Basics of Relay for Engineering Students
Basics of Relay for Engineering StudentsBasics of Relay for Engineering Students
Basics of Relay for Engineering Students
 
Filters for Electromagnetic Compatibility Applications
Filters for Electromagnetic Compatibility ApplicationsFilters for Electromagnetic Compatibility Applications
Filters for Electromagnetic Compatibility Applications
 
01-vogelsanger-stanag-4178-ed-2-the-new-nato-standard-for-nitrocellulose-test...
01-vogelsanger-stanag-4178-ed-2-the-new-nato-standard-for-nitrocellulose-test...01-vogelsanger-stanag-4178-ed-2-the-new-nato-standard-for-nitrocellulose-test...
01-vogelsanger-stanag-4178-ed-2-the-new-nato-standard-for-nitrocellulose-test...
 
Introduction-to- Metrology and Quality.pptx
Introduction-to- Metrology and Quality.pptxIntroduction-to- Metrology and Quality.pptx
Introduction-to- Metrology and Quality.pptx
 
Autodesk Construction Cloud (Autodesk Build).pptx
Autodesk Construction Cloud (Autodesk Build).pptxAutodesk Construction Cloud (Autodesk Build).pptx
Autodesk Construction Cloud (Autodesk Build).pptx
 
handbook on reinforce concrete and detailing
handbook on reinforce concrete and detailinghandbook on reinforce concrete and detailing
handbook on reinforce concrete and detailing
 
Circuit Breakers for Engineering Students
Circuit Breakers for Engineering StudentsCircuit Breakers for Engineering Students
Circuit Breakers for Engineering Students
 
Independent Solar-Powered Electric Vehicle Charging Station
Independent Solar-Powered Electric Vehicle Charging StationIndependent Solar-Powered Electric Vehicle Charging Station
Independent Solar-Powered Electric Vehicle Charging Station
 
21P35A0312 Internship eccccccReport.docx
21P35A0312 Internship eccccccReport.docx21P35A0312 Internship eccccccReport.docx
21P35A0312 Internship eccccccReport.docx
 
8th International Conference on Soft Computing, Mathematics and Control (SMC ...
8th International Conference on Soft Computing, Mathematics and Control (SMC ...8th International Conference on Soft Computing, Mathematics and Control (SMC ...
8th International Conference on Soft Computing, Mathematics and Control (SMC ...
 
Presentation on Slab, Beam, Column, and Foundation/Footing
Presentation on Slab,  Beam, Column, and Foundation/FootingPresentation on Slab,  Beam, Column, and Foundation/Footing
Presentation on Slab, Beam, Column, and Foundation/Footing
 
litvinenko_Henry_Intrusion_Hong-Kong_2024.pdf
litvinenko_Henry_Intrusion_Hong-Kong_2024.pdflitvinenko_Henry_Intrusion_Hong-Kong_2024.pdf
litvinenko_Henry_Intrusion_Hong-Kong_2024.pdf
 
Worksharing and 3D Modeling with Revit.pptx
Worksharing and 3D Modeling with Revit.pptxWorksharing and 3D Modeling with Revit.pptx
Worksharing and 3D Modeling with Revit.pptx
 
Theory of Time 2024 (Universal Theory for Everything)
Theory of Time 2024 (Universal Theory for Everything)Theory of Time 2024 (Universal Theory for Everything)
Theory of Time 2024 (Universal Theory for Everything)
 
Diploma Engineering Drawing Qp-2024 Ece .pdf
Diploma Engineering Drawing Qp-2024 Ece .pdfDiploma Engineering Drawing Qp-2024 Ece .pdf
Diploma Engineering Drawing Qp-2024 Ece .pdf
 
What is Coordinate Measuring Machine? CMM Types, Features, Functions
What is Coordinate Measuring Machine? CMM Types, Features, FunctionsWhat is Coordinate Measuring Machine? CMM Types, Features, Functions
What is Coordinate Measuring Machine? CMM Types, Features, Functions
 

Requirement Analysis & Specification sharbani bhattacharya

  • 1.
  • 2.  Requirement gathering and Analysis  Software Requirement Specifications  Formal Specification Technique  Characteristics of good SRS 2
  • 4. “Software requirements is one such area, to which little importance was attached in the early days of software development, as the emphasis was on coding and design.” “For large software systems, requirements analysis is perhaps the most difficult and intractable activity; it is also very error-prone.” by Prof. Pankaj Jalote 4
  • 5.  The requirements phase translates the ideas in the minds of the clients (the input), into a formal document (the output of the requirements phase). 5
  • 6. 6
  • 7.  A meeting is conducted at a neutral site and attended by both software engineers and customers.  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.  The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements in an atmosphere that is conducive to the accomplishment of the goal. 7
  • 8.  While reviewing the request in the days before the meeting, each FAST attendee is asked to make a list of objects that are part of the environment that surrounds the system, other objects that are to be produced by the system, and objects that are used by the system to perform its functions. 8
  • 9.  In addition, each attendee is asked to make another list of services (processes or functions) that manipulate or interact with the objects. Finally, lists of constraints (e.g., cost, size, business rules) and performance criteria (e.g., speed, accuracy) are also developed.  The attendees are informed that the lists are not expected to be exhaustive but are expected to reflect each person’s perception of the system. 9
  • 10.  Quality function deployment (QFD) is a quality management technique that translates the needs of the customer into technical requirements for software.  Originally developed in Japan and first used at the Kobe Shipyard of Mitsubishi Heavy Industries, Ltd.,  In the early 1970s, QFD “concentrates on maximizing customer satisfaction from the software engineering process [ZUL92].” 10
  • 11.  Normal requirements  Expected requirements  Exciting requirements 11
  • 12. The objectives and goals that are stated for a product or system during meetings with the customer. If these requirements are present, the customer is satisfied. Examples of normal requirements might be requested types of graphical displays, specific system functions, and defined levels of performance. 12
  • 13. These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them. Their absence will be a cause for significant dissatisfaction.  Examples of expected requirements are: ease of human/machine interaction, overall operational correctness and reliability, and ease of software installation. 13
  • 14. These features go beyond the customer’s expectations and prove to be very satisfying when present. For example, word processing software is requested with standard features. The delivered product contains a number of page layout capabilities that are quite pleasing and unexpected. 14
  • 15. The requirements engineering process can be described in five distinct steps-  Requirements elicitation  Requirements analysis and negotiation  Requirements specification  System modeling  Requirements validation  Requirements management 15
  • 16.  Ask the customer, the users, and others what the objectives for the system or product are  That is to be accomplished, how the system or product fits into the needs of the business, and finally  How the system or product is to be used on a day-to-day basis. But it isn’t simple—it’s very hard. 16
  • 17. Christel and Kang [CRI92] identify a number of problems that help us understand why requirements elicitation is difficult:  Problems of scope  Problems of understanding  Problems of volatility 17
  • 18. The boundary of the system is ill-defined or the customers/ users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives. 18
  • 19. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be “obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable. 19
  • 20.  The requirements change over time. To help overcome these problems, system engineers must approach the requirements gathering activity in an organized manner. 20
  • 21. Sommerville and Sawyer [SOM97] suggest a set of detailed guidelines for requirements elicitation  Assess the business and technical feasibility for the proposed system.  Identify the people who will help specify requirements and understand their organizational bias.  Define the technical environment (e.g., computing architecture, operating system, telecommunications needs) into which the system or product will be placed.  Identify “domain constraints” (i.e., characteristics of the business environment specific to the application domain) that limit the functionality or performance of the system or product to be built. 21
  • 22. Sommerville and Sawyer [SOM97] suggest a set of detailed guidelines for requirements elicitation  Define one or more requirements elicitation methods (e.g., interviews, focus groups, team meetings).  Solicit participation from many people so that requirements are defined from different points of view; be sure to identify the rationale for each requirement that is recorded.  Identify ambiguous requirements as candidates for prototyping.  Create usage scenarios to help customers/users better identify key requirements. 22
  • 23. The work products produced as a consequence of the requirements elicitation activity will vary depending on the size of the system or product to be built. 23
  • 24.  A statement of need and feasibility.  A bounded statement of scope for the system or product.  A list of customers, users, and other stakeholders who participated in the requirements elicitation activity. 24
  • 25.  A description of the system’s technical environment.  A list of requirements (preferably organized by function) and the domain constraints that apply to each.  A set of usage scenarios that provide insight into the use of the system or product under different operating conditions.  Any prototypes developed to better define requirements. 25
  • 26.  Each of these work products is reviewed by all people who have participated in the requirements elicitation. 26
  • 27. 1. Requirement Gathering is important for __________________ 2. Requirement Analysis may be error-prone said by _____________. 3. Prototype are developed in _________________. Put right words in blanks  Software Development  Requirement gathering  Prof. Jalote 27
  • 28. 1. Requirement Gathering is important for Software Development 2. Requirement Analysis may be error-prone said by Prof. Jalote 3. Prototype are developed in Requirement gathering. 28
  • 29. Analysis categorizes requirements and organizes them into related subsets; explores each requirement in relationship to others; examines requirements for consistency, omissions, and ambiguity; and ranks requirements based on the needs of customers/users. 29
  • 30.  Is each requirement consistent with the overall objective for the system/product?  Have all requirements been specified at the proper level of abstraction?  That is, do some requirements provide a level of technical detail that is inappropriate at this stage?  Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?  Is each requirement bounded and unambiguous? 30
  • 31.  Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?  Do any requirements conflict with other requirements?  Is each requirement achievable in the technical environment that will house the system or product?  Is each requirement testable, once implemented? 31
  • 32.  Rough estimates of development effort are made and used to assess the impact of each requirement on project cost and delivery time.  Using an iterative approach, requirements are eliminated, combined, and/or modified so that each party achieves some measure of satisfaction. 32
  • 33. “A specification can be a written document, a graphical model, a formal mathematical model, a collection of usage scenarios, a prototype, or any combination of these.” Pressman 33
  • 34.  The System Specification is the final work product produced by the system and requirements engineer. It serves as the foundation for hardware engineering, software engineering, database engineering, and human engineering.  It describes the function and performance of a computer-based system and the constraints that will govern its development. 34
  • 35.  Why requirement specification is important, how requirements are analyzed and specified?  How requirements are validated, and some metrics that can be applied to requirements? 35
  • 36.  A condition of capability needed by a user to solve a problem or achieve an objective;  A condition or a capability that must be met or possessed by a system ... to satisfy a contract, standard, specification, or other formally imposed document. by IEEE 36
  • 37. The goal of the requirements activity is to produce the Software Requirements Specification (SRS), that describes what the proposed software should do without describing how the software will do it. 37
  • 38. A basic limitation for this is that the user needs keep changing as the environment in which the system is to function changes with time. Even while accepting that some requirement change requests are inevitable, there are still pressing reasons why a thorough job should be done in the requirements phase to produce a high-quality and relatively stable SRS. 38
  • 39. The origin of most software systems is in the needs of some clients. The software system itself is created by some developers. 39
  • 40. There are three major parties interested in a new system:  the client,  the developer,  and the users. 40
  • 41.  The problem is that the client usually does not understand software or the software development process,  The developer often does not understand the client's problem and application area. This causes a communication gap between the parties involved in the development project. 41
  • 42. In order to fully specify what is to be built, you would need a meaningful model of the kitchen, that is, a blueprint or three-dimensional rendering that shows the position of the cabinets and appliances and their relationship to one another. 42
  • 43. From the model, it would be relatively easy to assess the efficiency of work flow (a requirement for all kitchens), the aesthetic “look” of the room (a personal, but very important requirement). 43
  • 44. It is important to evaluate the system’s components in relationship to one another, to determine how requirements fit into this picture, and to assess the “aesthetics” of the system as it has been conceived. 44
  • 45. 45
  • 46. To develop the system model  (1) user interface,  (2) input,  (3) system function and control,  (4) output, and  (5) maintenance and self-test. 46
  • 47. The work products produced as a consequence of requirements engineering (a system specification and related information) are assessed for quality during a validation step. 47
  • 48. Examines the specification to ensure that all system requirements have been stated unambiguously; that inconsistencies, omissions, and errors have been detected and corrected; and that the work products conform to the standards established for the process, the project, and the product. 48
  • 49.  The primary requirements validation mechanism is the formal technical review.  The review team includes system engineers, customers, users, and other stakeholders who examine the system specification looking for errors in content or interpretation, areas where clarification may be required, missing information, inconsistencies (a major problem when large products or systems are engineered), conflicting requirements, or unrealistic (unachievable) requirements. 49
  • 50. Following questions represent a small subset  Are requirements stated clearly?  Can they be misinterpreted?  Is the source (e.g., a person, a regulation, a document) of the requirement identified?  Has the final statement of the requirement been examined by or against the original source?  Is the requirement bounded in quantitative terms?  What other requirements relate to this requirement?  Are they clearly noted via a cross-reference matrix or other mechanism? 50
  • 51.  Does the requirement violate any domain constraints?  Is the requirement testable? If so, can we specify tests (sometimes called validation criteria) to exercise the requirement?  Is the requirement traceable to any system model that has been created?  Is the requirement traceable to overall system/product objectives? 51
  • 52.  Is the system specification structured in a way that leads to easy understanding, easy reference, and easy translation into more technical work products?  Has an index for the specification been created?  Have requirements associated with system performance, behavior, and operational characteristics been clearly stated?  What requirements appear to be implicit? 52
  • 53. Requirements management is a set of activities that help the project team to identify, control, and track requirements and changes to requirements at any time as the project proceeds. 53
  • 54. Like SCM, requirements management begins with identification. Each requirement is assigned a unique identifier that might take the form <requirement type><requirement #> where requirement type takes on values such as F = functional requirement, D = data requirement, B = behavioral requirement, I = interface requirement, P = output Hence, a requirement identified as F09 indicates a functional requirement assigned requirement number 9. 54
  • 55. Among many possible traceability tables are the following:  Features traceability table  Source traceability table  Dependency traceability table  Subsystem traceability table  Interface traceability table 55
  • 56. Shows how requirements relate to important customer observable system/product features. 56
  • 57. Identifies the source of each requirement. 57
  • 58. Indicates how requirements are related to one another. 58
  • 59.  Shows how requirements relate to both internal and external system interfaces. 59
  • 60. Categorizes requirements by the subsystem(s) that they govern. 60
  • 61. 61
  • 62. 62
  • 63. 63
  • 64.  Major parties of SRS are ________ , _______ and ________.  User interface, input, system function and control, output, and maintenance and self- test are in ________________  _____________________ identifies the source of each requirement. 64
  • 65.  Major parties of SRS are Client , Developer and User.  User interface, input, system function and control, output, and maintenance and self- test are in System Modeling.  Source Traceability Table identifies the source of each requirement. 65
  • 66.  The modeling is essentially a tool to help obtain a thorough and complete knowledge about the proposed system.  The SRS is written based on the knowledge acquired during analysis.  As converting knowledge into a structured document is not straightforward, specification itself is a major task, which is relatively independent. 66
  • 67.  As the primary objective of analysis is problem understanding, while the basic objective of the requirements phase is to produce the SRS, the complete and detailed analysis structures are not critical. 67
  • 68.  It is possible to develop the SRS without using formal modeling techniques.  The basic aim of the structures used in modeling is to help in knowledge representation and problem partitioning, the structures are not an end in themselves. 68
  • 69. To properly satisfy the basic goals, an SRS should have certain properties and should contain different types of requirements. 69
  • 70.  1.Correct  2. Complete  3. Unambiguous  4. Verifiable  5. Consistent  6. Ranked for importance and/or stability  7. Modifiable  8. Traceable 70
  • 71. An SRS is correct if every requirement included in the SRS represents something required in the final system. 71
  • 72. An SRS is complete if everything the software is supposed to do and the responses of the software to all classes of input data are specified in the SRS. 72
  • 73.  An SRS is unambiguous if and only if every requirement stated has one and only one interpretation.  Requirements are often written in natural language, which are inherently ambiguous. If the requirements are specified in a natural language, the SRS writer has to be especially careful to ensure that there are no ambiguities. 73
  • 74.  An SRS is verifiable if and only if every stated requirement is verifiable.  A requirement is verifiable if there exists some cost-effective process thatcan check whether the final software meets that requirement.  This implies that the requirements should have as little subjectivity as possible because subjective requirements are difficult to verify. 74
  • 75.  An SRS is consistent if there is no requirement that conflicts with another.  Terminology can cause inconsistencies; for example, different requirements may use different terms to refer to the same object. There may be logical or temporal conflict between requirements that causes inconsistencies. 75
  • 76. Example-  Suppose a requirement states that an event e is to occur before another event / . But then another set of requirements states (directly or indirectly by transitivity) that event / should occur before event e. Inconsistencies in an SRS can reflect of some major problems. 76
  • 77.  An SRS is ranked for importance and/or stability if for each requirement the importance and the stability of the requirement are indicated.  Stability of a requirement reflects the chances of it changing in future. It can be reflected in terms of the expected change volume. 77
  • 78.  An SRS is modifiable if its structure and style are such that any necessary change can be made easily while preserving completeness and consistency.  Presence of redundancy is a major hindrance to modifiability, as it can easily lead to errors. 78
  • 79.  Example-  assume that a requirement is stated in two places and that the requirement  later needs to be changed. If only one occurrence of the requirement is  modified, the resulting SRS will be inconsistent. 79
  • 80.  An SRS is traceable if the origin of each of its requirements is clear and if it facihtates the referencing of each requirement in future development .  Forward traceability means that each requirement should be traceable to some design and code elements.  Backward traceability requires that it be possible to trace design and code elements to the requirements they support.  Traceability aids verification and validation. 80
  • 81.  Functionality  Performance  Design constraints imposed on an implementation  External interfaces 81
  • 82.  Functional requirements specify which outputs should be produced from the given inputs.  They describe the relationship between the input and output of the system.  For each functional requirement, a detailed description of all the data inputs and their source, the units of measure, and the range of valid inputs must be specified. 82
  • 83.  All the requirements relating to the performance characteristics of the system must be clearly specified. There are two types of performance requirements:  Static  Dynamic. 83
  • 84.  Static requirements are those that do not impose constraint on the execution characteristics of the system.  These include requirements like the number of terminals to be supported, the number of simultaneous users to be supported, and the number of files that the system has to process and their sizes. These are also called capacity requirements of the system. 84
  • 85.  Dynamic requirements specify constraints on the execution behavior of the system.  These typically include response time and throughput constraints on the system.  Response time is the expected time for the completion of an operation under specified circumstances.  Throughput is the expected number of operations that can be performed in a unit time.  For example, the SRS may specify the number of transactions that must be processed per unit time, or what the response time for a particular command should be.  Acceptable ranges of the different performance parameters should be specified, as well as acceptable performance for both normal and peak workload conditions. 85
  • 86.  There are a number of factors in the client's environment that may restrict the choices of a designer. Such factors include standards that must be followed, resource limits, operating environment, reliability and security requirements, and policies that may have an impact on the design of the system.  An SRS should identify and specify all such constraints. 86
  • 87.  Standards Compliance  Hardware Limitations  Reliability and Fault Tolerance  Security 87
  • 88.  All the interactions of the software with people, hardware, and other software should be clearly specified.  For the user interface, the characteristics of each user interface of the software product should be specified. User interface is becoming increasingly important and must be given proper attention. 88
  • 89.  All the requirements for the system have to be included in a document that is clear and concise.  For this, it is necessary to organize the requirements document as sections and subsections.  There can be many ways to structure a requirements document. 89
  • 90. 90
  • 91. 91
  • 92.  Actors and goals  Main success scenarios  Failure conditions  Failure handling 92
  • 93. 93
  • 94. 94
  • 95. 95
  • 96. 96
  • 97.  Are all hardware resources defined?  Have the response times of functions been specified?  Have all the hardware, external software, and data interfaces been defined?  Have all the functions required by the client been specified?  Is each requirement testable?  Is the initial state of the system defined?  Are the responses to exceptional conditions specified?  Does the requirement contain restrictions that can be controlled by the designer?  Are possible future modifications specified? 97
  • 98.  Checklist are part of ________  Functional Requirements are part of________________  ______________________ is part of Design Constarints. 98
  • 99.  Checklist are part of Review  Functional Requirements are part of Software Requirements Specifications  Reliability and Fault Tolerance is part of Design Constarints 99
  • 100.  Software Engineering by Somerville  Software Engineering-Pressman  Software Engineering- Pankaj Jalote  Software Engineering Tutorial Point  Software Engineering Wikipedia 100
  • 101. 101