SlideShare a Scribd company logo
1 of 59
Download to read offline
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 11
AnalysisAnalysis
andand
Software RequirementsSoftware Requirements
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 22
ObjectivesObjectives
To introduce the concepts of user and systemTo introduce the concepts of user and system
requirementsrequirements
To describe functional and nonTo describe functional and non--functionalfunctional
requirementsrequirements
To explain how software requirements may beTo explain how software requirements may be
organised in a requirements documentorganised in a requirements document
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 33
Problem AnalysisProblem Analysis
Structuring informationStructuring information
Data flow diagram (DFD)Data flow diagram (DFD)
Structured AnalysisStructured Analysis
PrototypingPrototyping
Other tools/methods for analysisOther tools/methods for analysis
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 44
Requirement SpecificationRequirement Specification
Functional and nonFunctional and non--functionalfunctional
PerformancePerformance
Design constraints imposed on anDesign constraints imposed on an
implementationimplementation
External interfacesExternal interfaces
Specification
Making , becoming ,
Being specific a detailed
of requirement
Specify to mention
particularly
Require to ask
Requirement a need,
A thing needed.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 55
Software Requirement SpecificationSoftware Requirement Specification
(SRS)(SRS)
An SRS establishes the basis for agreementAn SRS establishes the basis for agreement
between the client and the supplier on what thebetween the client and the supplier on what the
software product will do.software product will do.
As SRS provides a reference for validation ofAs SRS provides a reference for validation of
the final product.the final product.
A high quality SRS is a prerequisite to highA high quality SRS is a prerequisite to high
quality software.quality software.
A high quality SRS reduces the developmentA high quality SRS reduces the development
costcost
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 66
Components of an SRSComponents of an SRS
Performance
Requirements
Functional
Requirements
Design
constrains
External
Interfaces
Software
Requirements specification
Document
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 77
Format of SRSFormat of SRS
Product overview and summary.Product overview and summary.
Development, operating and maintenanceDevelopment, operating and maintenance
environments.environments.
External interfaces and data flowExternal interfaces and data flow
Functional requirementsFunctional requirements
Performance requirements.Performance requirements.
Exception handing.Exception handing.
Early subsets and implementation and priorities.Early subsets and implementation and priorities.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 88
Foreseeable modification and EnhancementsForeseeable modification and Enhancements
Acceptance criteriaAcceptance criteria
Design hints and guidelinesDesign hints and guidelines
Cross reference indexCross reference index
Glossary of teemsGlossary of teems
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 99
Characteristic of an SRSCharacteristic of an SRS
UnderstandableUnderstandable
UnambiguousUnambiguous
CompleteComplete
VerifiableVerifiable
ConsistentConsistent
ModifiableModifiable
TraceableTraceable
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1010
ValidationValidation
Requirement reviewsRequirement reviews
Constructing methodsConstructing methods
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1111
Requirements engineeringRequirements engineering
The process of establishing the services that theThe process of establishing the services that the
customer requires from a system and thecustomer requires from a system and the
constraints under which it operates and isconstraints under which it operates and is
developed.developed.
The requirements themselves are theThe requirements themselves are the
descriptions of the system services anddescriptions of the system services and
constraints that are generated during theconstraints that are generated during the
requirements engineering process.requirements engineering process.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1212
What is a requirement?What is a requirement?
It may range from a highIt may range from a high--level abstractlevel abstract
statement of a service or of a system constraintstatement of a service or of a system constraint
to a detailed mathematical functionalto a detailed mathematical functional
specification.specification.
This is inevitable as requirements may serve aThis is inevitable as requirements may serve a
dual functiondual function
–– May be the basis for a bid for a contractMay be the basis for a bid for a contract -- thereforetherefore
must be open to interpretation;must be open to interpretation;
–– May be the basis for the contract itselfMay be the basis for the contract itself -- thereforetherefore
must be defined in detail;must be defined in detail;
–– Both these statements may be called requirements.Both these statements may be called requirements.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1313
Requirements abstraction (Davis)Requirements abstraction (Davis)
“If a company wishes to let a contract for a large software development project, it
must define its needs in a sufficiently abstract way that a solution is not pre-defined.
The requirements must be written so that several contractors can bid for the contract,
offering, perhaps, different ways of meeting the client organisation’s needs. Once a
contract has been awarded, the contractor must write a system definition for the client
in more detail so that the client understands and can validate what the software will
do. Both o f these documents may be called the requirements document for the
system.”
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1414
Types of requirementTypes of requirement
User requirementsUser requirements
–– Statements in natural language plus diagrams of theStatements in natural language plus diagrams of the
services the system provides and its operationalservices the system provides and its operational
constraints. Written for customers.constraints. Written for customers.
System requirementsSystem requirements
–– A structured document setting out detailedA structured document setting out detailed
descriptions of the systemdescriptions of the system’’s functions, services ands functions, services and
operational constraints. Defines what should beoperational constraints. Defines what should be
implemented so may be part of a contract betweenimplemented so may be part of a contract between
client and contractor.client and contractor.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1515
Definitions and specificationsDefinitions and specifications
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1616
Requirements readersRequirements readers
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1717
Functional and nonFunctional and non--functional requirementsfunctional requirements
Functional requirementsFunctional requirements
–– Statements of services the system should provide, how theStatements of services the system should provide, how the
system should react to particular inputs and how the systemsystem should react to particular inputs and how the system
should behave in particular situations.should behave in particular situations.
NonNon--functional requirementsfunctional requirements
–– constraints on the services or functions offered by the systemconstraints on the services or functions offered by the system
such as timing constraints, constraints on the developmentsuch as timing constraints, constraints on the development
process, standards, etc.process, standards, etc.
Domain requirementsDomain requirements
–– Requirements that come from the application domain of theRequirements that come from the application domain of the
system and that reflect characteristics of that domain.system and that reflect characteristics of that domain.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1818
Functional requirementsFunctional requirements
Describe functionality or system services.Describe functionality or system services.
Depend on the type of software, expected usersDepend on the type of software, expected users
and the type of system where the software isand the type of system where the software is
used.used.
Functional user requirements may be highFunctional user requirements may be high--levellevel
statements of what the system should do butstatements of what the system should do but
functional system requirements should describefunctional system requirements should describe
the system services in detail.the system services in detail.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1919
Examples of functional requirementsExamples of functional requirements
The user shall be able to search either all of theThe user shall be able to search either all of the
initial set of databases or select a subset from it.initial set of databases or select a subset from it.
The system shall provide appropriate viewersThe system shall provide appropriate viewers
for the user to read documents in the documentfor the user to read documents in the document
store.store.
Every order shall be allocated a unique identifierEvery order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to(ORDER_ID) which the user shall be able to
copy to the accountcopy to the account’’s permanent storage area.s permanent storage area.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2020
Requirements imprecisionRequirements imprecision
Problems arise when requirements are notProblems arise when requirements are not
precisely stated.precisely stated.
Ambiguous requirements may be interpreted inAmbiguous requirements may be interpreted in
different ways by developers and users.different ways by developers and users.
Consider the termConsider the term ‘‘appropriate viewersappropriate viewers’’
–– User intentionUser intention -- special purpose viewer for eachspecial purpose viewer for each
different document type;different document type;
–– Developer interpretationDeveloper interpretation -- Provide a text viewer thatProvide a text viewer that
shows the contents of the document.shows the contents of the document.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2121
Requirements completeness andRequirements completeness and
consistencyconsistency
In principle, requirements should be both complete andIn principle, requirements should be both complete and
consistent.consistent.
CompleteComplete
–– They should include descriptions of all facilitiesThey should include descriptions of all facilities
required.required.
ConsistentConsistent
–– There should be no conflicts or contradictions in theThere should be no conflicts or contradictions in the
descriptions of the system facilities.descriptions of the system facilities.
In practice, it is impossible to produce a complete andIn practice, it is impossible to produce a complete and
consistent requirements document.consistent requirements document.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2222
NonNon--functional requirementsfunctional requirements
These define system properties and constraintsThese define system properties and constraints
e.g. reliability, response time and storagee.g. reliability, response time and storage
requirements. Constraints are I/O devicerequirements. Constraints are I/O device
capability, system representations, etc.capability, system representations, etc.
Process requirements may also be specifiedProcess requirements may also be specified
mandating a particular CASE system,mandating a particular CASE system,
programming language or development method.programming language or development method.
NonNon--functional requirements may be morefunctional requirements may be more
critical than functional requirements. If these arecritical than functional requirements. If these are
not met, the system is useless.not met, the system is useless.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2323
NonNon--functional classificationsfunctional classifications
Product requirementsProduct requirements
–– Requirements which specify that the delivered product mustRequirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability,behave in a particular way e.g. execution speed, reliability,
etc.etc.
Organisational requirementsOrganisational requirements
–– Requirements which are a consequence of organisationalRequirements which are a consequence of organisational
policies and procedures e.g. process standards used,policies and procedures e.g. process standards used,
implementation requirements, etc.implementation requirements, etc.
External requirementsExternal requirements
–– Requirements which arise from factors which are external toRequirements which arise from factors which are external to
the system and its development process e.g. interoperabilitythe system and its development process e.g. interoperability
requirements, legislative requirements, etc.requirements, legislative requirements, etc.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2424
NonNon--functional requirement typesfunctional requirement types
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2525
NonNon--functional requirements examplesfunctional requirements examples
Product requirementProduct requirement
8.18.1 The user interface for LIBSYS shall be implemented asThe user interface for LIBSYS shall be implemented as
simple HTML without frames or Java applets.simple HTML without frames or Java applets.
Organisational requirementOrganisational requirement
9.3.2 The system development process and deliverable9.3.2 The system development process and deliverable
documents shall conform to the process and deliverablesdocuments shall conform to the process and deliverables
defined in XYZCodefined in XYZCo--SPSP--STANSTAN--95.95.
External requirementExternal requirement
7.6.5 The system shall not disclose any personal information7.6.5 The system shall not disclose any personal information
about customers apart from their name and referenceabout customers apart from their name and reference
number to the operators of the system.number to the operators of the system.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2626
Goals and requirementsGoals and requirements
NonNon--functional requirements may be very difficult tofunctional requirements may be very difficult to
state precisely and imprecise requirements may bestate precisely and imprecise requirements may be
difficult to verify.difficult to verify.
GoalGoal
–– A general intention of the user such as ease of use.A general intention of the user such as ease of use.
Verifiable nonVerifiable non--functional requirementfunctional requirement
–– A statement using some measure that can be objectivelyA statement using some measure that can be objectively
tested.tested.
Goals are helpful to developers as they convey theGoals are helpful to developers as they convey the
intentions of the system users.intentions of the system users.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2727
ExamplesExamples
A system goalA system goal
–– The system should be easy to use by experienced controllersThe system should be easy to use by experienced controllers
and should be organised in such a way that user errors areand should be organised in such a way that user errors are
minimised.minimised.
A verifiable nonA verifiable non--functional requirementfunctional requirement
–– Experienced controllers shall be able to use all the systemExperienced controllers shall be able to use all the system
functions after a total of two hours training. After this trainifunctions after a total of two hours training. After this training,ng,
the average number of errors made by experienced usersthe average number of errors made by experienced users
shall not exceed two per day.shall not exceed two per day.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2828
Requirements measuresRequirements measures
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size M Bytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2929
Requirements interactionRequirements interaction
Conflicts between different nonConflicts between different non--functionalfunctional
requirements are common in complex systems.requirements are common in complex systems.
Spacecraft systemSpacecraft system
–– To minimise weight, the number of separate chips inTo minimise weight, the number of separate chips in
the system should be minimised.the system should be minimised.
–– To minimise power consumption, lower power chipsTo minimise power consumption, lower power chips
should be used.should be used.
–– However, using low power chips may mean thatHowever, using low power chips may mean that
more chips have to be used. Which is the mostmore chips have to be used. Which is the most
critical requirement?critical requirement?
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3030
Domain requirementsDomain requirements
Derived from the application domain andDerived from the application domain and
describe system characteristics and featuresdescribe system characteristics and features
that reflect the domain.that reflect the domain.
Domain requirements be new functionalDomain requirements be new functional
requirements, constraints on existingrequirements, constraints on existing
requirements or define specific computations.requirements or define specific computations.
If domain requirements are not satisfied, theIf domain requirements are not satisfied, the
system may be unworkable.system may be unworkable.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3131
Library system domainLibrary system domain
requirementsrequirements
There shall be a standard user interface to allThere shall be a standard user interface to all
databases which shall be based on the Z39.50databases which shall be based on the Z39.50
standard.standard.
Because of copyright restrictions, someBecause of copyright restrictions, some
documents must be deleted immediately ondocuments must be deleted immediately on
arrival. Depending on the userarrival. Depending on the user’’s requirements,s requirements,
these documents will either be printed locally onthese documents will either be printed locally on
the system server for manually forwarding to thethe system server for manually forwarding to the
user or routed to a network printer.user or routed to a network printer.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3232
Train protection systemTrain protection system
The deceleration of the train shall beThe deceleration of the train shall be
computed as:computed as:
–– DDtraintrain == DDcontrolcontrol ++ DDgradientgradient
wherewhere DDgradientgradient is 9.81msis 9.81ms22
* compensated* compensated
gradient/alpha and where the values ofgradient/alpha and where the values of
9.81ms9.81ms22
/alpha are known for different types/alpha are known for different types
of train.of train.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3333
Domain requirements problemsDomain requirements problems
UnderstandabilityUnderstandability
–– Requirements are expressed in the language of theRequirements are expressed in the language of the
application domain;application domain;
–– This is often not understood by software engineersThis is often not understood by software engineers
developing the system.developing the system.
ImplicitnessImplicitness
–– Domain specialists understand the area so well thatDomain specialists understand the area so well that
they do not think of making the domain requirementsthey do not think of making the domain requirements
explicit.explicit.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3434
User requirementsUser requirements
Should describe functional and nonShould describe functional and non--functionalfunctional
requirements in such a way that they arerequirements in such a way that they are
understandable by system users who donunderstandable by system users who don’’t havet have
detailed technical knowledge.detailed technical knowledge.
User requirements are defined using naturalUser requirements are defined using natural
language, tables and diagrams as these can belanguage, tables and diagrams as these can be
understood by all users.understood by all users.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3535
Problems with natural languageProblems with natural language
Lack of clarityLack of clarity
–– Precision is difficult without making the documentPrecision is difficult without making the document
difficult to read.difficult to read.
Requirements confusionRequirements confusion
–– Functional and nonFunctional and non--functional requirements tend tofunctional requirements tend to
be mixedbe mixed--up.up.
Requirements amalgamationRequirements amalgamation
–– Several different requirements may be expressedSeveral different requirements may be expressed
together.together.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3636
Editor grid requirementEditor grid requirement
2.6 Grid facilities To assist in the positioning of entities on a diagram,
the user may turn on a grid in either centimetres or inches, via an
option on the control panel. Initially, the grid is off. The grid may be
turned on and off at any time during an editing session and can be
toggled between inches and centimetres at any time. A grid option
will be provided on the reduce-to-fit view but the number of grid
lines shown will be reduced to avoid filling the smaller diagram
with grid lines.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3737
Requirement problemsRequirement problems
Database requirements includes both conceptual andDatabase requirements includes both conceptual and
detailed informationdetailed information
–– Describes the concept of a financial accounting system that isDescribes the concept of a financial accounting system that is
to be included in LIBSYS;to be included in LIBSYS;
–– However, it also includes the detail that managers canHowever, it also includes the detail that managers can
configure this systemconfigure this system -- this is unnecessary at this level.this is unnecessary at this level.
Grid requirement mixes three different kinds ofGrid requirement mixes three different kinds of
requirementrequirement
–– Conceptual functional requirement (the need for a grid);Conceptual functional requirement (the need for a grid);
–– NonNon--functional requirement (grid units);functional requirement (grid units);
–– NonNon--functional UI requirement (grid switching).functional UI requirement (grid switching).
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3838
Structured presentationStructured presentation
2.6.1 Grid facilities
The editor shall provide a grid facility where a m atrix of horizontal and
vertical lines provide a background to the editor window. This grid shall be a
passive grid where the alignment of entities is the user's responsibility.
Rationale: A grid helps the user to create a tidy diagram with well-spaced
entities. Although an active grid, where entities 'snap-to' grid lines can be useful,
the positioning is imprecise. The user is the best person to decide where entities
should be positioned.
Specification: ECLIPSE/WS/Tools/DE/FS Section 5.6
Source: Ray Wilson, Glasgow Office
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3939
Guidelines for writing requirementsGuidelines for writing requirements
Invent a standard format and use it for allInvent a standard format and use it for all
requirements.requirements.
Use language in a consistent way. Use shall forUse language in a consistent way. Use shall for
mandatory requirements, should for desirablemandatory requirements, should for desirable
requirements.requirements.
Use text highlighting to identify key parts of theUse text highlighting to identify key parts of the
requirement.requirement.
Avoid the use of computer jargon.Avoid the use of computer jargon.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4040
System requirementsSystem requirements
More detailed specifications of system functions,More detailed specifications of system functions,
services and constraints than userservices and constraints than user
requirements.requirements.
They are intended to be a basis for designingThey are intended to be a basis for designing
the system.the system.
They may be incorporated into the systemThey may be incorporated into the system
contract.contract.
System requirements may be defined orSystem requirements may be defined or
illustrated using system models discussed inillustrated using system models discussed in
Chapter 8.Chapter 8.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4141
Requirements and designRequirements and design
In principle, requirements should state what theIn principle, requirements should state what the
system should do and the design shouldsystem should do and the design should
describe how it does this.describe how it does this.
In practice, requirements and design areIn practice, requirements and design are
inseparableinseparable
–– A system architecture may be designed to structureA system architecture may be designed to structure
the requirements;the requirements;
–– The system may interThe system may inter--operate with other systemsoperate with other systems
that generate design requirements;that generate design requirements;
–– The use of a specific design may be a domainThe use of a specific design may be a domain
requirement.requirement.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4242
Problems with NL specificationProblems with NL specification
AmbiguityAmbiguity
–– The readers and writers of the requirement mustThe readers and writers of the requirement must
interpret the same words in the same way. NL isinterpret the same words in the same way. NL is
naturally ambiguous so this is very difficult.naturally ambiguous so this is very difficult.
OverOver--flexibilityflexibility
–– The same thing may be said in a number of differentThe same thing may be said in a number of different
ways in the specification.ways in the specification.
Lack of modularisationLack of modularisation
–– NL structures are inadequate to structure systemNL structures are inadequate to structure system
requirements.requirements.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4343
Alternatives to NL specificationAlternatives to NL specification
Notation Description
Structured natural
language
This approach depends on defining standard forms or templates to express the
requirements specification.
Design
description
languages
This approach uses a language like a programming language but with more abstract
features to specify the requirements by defining an operational model of the system.
This approach is not now widely used although it can be useful for interface
specifications.
Graphical
notations
A graphical language, supplemented by text annotations is used to define the
functional requirements for the system. An early example of such a graphical
language was SADT. Now, use-case descriptions and sequence d iagrams are
commonly used .
Mathematical
specifications
These are notations based on mathematical concepts such as finite-state machines or
sets. These unambiguous specifications reduce the arguments between customer and
contractor about system functionality. However, most customers don’t understand
formal specifications and are reluctant to accept it as a system contract.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4444
Structured language specificationsStructured language specifications
The freedom of the requirements writer is limitedThe freedom of the requirements writer is limited
by a predefined template for requirements.by a predefined template for requirements.
All requirements are written in a standard way.All requirements are written in a standard way.
The terminology used in the description may beThe terminology used in the description may be
limited.limited.
The advantage is that the most of theThe advantage is that the most of the
expressiveness of natural language isexpressiveness of natural language is
maintained but a degree of uniformity ismaintained but a degree of uniformity is
imposed on the specification.imposed on the specification.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4545
FormForm--based specificationsbased specifications
Definition of the function or entity.Definition of the function or entity.
Description of inputs and where they come from.Description of inputs and where they come from.
Description of outputs and where they go to.Description of outputs and where they go to.
Indication of other entities required.Indication of other entities required.
Pre and post conditions (if appropriate).Pre and post conditions (if appropriate).
The side effects (if any) of the function.The side effects (if any) of the function.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4646
FormForm--based node specificationbased node specification
Insulin Pump/Control Software/SRS/3.3.2
Function Compute insulin dose: Safe sugar level
Description Computes the dose of insulin to be delivered when the current measured sugar level is in
the safe zone between 3 and 7 units.
Inputs Current sugar reading (r2), the previous two readings (r0 and r1)
Source Current sugar reading from sensor. Other readings from memory.
Outputs CompDose Š the dose in insulin to be delivered
Destination Main control loop
Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of
increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is
computed by dividing the difference between the current sugar level and the previous level by 4 and
rounding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that can
be delivered.
Requires Two previous readings so that the rate of change of sugar level can be computed.
Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin..
Post-condition r0 is replaced by r1 then r1 is replaced by r2
Side-effects None
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4747
Tabular specificationTabular specification
Used to supplement natural language.Used to supplement natural language.
Particularly useful when you have to define aParticularly useful when you have to define a
number of possible alternative courses of action.number of possible alternative courses of action.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4848
Tabular specificationTabular specification
Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of
increase decreasing ((r2-r1)<(r1-r0))
CompDose = 0
Sugar level increasing and rate of
increase stable or increasing. ((r2-r1)
(r1-r0))
CompDose = round ((r2-r1)/4)
If rounded result = 0 then
CompDose = MinimumDose
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4949
Graphical modelsGraphical models
Graphical models are most useful when youGraphical models are most useful when you
need to show how state changes or where youneed to show how state changes or where you
need to describe a sequence of actions.need to describe a sequence of actions.
Different graphical models are explained inDifferent graphical models are explained in
Chapter 8(Sommerville).Chapter 8(Sommerville).
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5050
Sequence diagramsSequence diagrams
These show the sequence of events that takeThese show the sequence of events that take
place during some user interaction with aplace during some user interaction with a
system.system.
You read them from top to bottom to see theYou read them from top to bottom to see the
order of the actions that take place.order of the actions that take place.
Cash withdrawal from an ATMCash withdrawal from an ATM
–– Validate card;Validate card;
–– Handle request;Handle request;
–– Complete transaction.Complete transaction.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5151
Sequence diagram of ATM withdrawalSequence diagram of ATM withdrawal
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5252
Interface specificationInterface specification
Most systems must operate with other systemsMost systems must operate with other systems
and the operating interfaces must be specifiedand the operating interfaces must be specified
as part of the requirements.as part of the requirements.
Three types of interface may have to be definedThree types of interface may have to be defined
–– Procedural interfaces;Procedural interfaces;
–– Data structures that are exchanged;Data structures that are exchanged;
–– Data representations.Data representations.
Formal notations are an effective technique forFormal notations are an effective technique for
interface specification.interface specification.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5353
PDL interface descriptionPDL interface description
interface PrintServer {
// defines an abstract printer server
// requires: interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter
void initialize ( Printer p ) ;
void print ( Printer p, PrintDoc d ) ;
void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;
} //PrintServer
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5454
The requirements documentThe requirements document
The requirements document is the officialThe requirements document is the official
statement of what is required of the systemstatement of what is required of the system
developers.developers.
Should include both a definition of userShould include both a definition of user
requirements and a specification of the systemrequirements and a specification of the system
requirements.requirements.
It is NOT a design document. As far as possible,It is NOT a design document. As far as possible,
it should set of WHAT the system should doit should set of WHAT the system should do
rather than HOW it should do itrather than HOW it should do it
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5555
Users of a requirements documentUsers of a requirements document
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5656
IEEE requirements standardIEEE requirements standard
Defines a generic structure for a requirementsDefines a generic structure for a requirements
document that must be instantiated for eachdocument that must be instantiated for each
specific system.specific system.
–– Introduction.Introduction.
–– General description.General description.
–– Specific requirements.Specific requirements.
–– Appendices.Appendices.
–– Index.Index.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5757
Requirements document structureRequirements document structure
PrefacePreface
IntroductionIntroduction
GlossaryGlossary
User requirements definitionUser requirements definition
System architectureSystem architecture
System requirements specificationSystem requirements specification
System modelsSystem models
System evolutionSystem evolution
AppendicesAppendices
IndexIndex
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5858
Key pointsKey points
Requirements set out what the system should do andRequirements set out what the system should do and
define constraints on its operation and implementation.define constraints on its operation and implementation.
Functional requirements set out services the systemFunctional requirements set out services the system
should provide.should provide.
NonNon--functional requirements constrain the systemfunctional requirements constrain the system
being developed or the development process.being developed or the development process.
User requirements are highUser requirements are high--level statements of whatlevel statements of what
the system should do. User requirements should bethe system should do. User requirements should be
written using natural language, tables and diagrams.written using natural language, tables and diagrams.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net
1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5959
Key pointsKey points
System requirements are intended toSystem requirements are intended to
communicate the functions that the systemcommunicate the functions that the system
should provide.should provide.
A software requirements document is anA software requirements document is an
agreed statement of the systemagreed statement of the system
requirements.requirements.
The IEEE standard is a useful starting pointThe IEEE standard is a useful starting point
for defining more detailed specificfor defining more detailed specific
requirements standards.requirements standards.
www.jntuworld.com
www.jntuworld.com
www.jwjobs.net

More Related Content

What's hot

Software Engineering unit 5
Software Engineering unit 5Software Engineering unit 5
Software Engineering unit 5Abhimanyu Mishra
 
Testing and Rolling Out Enterprise Applications
Testing and Rolling Out Enterprise ApplicationsTesting and Rolling Out Enterprise Applications
Testing and Rolling Out Enterprise ApplicationsGem WeBlog
 
Survey on Requirements Engineering Tools
Survey on Requirements Engineering Tools Survey on Requirements Engineering Tools
Survey on Requirements Engineering Tools jnicolasros
 
Software Engineering- Crisis and Process Models
Software Engineering- Crisis and Process ModelsSoftware Engineering- Crisis and Process Models
Software Engineering- Crisis and Process ModelsNishu Rastogi
 
Software Requirements in Software Engineering SE5
Software Requirements in Software Engineering SE5Software Requirements in Software Engineering SE5
Software Requirements in Software Engineering SE5koolkampus
 
Object oriented-systems-development-life-cycle ppt
Object oriented-systems-development-life-cycle pptObject oriented-systems-development-life-cycle ppt
Object oriented-systems-development-life-cycle pptKunal Kishor Nirala
 
Unit iii-Architecture in the lifecycle
Unit iii-Architecture in the lifecycleUnit iii-Architecture in the lifecycle
Unit iii-Architecture in the lifecycleDhivyaa C.R
 
Software Requirements Engineering Methodologies
Software Requirements Engineering MethodologiesSoftware Requirements Engineering Methodologies
Software Requirements Engineering MethodologiesKiran Munir
 
Unit iv -Documenting and Implementation of Software Architecture
Unit iv -Documenting and Implementation of Software ArchitectureUnit iv -Documenting and Implementation of Software Architecture
Unit iv -Documenting and Implementation of Software ArchitectureDhivyaa C.R
 
Software Requirement Specification
Software Requirement SpecificationSoftware Requirement Specification
Software Requirement SpecificationNiraj Kumar
 
software Engineering process
software Engineering processsoftware Engineering process
software Engineering processRaheel Aslam
 
System requirements engineering
System requirements engineeringSystem requirements engineering
System requirements engineeringAnimesh Chaturvedi
 
software engineering
software engineeringsoftware engineering
software engineeringSnow Queenzz
 
Requirements engineering process in software engineering
Requirements engineering process in software engineeringRequirements engineering process in software engineering
Requirements engineering process in software engineeringPreeti Mishra
 

What's hot (20)

Software Engineering unit 5
Software Engineering unit 5Software Engineering unit 5
Software Engineering unit 5
 
Testing and Rolling Out Enterprise Applications
Testing and Rolling Out Enterprise ApplicationsTesting and Rolling Out Enterprise Applications
Testing and Rolling Out Enterprise Applications
 
Survey on Requirements Engineering Tools
Survey on Requirements Engineering Tools Survey on Requirements Engineering Tools
Survey on Requirements Engineering Tools
 
Software Engineering- Crisis and Process Models
Software Engineering- Crisis and Process ModelsSoftware Engineering- Crisis and Process Models
Software Engineering- Crisis and Process Models
 
Session3
Session3Session3
Session3
 
Software Engineering
Software EngineeringSoftware Engineering
Software Engineering
 
4 sdlc and stlc
4 sdlc and stlc4 sdlc and stlc
4 sdlc and stlc
 
Software Requirements in Software Engineering SE5
Software Requirements in Software Engineering SE5Software Requirements in Software Engineering SE5
Software Requirements in Software Engineering SE5
 
Object oriented-systems-development-life-cycle ppt
Object oriented-systems-development-life-cycle pptObject oriented-systems-development-life-cycle ppt
Object oriented-systems-development-life-cycle ppt
 
Unit iii-Architecture in the lifecycle
Unit iii-Architecture in the lifecycleUnit iii-Architecture in the lifecycle
Unit iii-Architecture in the lifecycle
 
Sdpl1
Sdpl1Sdpl1
Sdpl1
 
Software Requirements Engineering Methodologies
Software Requirements Engineering MethodologiesSoftware Requirements Engineering Methodologies
Software Requirements Engineering Methodologies
 
Lecture 4
Lecture 4Lecture 4
Lecture 4
 
Unit iv -Documenting and Implementation of Software Architecture
Unit iv -Documenting and Implementation of Software ArchitectureUnit iv -Documenting and Implementation of Software Architecture
Unit iv -Documenting and Implementation of Software Architecture
 
Software Requirement Specification
Software Requirement SpecificationSoftware Requirement Specification
Software Requirement Specification
 
software Engineering process
software Engineering processsoftware Engineering process
software Engineering process
 
System requirements engineering
System requirements engineeringSystem requirements engineering
System requirements engineering
 
software engineering
software engineeringsoftware engineering
software engineering
 
Requirements engineering process in software engineering
Requirements engineering process in software engineeringRequirements engineering process in software engineering
Requirements engineering process in software engineering
 
Soa 1 7.ppsx
Soa 1 7.ppsxSoa 1 7.ppsx
Soa 1 7.ppsx
 

Similar to Unit 2 analysis and software requirements

Unit 3 requirements engineering processes
Unit 3 requirements engineering processesUnit 3 requirements engineering processes
Unit 3 requirements engineering processesAzhar Shaik
 
Unit 3 requirements engineering processes merged
Unit 3 requirements engineering processes mergedUnit 3 requirements engineering processes merged
Unit 3 requirements engineering processes mergedanuragmbst
 
Performance Requirements: the Backbone of the Performance Engineering Process
Performance Requirements: the Backbone of the Performance Engineering ProcessPerformance Requirements: the Backbone of the Performance Engineering Process
Performance Requirements: the Backbone of the Performance Engineering ProcessAlexander Podelko
 
INTRODUCTION to software engineering requirements specifications
INTRODUCTION to software engineering requirements specificationsINTRODUCTION to software engineering requirements specifications
INTRODUCTION to software engineering requirements specificationskylan2
 
Ch 2 types of reqirement
Ch 2  types of reqirementCh 2  types of reqirement
Ch 2 types of reqirementFish Abe
 
Requirements engineering
Requirements engineeringRequirements engineering
Requirements engineeringAyaz Shariff
 
Requirements engineering
Requirements engineeringRequirements engineering
Requirements engineeringAyaz Ahmed
 
Software requirement enginering
Software requirement engineringSoftware requirement enginering
Software requirement engineringWajid Ali
 
Software Requirements
Software RequirementsSoftware Requirements
Software RequirementsBala Ganesh
 
The software requirements specification
The software requirements specificationThe software requirements specification
The software requirements specificationeduardoestrada123
 
Requirement Analysis
Requirement AnalysisRequirement Analysis
Requirement Analysissslovepk
 
Requirements engineering
Requirements engineeringRequirements engineering
Requirements engineeringJennifer Polack
 
Ch 1-Introduction.ppt
Ch 1-Introduction.pptCh 1-Introduction.ppt
Ch 1-Introduction.pptbalewayalew
 
Requirement and Specification
Requirement and SpecificationRequirement and Specification
Requirement and Specificationsarojsaroza
 
Service Oriented Architecture
Service Oriented ArchitectureService Oriented Architecture
Service Oriented ArchitectureSandeep Ganji
 
CMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docx
CMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docxCMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docx
CMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docxmary772
 
SE_Module2.pdf
SE_Module2.pdfSE_Module2.pdf
SE_Module2.pdfADARSHN40
 
9 requirements engineering2
9 requirements engineering29 requirements engineering2
9 requirements engineering2Lilia Sfaxi
 
Software requirements specifications documents pdf
Software requirements specifications documents pdfSoftware requirements specifications documents pdf
Software requirements specifications documents pdfNothing807440
 

Similar to Unit 2 analysis and software requirements (20)

Unit 3 requirements engineering processes
Unit 3 requirements engineering processesUnit 3 requirements engineering processes
Unit 3 requirements engineering processes
 
Unit 3 requirements engineering processes merged
Unit 3 requirements engineering processes mergedUnit 3 requirements engineering processes merged
Unit 3 requirements engineering processes merged
 
Performance Requirements: the Backbone of the Performance Engineering Process
Performance Requirements: the Backbone of the Performance Engineering ProcessPerformance Requirements: the Backbone of the Performance Engineering Process
Performance Requirements: the Backbone of the Performance Engineering Process
 
INTRODUCTION to software engineering requirements specifications
INTRODUCTION to software engineering requirements specificationsINTRODUCTION to software engineering requirements specifications
INTRODUCTION to software engineering requirements specifications
 
Ch 2 types of reqirement
Ch 2  types of reqirementCh 2  types of reqirement
Ch 2 types of reqirement
 
Requirements engineering
Requirements engineeringRequirements engineering
Requirements engineering
 
Requirements engineering
Requirements engineeringRequirements engineering
Requirements engineering
 
Software requirement enginering
Software requirement engineringSoftware requirement enginering
Software requirement enginering
 
Software Requirements
Software RequirementsSoftware Requirements
Software Requirements
 
The software requirements specification
The software requirements specificationThe software requirements specification
The software requirements specification
 
Requirement Analysis
Requirement AnalysisRequirement Analysis
Requirement Analysis
 
Requirements engineering
Requirements engineeringRequirements engineering
Requirements engineering
 
Ch 1-Introduction.ppt
Ch 1-Introduction.pptCh 1-Introduction.ppt
Ch 1-Introduction.ppt
 
Requirement and Specification
Requirement and SpecificationRequirement and Specification
Requirement and Specification
 
Service Oriented Architecture
Service Oriented ArchitectureService Oriented Architecture
Service Oriented Architecture
 
Software engg unit 2
Software engg unit 2 Software engg unit 2
Software engg unit 2
 
CMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docx
CMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docxCMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docx
CMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docx
 
SE_Module2.pdf
SE_Module2.pdfSE_Module2.pdf
SE_Module2.pdf
 
9 requirements engineering2
9 requirements engineering29 requirements engineering2
9 requirements engineering2
 
Software requirements specifications documents pdf
Software requirements specifications documents pdfSoftware requirements specifications documents pdf
Software requirements specifications documents pdf
 

More from Azhar Shaik

Software engineering jwfiles 3
Software engineering jwfiles 3Software engineering jwfiles 3
Software engineering jwfiles 3Azhar Shaik
 
SOFTWARE ENGINEERING UNIT 6 Ch22
SOFTWARE ENGINEERING UNIT 6 Ch22SOFTWARE ENGINEERING UNIT 6 Ch22
SOFTWARE ENGINEERING UNIT 6 Ch22Azhar Shaik
 
SOFTWARE ENGINEERING UNIT 6 Ch14
SOFTWARE ENGINEERING UNIT 6 Ch14SOFTWARE ENGINEERING UNIT 6 Ch14
SOFTWARE ENGINEERING UNIT 6 Ch14Azhar Shaik
 
SOFTWARE ENGINEERING UNIT 6 Ch 13
SOFTWARE ENGINEERING UNIT 6 Ch 13SOFTWARE ENGINEERING UNIT 6 Ch 13
SOFTWARE ENGINEERING UNIT 6 Ch 13Azhar Shaik
 
Object oriented design-UNIT V
Object oriented design-UNIT VObject oriented design-UNIT V
Object oriented design-UNIT VAzhar Shaik
 
Performing user interface design v
Performing user interface design vPerforming user interface design v
Performing user interface design vAzhar Shaik
 
S.e material2 DESIGN ENGINEERING
S.e material2 DESIGN ENGINEERINGS.e material2 DESIGN ENGINEERING
S.e material2 DESIGN ENGINEERINGAzhar Shaik
 
Unit 3 system models
Unit 3 system modelsUnit 3 system models
Unit 3 system modelsAzhar Shaik
 

More from Azhar Shaik (14)

Software engineering jwfiles 3
Software engineering jwfiles 3Software engineering jwfiles 3
Software engineering jwfiles 3
 
Unit 7 risk
Unit 7 riskUnit 7 risk
Unit 7 risk
 
Unit 6
Unit 6Unit 6
Unit 6
 
SOFTWARE ENGINEERING UNIT 6 Ch22
SOFTWARE ENGINEERING UNIT 6 Ch22SOFTWARE ENGINEERING UNIT 6 Ch22
SOFTWARE ENGINEERING UNIT 6 Ch22
 
SOFTWARE ENGINEERING UNIT 6 Ch14
SOFTWARE ENGINEERING UNIT 6 Ch14SOFTWARE ENGINEERING UNIT 6 Ch14
SOFTWARE ENGINEERING UNIT 6 Ch14
 
SOFTWARE ENGINEERING UNIT 6 Ch 13
SOFTWARE ENGINEERING UNIT 6 Ch 13SOFTWARE ENGINEERING UNIT 6 Ch 13
SOFTWARE ENGINEERING UNIT 6 Ch 13
 
Object oriented design-UNIT V
Object oriented design-UNIT VObject oriented design-UNIT V
Object oriented design-UNIT V
 
Performing user interface design v
Performing user interface design vPerforming user interface design v
Performing user interface design v
 
S.e material2 DESIGN ENGINEERING
S.e material2 DESIGN ENGINEERINGS.e material2 DESIGN ENGINEERING
S.e material2 DESIGN ENGINEERING
 
Unit 4
Unit 4Unit 4
Unit 4
 
Unit 3 system models
Unit 3 system modelsUnit 3 system models
Unit 3 system models
 
Unit 2
Unit 2Unit 2
Unit 2
 
S.e material
S.e materialS.e material
S.e material
 
Unit 1 se
Unit 1 seUnit 1 se
Unit 1 se
 

Recently uploaded

Congestive Cardiac Failure..presentation
Congestive Cardiac Failure..presentationCongestive Cardiac Failure..presentation
Congestive Cardiac Failure..presentationdeepaannamalai16
 
4.16.24 21st Century Movements for Black Lives.pptx
4.16.24 21st Century Movements for Black Lives.pptx4.16.24 21st Century Movements for Black Lives.pptx
4.16.24 21st Century Movements for Black Lives.pptxmary850239
 
ROLES IN A STAGE PRODUCTION in arts.pptx
ROLES IN A STAGE PRODUCTION in arts.pptxROLES IN A STAGE PRODUCTION in arts.pptx
ROLES IN A STAGE PRODUCTION in arts.pptxVanesaIglesias10
 
Expanded definition: technical and operational
Expanded definition: technical and operationalExpanded definition: technical and operational
Expanded definition: technical and operationalssuser3e220a
 
DIFFERENT BASKETRY IN THE PHILIPPINES PPT.pptx
DIFFERENT BASKETRY IN THE PHILIPPINES PPT.pptxDIFFERENT BASKETRY IN THE PHILIPPINES PPT.pptx
DIFFERENT BASKETRY IN THE PHILIPPINES PPT.pptxMichelleTuguinay1
 
Decoding the Tweet _ Practical Criticism in the Age of Hashtag.pptx
Decoding the Tweet _ Practical Criticism in the Age of Hashtag.pptxDecoding the Tweet _ Practical Criticism in the Age of Hashtag.pptx
Decoding the Tweet _ Practical Criticism in the Age of Hashtag.pptxDhatriParmar
 
Concurrency Control in Database Management system
Concurrency Control in Database Management systemConcurrency Control in Database Management system
Concurrency Control in Database Management systemChristalin Nelson
 
Mental Health Awareness - a toolkit for supporting young minds
Mental Health Awareness - a toolkit for supporting young mindsMental Health Awareness - a toolkit for supporting young minds
Mental Health Awareness - a toolkit for supporting young mindsPooky Knightsmith
 
Q-Factor HISPOL Quiz-6th April 2024, Quiz Club NITW
Q-Factor HISPOL Quiz-6th April 2024, Quiz Club NITWQ-Factor HISPOL Quiz-6th April 2024, Quiz Club NITW
Q-Factor HISPOL Quiz-6th April 2024, Quiz Club NITWQuiz Club NITW
 
Transaction Management in Database Management System
Transaction Management in Database Management SystemTransaction Management in Database Management System
Transaction Management in Database Management SystemChristalin Nelson
 
Scientific Writing :Research Discourse
Scientific  Writing :Research  DiscourseScientific  Writing :Research  Discourse
Scientific Writing :Research DiscourseAnita GoswamiGiri
 
Measures of Position DECILES for ungrouped data
Measures of Position DECILES for ungrouped dataMeasures of Position DECILES for ungrouped data
Measures of Position DECILES for ungrouped dataBabyAnnMotar
 
Grade 9 Quarter 4 Dll Grade 9 Quarter 4 DLL.pdf
Grade 9 Quarter 4 Dll Grade 9 Quarter 4 DLL.pdfGrade 9 Quarter 4 Dll Grade 9 Quarter 4 DLL.pdf
Grade 9 Quarter 4 Dll Grade 9 Quarter 4 DLL.pdfJemuel Francisco
 
Grade Three -ELLNA-REVIEWER-ENGLISH.pptx
Grade Three -ELLNA-REVIEWER-ENGLISH.pptxGrade Three -ELLNA-REVIEWER-ENGLISH.pptx
Grade Three -ELLNA-REVIEWER-ENGLISH.pptxkarenfajardo43
 
Textual Evidence in Reading and Writing of SHS
Textual Evidence in Reading and Writing of SHSTextual Evidence in Reading and Writing of SHS
Textual Evidence in Reading and Writing of SHSMae Pangan
 
Q4-PPT-Music9_Lesson-1-Romantic-Opera.pptx
Q4-PPT-Music9_Lesson-1-Romantic-Opera.pptxQ4-PPT-Music9_Lesson-1-Romantic-Opera.pptx
Q4-PPT-Music9_Lesson-1-Romantic-Opera.pptxlancelewisportillo
 
Reading and Writing Skills 11 quarter 4 melc 1
Reading and Writing Skills 11 quarter 4 melc 1Reading and Writing Skills 11 quarter 4 melc 1
Reading and Writing Skills 11 quarter 4 melc 1GloryAnnCastre1
 

Recently uploaded (20)

Congestive Cardiac Failure..presentation
Congestive Cardiac Failure..presentationCongestive Cardiac Failure..presentation
Congestive Cardiac Failure..presentation
 
4.16.24 21st Century Movements for Black Lives.pptx
4.16.24 21st Century Movements for Black Lives.pptx4.16.24 21st Century Movements for Black Lives.pptx
4.16.24 21st Century Movements for Black Lives.pptx
 
ROLES IN A STAGE PRODUCTION in arts.pptx
ROLES IN A STAGE PRODUCTION in arts.pptxROLES IN A STAGE PRODUCTION in arts.pptx
ROLES IN A STAGE PRODUCTION in arts.pptx
 
Paradigm shift in nursing research by RS MEHTA
Paradigm shift in nursing research by RS MEHTAParadigm shift in nursing research by RS MEHTA
Paradigm shift in nursing research by RS MEHTA
 
Expanded definition: technical and operational
Expanded definition: technical and operationalExpanded definition: technical and operational
Expanded definition: technical and operational
 
DIFFERENT BASKETRY IN THE PHILIPPINES PPT.pptx
DIFFERENT BASKETRY IN THE PHILIPPINES PPT.pptxDIFFERENT BASKETRY IN THE PHILIPPINES PPT.pptx
DIFFERENT BASKETRY IN THE PHILIPPINES PPT.pptx
 
Decoding the Tweet _ Practical Criticism in the Age of Hashtag.pptx
Decoding the Tweet _ Practical Criticism in the Age of Hashtag.pptxDecoding the Tweet _ Practical Criticism in the Age of Hashtag.pptx
Decoding the Tweet _ Practical Criticism in the Age of Hashtag.pptx
 
Concurrency Control in Database Management system
Concurrency Control in Database Management systemConcurrency Control in Database Management system
Concurrency Control in Database Management system
 
Mental Health Awareness - a toolkit for supporting young minds
Mental Health Awareness - a toolkit for supporting young mindsMental Health Awareness - a toolkit for supporting young minds
Mental Health Awareness - a toolkit for supporting young minds
 
Q-Factor HISPOL Quiz-6th April 2024, Quiz Club NITW
Q-Factor HISPOL Quiz-6th April 2024, Quiz Club NITWQ-Factor HISPOL Quiz-6th April 2024, Quiz Club NITW
Q-Factor HISPOL Quiz-6th April 2024, Quiz Club NITW
 
Transaction Management in Database Management System
Transaction Management in Database Management SystemTransaction Management in Database Management System
Transaction Management in Database Management System
 
prashanth updated resume 2024 for Teaching Profession
prashanth updated resume 2024 for Teaching Professionprashanth updated resume 2024 for Teaching Profession
prashanth updated resume 2024 for Teaching Profession
 
Scientific Writing :Research Discourse
Scientific  Writing :Research  DiscourseScientific  Writing :Research  Discourse
Scientific Writing :Research Discourse
 
Measures of Position DECILES for ungrouped data
Measures of Position DECILES for ungrouped dataMeasures of Position DECILES for ungrouped data
Measures of Position DECILES for ungrouped data
 
Grade 9 Quarter 4 Dll Grade 9 Quarter 4 DLL.pdf
Grade 9 Quarter 4 Dll Grade 9 Quarter 4 DLL.pdfGrade 9 Quarter 4 Dll Grade 9 Quarter 4 DLL.pdf
Grade 9 Quarter 4 Dll Grade 9 Quarter 4 DLL.pdf
 
Grade Three -ELLNA-REVIEWER-ENGLISH.pptx
Grade Three -ELLNA-REVIEWER-ENGLISH.pptxGrade Three -ELLNA-REVIEWER-ENGLISH.pptx
Grade Three -ELLNA-REVIEWER-ENGLISH.pptx
 
INCLUSIVE EDUCATION PRACTICES FOR TEACHERS AND TRAINERS.pptx
INCLUSIVE EDUCATION PRACTICES FOR TEACHERS AND TRAINERS.pptxINCLUSIVE EDUCATION PRACTICES FOR TEACHERS AND TRAINERS.pptx
INCLUSIVE EDUCATION PRACTICES FOR TEACHERS AND TRAINERS.pptx
 
Textual Evidence in Reading and Writing of SHS
Textual Evidence in Reading and Writing of SHSTextual Evidence in Reading and Writing of SHS
Textual Evidence in Reading and Writing of SHS
 
Q4-PPT-Music9_Lesson-1-Romantic-Opera.pptx
Q4-PPT-Music9_Lesson-1-Romantic-Opera.pptxQ4-PPT-Music9_Lesson-1-Romantic-Opera.pptx
Q4-PPT-Music9_Lesson-1-Romantic-Opera.pptx
 
Reading and Writing Skills 11 quarter 4 melc 1
Reading and Writing Skills 11 quarter 4 melc 1Reading and Writing Skills 11 quarter 4 melc 1
Reading and Writing Skills 11 quarter 4 melc 1
 

Unit 2 analysis and software requirements

  • 1. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 11 AnalysisAnalysis andand Software RequirementsSoftware Requirements www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 2. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 22 ObjectivesObjectives To introduce the concepts of user and systemTo introduce the concepts of user and system requirementsrequirements To describe functional and nonTo describe functional and non--functionalfunctional requirementsrequirements To explain how software requirements may beTo explain how software requirements may be organised in a requirements documentorganised in a requirements document www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 3. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 33 Problem AnalysisProblem Analysis Structuring informationStructuring information Data flow diagram (DFD)Data flow diagram (DFD) Structured AnalysisStructured Analysis PrototypingPrototyping Other tools/methods for analysisOther tools/methods for analysis www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 4. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 44 Requirement SpecificationRequirement Specification Functional and nonFunctional and non--functionalfunctional PerformancePerformance Design constraints imposed on anDesign constraints imposed on an implementationimplementation External interfacesExternal interfaces Specification Making , becoming , Being specific a detailed of requirement Specify to mention particularly Require to ask Requirement a need, A thing needed. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 5. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 55 Software Requirement SpecificationSoftware Requirement Specification (SRS)(SRS) An SRS establishes the basis for agreementAn SRS establishes the basis for agreement between the client and the supplier on what thebetween the client and the supplier on what the software product will do.software product will do. As SRS provides a reference for validation ofAs SRS provides a reference for validation of the final product.the final product. A high quality SRS is a prerequisite to highA high quality SRS is a prerequisite to high quality software.quality software. A high quality SRS reduces the developmentA high quality SRS reduces the development costcost www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 6. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 66 Components of an SRSComponents of an SRS Performance Requirements Functional Requirements Design constrains External Interfaces Software Requirements specification Document www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 7. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 77 Format of SRSFormat of SRS Product overview and summary.Product overview and summary. Development, operating and maintenanceDevelopment, operating and maintenance environments.environments. External interfaces and data flowExternal interfaces and data flow Functional requirementsFunctional requirements Performance requirements.Performance requirements. Exception handing.Exception handing. Early subsets and implementation and priorities.Early subsets and implementation and priorities. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 8. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 88 Foreseeable modification and EnhancementsForeseeable modification and Enhancements Acceptance criteriaAcceptance criteria Design hints and guidelinesDesign hints and guidelines Cross reference indexCross reference index Glossary of teemsGlossary of teems www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 9. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 99 Characteristic of an SRSCharacteristic of an SRS UnderstandableUnderstandable UnambiguousUnambiguous CompleteComplete VerifiableVerifiable ConsistentConsistent ModifiableModifiable TraceableTraceable www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 10. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1010 ValidationValidation Requirement reviewsRequirement reviews Constructing methodsConstructing methods www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 11. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1111 Requirements engineeringRequirements engineering The process of establishing the services that theThe process of establishing the services that the customer requires from a system and thecustomer requires from a system and the constraints under which it operates and isconstraints under which it operates and is developed.developed. The requirements themselves are theThe requirements themselves are the descriptions of the system services anddescriptions of the system services and constraints that are generated during theconstraints that are generated during the requirements engineering process.requirements engineering process. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 12. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1212 What is a requirement?What is a requirement? It may range from a highIt may range from a high--level abstractlevel abstract statement of a service or of a system constraintstatement of a service or of a system constraint to a detailed mathematical functionalto a detailed mathematical functional specification.specification. This is inevitable as requirements may serve aThis is inevitable as requirements may serve a dual functiondual function –– May be the basis for a bid for a contractMay be the basis for a bid for a contract -- thereforetherefore must be open to interpretation;must be open to interpretation; –– May be the basis for the contract itselfMay be the basis for the contract itself -- thereforetherefore must be defined in detail;must be defined in detail; –– Both these statements may be called requirements.Both these statements may be called requirements. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 13. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1313 Requirements abstraction (Davis)Requirements abstraction (Davis) “If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisation’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both o f these documents may be called the requirements document for the system.” www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 14. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1414 Types of requirementTypes of requirement User requirementsUser requirements –– Statements in natural language plus diagrams of theStatements in natural language plus diagrams of the services the system provides and its operationalservices the system provides and its operational constraints. Written for customers.constraints. Written for customers. System requirementsSystem requirements –– A structured document setting out detailedA structured document setting out detailed descriptions of the systemdescriptions of the system’’s functions, services ands functions, services and operational constraints. Defines what should beoperational constraints. Defines what should be implemented so may be part of a contract betweenimplemented so may be part of a contract between client and contractor.client and contractor. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 15. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1515 Definitions and specificationsDefinitions and specifications www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 16. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1616 Requirements readersRequirements readers www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 17. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1717 Functional and nonFunctional and non--functional requirementsfunctional requirements Functional requirementsFunctional requirements –– Statements of services the system should provide, how theStatements of services the system should provide, how the system should react to particular inputs and how the systemsystem should react to particular inputs and how the system should behave in particular situations.should behave in particular situations. NonNon--functional requirementsfunctional requirements –– constraints on the services or functions offered by the systemconstraints on the services or functions offered by the system such as timing constraints, constraints on the developmentsuch as timing constraints, constraints on the development process, standards, etc.process, standards, etc. Domain requirementsDomain requirements –– Requirements that come from the application domain of theRequirements that come from the application domain of the system and that reflect characteristics of that domain.system and that reflect characteristics of that domain. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 18. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1818 Functional requirementsFunctional requirements Describe functionality or system services.Describe functionality or system services. Depend on the type of software, expected usersDepend on the type of software, expected users and the type of system where the software isand the type of system where the software is used.used. Functional user requirements may be highFunctional user requirements may be high--levellevel statements of what the system should do butstatements of what the system should do but functional system requirements should describefunctional system requirements should describe the system services in detail.the system services in detail. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 19. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 1919 Examples of functional requirementsExamples of functional requirements The user shall be able to search either all of theThe user shall be able to search either all of the initial set of databases or select a subset from it.initial set of databases or select a subset from it. The system shall provide appropriate viewersThe system shall provide appropriate viewers for the user to read documents in the documentfor the user to read documents in the document store.store. Every order shall be allocated a unique identifierEvery order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to(ORDER_ID) which the user shall be able to copy to the accountcopy to the account’’s permanent storage area.s permanent storage area. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 20. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2020 Requirements imprecisionRequirements imprecision Problems arise when requirements are notProblems arise when requirements are not precisely stated.precisely stated. Ambiguous requirements may be interpreted inAmbiguous requirements may be interpreted in different ways by developers and users.different ways by developers and users. Consider the termConsider the term ‘‘appropriate viewersappropriate viewers’’ –– User intentionUser intention -- special purpose viewer for eachspecial purpose viewer for each different document type;different document type; –– Developer interpretationDeveloper interpretation -- Provide a text viewer thatProvide a text viewer that shows the contents of the document.shows the contents of the document. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 21. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2121 Requirements completeness andRequirements completeness and consistencyconsistency In principle, requirements should be both complete andIn principle, requirements should be both complete and consistent.consistent. CompleteComplete –– They should include descriptions of all facilitiesThey should include descriptions of all facilities required.required. ConsistentConsistent –– There should be no conflicts or contradictions in theThere should be no conflicts or contradictions in the descriptions of the system facilities.descriptions of the system facilities. In practice, it is impossible to produce a complete andIn practice, it is impossible to produce a complete and consistent requirements document.consistent requirements document. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 22. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2222 NonNon--functional requirementsfunctional requirements These define system properties and constraintsThese define system properties and constraints e.g. reliability, response time and storagee.g. reliability, response time and storage requirements. Constraints are I/O devicerequirements. Constraints are I/O device capability, system representations, etc.capability, system representations, etc. Process requirements may also be specifiedProcess requirements may also be specified mandating a particular CASE system,mandating a particular CASE system, programming language or development method.programming language or development method. NonNon--functional requirements may be morefunctional requirements may be more critical than functional requirements. If these arecritical than functional requirements. If these are not met, the system is useless.not met, the system is useless. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 23. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2323 NonNon--functional classificationsfunctional classifications Product requirementsProduct requirements –– Requirements which specify that the delivered product mustRequirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability,behave in a particular way e.g. execution speed, reliability, etc.etc. Organisational requirementsOrganisational requirements –– Requirements which are a consequence of organisationalRequirements which are a consequence of organisational policies and procedures e.g. process standards used,policies and procedures e.g. process standards used, implementation requirements, etc.implementation requirements, etc. External requirementsExternal requirements –– Requirements which arise from factors which are external toRequirements which arise from factors which are external to the system and its development process e.g. interoperabilitythe system and its development process e.g. interoperability requirements, legislative requirements, etc.requirements, legislative requirements, etc. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 24. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2424 NonNon--functional requirement typesfunctional requirement types www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 25. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2525 NonNon--functional requirements examplesfunctional requirements examples Product requirementProduct requirement 8.18.1 The user interface for LIBSYS shall be implemented asThe user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets.simple HTML without frames or Java applets. Organisational requirementOrganisational requirement 9.3.2 The system development process and deliverable9.3.2 The system development process and deliverable documents shall conform to the process and deliverablesdocuments shall conform to the process and deliverables defined in XYZCodefined in XYZCo--SPSP--STANSTAN--95.95. External requirementExternal requirement 7.6.5 The system shall not disclose any personal information7.6.5 The system shall not disclose any personal information about customers apart from their name and referenceabout customers apart from their name and reference number to the operators of the system.number to the operators of the system. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 26. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2626 Goals and requirementsGoals and requirements NonNon--functional requirements may be very difficult tofunctional requirements may be very difficult to state precisely and imprecise requirements may bestate precisely and imprecise requirements may be difficult to verify.difficult to verify. GoalGoal –– A general intention of the user such as ease of use.A general intention of the user such as ease of use. Verifiable nonVerifiable non--functional requirementfunctional requirement –– A statement using some measure that can be objectivelyA statement using some measure that can be objectively tested.tested. Goals are helpful to developers as they convey theGoals are helpful to developers as they convey the intentions of the system users.intentions of the system users. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 27. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2727 ExamplesExamples A system goalA system goal –– The system should be easy to use by experienced controllersThe system should be easy to use by experienced controllers and should be organised in such a way that user errors areand should be organised in such a way that user errors are minimised.minimised. A verifiable nonA verifiable non--functional requirementfunctional requirement –– Experienced controllers shall be able to use all the systemExperienced controllers shall be able to use all the system functions after a total of two hours training. After this trainifunctions after a total of two hours training. After this training,ng, the average number of errors made by experienced usersthe average number of errors made by experienced users shall not exceed two per day.shall not exceed two per day. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 28. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2828 Requirements measuresRequirements measures Property Measure Speed Processed transactions/second User/Event response time Screen refresh time Size M Bytes Number of ROM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 29. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 2929 Requirements interactionRequirements interaction Conflicts between different nonConflicts between different non--functionalfunctional requirements are common in complex systems.requirements are common in complex systems. Spacecraft systemSpacecraft system –– To minimise weight, the number of separate chips inTo minimise weight, the number of separate chips in the system should be minimised.the system should be minimised. –– To minimise power consumption, lower power chipsTo minimise power consumption, lower power chips should be used.should be used. –– However, using low power chips may mean thatHowever, using low power chips may mean that more chips have to be used. Which is the mostmore chips have to be used. Which is the most critical requirement?critical requirement? www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 30. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3030 Domain requirementsDomain requirements Derived from the application domain andDerived from the application domain and describe system characteristics and featuresdescribe system characteristics and features that reflect the domain.that reflect the domain. Domain requirements be new functionalDomain requirements be new functional requirements, constraints on existingrequirements, constraints on existing requirements or define specific computations.requirements or define specific computations. If domain requirements are not satisfied, theIf domain requirements are not satisfied, the system may be unworkable.system may be unworkable. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 31. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3131 Library system domainLibrary system domain requirementsrequirements There shall be a standard user interface to allThere shall be a standard user interface to all databases which shall be based on the Z39.50databases which shall be based on the Z39.50 standard.standard. Because of copyright restrictions, someBecause of copyright restrictions, some documents must be deleted immediately ondocuments must be deleted immediately on arrival. Depending on the userarrival. Depending on the user’’s requirements,s requirements, these documents will either be printed locally onthese documents will either be printed locally on the system server for manually forwarding to thethe system server for manually forwarding to the user or routed to a network printer.user or routed to a network printer. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 32. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3232 Train protection systemTrain protection system The deceleration of the train shall beThe deceleration of the train shall be computed as:computed as: –– DDtraintrain == DDcontrolcontrol ++ DDgradientgradient wherewhere DDgradientgradient is 9.81msis 9.81ms22 * compensated* compensated gradient/alpha and where the values ofgradient/alpha and where the values of 9.81ms9.81ms22 /alpha are known for different types/alpha are known for different types of train.of train. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 33. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3333 Domain requirements problemsDomain requirements problems UnderstandabilityUnderstandability –– Requirements are expressed in the language of theRequirements are expressed in the language of the application domain;application domain; –– This is often not understood by software engineersThis is often not understood by software engineers developing the system.developing the system. ImplicitnessImplicitness –– Domain specialists understand the area so well thatDomain specialists understand the area so well that they do not think of making the domain requirementsthey do not think of making the domain requirements explicit.explicit. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 34. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3434 User requirementsUser requirements Should describe functional and nonShould describe functional and non--functionalfunctional requirements in such a way that they arerequirements in such a way that they are understandable by system users who donunderstandable by system users who don’’t havet have detailed technical knowledge.detailed technical knowledge. User requirements are defined using naturalUser requirements are defined using natural language, tables and diagrams as these can belanguage, tables and diagrams as these can be understood by all users.understood by all users. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 35. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3535 Problems with natural languageProblems with natural language Lack of clarityLack of clarity –– Precision is difficult without making the documentPrecision is difficult without making the document difficult to read.difficult to read. Requirements confusionRequirements confusion –– Functional and nonFunctional and non--functional requirements tend tofunctional requirements tend to be mixedbe mixed--up.up. Requirements amalgamationRequirements amalgamation –– Several different requirements may be expressedSeveral different requirements may be expressed together.together. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 36. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3636 Editor grid requirementEditor grid requirement 2.6 Grid facilities To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an option on the control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 37. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3737 Requirement problemsRequirement problems Database requirements includes both conceptual andDatabase requirements includes both conceptual and detailed informationdetailed information –– Describes the concept of a financial accounting system that isDescribes the concept of a financial accounting system that is to be included in LIBSYS;to be included in LIBSYS; –– However, it also includes the detail that managers canHowever, it also includes the detail that managers can configure this systemconfigure this system -- this is unnecessary at this level.this is unnecessary at this level. Grid requirement mixes three different kinds ofGrid requirement mixes three different kinds of requirementrequirement –– Conceptual functional requirement (the need for a grid);Conceptual functional requirement (the need for a grid); –– NonNon--functional requirement (grid units);functional requirement (grid units); –– NonNon--functional UI requirement (grid switching).functional UI requirement (grid switching). www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 38. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3838 Structured presentationStructured presentation 2.6.1 Grid facilities The editor shall provide a grid facility where a m atrix of horizontal and vertical lines provide a background to the editor window. This grid shall be a passive grid where the alignment of entities is the user's responsibility. Rationale: A grid helps the user to create a tidy diagram with well-spaced entities. Although an active grid, where entities 'snap-to' grid lines can be useful, the positioning is imprecise. The user is the best person to decide where entities should be positioned. Specification: ECLIPSE/WS/Tools/DE/FS Section 5.6 Source: Ray Wilson, Glasgow Office www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 39. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 3939 Guidelines for writing requirementsGuidelines for writing requirements Invent a standard format and use it for allInvent a standard format and use it for all requirements.requirements. Use language in a consistent way. Use shall forUse language in a consistent way. Use shall for mandatory requirements, should for desirablemandatory requirements, should for desirable requirements.requirements. Use text highlighting to identify key parts of theUse text highlighting to identify key parts of the requirement.requirement. Avoid the use of computer jargon.Avoid the use of computer jargon. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 40. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4040 System requirementsSystem requirements More detailed specifications of system functions,More detailed specifications of system functions, services and constraints than userservices and constraints than user requirements.requirements. They are intended to be a basis for designingThey are intended to be a basis for designing the system.the system. They may be incorporated into the systemThey may be incorporated into the system contract.contract. System requirements may be defined orSystem requirements may be defined or illustrated using system models discussed inillustrated using system models discussed in Chapter 8.Chapter 8. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 41. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4141 Requirements and designRequirements and design In principle, requirements should state what theIn principle, requirements should state what the system should do and the design shouldsystem should do and the design should describe how it does this.describe how it does this. In practice, requirements and design areIn practice, requirements and design are inseparableinseparable –– A system architecture may be designed to structureA system architecture may be designed to structure the requirements;the requirements; –– The system may interThe system may inter--operate with other systemsoperate with other systems that generate design requirements;that generate design requirements; –– The use of a specific design may be a domainThe use of a specific design may be a domain requirement.requirement. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 42. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4242 Problems with NL specificationProblems with NL specification AmbiguityAmbiguity –– The readers and writers of the requirement mustThe readers and writers of the requirement must interpret the same words in the same way. NL isinterpret the same words in the same way. NL is naturally ambiguous so this is very difficult.naturally ambiguous so this is very difficult. OverOver--flexibilityflexibility –– The same thing may be said in a number of differentThe same thing may be said in a number of different ways in the specification.ways in the specification. Lack of modularisationLack of modularisation –– NL structures are inadequate to structure systemNL structures are inadequate to structure system requirements.requirements. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 43. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4343 Alternatives to NL specificationAlternatives to NL specification Notation Description Structured natural language This approach depends on defining standard forms or templates to express the requirements specification. Design description languages This approach uses a language like a programming language but with more abstract features to specify the requirements by defining an operational model of the system. This approach is not now widely used although it can be useful for interface specifications. Graphical notations A graphical language, supplemented by text annotations is used to define the functional requirements for the system. An early example of such a graphical language was SADT. Now, use-case descriptions and sequence d iagrams are commonly used . Mathematical specifications These are notations based on mathematical concepts such as finite-state machines or sets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality. However, most customers don’t understand formal specifications and are reluctant to accept it as a system contract. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 44. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4444 Structured language specificationsStructured language specifications The freedom of the requirements writer is limitedThe freedom of the requirements writer is limited by a predefined template for requirements.by a predefined template for requirements. All requirements are written in a standard way.All requirements are written in a standard way. The terminology used in the description may beThe terminology used in the description may be limited.limited. The advantage is that the most of theThe advantage is that the most of the expressiveness of natural language isexpressiveness of natural language is maintained but a degree of uniformity ismaintained but a degree of uniformity is imposed on the specification.imposed on the specification. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 45. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4545 FormForm--based specificationsbased specifications Definition of the function or entity.Definition of the function or entity. Description of inputs and where they come from.Description of inputs and where they come from. Description of outputs and where they go to.Description of outputs and where they go to. Indication of other entities required.Indication of other entities required. Pre and post conditions (if appropriate).Pre and post conditions (if appropriate). The side effects (if any) of the function.The side effects (if any) of the function. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 46. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4646 FormForm--based node specificationbased node specification Insulin Pump/Control Software/SRS/3.3.2 Function Compute insulin dose: Safe sugar level Description Computes the dose of insulin to be delivered when the current measured sugar level is in the safe zone between 3 and 7 units. Inputs Current sugar reading (r2), the previous two readings (r0 and r1) Source Current sugar reading from sensor. Other readings from memory. Outputs CompDose Š the dose in insulin to be delivered Destination Main control loop Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is computed by dividing the difference between the current sugar level and the previous level by 4 and rounding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that can be delivered. Requires Two previous readings so that the rate of change of sugar level can be computed. Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin.. Post-condition r0 is replaced by r1 then r1 is replaced by r2 Side-effects None www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 47. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4747 Tabular specificationTabular specification Used to supplement natural language.Used to supplement natural language. Particularly useful when you have to define aParticularly useful when you have to define a number of possible alternative courses of action.number of possible alternative courses of action. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 48. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4848 Tabular specificationTabular specification Condition Action Sugar level falling (r2 < r1) CompDose = 0 Sugar level stable (r2 = r1) CompDose = 0 Sugar level increasing and rate of increase decreasing ((r2-r1)<(r1-r0)) CompDose = 0 Sugar level increasing and rate of increase stable or increasing. ((r2-r1) (r1-r0)) CompDose = round ((r2-r1)/4) If rounded result = 0 then CompDose = MinimumDose www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 49. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 4949 Graphical modelsGraphical models Graphical models are most useful when youGraphical models are most useful when you need to show how state changes or where youneed to show how state changes or where you need to describe a sequence of actions.need to describe a sequence of actions. Different graphical models are explained inDifferent graphical models are explained in Chapter 8(Sommerville).Chapter 8(Sommerville). www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 50. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5050 Sequence diagramsSequence diagrams These show the sequence of events that takeThese show the sequence of events that take place during some user interaction with aplace during some user interaction with a system.system. You read them from top to bottom to see theYou read them from top to bottom to see the order of the actions that take place.order of the actions that take place. Cash withdrawal from an ATMCash withdrawal from an ATM –– Validate card;Validate card; –– Handle request;Handle request; –– Complete transaction.Complete transaction. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 51. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5151 Sequence diagram of ATM withdrawalSequence diagram of ATM withdrawal www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 52. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5252 Interface specificationInterface specification Most systems must operate with other systemsMost systems must operate with other systems and the operating interfaces must be specifiedand the operating interfaces must be specified as part of the requirements.as part of the requirements. Three types of interface may have to be definedThree types of interface may have to be defined –– Procedural interfaces;Procedural interfaces; –– Data structures that are exchanged;Data structures that are exchanged; –– Data representations.Data representations. Formal notations are an effective technique forFormal notations are an effective technique for interface specification.interface specification. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 53. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5353 PDL interface descriptionPDL interface description interface PrintServer { // defines an abstract printer server // requires: interface Printer, interface PrintDoc // provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter void initialize ( Printer p ) ; void print ( Printer p, PrintDoc d ) ; void displayPrintQueue ( Printer p ) ; void cancelPrintJob (Printer p, PrintDoc d) ; void switchPrinter (Printer p1, Printer p2, PrintDoc d) ; } //PrintServer www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 54. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5454 The requirements documentThe requirements document The requirements document is the officialThe requirements document is the official statement of what is required of the systemstatement of what is required of the system developers.developers. Should include both a definition of userShould include both a definition of user requirements and a specification of the systemrequirements and a specification of the system requirements.requirements. It is NOT a design document. As far as possible,It is NOT a design document. As far as possible, it should set of WHAT the system should doit should set of WHAT the system should do rather than HOW it should do itrather than HOW it should do it www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 55. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5555 Users of a requirements documentUsers of a requirements document www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 56. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5656 IEEE requirements standardIEEE requirements standard Defines a generic structure for a requirementsDefines a generic structure for a requirements document that must be instantiated for eachdocument that must be instantiated for each specific system.specific system. –– Introduction.Introduction. –– General description.General description. –– Specific requirements.Specific requirements. –– Appendices.Appendices. –– Index.Index. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 57. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5757 Requirements document structureRequirements document structure PrefacePreface IntroductionIntroduction GlossaryGlossary User requirements definitionUser requirements definition System architectureSystem architecture System requirements specificationSystem requirements specification System modelsSystem models System evolutionSystem evolution AppendicesAppendices IndexIndex www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 58. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5858 Key pointsKey points Requirements set out what the system should do andRequirements set out what the system should do and define constraints on its operation and implementation.define constraints on its operation and implementation. Functional requirements set out services the systemFunctional requirements set out services the system should provide.should provide. NonNon--functional requirements constrain the systemfunctional requirements constrain the system being developed or the development process.being developed or the development process. User requirements are highUser requirements are high--level statements of whatlevel statements of what the system should do. User requirements should bethe system should do. User requirements should be written using natural language, tables and diagrams.written using natural language, tables and diagrams. www.jntuworld.com www.jntuworld.com www.jwjobs.net
  • 59. 1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 5959 Key pointsKey points System requirements are intended toSystem requirements are intended to communicate the functions that the systemcommunicate the functions that the system should provide.should provide. A software requirements document is anA software requirements document is an agreed statement of the systemagreed statement of the system requirements.requirements. The IEEE standard is a useful starting pointThe IEEE standard is a useful starting point for defining more detailed specificfor defining more detailed specific requirements standards.requirements standards. www.jntuworld.com www.jntuworld.com www.jwjobs.net