software requirements
DESCRIPTION
Software RequirementsTRANSCRIPT
Software Requirements
Loganathan RLoganathan R
Objectives
• To introduce the concepts of user requirementsand system requirements
• To describe functional and non-functionalrequirementsrequirements
• To explain how software requirements may beorganised in a requirements document
2Prof. Loganathan R., CSE, HKBKCE
Requirements engineering
• The process of finding out, analysing,documenting, and checking the services that thecustomer requires from a system and itsoperational constraints is called RE.operational constraints is called RE.
• Requirement may range from a high-level abstractstatement of a service or of a system constraint toa detailed mathematical functional specification.
3Prof. Loganathan R., CSE, HKBKCE
Requirements abstraction (Davis)
“If a company wishes to let a contract for a large softwaredevelopment project, it must define its needs in asufficiently abstract way that a solution is not pre-defined.The requirements must be written so that severalcontractors can bid for the contract, offering, perhaps,contractors can bid for the contract, offering, perhaps,different ways of meeting the client organisation’s needs.Once a contract has been awarded, the contractor mustwrite a system definition for the client in more detail sothat the client understands and can validate what thesoftware will do. Both of these documents may be calledthe requirements document for the system.”
4Prof. Loganathan R., CSE, HKBKCE
Types of requirement
• User requirements (high level abstract requirements)
– Statements in natural language plus diagrams of whatservices the system provides and its operationalconstraints. Written for customers.
• System requirements (description of what system should do)
– A structured document(also called functional specification)setting out detailed descriptions of the system’s functions,services and operational constraints. Defines what shouldbe implemented so may be part of a contract betweenclient and contractor.
5Prof. Loganathan R., CSE, HKBKCE
Definitions and specifications
1.1 On making a request for a document from LIBSYS, the requestor shall bepresented with a form that records details of user and the request made
1. LIBSYS shall keep track of all data required by copyright licensingagencies in INDIA and elsewhere1.
User requirement Definition
System Requirements Specification
Prof. Loganathan R., CSE, HKBKCE 6
presented with a form that records details of user and the request made
1.2 LIBSYS request forms shall be stored on the system for 5 years from thedate of the request
1.3 All LIBSYS request forms must be indexed by user, by the name of thematerial requested and by the supplier of the request
1.4 LIBSYS shall maintain a log of all requests that have been made to thesystem.
1.5 For material where authors lending rights apply, loan details shall be sentmonthly to copyright licensing agencies that have registered with LIBSYS.
.
.
.
.
Requirements readers
UserRequirements
Client ManagersSystem End-UsersClient EngineersContractor ManagersSystem Architect
7Prof. Loganathan R., CSE, HKBKCE
System Architect
System End-UsersClient EngineersSystem ArchitectSoftware Developers
SystemRequirements
Functional and non-functional requirements
• Software system requirements are classified as:
• Functional requirements– Statements of services the system should provide, how the
system should react to particular inputs and how the systemshould behave in particular situations(and sometimes what itshould NOT do).should NOT do).
• Non-functional requirements– constraints on the services or functions offered by the system
such as timing constraints, constraints on the developmentprocess, standards, etc. Apply to the system as whole.
• Domain requirements– Requirements that come from the application domain of the
system and that reflect characteristics of that domain.8Prof. Loganathan R., CSE, HKBKCE
Functional requirements
• Describe what the system should do.
• Depend on the type of software, expected usersand the type of system where the software isused.used.
• Functional user requirements may be high-levelstatements of what the system should do butfunctional system requirements should describethe system services in detail, its i/o, exceptionsand so on.
9Prof. Loganathan R., CSE, HKBKCE
Example: The LIBSYS system
• A library system that provides a single interface toa number of databases of articles in differentlibraries.
• Users can search for, download and print these• Users can search for, download and print thesearticles for personal study.
10Prof. Loganathan R., CSE, HKBKCE
Examples of functional requirements of LIBSYS
• The user shall be able to search either all of theinitial set of databases or select a subset from it.
• The system shall provide appropriate viewers forthe user to read documents in the documentthe user to read documents in the documentstore.
• Every order shall be allocated a unique identifier(ORDER_ID) which the user shall be able to copyto the account’s permanent storage area.
11Prof. Loganathan R., CSE, HKBKCE
Requirements imprecision
• Problems arise when requirements are notprecisely stated.
• Ambiguous requirements may be interpreted indifferent ways by developers and users.different ways by developers and users.
• Consider the term ‘appropriate viewers’– User intention - special purpose viewer for each
different document type;
– Developer interpretation - Provide a text viewer thatshows the contents of the document.
12Prof. Loganathan R., CSE, HKBKCE
Requirements completeness and consistency
• In principle, requirements should be bothcomplete and consistent.
• Completeness
– All services required by the user should be defined.– All services required by the user should be defined.
• Consistent
– Requirements should NOT have conflicts orcontradictions in the descriptions.
• In practice, it is impossible to produce a complete and consistentrequirements document.
13Prof. Loganathan R., CSE, HKBKCE
Non-functional requirements
• Related to emergent properties and constraints .Emergent properties are reliability, response time,storage requirements and so on. Constraints areI/O device capability, data representations, etc.
• Process requirements may also be specified• Process requirements may also be specifiedmandating a particular CASE system, programminglanguage or development method.
• Non-functional requirements may be more criticalthan functional requirements. If these are notmet, the system is useless.
14Prof. Loganathan R., CSE, HKBKCE
• Product requirements
– Specify product behaviour. E.g. execution speed, memoryrequired, reliability (failure rate), portability requirements,usability requirements, etc.
• Organisational requirements
Non-functional requirement types
• Organisational requirements
– Derived from customer and developer organisational policiesand procedures. e.g. process standards used, implementationrequirements, delivery requirements, etc.
• External requirements
– Derived from factors which are external to the system and itsdevelopment process e.g. interoperability requirements,legislative requirements, ethical requirements etc.
15Prof. Loganathan R., CSE, HKBKCE
Non-functional requirement types
ProductRequirements
OrganisationalRequirements
ExternalRequirements
Non-functionalRequirements
16Prof. Loganathan R., CSE, HKBKCE
PerformanceRequirements
SpaceRequirements
UsabilityRequirements
EfficiencyRequirements
ReliabilityRequirements
PortabilityRequirements
InteroperabilityRequirements
EthicalRequirements
LegislativeRequirements
ImplementationRequirements
StandardsRequirements
DeliveryRequirements
SafetyRequirements
PrivacyRequirements
LIBSYS Non-functional requirements
• Product requirement8.1 The user interface for LIBSYS shall be implemented as simple HTML without
frames or Java applets.
• Organisational requirement9.3.2 The system development process and deliverable documents shall conform9.3.2 The system development process and deliverable documents shall conform
to the process and deliverables defined in XYZCo-SP-STAN-95.
• External requirement7.6.5 The system shall not disclose any personal information about customers
apart from their name and reference number to the operators of the system.
17Prof. Loganathan R., CSE, HKBKCE
Problems in non-functional requirements
• Non-functional requirements may be very difficult tostate precisely and imprecise requirements may bedifficult to verify.
• Goal
– A general intention of the user such as ease of use, recovery– A general intention of the user such as ease of use, recoveryfrom failure, etc.
• Verifiable non-functional requirement
– A statement using some measure that can be objectively tested.
• Goals are helpful to developers as they convey theintentions of the system users.
18Prof. Loganathan R., CSE, HKBKCE
Examples
• A system goal– The system should be easy to use by experienced controllers and should be
organised in such a way that user errors are minimised.
• A verifiable non-functional requirement– Experienced controllers shall be able to use all the system functions after a– Experienced controllers shall be able to use all the system functions after a
total of two hours training. After this training, the average number of errorsmade by experienced users shall not exceed two per day.
19Prof. Loganathan R., CSE, HKBKCE
Requirements MeasuresProperty Measure
SpeedProcessed transactions/secondUser/Event response timeScreen refresh time
SizeM BytesNumber of ROM chips
Ease of useTraining time
20Prof. Loganathan R., CSE, HKBKCE
Ease of useTraining timeNumber of help frames
Reliability
Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability
RobustnessTime to restart after failurePercentage of events causing failureProbability of data corruption on failure
PortabilityPercentage of target dependent statementsNumber of target systems
Requirements interaction
• Conflicts between different non-functionalrequirements are common in complex systems.
• Example :Spacecraft system– To minimise weight, the number of separate chips in– To minimise weight, the number of separate chips in
the system should be minimised.
– To minimise power consumption, lower power chipsshould be used.
– However, using low power chips may mean that morechips have to be used. Which is the most criticalrequirement?
21Prof. Loganathan R., CSE, HKBKCE
Domain requirements
• Derived from the application domain and describesystem characteristics and features that reflect thedomain.
• Domain requirements be new functional• Domain requirements be new functionalrequirements, constraints on existingrequirements or define specific computations.
• If domain requirements are not satisfied, thesystem may be unworkable.
22Prof. Loganathan R., CSE, HKBKCE
Example of LIBSYS domain requirements
• There shall be a standard user interface to alldatabases which shall be based on the Z39.50standard.
• Because of copyright restrictions, some• Because of copyright restrictions, somedocuments must be deleted immediately onarrival. Depending on the user’s requirements,these documents will either be printed locally onthe system server for manually forwarding to theuser or routed to a network printer.
23Prof. Loganathan R., CSE, HKBKCE
Example : Train protection system• Computation of deceleration to stop the train:
The deceleration of the train shall be computed as:
Dtrain = Dcontrol + Dgradient
where D is 9.81ms2 * compensated gradient/alphawhere Dgradient is 9.81ms2 * compensated gradient/alphaand where the values of 9.81ms2 /alpha are known fordifferent types of train.
• Problem: Since it is written in application domainlanguage its difficult to understand by s/wengineers.
24Prof. Loganathan R., CSE, HKBKCE
Domain requirements problems
• Understandability
– Requirements are expressed in the language of theapplication domain;
– This is often not understood by software engineers– This is often not understood by software engineersdeveloping the system.
• Implicitness
– Domain specialists understand the area so well thatthey do not think of making the domain requirementsexplicit.
25Prof. Loganathan R., CSE, HKBKCE
User requirements
• Should describe functional and non-functionalrequirements in such a way that they areunderstandable by system users who don’t havedetailed technical knowledge.detailed technical knowledge.
• User requirements are defined using naturallanguage, tables and diagrams as these can beunderstood by all users.
26Prof. Loganathan R., CSE, HKBKCE
Problems with natural language(UR)
• Lack of clarity– Precision is difficult without making the document
difficult to read.
• Requirements confusion• Requirements confusion– Functional and non-functional requirements tend to be
mixed-up.
• Requirements amalgamation– Several different requirements may be expressed
together.
27Prof. Loganathan R., CSE, HKBKCE
A user requirement for accountingsystem in LIBSYS
4..5 LIBSYS shall provide a financial accountingsystem that maintains records of all paymentsmade by users of the system. System managersmade by users of the system. System managersmay configure this system so that regular usersmay receive discounted rates.
28Prof. Loganathan R., CSE, HKBKCE
A user requirement for Editor grid in LIBSYS
2.6 Grid facilities To assist in the positioning of entities on adiagram, the user may turn on a grid in either centimetres orinches, via an option on the control panel. Initially, the grid is off.The grid may be turned on and off at any time during an editingThe grid may be turned on and off at any time during an editingsession and can be toggled between inches and centimetres atany time. A grid option will be provided on the reduce-to-fit viewbut the number of grid lines shown will be reduced to avoidfilling the smaller diagram with grid lines.
29Prof. Loganathan R., CSE, HKBKCE
Requirement problems• Database requirements includes both conceptual and
detailed information– Describes the concept of a financial accounting system that is to
be included in LIBSYS;
– However, it also includes the detail that managers can configurethis system - this is unnecessary at this level.this system - this is unnecessary at this level.
• Grid requirement mixes three different kinds ofrequirement– Conceptual functional requirement is the need for a grid. It
presents rationale for this
– Non-functional requirement of grid units (inches/cm)
– Non-functional UI requirement grid switching(on/off)
30Prof. Loganathan R., CSE, HKBKCE
Definition of an editor grid facility
• Grid requirements are rewritten to focus on theessential system feature
2.6.1 Grid facilitiesThe editor shall provide a grid facility where a matrix of horizontaland vertical lines provide a background to the editor window. Thisgrid shall be a passive grid where the alignment of entities is the user's
31Prof. Loganathan R., CSE, HKBKCE
grid shall be a passive grid where the alignment of entities is the user'sresponsibility.
Rationale: A grid helps the user to create a tidy diagram with well-spaced entities. Although an active grid, where entities 'snap-to'grid lines can be useful, the positioning is imprecise. The user is thebest person to decide where entities should be positioned.
Specification: ECLIPSE/WS/Tools/DE/FS Section 5.6Source: Ray Wilson, Glasgow Office
Guidelines for writing User Requirements
• Invent a standard format and use it for allrequirements.
• Use language in a consistent way. Use shall formandatory requirements, should for desirablemandatory requirements, should for desirablerequirements.
• Use text highlighting(Bold, Italic or Colour) toidentify key parts of the requirement.
• Avoid the use of computer jargon.
32Prof. Loganathan R., CSE, HKBKCE
System requirements
• More detailed specifications of system functions,services and constraints than user requirements.
• They are intended to be a basis for designing thesystem.system.
• They may be incorporated into the systemcontract.
• Natural Language(NL) is often used to writesystem requirements specification as well as userrequirements.
33Prof. Loganathan R., CSE, HKBKCE
Inseparable : Requirements and design
• In principle, requirements should state what thesystem should do and the design should describehow it does this.
• In practice, requirements and design areinseparableinseparable– A system architecture may be designed to structure the
requirements;– The system may inter-operate with other systems that
generate design requirements;– The use of a specific design may be a domain
requirement.
34Prof. Loganathan R., CSE, HKBKCE
Problems with NL specification(Sys Req.)
• Ambiguity– The readers and writers of the requirement must
interpret the same words in the same way. NL isnaturally ambiguous so this is very difficult.
• Over-flexibility• Over-flexibility– The same thing may be said in a number of different
ways in the specification.
• Lack of modularisation– NL structures are inadequate to structure system
requirements.
35Prof. Loganathan R., CSE, HKBKCE
Notations for requirements specification• These can be used as alternatives to NL specification
Notation Description
Structured naturallanguage
This approach depends on defining standard forms or templates to express therequirements specification.
Design descriptionlanguages
This approach uses a language like a programming language but with moreabstract features to specify the requirements by defining an operational modelof the system. This approach is not now widely used although it can be useful
36Prof. Loganathan R., CSE, HKBKCE
of the system. This approach is not now widely used although it can be usefulfor interface specifications.
Graphical notations A graphical language, supplemented by text annotations is used to define thefunctional requirements for the system. An early example of such a graphicallanguage was SADT. Now, use-case descriptions and sequence diagrams arecommonly used .
Mathematicalspecifications
These are notations based on mathematical concepts such as finite-statemachines or sets. These unambiguous specifications reduce the argumentsbetween customer and contractor about system functionality. However, mostcustomers don’t understand formal specifications and are reluctant to accept itas a system contract.
Structured Language Specifications
• The freedom of the requirements writer is limitedby a predefined template for requirements.
• All requirements are written in a standard way.
• The terminology used in the description may be• The terminology used in the description may belimited.
• The advantage is that the most of theexpressiveness of natural language is maintainedbut a degree of uniformity is imposed on thespecification.
37Prof. Loganathan R., CSE, HKBKCE
Form-based Approach
• One or more standard forms/templates aredesigned to express the requirements. It shouldinclude the following information.– Description of the function or entity.
– Description of inputs and where they come from.
– Description of outputs and where they go to.
– Indication of what other entities required.
– Description of action to be taken.
– Pre and post conditions what must be true before & after function call(ifappropriate).
– Description the side effects (if any) of the function.
38Prof. Loganathan R., CSE, HKBKCE
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 isin 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
Form-based specification Example
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 therate of increase is decreasing. If the level is increasing and the rate of increase isincreasing, then CompDose is computed by dividing the difference between the currentsugar level and the previous level by 4 and rounding the result. If the result, is roundedto zero then CompDose is set to the minimum dose that can be delivered.
Requires Two previous readings so that the rate of change of sugar level can be computed.
Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin
Post-condition r0 is replaced by r1 then r1 is replaced by r2
Side-effects None39Prof. Loganathan R., CSE, HKBKCE
Tabular specification• Used to supplement natural language.
• Particularly useful when you have to define a number of possiblealternative courses of action.
• Example : Tabular specification of computation
Condition Action
40Prof. Loganathan R., CSE, HKBKCE
Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of increasedecreasing ((r2-r1)<(r1-r0))
CompDose = 0
Sugar level increasing and rate of increasestable or increasing. ((r2-r1) ≥ (r1-r0))
CompDose = round ((r2-r1)/4)If rounded result = 0 thenCompDose = MinimumDose
Graphical models
• Graphical models are most useful when you need to showhow state changes or where you need to describe asequence of actions.
• Example Sequence diagrams
• These show the sequence of events that take place during• These show the sequence of events that take place duringsome user interaction with a system.
• Read them from top to bottom to see the order of theactions that take place.
• Cash withdrawal from an ATM– Validate card : By checking the card number and user’s PIN
– Handle request : user requests are handled. Query database for withdrawal
– Complete transaction: return the card and deliver cash & receipt.41Prof. Loganathan R., CSE, HKBKCE
Sequence diagram of ATM withdrawal
Validate card
ATM Database
CardCard number
Card OKPIN request
PIN
Option menu
<<exception>>invalid card
Withdraw request Balance request
42Prof. Loganathan R., CSE, HKBKCE
Withdraw request
Amount request
Amount
Balance request
Balance
<<exception>>Insufficient cash
Debit (amount)
Debit response
Card
Card removed
Cash
Cash removed
Receipt
Handle request
Completetransaction
Interface specification
• Most systems must operate with other systemsand the operating interfaces must be specified aspart of the requirements.
• Three types of interface may have to be defined– Procedural interfaces : ;– Procedural interfaces : APIs;
– Data structures : Passed from one subsystem to another
– Data representations (ordering of bits) : for existingsubsystem
• Formal notations(Program Design Language - PDL)are an effective technique for interfacespecification.
43Prof. Loganathan R., CSE, HKBKCE
PDL interface description
interface PrintServer {// defines an abstract printer server// requires: interface Printer, interface PrintDoc// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter
void initialize ( Printer p ) ;void print ( Printer p, PrintDoc d ) ;
44Prof. Loganathan R., CSE, HKBKCE
void print ( Printer p, PrintDoc d ) ;void displayPrintQueue ( Printer p ) ;void cancelPrintJob (Printer p, PrintDoc d) ;void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;
} //PrintServer
The Software Requirements Document
• The requirements document is the officialstatement of what is required of the systemdevelopers.
• Should include both a definition of user• Should include both a definition of userrequirements and a specification of the systemrequirements.
• It is NOT a design document. As far as possible, itshould set of WHAT the system should do ratherthan HOW it should do it
45Prof. Loganathan R., CSE, HKBKCE
Users of a requirements document
Use the requirements
document to plan a bid for
the system and to plan the
system development process
Managers
SystemCustomers
Specify the requirements and
read them to check that they
meet their needs. They
specify changes to the
requirements
46Prof. Loganathan R., CSE, HKBKCE
System TestEngineers
Use the requirements to
develop validation tests for
the system
Use the requirements to
understand what system is to
be developed
SystemEngineers
SystemMaintenance
Engineers
Use the requirements to help
understand the system and
the relationships between itsparts
IEEE requirements standard• Defines a structure for a requirements document.
1. Introduction.1.1 Purpose of the requirements document
1.2 Scope of the product
1.3 Definition, acronyms & abbreviations
1.4 References
1.5 Overview of the remainder of the document
2. General description.2. General description.2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions & dependencies
3. Specific requirements.(covers functional, non-functional & interface requirements)
4. Appendices.
5. Index.
47Prof. Loganathan R., CSE, HKBKCE
Requirements document structure• Organisation for a requirements document based on IEEE standard
– Preface : Defines expected readership, version history & changes in each version
– Introduction : Describes the needs of the system
– Glossary : Defines technical terms used in the document
– User requirements definition : Describes services provided & non-functional requirementsfunctional requirements
– System architecture : Presents high level overview of system
– System requirements specification : Describes functional & non-functional requirements in detail
– System models : Provides 1 or more system models
– System evolution : Describes anticipated changes
– Appendices
– Index48Prof. Loganathan R., CSE, HKBKCE