What is a requirement?

• May range from

– a high-level abstract statement of a service
or

Software Requirements – a statement of a system constraint to a

detailed mathematical functional specification
• Requirements may be used for
– a bid for a contract
Descriptions and specifications • must be open to interpretation
of a system – the basis for the contract itself
• must be defined in detail
• Both the above statements may be called
requirements

Example Example
ECLIPSE/Workstation/Tools/DE/FS/3.5.1

Function Add node

Description Adds a node to an existing design. The user selects the type of node, and its position.
When added to the design, the node becomesthe current selection. The user chooses the node position by
moving the cursor to the area where the node is added.
Inputs Node type, Node position, Design identifier. ……
……
Source Node type and Node position are input by the user, Design identifier from the database. 4.A.5
4.A.5 The
Thedatabase
databaseshall
shallsupport
supportthethegeneration
generationand
andcontrol
controlof
of
Outputs Design identifier. configuration
configurationobjects;
objects;that
thatis,
is,objects
objectswhich
whichare
arethemselves
themselvesgroupings
groupings
Destination The design database. The design is committed to the database on completion of the
operation.
of
ofother
otherobjects
objectsin
inthe
thedatabase.
database.The
Theconfiguration
configurationcontrol
controlfacilities
facilities
Requires Design graph rooted at input design identifier. shall
shallallow
allowaccess
accesstotothe
theobjects
objectsininaaversion
versiongroup
groupby
bythe
theuse
useofofanan
Pre-condition The design is open and displayed on the user's screen. incomplete
incompletename.
name.
Post-condition The design is unchanged apart from the addition of a node of the specified type ……
……
at the given position.
Side-effects None
Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1

Types of requirements User requirements readers

• Written for customers • Client managers
– User requirements
• Statements in natural language plus diagrams of the • System end-users
services the system provides and its operational
constraints. • Client engineers
• Written as a contract between client and • Contractor managers
contractor
– System requirements • System architects
• A structured document setting out detailed
descriptions of the system services.
• Written for developers
– Software specification
• A detailed software description which can serve as a
basis for a design or implementation.

1
System requirements readers Software specification readers
• System end-users • Client engineers (maybe)
• Client engineers • System architects
• System architects • Software developers
• Software developers

Functional requirements
• Statements of services the system
should provide, how the system
We will come back to user should react to particular inputs
and how the system should behave
and system requirements
in particular situations.

Examples of functional
Functional requirements
requirements
• Describe functionality or system services 1.
1. The
The user
user shall
shall be
be able
able to
to search
search either
either
• Depend on the type of software, all
all of
of the
the initial
initial set
set of
of databases
databases oror
expected users and the type of system select
select aa subset
subset from
from it.
it.
where the software is used 2.
2. The
The system
system shall
shall provide
provide appropriate
appropriate
• Functional user requirements may be viewers
viewers forfor the
the user
user to
to read
read documents
documents
high-level statements of what the in
in the
the document
document store.
store.
system should do but functional system 3.
3. Every
Every order
order shall
shall be
be allocated
allocated aa unique
unique
requirements should describe the system identifier
identifier (ORDER_ID)
(ORDER_ID) which which the
the user
user
services in detail shall
shall be
be able
able toto copy
copy to
to the
the account’s
account’s
permanent
permanent storage
storage area.
area.

2
 Requirements completeness and
Requirements imprecision
consistency
• Problems arise when requirements are • In principle, requirements should be both
not precisely stated complete and consistent
• Ambiguous requirements may be • Complete
interpreted in different ways by – They should include descriptions of all
facilities required
developers and users
• Consistent
• Consider the term ‘appropriate viewers’ – There should be no conflicts or
– User intention - special purpose viewer for contradictions in the descriptions of the
each different document type system facilities
– Developer interpretation - Provide a text • In practice, it is difficult (?impossible?)
viewer that shows the contents of the to produce a complete and consistent
document requirements document

What requirements are these? Non-functional requirements

•• It
It shall
shall be
be possible
possible for
for all
all necessary
necessary • constraints on the services or
communication
communication between
between the
the APSE
APSE and
and functions offered by the system
the
the user
user toto be
be expressed
expressed in in the
the standard
standard
Ada
Ada character
character setset
such as timing constraints,
•• The
The system
system development
development process
process andand constraints on the development
deliverable
deliverable documents
documents shall
shall conform
conform toto process, standards, etc.
the
the process
process andand deliverables
deliverables defined
defined in
in
XYZCo-SP-STAN-95
XYZCo-SP-STAN-95
•• The
The system
system shall
shall not
not disclose
disclose anyany
personal
personal information
information about
about customers
customers
apart
apart from
from their
their name
name and
and reference
reference
number
number to to the
the operators
operators ofof thethe system
system

Non-functional requirements Non-functional classifications

• Define system properties and constraints • Product requirements
e.g. reliability, response time and – Requirements which specify that the
storage requirements. Constraints are delivered product must behave in a particular
I/O device capability, system way e.g. execution speed, reliability, etc.
representations, etc. • Organizational requirements
• Process requirements may also be – Requirements which are a consequence of
specified mandating a particular system, organizational policies and procedures e.g.
process standards used, implementation
programming language or development requirements, etc.
method
• External requirements
• Non-functional requirements may be – Requirements which arise from factors which
more critical than functional are external to the system and its
requirements. If these are not met, the development process e.g. interoperability
system is useless requirements, legislative requirements, etc.

3
Non-functional requirement Non-functional requirements
types examples
Non-functional
Requirements • Product requirement
– 4.C.8 It shall be possible for all necessary
Product
Requirements
Organizational
Requirements
External
Requirements
communication between the APSE and the user to
be expressed in the standard Ada character set
Usability Delivery Interoperability • Organizational requirement
Requirements Requirements Requirements
– 9.3.2 The system development process and
Efficiency Implementation Ethical deliverable documents shall conform to the
process and deliverables defined in XYZCo-SP-
Requirements Requirements

Performance Space
Standards Legislative STAN-95
Requirements Requirements
Requirements Requirements
• External requirement
Reliability Privacy Safety – 7.6.5 The system shall not disclose any personal
Requirements Requirements Requirements
information about customers apart from their
Portability name and reference number to the operators of
Requirements
the system

Goals and requirements Examples

• Non-functional requirements may be very • A system goal
difficult to state precisely and imprecise – The system should be easy to use by
requirements may be difficult to verify. experienced controllers and should be
organized in such a way that user errors are
• Goal minimized.
– A general intention of the user such as ease
of use • A verifiable non-functional requirement
– Experienced controllers shall be able to use
• Verifiable non-functional requirement all the system functions after a total of two
– A statement using some measure that can be hours training. After this training, the
objectively tested average number of errors made by
• Goals are helpful to developers as they experienced users shall not exceed two per
convey the intentions of the system day.
users

Requirements measures Requirements interaction

Property Measure • Conflicts between different non-
Speed •Processed transactions/second functional requirements are common in
•User/event response time
•Screen refresh time complex systems
Size •K Bytes • Spacecraft system
•Number of RAM chips
Ease of use •Training time – To minimize weight, the number of separate
•Number of help frames chips in the system should be minimized
Reliability •Mean time to failure – To minimize power consumption, lower power
•Probability of unavailability
•Rate of failure occurrence
chips should be used
•Availability – However, using low power chips may mean
Robustness •Time to restart after failure that more chips have to be used. Which is
•Percentage of events causing failure
the most critical requirement?
•Probability of data corruption on failure
Portability •Percentage of target dependent statements
•Number of target systems

4
 Domain requirements Domain requirements
• Requirements that come from the • Derived from the application domain and
application domain of the system describe system characteristics and
and that reflect characteristics of features that reflect the domain
that domain • May be new functional requirements,
constraints on existing requirements or
define specific computations
• If domain requirements are not
satisfied, the system may be unworkable

Library system domain

Domain requirements problems
requirements
• There shall be a standard user interface • Understandability
to all databases which shall be based on – Requirements are expressed in the
the Z39.50 standard. language of the application domain
• Because of copyright restrictions, some – This is often not understood by
documents must be deleted immediately software engineers developing the
on arrival. Depending on the user’s system
requirements, these documents will • Implicitness
either be printed locally on the system – Domain specialists understand the area
server for manually forwarding to the so well that they do not think of
user or routed to a network printer. making the domain requirements
explicit

User requirements
• Should describe functional and non-
functional requirements so that
Back to user and system they are understandable by system
requirements users who don’t have detailed
technical knowledge
• User requirements are defined using
natural language, tables and
diagrams

5
 Database requirement Requirement problems
• Database requirements includes
both conceptual and detailed
……
…… information
4.A.5
4.A.5 The
Thedatabase
databaseshall
shallsupport
supportthethegeneration
generationand
andcontrol
controlof
of – Describes the concept of configuration
configuration
configurationobjects;
objects;that
thatis,
is,objects
objectswhich
whichare
arethemselves
themselvesgroupings
groupings control facilities
of
ofother
otherobjects
objectsin
inthe
thedatabase.
database.The
Theconfiguration
configurationcontrol
controlfacilities
facilities
shall
shallallow
allowaccess
accesstotothe
theobjects
objectsininaaversion
versiongroup
groupby
bythe
theuse
useofofanan – Includes the detail that objects may
incomplete
incompletename.
name. be accessed using an incomplete name
……
……

Editor grid requirement Requirement problems

• Grid requirement mixes three
……
…… different kinds of requirement
2.6
2.6Grid
Gridfacilities
facilitiesTo
Toassist
assistin
inthe
thepositioning
positioningof ofentities
entitieson
onaadiagram,
the
diagram, – Conceptual functional requirement (the
theuser
usermay
mayturn
turnononaagrid
gridin
ineither
eithercentimetres
centimetresor orinches,
inches,via
viaan
an
option
option on the control panel. Initially, the grid is off. The grid maybe
on the control panel. Initially, the grid is off. The grid may be
need for a grid)
turned
turned on and off at any time during an editing session and canbe
on and off at any time during an editing session and can be – Non-functional requirement (grid units)
toggled
toggledbetween
betweeninches
inchesand
andcentimetres
centimetresatatanyanytime.
time.AAgrid
gridoption
will
option – Non-functional UI requirement (grid
willbe
beprovided
providedon onthe
thereduce-to-fit
reduce-to-fitview
viewbut
butthe
thenumber
numberof ofgrid
grid
lines switching)
linesshown
shownwill
willbebereduced
reducedtotoavoid
avoidfilling
fillingthe
thesmaller
smallerdiagram
diagram
with
withgrid
gridlines.
lines.
……
……

Problems with natural language

• Lack of clarity
– Precision is difficult without making
the document difficult to read
Why the problems? • Requirements confusion
– Functional and non-functional
requirements tend to be mixed-up
• Requirements mix-up
– Several different requirements may
be expressed together

6
 Structured presentation Detailed user requirement

2.6 Grid facilities 3.5.1 Adding nodes to a design

2.6.1 The editor shall provide a grid facility where a 3.5.1.1 The editor shall provide a f acility for users to add nodes of a specified type to their
design.
matrix of horizontal and vertical lines provide a
3.5.1.2 The sequence of actions to add a node should be as follows:
background to the editor window. T his grid shall be
a p assive grid where the alignment of entities is the 1. The user should select the type of node to be added.
user's responsibility. 2. The user should move the cursor to the approximate node position in the diagram and
indicate that the node symbol should be added at that point.
Rationale: A grid helps the user to create a tidy
3. The user should then drag the node symbol to its final position.
diagram with well-spaced entities. Although an active
Rationale: The user is the best person to decide where to position a node on the diagram.
grid, where entities 'snap-to' grid lines can be useful, This approach gives the user direct control over node type selection and positioning.
the positioning is imprecise. The user is the best person Specification: ECLIPSE/WS/Tools/DE/FS. Section 3.5.1
to decide where entities should be positioned.
Specification: ECLIPSE/WS/Tools/DE/FS Section 5.6

Guidelines for writing

System requirements
requirements
• Invent a standard format and use it • More detailed specifications of user
for all requirements requirements
• Use language in a consistent way. • Serve as a basis for designing the
Use “shall” for mandatory system
requirements, “should” for desirable • May be used as part of the system
requirements contract
• Use text highlighting to identify
key parts of the requirement
• Avoid the use of computer jargon

Problems with NL specification Alternatives to NL specification

• Ambiguity Notation Description
Structured This approach depends on defining standard forms or
– The readers and writers of the requirement natural templates to express the requirements specification.
must interpret the same words in the same language
Design This approach uses a language like a programming language
way. NL is naturally ambiguous so this is description but with more abstract features to specify the requirements
very difficult languages by defining an operational model of the system.
Graphical A graphical language, supplemented by text annotations is
• Over-flexibility notations used to define the functional requirements for the system.
An early example of such a graphical language was SADT
– The same thing may be said in a number of (Ross, 1977; Schoman and Ross, 1977). More recently, use-
different ways in the specification case descriptions (Jacobsen, Christerson et al., 1993) have
been used. I discuss these in the following chapter.
• Lack of modularisation Mathematical
specifications
These are notations based on mathematical concep ts such
as finite-state machines or sets. These unambiguous
– NL structures are inadequate to structure specifications reduce the arguments between customer and
contractor about system functionality. Howeve r, most
system requirements customers don’t understand formal specifications and are
reluctant to accept it as a system contract. I discuss formal
specification in Chapter 9.

7
 Structured language
Form-based specifications
specifications
• A limited form of natural language • Definition of the function or entity
may be used to express • Description of inputs and where
requirements they come from
• This removes some of the problems • Description of outputs and where
resulting from ambiguity and they go to
flexibility and imposes a degree of • Indication of other entities required
uniformity on a specification • Pre and post conditions (if
• Often best supported using a appropriate)
forms-based approach • The side effects (if any)

PDL-based requirements
Form-based node specification
definition
• Requirements may be defined using a
ECLIPSE/Workstation/Tools/DE/FS/3.5.1
language like a programming language but
Function Add node
with more flexibility of expression
Description Adds a node to an existing design. The user selects the type of node, and its position.
When added to the design, the node becomesthe current selection. The user chooses the node position by
moving the cursor to the area where the node is added.
• Most appropriate in two situations
Inputs Node type, Node position, Design identifier.
• Where an operation is specified as a sequence of
actions and the order is important
Source Node type and Node position are input by the user, Design identifier from the database.
Outputs Design identifier.
• When hardware and software interfaces have to be
specified
Destination The design database. The design is committed to the database on completion of the
operation. • Disadvantages are
– The program definition language (PDL) may
Requires Design graph rooted at input design identifier.

not be sufficiently expressive to define

Pre-condition The design is open and displayed on the user's screen.

domain concepts
Post-condition The design is unchanged apart from the addition of a node of the specified type
at the given position.
Side-effects None – The specification will be taken as a design
Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1
rather than a specification

Part of an ATM specification PDL disadvantages

• PDL may not be sufficiently expressive
to express the system functionality in an
understandable way
class ATM {
// declarations here
public static void main (String args[]) throws InvalidCard {
try {
thisCard.read () ; // may throw InvalidCard exception • Notation is only understandable to people
with programming language knowledge
pin = KeyPad.readPin () ; attempts = 1 ;
while ( !thisCard.pin.equals (pin) & attempts < 4 )
{ pin = KeyPad.readPin () ; attempts = attempts + 1 ;
}
if (!thisCard.pin.equals (pin)) • The requirement may be taken as a
throw new InvalidCard ("Bad PIN");
thisBalance = thisCard.getBalance () ; design specification rather than a model
to help understand the system
do { Screen.prompt (" Please select a service ") ;
service = Screen.touchKey () ;
switch (service) {
case Services.withdrawalWithReceipt:
receiptRequired = true ;

8
 Interface specification PDL interface description
• Most systems must operate with other
systems and the operating interfaces
must be specified as part of the interface PrintServer {
requirements // defines an abstract printer server
• Three types of interface may have to be // requires: interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter
defined
void initialize ( Printer p ) ;
– Procedural interfaces void print ( Printer p, PrintDoc d ) ;

– Data structures that are exchanged

void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
– Data representations void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;
} //PrintServer
• Formal notations are an effective
technique for interface specification

Viewpoint-oriented elicitation Banking ATM system

• Stakeholders represent different • The example used here is an auto-teller
system which provides some automated
ways of looking at a problem or banking services
problem viewpoints • I use a very simplified system which
• This multi-perspective analysis is offers some services to customers of the
important as there is no single bank who own the system and a narrower
range of services to other customers
correct way to analyze system
• Services include cash withdrawal,
requirements message passing (send a message to
request a service), ordering a statement
and transferring funds

Autoteller viewpoints Types of viewpoints

• Bank customers – Data sources or sinks
• Viewpoints are responsible for producing or consuming
• Representatives of other banks data.
• Hardware and software maintenance • Analysis involves checking that data is produced and
consumed and that assumptions about the source and
engineers sink of data are valid
• Marketing department – Representation frameworks
• Bank managers and counter staff • Viewpoints represent particular types of system
model.
• Database administrators and security • These may be compared to discover requirements
staff that would be missed using a single representation.
Particularly suitable for real-time systems
• Communications engineers – Receivers of services
• Personnel department • Viewpoints are external to the system and receive
services from it.
• Most suited to interactive systems

9
 External viewpoints Method-based analysis
• Natural to think of end-users as • Widely used approach to requirements
receivers of system services analysis. Depends on the application of a
structured method to understand the
• Viewpoints are a natural way to system
structure requirements elicitation • Methods have different emphases. Some
• It is relatively easy to decide if a are designed for requirements elicitation,
viewpoint is valid others are close to design methods
• Viewpoints and services may be • A viewpoint-oriented method (VORD) is
used to structure non-functional used as an example here. It also
illustrates the use of viewpoints
requirements

The VORD method VORD process model

• Viewpoint identification
Viewpoint
Viewpoint
Identification
– Discover viewpoints which receive system
Identification services and identify the services provided to
each viewpoint
Viewpoint
Viewpoint
Structuring
• Viewpoint structuring
Structuring
– Group related viewpoints into a hierarchy.
Common services are provided at higher-
Viewpoint
Viewpoint levels in the hierarchy
Documentation
Documentation
• Viewpoint documentation
– Refine the description of the identified
Viewpoint
Viewpoint
System
viewpoints and services
System
Mapping
Mapping • Viewpoint-system mapping
– Transform the analysis to an object-oriented
design

VORD standard forms Viewpoint identification

Viewpoint template Service template Query Get Customer Cash Transaction
Reference: The viewpoint name. Reference: The service name. balance transactions database withdrawal log
Attributes: Attributes providing Rationale: Reason why the service is
viewpoint information. provided. Manager Card Remote
Machine returning Order
Events: A reference to a set of event Specification: Reference to a list of service software
scenarios describing how specifications. These may supplies cheques
upgrade
the system reacts to be expressed in different Account Message Software
viewpoint events. notations. information log size Bank Invalid
Services A reference to a set of Viewpoints: List of viewpoint names User teller user
service descriptions. receiving the service. interface System cost Foreign
Sub-VPs: The names of sub- Non-functional Reference to a set of non - customer Printe
viewpoints. requirements: functional requirements r Security
which constrain the service. Account Stolen Order Hardware
Provider: Reference to a list of system card statement Card
holder maintenance retention
objects which provide the Message
service. passing
Remote Update Funds Card
Reliability account transfer
diagnostics validation

10
 Viewpoint service information Viewpoint data/control
Account Holder Foreign Customer Bank Teller
Service List Service List Service List
Account Control Input Data Input
1. Withdraw cash 1. Withdraw cash 1. Run diagnostics Holder
2. Query balance 2. Query balance 2. Add cash 1. Start transaction 1. Card details
3. Order checks 3. Add paper 2. Cancel transaction 2. PIN
4. Send message 4. Send Message 3. End transaction 3. Amount required
5. Transaction list 4. Select service 4. Message
6. Order statement
7. Transfer funds

Customer/cash withdrawal
Viewpoint hierarchy templates
•• Reference
Reference
Services All VPs •• Reference
Reference
–– Cash
Cash withdrawal
withdrawal
–– Customer •• Rationale
Rationale
Customer
Withdraw cash –– To
To improve
improve customer
customer service
•• Attributes
Attributes and
service
Query balance
Customer Bank staff and reduce
reduce paperwork
paperwork
–– Account
Account number
number •• Specification
Specification
–– PIN
PIN –– Users
Users choose
choose this
this service
service byby
Account Foreign Teller Manager Engineer –– Start transaction pressing
pressing the
the cash
cash withdrawal
Services Start transaction withdrawal
holder customer button.
button. They
They then
then enter
enter the
•• Events
Events amount
the
Order checks amount required.
required. ThisThis isis
–– Select
Select service
service confirmed
confirmed and,
and, ifif the
the funds
funds
Send message –– Cancel
Cancel transaction
transaction
are
are low,
low, the
the balance
balance isis
delivered
Transaction list –– End transaction
End transaction
delivered
•• VPs
VPs
Order statement •• Services
Services –– Customer
Customer
Transfer funds –– Cash
Cash withdrawal
withdrawal •• Non-functional
Non-functional requirements
requirements
–– Balance
Balance enquiry –– Deliver
enquiry Deliver cash
cash within
within 11 minute
minute
•• Sub-VPs of
of amount
amount being
being confirmed
confirmed
Sub-VPs
–– Account •• Provider
Account holder
holder Provider
–– Foreign –– Filled
Filled inin later
later
Foreign customer
customer

Scenarios Scenario descriptions

• Scenarios are descriptions of how a • System state at the beginning of
system is used in practice the scenario
• They are helpful in requirements • Normal flow of events in the
elicitation as people can relate to scenario
these more readily than abstract • What can go wrong and how this is
statement of what they require handled
from a system • Other concurrent activities
• Scenarios are particularly useful • System state on completion of the
for adding detail to an outline scenario
requirements description

11
 Event scenario - start
Event scenarios
transaction
Ellipses.
Ellipses. data
data provided
provided from
from
• Event scenarios may be used to Card
Card presentor
or delivered
delivered to
to aa viewpoint
viewpoint
describe how a system responds to Request Valid card
Request PIN
PIN
the occurrence of some particular PIN User OK
event such as ‘start transaction’ Account
Account Select
Select
Number Validate
Validate user
• VORD includes a diagrammatic PIN
user number service
service
convention for event scenarios. Timeout
Timeout Control
Control information
information enters
enters and
and
– Data provided and delivered
Return
Return card
card leaves
leaves at
at the top
thePIN
Incorrect
Incorrect top of
PIN of each
each box
box
Re-enter PIN
– Control information Invalid
Invalid card
card
Re-enter PIN
Name
Name of of next
next event
event is
is in
in
Data leaves
Datashaded
leaves from
from the
– Exception processing Return
Return card
card shaded box box the
– The next expected event right of each
right Incorrect
of eachPIN
Incorrect box
box
PIN
Stolen
Stolen card Exceptions are
card Exceptions
Return
Return card
cardare shown
shown at
at
Retain
Retain card
card the
the bottom
bottom of of each
each box
box

Use cases Lending use-case

• Use-cases are a scenario based
technique in the UML which identify
the actors in an interaction and
which describe the interaction itself
• A set of use cases should describe Lending Services
all possible interactions with the
system
Actors Class of Interactions

Library use-cases Sequence Diagrams

• Sequence diagrams may be used to
Library
Lending Services add detail to use-cases by showing
user the sequence of event processing in
the system

User administration
Library
staff

Supplier

Catalog Services

12
 Catalogue management: Requirements engineering
Sequence Diagram processes
Item:
Item:
Library
Books:
Books: • The processes used for RE vary widely
Library catalog
item
item
catalog depending on the application domain, the
Bookshop Cataloguer:
supplier Library staff
people involved and the organization
developing the requirements
Acquire New
• However, there are a number of generic
activities common to all processes
Catalog item – Requirements elicitation
– Requirements analysis
Dispose – Requirements validation
– Requirements management
Uncatalog item

The Requirements Engineering

Feasibility studies
Process
Feasibility
Feasibility • A feasibility study decides whether
Study
Study or not the proposed system is
Requirements
Requirements
Elicitation
worthwhile
Elicitation && Analysis
Analysis
Requirements
• A short focused study that checks
Requirements
Feasibility
Feasibility Specification
Specification – If the system contributes to
Report
Report
Requirements organizational objectives
Requirements
System
System Validation – If the system can be engineered using
Validation
Models
Models
current technology and within budget
User
User && System
System
Requirements
– If the system can be integrated with
Requirements
other systems that are used
Requirements
Requirements
Document
Document

Feasibility study implementation Elicit: by Webster dictionary

• Based on information assessment (what is Main
MainEntry:
Entry:elic·it
elic·it
required), information collection and Pronunciation:
Pronunciation:i-'li-s&t
i-'li-s&t
report writing Function:
Function:transitive
transitiveverb verb
Etymology:
Etymology: Latinelicitus,
Latin elicitus,past
pastparticiple
participleof
• Questions for people in the organization of
elicere,
elicere, from e- + lacereto
from e- + lacere toallure
allure
– What if the system wasn’t implemented? Date:
Date:1605
1605
– What are current process problems? 11::to
todraw
drawforth
forthor orbring
bringout
out(something
(something
– How will the proposed system help? latent
latentororpotential)
potential)<hypnotism
<hypnotismelicited
elicitedhis
his
– What will be the integration problems? hidden
hiddenfears>
fears>
– Is new technology needed? What skills? 22::to
tocall
callforth
forthor ordraw
drawout out(as
(as
– What facilities must be supported by the information
informationor oraaresponse)
response)<her
<herremarks
remarks
proposed system? elicited
elicitedcheers>
cheers>

13
 Elicitation Requirements Analysis
• Sometimes called requirements elicitation • Stakeholders don’t know what they really
or requirements discovery want
• Involves technical staff working with • Stakeholders express requirements in
customers to find out about the their own terms
application domain, the services that the • Different stakeholders may have
system should provide and the system’s conflicting requirements
operational constraints • Organizational and political factors may
• May involve end-users, managers, influence the system requirements
engineers involved in maintenance, domain • The requirements change during the
experts, trade unions, etc. These are analysis process. New stakeholders may
called stakeholders emerge and the business environment
change

The requirements analysis

process Requirements validation
Requirements
Requirements • Concerned with demonstrating that
Definition
Definition &&
Specification
the requirements define the system
Requirements Specification
Requirements
Validation
Validation
that the customer really wants
• Requirements error costs are high
Process Domain
so validation is very important
Domain Prioritization
Prioritization
Entry Understanding
Understanding – Fixing a requirements error after
delivery may cost up to 100 times the
Requirements
Requirements Conflict
Conflict cost of fixing an implementation error
Collection
Collection Resolution
Resolution

Classification
Classification

Requirements validation
Requirements Validation
techniques
• Validity. Does the system provide the • Requirements reviews
functions that best support the – Systematic manual analysis of the
customer’s needs? requirements
• Consistency. Are there any requirements • Prototyping
conflicts? – Using an executable model of the system to
• Completeness. Are all functions required check requirements.
by the customer included? • Test-case generation
• Realism. Can the requirements be – Developing tests for requirements to check
testability
implemented given available budget and
technology • Automated consistency analysis
– Checking the consistency of a structured
• Verifiability. Can the requirements be requirements description
checked?

14
 Requirements reviews Review checks
• Regular reviews should be held while the • Verifiability. Is the requirement
requirements definition is being realistically testable?
formulated
• Comprehensibility. Is the
• Both client and contractor staff should
be involved in reviews
requirement properly understood?
• Reviews may be formal (with completed • Traceability. Is the origin of the
documents) or informal. Good requirement clearly stated?
communications between developers, • Adaptability. Can the requirement
customers and users can resolve problems be changed without a large impact
at an early stage
on other requirements?

Requirements management Requirements management planning

• Requirements management is the process • During the requirements engineering
of managing changing requirements during process, you have to plan:
the requirements engineering process and – Requirements identification
system development • How requirements are individually identified
• Requirements are inevitably incomplete – A change management process
and inconsistent • The process followed when analyzing a requirements
change
– New requirements emerge during the process – Traceability policies
as business needs change and a better • The amount of information about requirements
understanding of the system is developed relationships that is maintained
– Different viewpoints have different – CASE tool support
requirements and these are often • The tool support required to help manage
contradictory requirements change

Traceability A traceability matrix

• Traceability is concerned with the
relationships between requirements, their Req id 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2
sources and the system design 1.1 R
• Source traceability 1.2 U U R U
– Links from requirements to stakeholders who 1.3 R R
proposed these requirements 2.1 R U U
• Requirements traceability 2.2 U
– Links between dependent requirements 2.3 R U
• Design traceability 3.1 R
– Links from the requirements to the design 3.2 R
U = “uses the requirement”, R = “Some other weaker relationship”

15
 Enduring and volatile
CASE tool support
requirements
• Requirements storage • Enduring requirements. Stable
– Requirements should be managed in a secure, requirements derived from the core
managed data store activity of the customer organisation.
E.g. a hospital will always have doctors,
• Change management
nurses, etc. May be derived from domain
– The process of change management is a models
workflow process whose stages can be
defined and information flow between these • Volatile requirements. Requirements
stages partially automated which change during development or when
the system is in use. In a hospital,
• Traceability management requirements derived from health-care
– Automated retrieval of the links between policy
requirements

Requirements change Requirements evolution

• The priority of requirements from
Initial Changed
different viewpoints changes during Initial
understanding
understanding
Changed
understanding
understanding
the development process of
of problem
problem of
of problem
problem
• System customers may specify
requirements from a business
perspective that conflict with end- Initial Changed
Initial Changed
user requirements requirements
requirements requirements
requirements
• The business and technical
environment of the system changes
Time
during its development

Requirements change management Requirements change management

Identified problem
• Should apply to all proposed changes to
the requirements
• Principal stages Problem
Problem analysis
analysis
and
and change
change specification
specification
– Problem analysis. Discuss requirements
problem and propose change
– Change analysis and costing. Assess effects Change
Change analysis
analysis
of change on other requirements and
and costing
costing
– Change implementation. Modify requirements
document and other documents to reflect
Change
Change implementation
change implementation

Revised requirements

16
 Users of a requirements
The requirements document
document
• The requirements document is the – System customers
• Specify the requirements and read them to check
official statement of what is that they meet their needs
required of the system developers – Managers
• Use the requirements document to plan a bid for the
• Should include both a definition and system and to plan the system

a specification of requirements – System engineers

• Use the requirements to understand what system is
• It is NOT a design document. As to be developed
– System test engineers
far as possible, it should set of • Use the requirements to develop validation tests for
WHAT the system should do rather the system
– System maintenance engineers
than HOW it should do it • Use the requirements to help understand the system
and the relationship between its parts

Requirements document
IEEE requirements standard
requirements
• Specify external system behaviour • Introduction
• Specify implementation constraints • General description
• Easy to change
• Specific requirements
• Serve as reference tool for maintenance
• Appendices
• Record forethought about the life cycle
of the system i.e. predict changes • Index
• Characterise responses to unexpected • This is a generic structure that
events must be instantiated for specific
systems

17