software req
TRANSCRIPT
-
8/3/2019 Software Req
1/39
LECTURE 3
SOFTWARE REQUIREMENTS
CSE 2142 Software Engineering
-
8/3/2019 Software Req
2/39
Objectives
To introduce the concepts of requirements
To describe functional /non-functionalrequirements
To explain techniques for describing
requirements.
To explain how software requirements may
be organised in a requirements document.
2
-
8/3/2019 Software Req
3/39
Introduction
In engineering a requirement is a singulardocumented need of what a particular productor service should be or perform.
It is a statement that identifies a necessaryattribute, capability, characteristic, or quality of asystem in order for it to have value and utility toa user.
The sets of requirements are used as inputs into
the design stages of product development.
3
-
8/3/2019 Software Req
4/39
Introduction
Requirements are also an important input intothe verification process, since tests should traceback to specific requirements.
Requirements show what elements andfunctions are necessary for the particularproject.
4
-
8/3/2019 Software Req
5/39
The notion of a requirement
Requirement Engineering : The process of
establishing the services that the customer requires
from a system and the constraints under which it
operates and is developed
Definition of Requirement [IEEE]:
a condition or capability needed by a user to solve a
problem or achieve an objective
a condition or capability that must be met or possessed by
a system or system component to satisfy a contract,
standard, specification or other formally imposed
documents
5
-
8/3/2019 Software Req
6/39
Types of requirement (1)
Requirements must be presented in alternative, but
consistent forms that are understandable to different
audiences. May range from a high-level abstract
statement of a service or of a system constraint to a
detailed mathematical functional specification.
1. User requirements: Statements in natural language,
diagrams of the services the system provides and its
operational constraints that are written for customers
6
-
8/3/2019 Software Req
7/39
Types of requirement(2)
1. System requirements: A structured document
setting out detailed descriptions of the systems
services and constraints. This document is usually
written as a contract between the client and the
contractor.
2. Software design specification: A detailed software
description which can serve as a basis for design and
implementation. This design specification is written
for developers and is usually a detailed version of the
system requirements.
7
-
8/3/2019 Software Req
8/39
Example8
-
8/3/2019 Software Req
9/39
Readers of Requirements
System customers:Specify therequirements and then read tocheck that the requirementsmeet their needs.
Managers : Use requirement
document to estimate a price forthe system and also plan theproject.
System Engineers: Use therequirements to understand whatsystem is to be developed.
System test engineers: Use therequirement to develop validationtests.
System Maintenanceengineers: Use requirement
document to understand the
9
UserRequirements
Client managersSystem end-usersClient engineersContractmanagersSystem architects
System end-usersClient engineersSystemarchitects
SoftwareDeveloper
SystemRequirements
SoftwareDevelopersClient engineersSystemarchitects
Softwaredesignspecification
-
8/3/2019 Software Req
10/39
Requirements Classification(1)
User Requirements Should describefunctional and non-functional requirementsso that they are understandable by system
users who dont have detailed technicalknowledge
Functional requirements:
A functional requirement is a description of whata system must do.
It is written down as statements of services thatthe software should provide, how the software
should react to particular inputs and how the
10
-
8/3/2019 Software Req
11/39
Requirements Classification(2)
Non-functional requirements:
Non functional requirement specifies somethingabout the software itself, and how well it performs
its functions. constraints on the services or functions offered by
the software, such as, timing constraints,constraints on the development process, standards,
and so on.
11
-
8/3/2019 Software Req
12/39
Functional Requirements
Functional requirements are statements that
describe the functionality that the system is toexecute; for example, formatting some text.
Descriptions of data to be entered into the system
Descriptions of operations performed.
Examples:
The user shallbe able to search either all of the initial
set of databases or select a subset from it The system shallprovide appropriate viewers for the
user to read documents in the document store
Every order shallbe allocated a unique identifierwhich the user shall be able to copy to the accounts
permanent storage area.
12
-
8/3/2019 Software Req
13/39
Requirements imprecision (1)
Problems arise when requirements are not preciselystated
Ambiguous requirements may be interpreted in differentways by developers and users
Consider the term appropriate viewers
User intention - special purpose viewer for eachdifferent document type
Developer interpretation - Provide a text viewer thatshows the contents of the document
In principle requirements should be both completeand consistent
13
-
8/3/2019 Software Req
14/39
Requirements imprecision(2)
Complete
They should include descriptions of all facilitiesrequired
Consistent There should be no conflicts or contradictions in the
descriptions of the system facilities
In practice, it is very difficult or impossible to produce a
complete and consistent requirements document
14
-
8/3/2019 Software Req
15/39
Non-Functional Requirements
Non functional requirements are those requirements arethe ones that act to constrain the solution.
Quality attribute
requirements(Dependability,Performance,Accuracy,Security)
Project Constraints (Maximum cost,Maximumschedule)
Design directives(sorting shall be done usingQuicksort algorithm)
Implementation directives (Software shall be written inC)
15
-
8/3/2019 Software Req
16/39
NFR Classification16
-
8/3/2019 Software Req
17/39
Verifiable NFR
Non-functional requirements may be very difficult tostate precisely and imprecise requirements may bedifficult to verify.
A verifiable non-functional requirement
Experienced controllers shall be able to use all thesystem functions after a total of two hours training.After this training, the average number of errors madeby experienced users shall not exceed two per day.
The table in the next slide give some measures thatcan be used to specify non-functional requirementsthat can be verified.
17
-
8/3/2019 Software Req
18/39
Requirement Measures18
-
8/3/2019 Software Req
19/39
Non-Functional Requirements
Design constraints include the fact that the softwaremust run using a certain database system or that thesoftware must fit into the memory of a 512Kbytemachine.
Performance requirements: for example 95% ofcatalogue database queries shall be completed within 2seconds.
Security: Access to student records shall be password-protected so that only authorized people can view them.
Reliability requirements: for instance, the acceptablefailure rate or the amount of time that the system will
19
-
8/3/2019 Software Req
20/39
Non-Functional Requirements
Usability requirements: The interface shall bemenu-driven, so that it is easy to learn and use.
Design directives: They tell the developer how
to design certain functionality of the software.For example, The sorting of the student recordsshall be done using Quicksort algorithm.
Implementation directives: They tell thedeveloper what to use to implement certainfunctionality of the software. For example, TheSoftware shall be written in java such that it canbe portable onto different operating system
platform.
20
-
8/3/2019 Software Req
21/39
Characteristics of goodrequirement
21
Unitary (Cohesive)The requirement addresses one andonly one thing.
CompleteThe requirement is fully stated in oneplace with no missing information.
ConsistentThe requirement does not contradictany other requirement
Non-Conjugated(Atomic)
The requirement is atomic, i.e., it doesnot contain conjunctions. E.g., "The
postal code field must validateAmerican andCanadian postal codes"should be written as two separaterequirements: (1) "The postal code field
must validate American postal codes"and (2) "The postal code field must
-
8/3/2019 Software Req
22/39
Characteristics of goodrequirement
22
TraceableThe requirement meets all or part of a businessneed as stated by stakeholders andauthoritatively documented.
FeasibleThe requirement can be implemented within the
constraints of the project.
Unambiguous
The requirement is concisely stated withoutrecourse to technical jargon, acronyms (unlessdefined elsewhere in the Requirementsdocument).
Mandatory
The requirement represents a stakeholder-defined characteristic the absence of which willresult in a deficiency that cannot beameliorated.
Verifiable
The implementation of the requirement can be
determined through one of four possiblemethods: inspection, demonstration, test or
-
8/3/2019 Software Req
23/39
Guidelines for writing
requirements(1)
Invent a standard format for numbering therequirement. The simplest approach is to give everyrequirement a unique sequence number, such as UR-2or SRS13. The most commonly used convention is
hierarchical numbering. If the functional requirementsappear in section 3.2 of your requirement document,they will all have labels that start by 3.2, for example,3.2.1 The system shall compute the salary ofemployee based on the time-sheet.
Use language consistently; for example, definemandatory requirement using shall and desirablerequirement using should.
23
-
8/3/2019 Software Req
24/39
Guidelines for writing
requirements(2)
Avoid, as far as possible, the use of computer jargon todescribe requirement. However, it will be inevitablewhen providing technical details.
To reduce ambiguity, avoid vague, subjective termssuch as user-friendly, easy, simple, rapid,efficient,support,several,superior,acceptable,and robust. Find out what the customers really meanwhen they say user-friendly or fast or robust and
state those expectations in the requirements.
Avoid comparative words such as improve,maximize, minimize, and optimize. Quantify the
degree of improvement that is needed, or state the
24
-
8/3/2019 Software Req
25/39
Requirements Analysis (1)
Analyse requirements in order to identify &
Resolve:
Ambiguities : different interpretations of naturallanguage
E.g: If the central computer receives an alarm signal from
the
local process-control computer, it will shut down.
Platitudes: Vague FRs and non-measurable NFRs
which leads to untestable/untraceable requirements
E.g: System shall be user-friendly, System shall be
25
-
8/3/2019 Software Req
26/39
Requirements Analysis (2)
Inconsistencies: Contradictory statements
After validating input lists, only alphabetically sorted lists remain.
Later on: If a validated list is not in alphabetical order, an error
message shall be displayed
Mixtures of abstraction : Different levels of detail in the same section
The PAYROLL subsystem performs all the functions related to staff
payment. The OVERTIME module computes the overtime paymentfor the employee currently being processed based on the time-sheet
for the current week.
FRs and NFRs mixed up
The OVERTIME subsystem shall be written in Java and computes the
overtime for an employee based on his time-sheet.
26
-
8/3/2019 Software Req
27/39
Requirements interaction
Conflicts between different non-functional requirements arecommon in complex systems
Spacecraft system
To minimise weight, the number of separate chipsin the system should be minimised
To minimise power consumption,
lower power chips should be used
However, using low power chips
may mean that more chips have
to be used.
Which is the most critical requirement?
27
P bl i h l l
-
8/3/2019 Software Req
28/39
Problems with natural language(1) Lack of clarity
Precision is difficult without making the documentdifficult to read
Requirements confusion
Functional and non-functional requirements tend to bemixed-up
Requirements amalgamation Several different requirements may be expressed
together
28
P bl ith t l
-
8/3/2019 Software Req
29/39
Problems with naturallanguage(2) Ambiguity
The readers and writers of the requirement mustinterpret the same words in the same way. NL isnaturally ambiguous so this is very difficult
Over-flexibility
The same thing may be said in a number of differentways in the specification
Lack of modularisation
NL structures are inadequate to structure systemrequirements
29
-
8/3/2019 Software Req
30/39
Alternative to Natural Language
Structural natural language: This approach depends ondefining standard forms or templates to express therequirements specification.
Design description language: It uses a language likeprogramming language but with more abstract features tospecify the requirement by defining an operational model ofthe system.
Graphical notations: A graphical language, supplementedby test annotations is used to define the functionalrequirements for the system. The most common graphicalrepresentation is Use-Case
Formal specifications:Requirements are specified, byusing mathematically precise formal logic languages ornotations based on mathematical concepts such as finite-state machines or sets.
30
St t d l
-
8/3/2019 Software Req
31/39
Structured languagespecifications
A limited form of natural language may be usedto express requirements
Often best supported using a Form-based
specifications, Special-purpose forms wheredesigned to describe the input, output andfunctions of a software system Definition 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)
31
-
8/3/2019 Software Req
32/39
32
PDL based specifications
Requirements may be defined operationally using a language like aprogramming language but with more flexibility of expression
Most appropriate in two situations
Where an operation is specified as a sequence of actions and the
order is important When hardware and software interfaces have to be specified
Disadvantages are
The PDL may not be sufficiently expressive to define domainconcepts
The specification will be taken as a design rather than aspecification.
PDL may not be sufficiently expressive to express the systemfunctionality in an understandable way
Notation is only understandable to people with programminglanguage knowledge
S ft R i t
-
8/3/2019 Software Req
33/39
Software RequirementsSpecification Software Requirements Specification (SRS): It is the official statement of what is required of the
system developers. The requirements are recorded inone or more form including natural language, formal,symbolic or graphical representations.
The primary purposes of documentingrequirements in only one document is to ensurethat: Customers and developers have the same understanding
of what is to be built.
All developers have identical understanding of what is tobe built.
Testers are testing for the same qualities that developersare building.
Management is applying resources to the same set of
33
-
8/3/2019 Software Req
34/39
34
Requirements Specifications
1.The software shall provide a means of representingand accessing external files created by other tools
1.1 The user should be provided with facilities to define thetype of external files
1.2 Each external file type may have an associated toolwhich may be applied to the file
1.3 Each external files type may be presented as a specificicon on the users display
The specifications adds detail to the requirementsdefinition and should be consistent with therequirements definition. Usually presented withsystem models
-
8/3/2019 Software Req
35/39
35
Audiences for SRS(1)
Customers and the marketing department rely onthe SRS to know what product they can expect to bedelivered.
Project managers base their plans and estimates ofschedule, effort, and resources on the productdescription contained in the SRS.
The software development team relies on the SRSto understand what is to be built.
The testing group uses the product behaviordescriptions contained in the SRS to derive testplans, cases, and procedures.
-
8/3/2019 Software Req
36/39
36
Audiences for SRS(2)
Software maintenance and support staff refer to theSRS to understand what each part of the product issupposed to do.
The publications group writes user documentation,such as manuals and help screens, based on boththe SRS and the user interface design.
Training personnel can use both the SRS and theuser documentation to help them developeducational materials.
-
8/3/2019 Software Req
37/39
37
Characteristics of Document
Correct : Free from errors
Unambiguous, precise & clear : One and onlyone interpretation for every requirement
Complete : All requirements for the problem identified &specified
Testable : By quantitative means
Consistent : No conflicting requirements
Modifiable: This attribute is more concerned with theformat & style of the SRS rather than the actual requirementsthemselves
Traceable : Backward & Forward traceability
-
8/3/2019 Software Req
38/39
Guidelines(1)38
Introduction
Purpose of document Intended audience, how is the SRS document tobe used?
Scope What are the boundaries of the specifiedsystem?
Definitions & notations: High-level definitions used throughout documente.g. Acct. No., TRX, Ref. No.
References Sources of information concerning the currentsystem.
GeneralDescription
Product perspective Context diagram, relationship between system &its environment
Product functions Brief description of the primary functions
Characteristics of eventual users Required background or training
Constraints Hardware limitations, Implementation &
language requirements
-
8/3/2019 Software Req
39/39
Guidelines(2)39
System Architecture Present a high-level overview of theanticipated system architecture showing thedistribution of functions across systemmodules
Specific Requirements Functional Requirements: Can be expressed
by using natural language, formal, symbolicor graphical representationsNon functional Requirements: Can beexpressed using natural language, formal,symbolic or graphical representations.
AppendicesProvide detailed, specific informationwhich is related to the application whichis being developed. (Hardwaredescriptions)
Index Page numbers of important section and sub-sections