1.
Unit-3
Software Requirementsq

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.

4.
Understanding the Importance of Requirements

5.
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.

6.
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.

7.
Classification of RequirementsClassification of Requirements

8.
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.

9.
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.

10.
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.

11.
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.

12.
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.

13.
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.

14.
Non-functional requirement types

15.
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

16.
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.

17.
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

18.
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;

19.
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

20.
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.

21.
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.

22.
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.

23.
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.

24.
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

25.
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.

26.
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.

27.
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

28.
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

29.
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.

30.
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.

31.
Sequence diagram of ATM withdrawal

32.
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.

33.
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

34.
Users of a requirements document

35.
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.

36.
Requirements document structure
P fPreface
Introduction
Glossary
User requirements definition
System architectureSystem architecture
System requirements specification
System models
System evolutionSystem evolution
Appendices

37.
RequirementsRequirementsRequirementsRequirements
EngineeringEngineering ProcessesProcessesEngineeringEngineering ProcessesProcesses

38.
Topics covered
Feasibility studies
Requirements elicitation and analysisq y
Requirements validation
Requirements management

39.
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.

40.
The requirements engineering process

41.
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..

42.
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?

43.
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..

44.
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.

45.
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.

46.
The requirements spiral

47.
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

48.
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.

49.
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.

50.
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.

51.
LIBSYS viewpoint hierarchy
All VPs
InteractorIndirect Domain
Article
providers
FinanceLibrary
manager
Library
staff
Users
Classification
system
UI
standards
ExternalStaffStudents Cataloguers
System
managers

52.
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.

53.
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.

54.
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.

55.
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.

56.
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.

57.
Article printing use-case

58.
LIBSYS use cases

59.
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

60.
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.

61.
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.

62.
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

63.
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.

64.
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.

65.
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?

66.
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.

67.
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.

68.
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?

69.
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.

70.
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.

71.
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;

72.
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

73.
Change management

74.
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.

75.
D ib j ti iti f i t i iDescribe major activities of requirements engineering process.