SlideShare a Scribd company logo
1 of 79
Download to read offline
Unit-3
Software Requirementsq
Topics covered
fFunctional and non-functional requirements
User requirementsq
System requirements
Interface specification
The software requirements documentThe software requirements document
Requirements engineering
The process of establishing the servicesservices that the
customer requires from a system and thecustomer requires from a system and the
constraintsconstraints under which it operates and is
developed.
Understanding the Importance of Requirements
Requirements imprecision
P bl i h i t tt i li l t t dt t dProblems arise when requirements areare notnot preciselyprecisely statedstated..
AmbiguousAmbiguous requirementsrequirements may be interpreted in different
ways by developers and usersusers.
Consider the term ‘appropriate‘appropriate viewers’viewers’
• User intention - special purpose viewer for each different
document type;document type;
• Developer interpretation - Provide a text viewer that
h th t t f th d tshows the contents of the document.
Requirements completeness and consistency
I i i l i t h ld b b th l t dIn principle, requirements should be both complete and
consistent.
Complete
• They should include descriptions of all facilities required.
Consistent
• There should be no conflicts or contradictions in the• There should be no conflicts or contradictions in the
descriptions of the system facilities.
Classification of RequirementsClassification of Requirements
Functional and non-functional requirements
Functional requirementsq
• Statements of servicesservices the system should provide, how the
system should react to particularparticular inputsinputs and how thesystem should react to particularparticular inputsinputs and how the
system should behavebehave in particular situations.
Non functional requirements( f )Non-functional requirements(performance)
• constraints on the services or functions offered by the system
such as timingtiming constraintsconstraints, constraints on the
developmentdevelopment processprocess,, standardsstandards, etc.
Functional requirements
D ib f ti lit t iDescribe functionality or system services.
Depend on the typetype ofof softwaresoftware, expected users and the
type of system where the software is used.
The LIBSYS system
A lib t th t id i l i t f t b fA library system that provides a single interface to a number of
databases of articlesarticles inin differentdifferent librarieslibraries..
Users can search for, download and print these articles for
personal study.
Examples of functional requirements
The user shall be able to search either all of the initialinitial setset of
databases or select a subsetsubset from it.
The system shall provide appropriateappropriate viewersviewers for the user to read
documents in the document store.
Every order shall be allocated a uniqueunique identifieridentifier (ORDER_ID)
which the user shall be able to copy to the account’s permanentwhich the user shall be able to copy to the account s permanent
storage area.
Non-functional requirements
Th d fi t ti d t i t li bilitli bilitThese define system properties and constraints e.g. reliabilityreliability,
responseresponse timetime and storagestorage requirementsrequirements. Constraints are I/O
device capability, system representations, etc.
Process requirements may also be specified mandating a
particular CASE system, programming language or
development method.
Non-functional requirements may be moremore criticalcritical than
functional requirements If these are not met the system isfunctional requirements. If these are not met, the system is
useless.
Non-functional classifications
Product requirementsq
• Requirements which specify that the delivereddelivered productproduct must
behave in a particular way e.g. execution speed, reliability, etc.p y g p , y,
Organisational requirements
• Requirements which are a consequence of organisationalorganisational• Requirements which are a consequence of organisationalorganisational
policiespolicies and procedures e.g. process standards used,
implementation requirements etcimplementation requirements, etc.
External requirements
• Requirements which arise fromfrom factorsfactors which are external to
the system and its development process e.g. interoperability
i t l i l ti i t trequirements, legislative requirements, etc.
Non-functional requirement types
Requirements measures
Property Measure
Speed Processed transactions/second
User/Event response timeUser/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 Timeto restart after failureRobustness Timeto restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
Domain requirements
D i d f th li ti d i d d ib tDerived from the application domain and describe system
characteristics and features that reflect the domain.
Domain requirements be new functional requirements, constraints
on existing requirements or define specific computations.
If domain requirements are not satisfied, the system may be
unworkable.
LIBSYS requirement
LIBSYS shall provide a financial accounting system that
maintains records of all payments made by users of the system.
System managers may configure this system so that regular users
may receive discounted rates.y
Requirement problems
D t b i t i l d b th t l d d t il dDatabase requirements includes both conceptual and detailed
information
• Describes the concept of a financial accounting system
that is to be included in LIBSYS;
Domain requirements problems
U d t d bilitUnderstand ability
• Requirements are expressed in the language of the
application domain;
• This is often not understood by software engineers
developing the system.
Implicitness
• Domain specialists understand the area so well that they do
not think of making the domain requirements explicit.g q p
User requirements
Sh ld d ib f ti lf ti l d f ti lf ti l i t iShould describe functionalfunctional and nonnon--functionalfunctional requirements in
such a way that they are understandable by system users who
d ’t h d t il d t h i l k l ddon’t have detailed technical knowledge.
User requirements are defined using natural languagenatural language,, tablestables
and diagramsdiagrams as these can be understood by all users.
Problems with natural language
L k f l itLack of clarity
• Precision is difficult without making the document difficult to
read.
Requirements confusion
• Functional and non-functional requirements tend to be
mixed-up.
Requirements amalgamation
• Several different requirements may be expressed together.Several different requirements may be expressed together.
Problems with NL specification
A bi itAmbiguity
• The readers and writers of the requirement must interpret the
same words in the same way. NL is naturally ambiguous so
this is very difficult.
Over-flexibility
• The same thing may be said in a number of different ways in
the specification.
Guidelines for writing requirements
Invent a standard format and use it for all requirements.
Use language in a consistent wayUse language in a consistent way.
Use text highlighting to identify key parts of the requirement.
A id th f t jAvoid the use of computer jargon.
Alternatives to NL specification
N t ti D i tiNotation Description
Structured
natural language
This approach depends on defining standard forms or templates to express the
requirements specification.g g q p
Design
description
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
languages 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 SADTnotations requirements for the system. An early example of such a graphical language was SADT.
Now, use-case descriptions and sequence diagrams are commonly used .
Mathematical These are notations based on mathematical concepts such as finite-state machines or
specifications 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.p p y
Structured language specifications
Th f d f th i t it i li it d b d fi dThe freedom of the requirements writer is limited by a predefined
templatetemplate for requirements.
All requirements are written in a standardstandard wayway.
The terminology used in the description may be limited.
The advantage is that the most of the expressiveness of natural
language is maintained but a degreedegree ofof uniformityuniformity is imposed on
the specification.
Form-based specifications
D fi iti f th f ti titDefinition of the function or entity.
Description of inputs and where they come from.
Description of outputs and where they go to.
Indication of other entities required.
Pre and post conditions (if appropriate).
The side effects (if any) of the function.The side effects (if any) of the function.
Form-based 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
t f i i d i If th l l i i i d th t f i i i i th C D irate 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 computedRequires 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 NoneSide effects None
Tabular specification
Used to supplement natural languageUsed to supplement natural language.
Particularly useful when you have to define a number of possible
alternative courses of action.
Condition Action
Sugar level falling (r2 < r1) CompDose = 0Sugar level falling (r2 < r1) CompDose 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of CompDose = 0g g
increase decreasing ((r2-r1)<(r1-r0))
p
Sugar level increasing and rate of
increase stable or increasing. ((r2-r1)
CompDose = round ((r2-r1)/4)
If rounded result = 0 thenincrease stable or increasing. ((r2 r1)
(r1-r0))
If rounded result 0 then
CompDose = MinimumDose
Graphical models
G hi l d l t f l h d t h hGraphical models are most useful when you need to show how
state changes or where you need to describe a sequence ofsequence of
titiactions.actions.
Sequence diagrams
Th h th f t th t t k l d iThese show the sequence of events that take place during some
user interaction with a system.
You read them from top to bottom to see the order of the actions
that take place.
Cash withdrawal from an ATM
• Validate card;
• Handle request;
• Complete transaction.Complete transaction.
Sequence diagram of ATM withdrawal
Interface specification
M t t t t ith tht ith th t d th tiMost systems must operate with otheroperate with other systems and the operating
interfaces must be specified as part of the requirements.
Three types of interfaceThree types of interface may have to be defined
• Procedural interfaces;
• Data structures that are exchanged;
• Data representations.p
Formal notationsFormal notations are an effective technique for interface
specification.specification.
The requirements document
Th i t d ti t d t i th ffi i l t t t f h t iThe requirements documentrequirements document is the official statement of what is
required of the system developers.
Should include both a definition of user requirements and a
specification of the system requirements.
It is NOT a design document. As far as possible, it should set of
WHATWHAT the system should do rather than HOWHOW it should do it
Users of a requirements document
IEEE requirements standard
D fi i t t f i t d t th t tDefines a generic structure for a requirements document that must
be instantiated for each specific system.
• Introduction.
• General description.
• Specific requirements.
• Appendices.pp
• Index.
Requirements document structure
P fPreface
Introduction
Glossary
User requirements definition
System architectureSystem architecture
System requirements specification
System models
System evolutionSystem evolution
Appendices
RequirementsRequirementsRequirementsRequirements
EngineeringEngineering ProcessesProcessesEngineeringEngineering ProcessesProcesses
Topics covered
Feasibility studies
Requirements elicitation and analysisq y
Requirements validation
Requirements management
Requirements Engineering Processes
Th d f RE id l d di thThe processes used for RE vary widely depending on the
application domain, the people involved and the organisation
developing the requirements.
However, there are a number of generic activities common to
all processes
• Requirements elicitation;q ;
• Feasibility study;
R i t l i• Requirements analysis;
• Requirements validation;
• Requirements management.
The requirements engineering process
Feasibility studies
A f ibilit t d d id h th t th d tA feasibility study decides whether or not the proposed system
is worthwhileworthwhile..
Feasibility study implementation
B d i f ti t ( h t i i d)Based on information assessment (what is required),
information collection and report writing.
Questions for people in the organisation
• What if the system wasn’t implemented?
• What are current process problems?
• How will the proposed system help?• How will the proposed system help?
• What will be the integration problems?
• Is new technology needed? What skills?
• What facilities must be supported by the proposed
system?
Elicitation and analysis
S ti ll d i t li it ti i ti tSometimes called requirements elicitation or requirementsrequirements
discoverydiscovery..
Involves technical staff working with customers to find out about
the application domain, the services that the system should
provide and the system’s operational constraints.
May involve end-users, managers, engineers involved iny , g , g
maintenance, domain experts, trade unions, etc. These are
called stakeholdersstakeholders..called stakeholdersstakeholders..
Problems of requirements analysis
Stakeholders don’t know what they really want.
Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting requirements.
Organisational and political factors may influence the systemOrganisational and political factors may influence the system
requirements.
The requirements change during the analysis process. New
stakeholders may emerge and the business environment
change.
Process activities
Requirements discoveryq y
• Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.Domain requirements are also discovered at this stage.
Requirements classification and organisation
• Groups related requirements and organises them into coherent• Groups related requirements and organises them into coherent
clusters.
Prioritisation and negotiationPrioritisation and negotiation
• Prioritising requirements and resolving requirements conflicts.
Requirements documentation
• Requirements are documented and input into the next round of
the spiral.
The requirements spiral
ATM stakeholders
B k tBank customers
Representatives of other banks
Bank managers
Counter staff
Database administrators
S itSecurity managers
Marketing department
Hardware and software maintenance engineers
Banking regulatorsg g
Viewpoints
Vi i t f t t it t i th i t t tViewpoints are a way of structuringstructuring the requirements to represent
the perspectivesperspectives of different stakeholders.
Stakeholders may be classified under different viewpoints.
This multi-perspective analysis is important as there is no single
correct way to analyse system requirements.
Types of viewpoint
InteractorInteractor viewpointsviewpointsInteractorInteractor viewpointsviewpoints
• People or other systems that interact directly with the system. In
an ATM the customer’s and the account database arean ATM, the customer s and the account database are
interactor VPs.
IndirectIndirect viewpointsviewpointsIndirectIndirect viewpointsviewpoints
• Stakeholders who do not use the system themselves but who
influence the requirements In an ATM management andinfluence the requirements. In an ATM, management and
security staff are indirect viewpoints.
DomainDomain viewpointsviewpointsDomainDomain viewpointsviewpoints
• Domain characteristics and constraints that influence the
requirements In an ATM an example would be standards forrequirements. In an ATM, an example would be standards for
inter-bank communications.
Viewpoint identification
Id tif i i t iIdentify viewpoints using
• Providers and receivers of system services;
• Systems that interact directly with the system being
specified;
• Regulations and standards;
• Sources of business and non-functional requirements.q
• Engineers who have to develop and maintain the system;
• Marketing and other business viewpoints• Marketing and other business viewpoints.
LIBSYS viewpoint hierarchy
All VPs
InteractorIndirect Domain
Article
providers
FinanceLibrary
manager
Library
staff
Users
Classification
system
UI
standards
ExternalStaffStudents Cataloguers
System
managers
Interviewing
I f l i f l i t i i th RE t t titiIn formal or informal interviewing, the RE team puts questionsquestions
to stakeholders about the system that they use and the system to
b d l dbe developed.
There are two types of interview
•• ClosedClosed interviewsinterviews where a pre-defined set of questions are
answered.
•• OpenOpen interviewsinterviews where there is no pre-defined agenda and
a range of issues are explored with stakeholders.
Scenarios
S i l lif l f h t b dScenarios are real-life examples of how a system can be used.
They should include
• A description of the startingstarting situationsituation;
• A description of the normalnormal flowflow ofof eventsevents;
• A description of whatwhat cancan gogo wrongwrong;
• Information about other concurrentconcurrent activitiesactivities;Information about other concurrentconcurrent activitiesactivities;
• A description of the statestate whenwhen thethe scenarioscenario finishesfinishes.
LIBSYS scenario (1)
InitialInitial assumptionassumption: The user has loggedlogged on to the LIBSYS system and has located
the journaljournal containing the copy of the article.
NormalNormal:: The user selects the article to be copied He or she is then prompted by theNormalNormal:: The user selects the article to be copied. He or she is then prompted by the
system to either provide subscribersubscriber informationinformation for the journal or to indicate how
they will pay for the article. Alternative payment methods are by credit card or byy p y p y y y
quoting an organisational account number.
The user is then asked to fill in a copyright form that maintains details of the
transaction and they then submit this to the LIBSYS system.
The copyright form is checked and, if OK, the PDF version of the article is
downloaded to the LIBSYS working area on the user’s computer and the user isdownloaded to the LIBSYS working area on the user s computer and the user is
informed that it is available. The user is asked to select a printer and a copy of the
article is printed. If the article has been flagged as ‘print-only’ it is deleted from the
user’s system once the user has confirmed that printing is complete.
LIBSYS scenario (2)
WhatWhat cancan gogo wrongwrong: The user may fail to fill in the copyrightcopyright formform correctlycorrectly In thisWhatWhat cancan gogo wrongwrong: The user may fail to fill in the copyrightcopyright formform correctlycorrectly. In this
case, the form should be re-presented to the user for correction. If the resubmitted
form is still incorrect then the user’s request for the article is rejected.
The payment may be rejected by the system. The user’s request for the article is
rejected.
The article download may fail. Retry until successful or the user terminates the
session.
It may not be possible to print the article If the article is not flagged as ‘print-only’ thenIt may not be possible to print the article. If the article is not flagged as print-only then
it is held in the LIBSYS workspace. Otherwise, the article is deleted and the user’s
account credited with the cost of the article.
OtherOther activitiesactivities: Simultaneous downloads of other articles.
SystemSystem statestate onon completioncompletion:: User is logged on. The downloaded article has
been deleted from LIBSYS workspace if it has been flagged as print-only.
Use cases
U i b d t h i i th UML hi hUse-cases are a scenario based technique in the UML which
identify the actorsactors in an interaction and which describe the
interaction itself.
A set of use cases should describe all possible interactions
with the system.
SequenceSequence diagramsdiagrams may be used to add detail to use-cases byqq gg y y
showing the sequence of event processing in the system.
Article printing use-case
LIBSYS use cases
Print article sequence
User
item:
Article
copyrightForm:
Form
myWorkspace:
W orkspace
myPrinter:
Printe r
request
complete
request
returnreturn
copyright OK
deliver
article OK
print send
confirminform
delete
Ethnography-Observational technique
A i l i ti t d id bl ti b ib i ddA social scientists spends a considerable time observingobserving andand
analysinganalysing how people actually work.
People do not have to explain or articulate their work.
Social and organisational factors of importance may be
observed.
Ethnographic studies have shown that work is usually richerEthnographic studies have shown that work is usually richer
and more complex than suggested by simple system models.
Focused ethnography
D l d i j t t d i th i t ffi t lDeveloped in a project studying the air traffic control process
Combines ethnography with prototyping
Prototype development results in unanswered questions which
focus the ethnographic analysis.
The problem with ethnography is that it studies existing practices
which may have some historical basis which is no longer relevant.
Ethnography and prototyping
Ethno g raphic
anal ysis
De briefing
meetings
Focused
ethno g raph yanal ysis meetings ethno g raph y
Prototype
evaluation
Generic system
de velopment
System
proto yping
Scope of ethnography
R i t th t d i d f th th t l t llRequirements that are derived from the way that people actually
work rather than the way which process definitions suggest that
th ht t kthey ought to work.
Requirements that are derived from cooperation and awareness of
other people’s activities.
Requirements validation
C d ith d t ti th t th i t d fi thConcerned with demonstrating that the requirements define the
system that the customercustomer reallyreally wantswants..
Requirements error costs are high so validation is very important
• Fixing a requirements error after delivery may cost up to 100
times the cost of fixing an implementation error.
Requirements checking
V liditV lidit D th t id th f ti hi h b tValidityValidity.. Does the system provide the functions which best
support the customer’s needs?
ConsistencyConsistency.. Are there any requirements conflicts?
CompletenessCompleteness. Are all functions required by the customer
included?
RealismRealism Can the requirements be implemented given availableRealismRealism. Can the requirements be implemented given available
budget and technology
V ifi bilitV ifi bilit C th i t b h k d?VerifiabilityVerifiability. Can the requirements be checked?
Requirements validation techniques
Requirements reviewsRequirements reviews
• Systematic manual analysis of the requirements.
PrototypingPrototyping
• Using an executable model of the system to check• Using an executable model of the system to check
requirements.
T tT t titiTestTest--case generationcase generation
• Developing tests for requirements to check testability.
Requirements reviews
R l i h ld b h ld hil th i t d fi itiRegular reviews should be held while the requirements definition
is being formulated.
Both client and contractor staff should be involved in reviews.
Reviews may be formal (with completed documents) or informal.
Good communications between developers, customers and users
can resolve problems at an early stage.
Review checks
V ifi bilit I th i t li ti ll t t bl ?Verifiability. Is the requirement realistically testable?
Comprehensibility. Is the requirement properly understood?
Traceability. Is the origin of the requirement clearly stated?
Adaptability. Can the requirement be changed without a large
impact on other requirements?
Requirements management
Req irements management is the process of managingmanaging changingchangingRequirements management is the process of managingmanaging changingchanging
requirementsrequirements during the requirements engineering process and
system developmentsystem development.
Requirements change
Th i it f i t f diff t i i t hThe priority of requirements from different viewpoints changes
during the development process.
System customers may specify requirements from a business
perspective that conflict with end-user requirements.
The business and technical environment of the system changes
during its development.
Requirements management planning
During the requirements engineering process, you have to plan:g q g g p , y p
• Requirements identification
• How requirements are individually identified;How requirements are individually identified;
• A change management process
• The process followed when analysing a requirements change;The process followed when analysing a requirements change;
• Traceability policies
• The amount of information about requirements relationships that is• The amount of information about requirements relationships that is
maintained;
• CASE tool supportCASE tool support
• The tool support required to help manage requirements change;
Requirements change management
Sh ld l t ll d h t th i tShould apply to all proposed changes to the requirements.
Principal stages
• Problem analysis. Discuss requirements problem and
propose change;
• Change analysis and costing. Assess effects of change on
other requirements;
• Change implementation. Modify requirements document and
other documents to reflect change.g
Change management
Unit Review Questions
1 What are the differences between requirements definition and requirements1. What are the differences between requirements definition and requirements
specification?
2. Explain the software (system) requirement classification in detail with example
3. Describe different software requirements with examples.
4. Explain the characteristic features and Structure of a software requirementsStructure of a software requirements
documentdocumentdocument.document.
5. Describe major activities of requirements engineering processmajor activities of requirements engineering process.
6. What are the various techniques used for requirements elicitationtechniques used for requirements elicitation and analysis?
Explain any one in detail.
7. Explain the salient features of View point, stockholdersView point, stockholders and scenario techniques.scenario techniques.
W it h t t8. Write short notes on:
a. Ethnography b. Use-case c. Sequence diagram d. Feasibility study
e. Volatile requirements e. Require change management.q q g g
9. What is requirement validation ?is requirement validation ? Explain different requirements validation
techniques.
D ib j ti iti f i t i iDescribe major activities of requirements engineering process.

More Related Content

What's hot

SE - Software Requirements
SE - Software RequirementsSE - Software Requirements
SE - Software RequirementsJomel Penalba
 
Model-Based Systems Requirements
Model-Based Systems RequirementsModel-Based Systems Requirements
Model-Based Systems RequirementsJean-Michel Bruel
 
Object oriented analysis &design - requirement analysis
Object oriented analysis &design - requirement analysisObject oriented analysis &design - requirement analysis
Object oriented analysis &design - requirement analysisAbhilasha Lahigude
 
Shared information systems
Shared information systemsShared information systems
Shared information systemsHimanshu
 
Chapter 4 software design
Chapter 4  software designChapter 4  software design
Chapter 4 software designCliftone Mullah
 
Software engineering rogers pressman chapter 7
Software engineering rogers pressman chapter 7Software engineering rogers pressman chapter 7
Software engineering rogers pressman chapter 7mohammad hossein Jalili
 
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddel
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddelCHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddel
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddelmohamed khalaf alla mohamedain
 
SE_Lec 01_ Introduction to Software Enginerring
SE_Lec 01_ Introduction to Software EnginerringSE_Lec 01_ Introduction to Software Enginerring
SE_Lec 01_ Introduction to Software EnginerringAmr E. Mohamed
 
SE18_Lec 07_System Modelling and Context Model
SE18_Lec 07_System Modelling and Context ModelSE18_Lec 07_System Modelling and Context Model
SE18_Lec 07_System Modelling and Context ModelAmr E. Mohamed
 
SWE-401 - 6. Software Analysis and Design Tools
SWE-401 - 6. Software Analysis and Design ToolsSWE-401 - 6. Software Analysis and Design Tools
SWE-401 - 6. Software Analysis and Design Toolsghayour abbas
 
SE2018_Lec 14_ Process Modeling and Data Flow Diagram.pptx
SE2018_Lec 14_ Process Modeling and Data Flow Diagram.pptxSE2018_Lec 14_ Process Modeling and Data Flow Diagram.pptx
SE2018_Lec 14_ Process Modeling and Data Flow Diagram.pptxAmr E. Mohamed
 
System Development Life Cycle (SDLC)
System Development Life Cycle (SDLC)System Development Life Cycle (SDLC)
System Development Life Cycle (SDLC)Animesh Chaturvedi
 
Unit 4- Software Engineering System Model Notes
Unit 4- Software Engineering System Model Notes Unit 4- Software Engineering System Model Notes
Unit 4- Software Engineering System Model Notes arvind pandey
 
Reference Data Management
Reference Data ManagementReference Data Management
Reference Data ManagementProfinit
 
Analysis modeling & scenario based modeling
Analysis modeling &  scenario based modeling Analysis modeling &  scenario based modeling
Analysis modeling & scenario based modeling Benazir Fathima
 

What's hot (20)

SE - Software Requirements
SE - Software RequirementsSE - Software Requirements
SE - Software Requirements
 
Bank managment system
Bank managment systemBank managment system
Bank managment system
 
Model-Based Systems Requirements
Model-Based Systems RequirementsModel-Based Systems Requirements
Model-Based Systems Requirements
 
Object oriented analysis &design - requirement analysis
Object oriented analysis &design - requirement analysisObject oriented analysis &design - requirement analysis
Object oriented analysis &design - requirement analysis
 
Shared information systems
Shared information systemsShared information systems
Shared information systems
 
Chapter 4 software design
Chapter 4  software designChapter 4  software design
Chapter 4 software design
 
Analysis modeling
Analysis modelingAnalysis modeling
Analysis modeling
 
Software engineering rogers pressman chapter 7
Software engineering rogers pressman chapter 7Software engineering rogers pressman chapter 7
Software engineering rogers pressman chapter 7
 
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddel
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddelCHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddel
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddel
 
Analysis modeling
Analysis modelingAnalysis modeling
Analysis modeling
 
SE_Lec 01_ Introduction to Software Enginerring
SE_Lec 01_ Introduction to Software EnginerringSE_Lec 01_ Introduction to Software Enginerring
SE_Lec 01_ Introduction to Software Enginerring
 
Slides chapter 8
Slides chapter 8Slides chapter 8
Slides chapter 8
 
SE18_Lec 07_System Modelling and Context Model
SE18_Lec 07_System Modelling and Context ModelSE18_Lec 07_System Modelling and Context Model
SE18_Lec 07_System Modelling and Context Model
 
SWE-401 - 6. Software Analysis and Design Tools
SWE-401 - 6. Software Analysis and Design ToolsSWE-401 - 6. Software Analysis and Design Tools
SWE-401 - 6. Software Analysis and Design Tools
 
SE2018_Lec 14_ Process Modeling and Data Flow Diagram.pptx
SE2018_Lec 14_ Process Modeling and Data Flow Diagram.pptxSE2018_Lec 14_ Process Modeling and Data Flow Diagram.pptx
SE2018_Lec 14_ Process Modeling and Data Flow Diagram.pptx
 
System Development Life Cycle (SDLC)
System Development Life Cycle (SDLC)System Development Life Cycle (SDLC)
System Development Life Cycle (SDLC)
 
Unit 4- Software Engineering System Model Notes
Unit 4- Software Engineering System Model Notes Unit 4- Software Engineering System Model Notes
Unit 4- Software Engineering System Model Notes
 
Reference Data Management
Reference Data ManagementReference Data Management
Reference Data Management
 
Analysis modeling & scenario based modeling
Analysis modeling &  scenario based modeling Analysis modeling &  scenario based modeling
Analysis modeling & scenario based modeling
 
Component level design
Component   level designComponent   level design
Component level design
 

Similar to Unit 3- requirements for software development

Software engineering lecture 1
Software engineering  lecture 1Software engineering  lecture 1
Software engineering lecture 1JusperKato
 
Software Requirements
Software RequirementsSoftware Requirements
Software RequirementsBala Ganesh
 
Software Requirements in Software Engineering SE5
Software Requirements in Software Engineering SE5Software Requirements in Software Engineering SE5
Software Requirements in Software Engineering SE5koolkampus
 
Software Requrement
Software RequrementSoftware Requrement
Software RequrementSeif Shaame
 
CS8494 SOFTWARE ENGINEERING Unit-2
CS8494 SOFTWARE ENGINEERING Unit-2CS8494 SOFTWARE ENGINEERING Unit-2
CS8494 SOFTWARE ENGINEERING Unit-2SIMONTHOMAS S
 
1 Software Requirements Descriptions and specification.docx
1 Software Requirements Descriptions and specification.docx1 Software Requirements Descriptions and specification.docx
1 Software Requirements Descriptions and specification.docxjeremylockett77
 
Requirements Engineering
Requirements EngineeringRequirements Engineering
Requirements EngineeringEhsan Elahi
 
Lecture-5-Requirements Analysis and Specification.pptx
Lecture-5-Requirements Analysis and Specification.pptxLecture-5-Requirements Analysis and Specification.pptx
Lecture-5-Requirements Analysis and Specification.pptxYaseenNazir3
 
Chap 4 - Requirements Engineering 1.ppt
Chap 4 - Requirements Engineering 1.pptChap 4 - Requirements Engineering 1.ppt
Chap 4 - Requirements Engineering 1.pptDrCMeenakshiVISTAS
 
Chap 4 - Requirements Engineering 1.ppt
Chap 4 - Requirements Engineering 1.pptChap 4 - Requirements Engineering 1.ppt
Chap 4 - Requirements Engineering 1.pptazida3
 
Cs2 ah0405 softwarerequirements
Cs2 ah0405 softwarerequirementsCs2 ah0405 softwarerequirements
Cs2 ah0405 softwarerequirementsMISHAQ6
 
Software requirement specification
Software requirement specificationSoftware requirement specification
Software requirement specificationshiprashakya2
 
SWE-401 - 4. Software Requirement Specifications
SWE-401 - 4. Software Requirement Specifications SWE-401 - 4. Software Requirement Specifications
SWE-401 - 4. Software Requirement Specifications ghayour abbas
 
SE Unit 2(1).pptx
SE Unit 2(1).pptxSE Unit 2(1).pptx
SE Unit 2(1).pptxaryan631999
 

Similar to Unit 3- requirements for software development (20)

Software engineering lecture 1
Software engineering  lecture 1Software engineering  lecture 1
Software engineering lecture 1
 
SECh56
SECh56SECh56
SECh56
 
Software Requirements
Software RequirementsSoftware Requirements
Software Requirements
 
Software Requirements in Software Engineering SE5
Software Requirements in Software Engineering SE5Software Requirements in Software Engineering SE5
Software Requirements in Software Engineering SE5
 
Software Requrement
Software RequrementSoftware Requrement
Software Requrement
 
Se week 4
Se week 4Se week 4
Se week 4
 
Se week 4
Se week 4Se week 4
Se week 4
 
SE UNIT 2.pdf
SE UNIT 2.pdfSE UNIT 2.pdf
SE UNIT 2.pdf
 
CS8494 SOFTWARE ENGINEERING Unit-2
CS8494 SOFTWARE ENGINEERING Unit-2CS8494 SOFTWARE ENGINEERING Unit-2
CS8494 SOFTWARE ENGINEERING Unit-2
 
1 Software Requirements Descriptions and specification.docx
1 Software Requirements Descriptions and specification.docx1 Software Requirements Descriptions and specification.docx
1 Software Requirements Descriptions and specification.docx
 
Requirements Engineering
Requirements EngineeringRequirements Engineering
Requirements Engineering
 
Lecture-5-Requirements Analysis and Specification.pptx
Lecture-5-Requirements Analysis and Specification.pptxLecture-5-Requirements Analysis and Specification.pptx
Lecture-5-Requirements Analysis and Specification.pptx
 
Chap 4 - Requirements Engineering 1.ppt
Chap 4 - Requirements Engineering 1.pptChap 4 - Requirements Engineering 1.ppt
Chap 4 - Requirements Engineering 1.ppt
 
Chap 4 - Requirements Engineering 1.ppt
Chap 4 - Requirements Engineering 1.pptChap 4 - Requirements Engineering 1.ppt
Chap 4 - Requirements Engineering 1.ppt
 
Cs2 ah0405 softwarerequirements
Cs2 ah0405 softwarerequirementsCs2 ah0405 softwarerequirements
Cs2 ah0405 softwarerequirements
 
Software requirement specification
Software requirement specificationSoftware requirement specification
Software requirement specification
 
SWE-401 - 4. Software Requirement Specifications
SWE-401 - 4. Software Requirement Specifications SWE-401 - 4. Software Requirement Specifications
SWE-401 - 4. Software Requirement Specifications
 
Requirements engineering
Requirements engineeringRequirements engineering
Requirements engineering
 
Lec srs
Lec srsLec srs
Lec srs
 
SE Unit 2(1).pptx
SE Unit 2(1).pptxSE Unit 2(1).pptx
SE Unit 2(1).pptx
 

More from arvind pandey

ADBMS ALL 2069-73 [CSITauthority.blogspot.com].pdf
ADBMS ALL 2069-73 [CSITauthority.blogspot.com].pdfADBMS ALL 2069-73 [CSITauthority.blogspot.com].pdf
ADBMS ALL 2069-73 [CSITauthority.blogspot.com].pdfarvind pandey
 
Internet service provider and network backbone
Internet service provider and network backboneInternet service provider and network backbone
Internet service provider and network backbonearvind pandey
 
Core java complete ppt(note)
Core java  complete  ppt(note)Core java  complete  ppt(note)
Core java complete ppt(note)arvind pandey
 
Unit 2-software development process notes
Unit 2-software development process notes Unit 2-software development process notes
Unit 2-software development process notes arvind pandey
 
Chapter1 computer introduction note
Chapter1  computer introduction note Chapter1  computer introduction note
Chapter1 computer introduction note arvind pandey
 
computer network fundamental note
computer network fundamental note computer network fundamental note
computer network fundamental note arvind pandey
 

More from arvind pandey (11)

ADBMS ALL 2069-73 [CSITauthority.blogspot.com].pdf
ADBMS ALL 2069-73 [CSITauthority.blogspot.com].pdfADBMS ALL 2069-73 [CSITauthority.blogspot.com].pdf
ADBMS ALL 2069-73 [CSITauthority.blogspot.com].pdf
 
Syllabus.pdf
Syllabus.pdfSyllabus.pdf
Syllabus.pdf
 
Network entites
Network entitesNetwork entites
Network entites
 
Transport layer
Transport layerTransport layer
Transport layer
 
Internet service provider and network backbone
Internet service provider and network backboneInternet service provider and network backbone
Internet service provider and network backbone
 
Core java complete ppt(note)
Core java  complete  ppt(note)Core java  complete  ppt(note)
Core java complete ppt(note)
 
Unit 2-software development process notes
Unit 2-software development process notes Unit 2-software development process notes
Unit 2-software development process notes
 
Chapter1 computer introduction note
Chapter1  computer introduction note Chapter1  computer introduction note
Chapter1 computer introduction note
 
computer network fundamental note
computer network fundamental note computer network fundamental note
computer network fundamental note
 
I have a dream
I have a dreamI have a dream
I have a dream
 
brain.ppts
brain.pptsbrain.ppts
brain.ppts
 

Recently uploaded

FUNCTIONAL AND NON FUNCTIONAL REQUIREMENT
FUNCTIONAL AND NON FUNCTIONAL REQUIREMENTFUNCTIONAL AND NON FUNCTIONAL REQUIREMENT
FUNCTIONAL AND NON FUNCTIONAL REQUIREMENTSneha Padhiar
 
CS 3251 Programming in c all unit notes pdf
CS 3251 Programming in c all unit notes pdfCS 3251 Programming in c all unit notes pdf
CS 3251 Programming in c all unit notes pdfBalamuruganV28
 
Module-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdfModule-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdfManish Kumar
 
Module-1-Building Acoustics(Introduction)(Unit-1).pdf
Module-1-Building Acoustics(Introduction)(Unit-1).pdfModule-1-Building Acoustics(Introduction)(Unit-1).pdf
Module-1-Building Acoustics(Introduction)(Unit-1).pdfManish Kumar
 
Artificial Intelligence in Power System overview
Artificial Intelligence in Power System overviewArtificial Intelligence in Power System overview
Artificial Intelligence in Power System overviewsandhya757531
 
Detection&Tracking - Thermal imaging object detection and tracking
Detection&Tracking - Thermal imaging object detection and trackingDetection&Tracking - Thermal imaging object detection and tracking
Detection&Tracking - Thermal imaging object detection and trackinghadarpinhas1
 
"Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ..."Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ...Erbil Polytechnic University
 
Gravity concentration_MI20612MI_________
Gravity concentration_MI20612MI_________Gravity concentration_MI20612MI_________
Gravity concentration_MI20612MI_________Romil Mishra
 
multiple access in wireless communication
multiple access in wireless communicationmultiple access in wireless communication
multiple access in wireless communicationpanditadesh123
 
2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.
2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.
2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.elesangwon
 
Indian Tradition, Culture & Societies.pdf
Indian Tradition, Culture & Societies.pdfIndian Tradition, Culture & Societies.pdf
Indian Tradition, Culture & Societies.pdfalokitpathak01
 
High Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMS
High Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMSHigh Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMS
High Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMSsandhya757531
 
Novel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending ActuatorsNovel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending ActuatorsResearcher Researcher
 
Python Programming for basic beginners.pptx
Python Programming for basic beginners.pptxPython Programming for basic beginners.pptx
Python Programming for basic beginners.pptxmohitesoham12
 
TEST CASE GENERATION GENERATION BLOCK BOX APPROACH
TEST CASE GENERATION GENERATION BLOCK BOX APPROACHTEST CASE GENERATION GENERATION BLOCK BOX APPROACH
TEST CASE GENERATION GENERATION BLOCK BOX APPROACHSneha Padhiar
 
Katarzyna Lipka-Sidor - BIM School Course
Katarzyna Lipka-Sidor - BIM School CourseKatarzyna Lipka-Sidor - BIM School Course
Katarzyna Lipka-Sidor - BIM School Coursebim.edu.pl
 
Theory of Machine Notes / Lecture Material .pdf
Theory of Machine Notes / Lecture Material .pdfTheory of Machine Notes / Lecture Material .pdf
Theory of Machine Notes / Lecture Material .pdfShreyas Pandit
 
22CYT12 & Chemistry for Computer Systems_Unit-II-Corrosion & its Control Meth...
22CYT12 & Chemistry for Computer Systems_Unit-II-Corrosion & its Control Meth...22CYT12 & Chemistry for Computer Systems_Unit-II-Corrosion & its Control Meth...
22CYT12 & Chemistry for Computer Systems_Unit-II-Corrosion & its Control Meth...KrishnaveniKrishnara1
 
Curve setting (Basic Mine Surveying)_MI10412MI.pptx
Curve setting (Basic Mine Surveying)_MI10412MI.pptxCurve setting (Basic Mine Surveying)_MI10412MI.pptx
Curve setting (Basic Mine Surveying)_MI10412MI.pptxRomil Mishra
 

Recently uploaded (20)

ASME-B31.4-2019-estandar para diseño de ductos
ASME-B31.4-2019-estandar para diseño de ductosASME-B31.4-2019-estandar para diseño de ductos
ASME-B31.4-2019-estandar para diseño de ductos
 
FUNCTIONAL AND NON FUNCTIONAL REQUIREMENT
FUNCTIONAL AND NON FUNCTIONAL REQUIREMENTFUNCTIONAL AND NON FUNCTIONAL REQUIREMENT
FUNCTIONAL AND NON FUNCTIONAL REQUIREMENT
 
CS 3251 Programming in c all unit notes pdf
CS 3251 Programming in c all unit notes pdfCS 3251 Programming in c all unit notes pdf
CS 3251 Programming in c all unit notes pdf
 
Module-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdfModule-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdf
 
Module-1-Building Acoustics(Introduction)(Unit-1).pdf
Module-1-Building Acoustics(Introduction)(Unit-1).pdfModule-1-Building Acoustics(Introduction)(Unit-1).pdf
Module-1-Building Acoustics(Introduction)(Unit-1).pdf
 
Artificial Intelligence in Power System overview
Artificial Intelligence in Power System overviewArtificial Intelligence in Power System overview
Artificial Intelligence in Power System overview
 
Detection&Tracking - Thermal imaging object detection and tracking
Detection&Tracking - Thermal imaging object detection and trackingDetection&Tracking - Thermal imaging object detection and tracking
Detection&Tracking - Thermal imaging object detection and tracking
 
"Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ..."Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ...
 
Gravity concentration_MI20612MI_________
Gravity concentration_MI20612MI_________Gravity concentration_MI20612MI_________
Gravity concentration_MI20612MI_________
 
multiple access in wireless communication
multiple access in wireless communicationmultiple access in wireless communication
multiple access in wireless communication
 
2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.
2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.
2022 AWS DNA Hackathon 장애 대응 솔루션 jarvis.
 
Indian Tradition, Culture & Societies.pdf
Indian Tradition, Culture & Societies.pdfIndian Tradition, Culture & Societies.pdf
Indian Tradition, Culture & Societies.pdf
 
High Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMS
High Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMSHigh Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMS
High Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMS
 
Novel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending ActuatorsNovel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending Actuators
 
Python Programming for basic beginners.pptx
Python Programming for basic beginners.pptxPython Programming for basic beginners.pptx
Python Programming for basic beginners.pptx
 
TEST CASE GENERATION GENERATION BLOCK BOX APPROACH
TEST CASE GENERATION GENERATION BLOCK BOX APPROACHTEST CASE GENERATION GENERATION BLOCK BOX APPROACH
TEST CASE GENERATION GENERATION BLOCK BOX APPROACH
 
Katarzyna Lipka-Sidor - BIM School Course
Katarzyna Lipka-Sidor - BIM School CourseKatarzyna Lipka-Sidor - BIM School Course
Katarzyna Lipka-Sidor - BIM School Course
 
Theory of Machine Notes / Lecture Material .pdf
Theory of Machine Notes / Lecture Material .pdfTheory of Machine Notes / Lecture Material .pdf
Theory of Machine Notes / Lecture Material .pdf
 
22CYT12 & Chemistry for Computer Systems_Unit-II-Corrosion & its Control Meth...
22CYT12 & Chemistry for Computer Systems_Unit-II-Corrosion & its Control Meth...22CYT12 & Chemistry for Computer Systems_Unit-II-Corrosion & its Control Meth...
22CYT12 & Chemistry for Computer Systems_Unit-II-Corrosion & its Control Meth...
 
Curve setting (Basic Mine Surveying)_MI10412MI.pptx
Curve setting (Basic Mine Surveying)_MI10412MI.pptxCurve setting (Basic Mine Surveying)_MI10412MI.pptx
Curve setting (Basic Mine Surveying)_MI10412MI.pptx
 

Unit 3- requirements for software development

  • 2. Topics covered fFunctional and non-functional requirements User requirementsq System requirements Interface specification The software requirements documentThe software requirements document
  • 3. Requirements engineering The process of establishing the servicesservices that the customer requires from a system and thecustomer requires from a system and the constraintsconstraints under which it operates and is developed.
  • 5.
  • 6. Requirements imprecision P bl i h i t tt i li l t t dt t dProblems arise when requirements areare notnot preciselyprecisely statedstated.. AmbiguousAmbiguous requirementsrequirements may be interpreted in different ways by developers and usersusers. Consider the term ‘appropriate‘appropriate viewers’viewers’ • User intention - special purpose viewer for each different document type;document type; • Developer interpretation - Provide a text viewer that h th t t f th d tshows the contents of the document.
  • 7. Requirements completeness and consistency I i i l i t h ld b b th l t dIn principle, requirements should be both complete and consistent. Complete • They should include descriptions of all facilities required. Consistent • There should be no conflicts or contradictions in the• There should be no conflicts or contradictions in the descriptions of the system facilities.
  • 8.
  • 10. Functional and non-functional requirements Functional requirementsq • Statements of servicesservices the system should provide, how the system should react to particularparticular inputsinputs and how thesystem should react to particularparticular inputsinputs and how the system should behavebehave in particular situations. Non functional requirements( f )Non-functional requirements(performance) • constraints on the services or functions offered by the system such as timingtiming constraintsconstraints, constraints on the developmentdevelopment processprocess,, standardsstandards, etc.
  • 11. Functional requirements D ib f ti lit t iDescribe functionality or system services. Depend on the typetype ofof softwaresoftware, expected users and the type of system where the software is used.
  • 12. The LIBSYS system A lib t th t id i l i t f t b fA library system that provides a single interface to a number of databases of articlesarticles inin differentdifferent librarieslibraries.. Users can search for, download and print these articles for personal study.
  • 13. Examples of functional requirements The user shall be able to search either all of the initialinitial setset of databases or select a subsetsubset from it. The system shall provide appropriateappropriate viewersviewers for the user to read documents in the document store. Every order shall be allocated a uniqueunique identifieridentifier (ORDER_ID) which the user shall be able to copy to the account’s permanentwhich the user shall be able to copy to the account s permanent storage area.
  • 14. Non-functional requirements Th d fi t ti d t i t li bilitli bilitThese define system properties and constraints e.g. reliabilityreliability, responseresponse timetime and storagestorage requirementsrequirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular CASE system, programming language or development method. Non-functional requirements may be moremore criticalcritical than functional requirements If these are not met the system isfunctional requirements. If these are not met, the system is useless.
  • 15. Non-functional classifications Product requirementsq • Requirements which specify that the delivereddelivered productproduct must behave in a particular way e.g. execution speed, reliability, etc.p y g p , y, Organisational requirements • Requirements which are a consequence of organisationalorganisational• Requirements which are a consequence of organisationalorganisational policiespolicies and procedures e.g. process standards used, implementation requirements etcimplementation requirements, etc. External requirements • Requirements which arise fromfrom factorsfactors which are external to the system and its development process e.g. interoperability i t l i l ti i t trequirements, legislative requirements, etc.
  • 17. Requirements measures Property Measure Speed Processed transactions/second User/Event response timeUser/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 Timeto restart after failureRobustness Timeto restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems
  • 18. Domain requirements D i d f th li ti d i d d ib tDerived from the application domain and describe system characteristics and features that reflect the domain. Domain requirements be new functional requirements, constraints on existing requirements or define specific computations. If domain requirements are not satisfied, the system may be unworkable.
  • 19. LIBSYS requirement LIBSYS shall provide a financial accounting system that maintains records of all payments made by users of the system. System managers may configure this system so that regular users may receive discounted rates.y
  • 20. Requirement problems D t b i t i l d b th t l d d t il dDatabase requirements includes both conceptual and detailed information • Describes the concept of a financial accounting system that is to be included in LIBSYS;
  • 21. Domain requirements problems U d t d bilitUnderstand ability • Requirements are expressed in the language of the application domain; • This is often not understood by software engineers developing the system. Implicitness • Domain specialists understand the area so well that they do not think of making the domain requirements explicit.g q p
  • 22. User requirements Sh ld d ib f ti lf ti l d f ti lf ti l i t iShould describe functionalfunctional and nonnon--functionalfunctional requirements in such a way that they are understandable by system users who d ’t h d t il d t h i l k l ddon’t have detailed technical knowledge. User requirements are defined using natural languagenatural language,, tablestables and diagramsdiagrams as these can be understood by all users.
  • 23. Problems with natural language L k f l itLack of clarity • Precision is difficult without making the document difficult to read. Requirements confusion • Functional and non-functional requirements tend to be mixed-up. Requirements amalgamation • Several different requirements may be expressed together.Several different requirements may be expressed together.
  • 24. Problems with NL specification A bi itAmbiguity • The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult. Over-flexibility • The same thing may be said in a number of different ways in the specification.
  • 25. Guidelines for writing requirements Invent a standard format and use it for all requirements. Use language in a consistent wayUse language in a consistent way. Use text highlighting to identify key parts of the requirement. A id th f t jAvoid the use of computer jargon.
  • 26. Alternatives to NL specification N t ti D i tiNotation Description Structured natural language This approach depends on defining standard forms or templates to express the requirements specification.g g q p Design description 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 languages 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 SADTnotations requirements for the system. An early example of such a graphical language was SADT. Now, use-case descriptions and sequence diagrams are commonly used . Mathematical These are notations based on mathematical concepts such as finite-state machines or specifications 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.p p y
  • 27. Structured language specifications Th f d f th i t it i li it d b d fi dThe freedom of the requirements writer is limited by a predefined templatetemplate for requirements. All requirements are written in a standardstandard wayway. The terminology used in the description may be limited. The advantage is that the most of the expressiveness of natural language is maintained but a degreedegree ofof uniformityuniformity is imposed on the specification.
  • 28. Form-based specifications D fi iti f th f ti titDefinition of the function or entity. Description of inputs and where they come from. Description of outputs and where they go to. Indication of other entities required. Pre and post conditions (if appropriate). The side effects (if any) of the function.The side effects (if any) of the function.
  • 29. Form-based 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 t f i i d i If th l l i i i d th t f i i i i th C D irate 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 computedRequires 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 NoneSide effects None
  • 30. Tabular specification Used to supplement natural languageUsed to supplement natural language. Particularly useful when you have to define a number of possible alternative courses of action. Condition Action Sugar level falling (r2 < r1) CompDose = 0Sugar level falling (r2 < r1) CompDose 0 Sugar level stable (r2 = r1) CompDose = 0 Sugar level increasing and rate of CompDose = 0g g increase decreasing ((r2-r1)<(r1-r0)) p Sugar level increasing and rate of increase stable or increasing. ((r2-r1) CompDose = round ((r2-r1)/4) If rounded result = 0 thenincrease stable or increasing. ((r2 r1) (r1-r0)) If rounded result 0 then CompDose = MinimumDose
  • 31. Graphical models G hi l d l t f l h d t h hGraphical models are most useful when you need to show how state changes or where you need to describe a sequence ofsequence of titiactions.actions.
  • 32. Sequence diagrams Th h th f t th t t k l d iThese show the sequence of events that take place during some user interaction with a system. You read them from top to bottom to see the order of the actions that take place. Cash withdrawal from an ATM • Validate card; • Handle request; • Complete transaction.Complete transaction.
  • 33. Sequence diagram of ATM withdrawal
  • 34.
  • 35.
  • 36. Interface specification M t t t t ith tht ith th t d th tiMost systems must operate with otheroperate with other systems and the operating interfaces must be specified as part of the requirements. Three types of interfaceThree types of interface may have to be defined • Procedural interfaces; • Data structures that are exchanged; • Data representations.p Formal notationsFormal notations are an effective technique for interface specification.specification.
  • 37. The requirements document Th i t d ti t d t i th ffi i l t t t f h t iThe requirements documentrequirements document is the official statement of what is required of the system developers. Should include both a definition of user requirements and a specification of the system requirements. It is NOT a design document. As far as possible, it should set of WHATWHAT the system should do rather than HOWHOW it should do it
  • 38. Users of a requirements document
  • 39. IEEE requirements standard D fi i t t f i t d t th t tDefines a generic structure for a requirements document that must be instantiated for each specific system. • Introduction. • General description. • Specific requirements. • Appendices.pp • Index.
  • 40. Requirements document structure P fPreface Introduction Glossary User requirements definition System architectureSystem architecture System requirements specification System models System evolutionSystem evolution Appendices
  • 42. Topics covered Feasibility studies Requirements elicitation and analysisq y Requirements validation Requirements management
  • 43. Requirements Engineering Processes Th d f RE id l d di thThe processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements. However, there are a number of generic activities common to all processes • Requirements elicitation;q ; • Feasibility study; R i t l i• Requirements analysis; • Requirements validation; • Requirements management.
  • 45. Feasibility studies A f ibilit t d d id h th t th d tA feasibility study decides whether or not the proposed system is worthwhileworthwhile..
  • 46. Feasibility study implementation B d i f ti t ( h t i i d)Based on information assessment (what is required), information collection and report writing. Questions for people in the organisation • What if the system wasn’t implemented? • What are current process problems? • How will the proposed system help?• How will the proposed system help? • What will be the integration problems? • Is new technology needed? What skills? • What facilities must be supported by the proposed system?
  • 47. Elicitation and analysis S ti ll d i t li it ti i ti tSometimes called requirements elicitation or requirementsrequirements discoverydiscovery.. Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. May involve end-users, managers, engineers involved iny , g , g maintenance, domain experts, trade unions, etc. These are called stakeholdersstakeholders..called stakeholdersstakeholders..
  • 48. Problems of requirements analysis Stakeholders don’t know what they really want. Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. Organisational and political factors may influence the systemOrganisational and political factors may influence the system requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment change.
  • 49. Process activities Requirements discoveryq y • Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.Domain requirements are also discovered at this stage. Requirements classification and organisation • Groups related requirements and organises them into coherent• Groups related requirements and organises them into coherent clusters. Prioritisation and negotiationPrioritisation and negotiation • Prioritising requirements and resolving requirements conflicts. Requirements documentation • Requirements are documented and input into the next round of the spiral.
  • 51. ATM stakeholders B k tBank customers Representatives of other banks Bank managers Counter staff Database administrators S itSecurity managers Marketing department Hardware and software maintenance engineers Banking regulatorsg g
  • 52. Viewpoints Vi i t f t t it t i th i t t tViewpoints are a way of structuringstructuring the requirements to represent the perspectivesperspectives of different stakeholders. Stakeholders may be classified under different viewpoints. This multi-perspective analysis is important as there is no single correct way to analyse system requirements.
  • 53. Types of viewpoint InteractorInteractor viewpointsviewpointsInteractorInteractor viewpointsviewpoints • People or other systems that interact directly with the system. In an ATM the customer’s and the account database arean ATM, the customer s and the account database are interactor VPs. IndirectIndirect viewpointsviewpointsIndirectIndirect viewpointsviewpoints • Stakeholders who do not use the system themselves but who influence the requirements In an ATM management andinfluence the requirements. In an ATM, management and security staff are indirect viewpoints. DomainDomain viewpointsviewpointsDomainDomain viewpointsviewpoints • Domain characteristics and constraints that influence the requirements In an ATM an example would be standards forrequirements. In an ATM, an example would be standards for inter-bank communications.
  • 54. Viewpoint identification Id tif i i t iIdentify viewpoints using • Providers and receivers of system services; • Systems that interact directly with the system being specified; • Regulations and standards; • Sources of business and non-functional requirements.q • Engineers who have to develop and maintain the system; • Marketing and other business viewpoints• Marketing and other business viewpoints.
  • 55. LIBSYS viewpoint hierarchy All VPs InteractorIndirect Domain Article providers FinanceLibrary manager Library staff Users Classification system UI standards ExternalStaffStudents Cataloguers System managers
  • 56. Interviewing I f l i f l i t i i th RE t t titiIn formal or informal interviewing, the RE team puts questionsquestions to stakeholders about the system that they use and the system to b d l dbe developed. There are two types of interview •• ClosedClosed interviewsinterviews where a pre-defined set of questions are answered. •• OpenOpen interviewsinterviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.
  • 57. Scenarios S i l lif l f h t b dScenarios are real-life examples of how a system can be used. They should include • A description of the startingstarting situationsituation; • A description of the normalnormal flowflow ofof eventsevents; • A description of whatwhat cancan gogo wrongwrong; • Information about other concurrentconcurrent activitiesactivities;Information about other concurrentconcurrent activitiesactivities; • A description of the statestate whenwhen thethe scenarioscenario finishesfinishes.
  • 58. LIBSYS scenario (1) InitialInitial assumptionassumption: The user has loggedlogged on to the LIBSYS system and has located the journaljournal containing the copy of the article. NormalNormal:: The user selects the article to be copied He or she is then prompted by theNormalNormal:: The user selects the article to be copied. He or she is then prompted by the system to either provide subscribersubscriber informationinformation for the journal or to indicate how they will pay for the article. Alternative payment methods are by credit card or byy p y p y y y quoting an organisational account number. The user is then asked to fill in a copyright form that maintains details of the transaction and they then submit this to the LIBSYS system. The copyright form is checked and, if OK, the PDF version of the article is downloaded to the LIBSYS working area on the user’s computer and the user isdownloaded to the LIBSYS working area on the user s computer and the user is informed that it is available. The user is asked to select a printer and a copy of the article is printed. If the article has been flagged as ‘print-only’ it is deleted from the user’s system once the user has confirmed that printing is complete.
  • 59. LIBSYS scenario (2) WhatWhat cancan gogo wrongwrong: The user may fail to fill in the copyrightcopyright formform correctlycorrectly In thisWhatWhat cancan gogo wrongwrong: The user may fail to fill in the copyrightcopyright formform correctlycorrectly. In this case, the form should be re-presented to the user for correction. If the resubmitted form is still incorrect then the user’s request for the article is rejected. The payment may be rejected by the system. The user’s request for the article is rejected. The article download may fail. Retry until successful or the user terminates the session. It may not be possible to print the article If the article is not flagged as ‘print-only’ thenIt may not be possible to print the article. If the article is not flagged as print-only then it is held in the LIBSYS workspace. Otherwise, the article is deleted and the user’s account credited with the cost of the article. OtherOther activitiesactivities: Simultaneous downloads of other articles. SystemSystem statestate onon completioncompletion:: User is logged on. The downloaded article has been deleted from LIBSYS workspace if it has been flagged as print-only.
  • 60. Use cases U i b d t h i i th UML hi hUse-cases are a scenario based technique in the UML which identify the actorsactors in an interaction and which describe the interaction itself. A set of use cases should describe all possible interactions with the system. SequenceSequence diagramsdiagrams may be used to add detail to use-cases byqq gg y y showing the sequence of event processing in the system.
  • 63. Print article sequence User item: Article copyrightForm: Form myWorkspace: W orkspace myPrinter: Printe r request complete request returnreturn copyright OK deliver article OK print send confirminform delete
  • 64. Ethnography-Observational technique A i l i ti t d id bl ti b ib i ddA social scientists spends a considerable time observingobserving andand analysinganalysing how people actually work. People do not have to explain or articulate their work. Social and organisational factors of importance may be observed. Ethnographic studies have shown that work is usually richerEthnographic studies have shown that work is usually richer and more complex than suggested by simple system models.
  • 65. Focused ethnography D l d i j t t d i th i t ffi t lDeveloped in a project studying the air traffic control process Combines ethnography with prototyping Prototype development results in unanswered questions which focus the ethnographic analysis. The problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant.
  • 66. Ethnography and prototyping Ethno g raphic anal ysis De briefing meetings Focused ethno g raph yanal ysis meetings ethno g raph y Prototype evaluation Generic system de velopment System proto yping
  • 67. Scope of ethnography R i t th t d i d f th th t l t llRequirements that are derived from the way that people actually work rather than the way which process definitions suggest that th ht t kthey ought to work. Requirements that are derived from cooperation and awareness of other people’s activities.
  • 68. Requirements validation C d ith d t ti th t th i t d fi thConcerned with demonstrating that the requirements define the system that the customercustomer reallyreally wantswants.. Requirements error costs are high so validation is very important • Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.
  • 69. Requirements checking V liditV lidit D th t id th f ti hi h b tValidityValidity.. Does the system provide the functions which best support the customer’s needs? ConsistencyConsistency.. Are there any requirements conflicts? CompletenessCompleteness. Are all functions required by the customer included? RealismRealism Can the requirements be implemented given availableRealismRealism. Can the requirements be implemented given available budget and technology V ifi bilitV ifi bilit C th i t b h k d?VerifiabilityVerifiability. Can the requirements be checked?
  • 70. Requirements validation techniques Requirements reviewsRequirements reviews • Systematic manual analysis of the requirements. PrototypingPrototyping • Using an executable model of the system to check• Using an executable model of the system to check requirements. T tT t titiTestTest--case generationcase generation • Developing tests for requirements to check testability.
  • 71. Requirements reviews R l i h ld b h ld hil th i t d fi itiRegular reviews should be held while the requirements definition is being formulated. Both client and contractor staff should be involved in reviews. Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage.
  • 72. Review checks V ifi bilit I th i t li ti ll t t bl ?Verifiability. Is the requirement realistically testable? Comprehensibility. Is the requirement properly understood? Traceability. Is the origin of the requirement clearly stated? Adaptability. Can the requirement be changed without a large impact on other requirements?
  • 73. Requirements management Req irements management is the process of managingmanaging changingchangingRequirements management is the process of managingmanaging changingchanging requirementsrequirements during the requirements engineering process and system developmentsystem development.
  • 74. Requirements change Th i it f i t f diff t i i t hThe priority of requirements from different viewpoints changes during the development process. System customers may specify requirements from a business perspective that conflict with end-user requirements. The business and technical environment of the system changes during its development.
  • 75. Requirements management planning During the requirements engineering process, you have to plan:g q g g p , y p • Requirements identification • How requirements are individually identified;How requirements are individually identified; • A change management process • The process followed when analysing a requirements change;The process followed when analysing a requirements change; • Traceability policies • The amount of information about requirements relationships that is• The amount of information about requirements relationships that is maintained; • CASE tool supportCASE tool support • The tool support required to help manage requirements change;
  • 76. Requirements change management Sh ld l t ll d h t th i tShould apply to all proposed changes to the requirements. Principal stages • Problem analysis. Discuss requirements problem and propose change; • Change analysis and costing. Assess effects of change on other requirements; • Change implementation. Modify requirements document and other documents to reflect change.g
  • 78. Unit Review Questions 1 What are the differences between requirements definition and requirements1. What are the differences between requirements definition and requirements specification? 2. Explain the software (system) requirement classification in detail with example 3. Describe different software requirements with examples. 4. Explain the characteristic features and Structure of a software requirementsStructure of a software requirements documentdocumentdocument.document. 5. Describe major activities of requirements engineering processmajor activities of requirements engineering process. 6. What are the various techniques used for requirements elicitationtechniques used for requirements elicitation and analysis? Explain any one in detail. 7. Explain the salient features of View point, stockholdersView point, stockholders and scenario techniques.scenario techniques. W it h t t8. Write short notes on: a. Ethnography b. Use-case c. Sequence diagram d. Feasibility study e. Volatile requirements e. Require change management.q q g g 9. What is requirement validation ?is requirement validation ? Explain different requirements validation techniques.
  • 79. D ib j ti iti f i t i iDescribe major activities of requirements engineering process.