METHODS FOR REQUIREMENTS ENGINEERING

1

OBJECTIVES

To explain the role of methods and techniques in requirements engineering

To introduce data-flow modelling To introduce semantic data modelling To introduce object-oriented methods To explain the role of formal methods in

requirements engineering

2

ROLE OF METHODS IN RE Process of requirements engineering (RE) is

usually guided by a requirements method Requirement methods are systematic ways of

producing system modelsThe system models based on computational concepts

such as object or functions rather than app domain concept.

System models important bridges between the analysis and the design process

3

NECESSARY PROPERTIES FOR A RE METHOD

Suitability for agreement with the end-user The precision of definition of its notation Assistance with formulating requirements Definition of the world outside Scope for malleability Scope for integrating other approaches Scope for communication Tool support

4

SUITABILITY FOR AGREEMENT WITH THE END-USE

The extent to which the notation is understandable by someone without formal training. Formal specification is difficult to be understood

by most people Solution: combine both formal and informal

descriptions of system requirements

5

THE PRECISION OF DEFINITION OF ITS NOTATION The extent to which the requirements may be

checked for consistency and correctness using the notation. Imprecise notation errors and

misunderstanding

6

ASSISTANCE WITH FORMULATING REQUIREMENTS

To establish the system requirements must be guided by a problem analysis technique that takes all these viewpoints into account (capture, structuring, analysis and resolution of many ideas, perspectives and relationships at varying levels)

7

DEFINITION OF THE WORLD OUTSIDE

The requirements model shall model the environment with which the component interacts

8

SCOPE OF MALLEABILITY

The approach used and the resultant specification must be tolerant of temporary incompleteness and adaptable changes

9

SCOPE FOR INTEGRATING OTHER APPROACHES

No one requirements approach that adequately articulates all the requirements of a system Eg DFD – inadequately represent control

requirements Eg. Formal language – inadequately non-

functional requirements

10

SCOPE FOR COMMUNICATION

The requirements method or tool needs to be able to support the need for people to communicate their ideas and obtain feedback

11

TOOL SUPPORT

System development generates a large amount of information that must be analysed

Tool support contributes a lot to improve the management its complexity especially large project

12

NO IDEAL RE METHOD

There is no ideal requirement method A number of methods use a variety of modelling

techniques to formulate system requirements System models can be enriched by modelling different

aspects of using modelling techniques

13

MODELING TECHNIQUES

Data-flow models

Compositional models

Classification models

Stimulus-response models

Process models

14

DATA FLOW MODELLING

Based on the notion that systems can be modelled as a set of interacting functions

Uses data-flow diagrams (DFDs) to graphically represent the external entities, processes, data-flow, and data stores

15

DATA FLOW NOTATION

16

Transform

Terminator

Data dictionary

Input Output

NOTATION VARIABILITY

There is little uniformity in industry concerning the DFD notation

The notation shown was advanced by DeMarco Gane and Sarson use rounded rectangles for bubbles

shadowed rectangles for sources and destinations, and squared off C’s for data stores

Orr uses rectangles for bubbles, ellipses for sources and destinations, and ellipses for data stores

17

DFD EXAMPLE

Consider a simple library system intended to automate the issuing of library items

The first data-flow diagram derived by the analyst represents the ‘target’ system at its context level

The next level (level 1) of the data-flow diagram is constructed by decomposing the library system bubble into sub-functions

18

LIBRARY EXAMPLE-CONTEXT LEVEL DATA FLOW DIAGRAM

19

Libraryuser

Issue libraryitem

Library card

Requested item

Issued item

Libraryassistant

Return date

LIBRARY EXAMPLE -LEVEL 1 DATA FLOW DIAGRAM

20

Libraryuser

Checkuser

Item database

Checkitem

Librarycard

User status

requesteditem

Issueitem

Itemstatus

issueditem

updateuser

details

UserID

ItemID

Update detailsitem details

Libraryassistant

return date

User database

update detailsuser details

STRUCTURED ANALYSIS

The data-flow approach is typified by the Structured Analysis method (SA)

Two major strategies dominate structured analysis ‘Old’ method popularised by DeMarco ‘Modern’ approach by Yourdon

21

DEMARCO

A top-down approach The analyst maps the current physical system onto the

current logical data-flow model The approach can be summarised in four steps:

Analysis of current physical systemDerivation of logical modelDerivation of proposed logical model Implementation of new physical system

22

MODERN STRUCTURED ANALYSIS Distinguishes between user’s real needs and those

requirements that represent the external behaviour satisfying those needs

Includes real-time extensions Other structured analysis approaches include:

Structured Analysis and Design Technique (SADT) Structured Systems Analysis and Design Methodology (SSADM)

23

SEMANTIC DATA MODELING

An important aspect of system modeling is to define the logical form of the data processed by the system

One way of doing this is to use the relational model.

24

RELATIONAL MODEL

Data may be modelled using the relational model Specifies data as a set of tables, with some columns being used as

common keys

Disadvantages of relational model Implicit data typing – data type associated with relations

Inadequate modelling of relations

Data model should include information about the semantics of the data

25

SEMANTIC MODELS Approaches to semantic data modelling include:

Entity-relationship model (Chen, 1976) RM/ T (Codd, 1979) SDM (Hammer and McLeod, 1981)

Models identify the entities in a database, their attributes and their relationships

Uses graphical notations

26

NOTATION FOR SEMANTIC DATA MODELLING

27

<Name> <Name>

<Name>

<Input cardinality>

<Output cardinality>

An Entity An Entity

A relation between entities An inheritance relation

EXTENSIONS TO ENTITY RELATIONSHIP MODEL

The basic ERM has been extended to include sub and super-types to the basic entity and relation primitives

Types may have sub-types Types may inherit the attributes of their super-

types In addition, sub-types may have private

attributes

28

ERM EXAMPLE - SOFTWARE REQUIREMENT

29

Identifier Source Description Type Priority

Requirement

has

ChangesIdentifier

description

rationale

author

1

(0,N)

result in VersionN 1,N

Specification

OBJECT-ORIENTED APPROACHES

Closest precursor is entity relationship model Requirements methods based on object orientation:

Shlaer and Mellor (1988)Colbert (1989)Coad and Yourdon (1989)Wirf-Brock (1990)Rumbaugh (1991) Jacobson (1992)Martin-Odell (1992)

Notations for the various methods are semantically similar

30

OBJECT Are major actors, agents, and servers in the problem space

of the system Identified by analysing the domain Objects include:

Devices that the system interacts withSystems that interface with the system under studyOrganisational units Things that must be remembered over time Physical locations or sitesSpecific roles played by humans

31

BASIC CONCEPTS

Encapsulation Class Inheritance Operations or Services

32

OBJECT DEFINITION

Something real or abstract about which we store data and those operations that manipulate the data

Examples include:An account, a sensor, a software design, a car , an organisation

May be composite - composed of other objects

33

CLASS DEFINITION

An implementation of an object type The object type Bank Customer refers to a class of bank

customers

Objects that share common attributes and operations An object is an instance of a class For example, if “John Smith” is a bank customer, then bank

customer is the class and “John Smith” is an instance of the bank customer

34

OPERATIONS AND METHODS

Used to read and manipulate the data of an object Reference only the data structures of that object type To access the data structures of another object, objects

must send messages to that object Methods specify the way in which operations are encoded

in software

35

ENCAPSULATION

Packaging together of data and operations that manipulate the data

Details of how the operation is performed hidden from user

Prevents the unauthorised access of an object’s data

36

INHERITANCE

Objects at a lower level in class hierarchy inherit the operations and attributes of their parent(s)

Objects are able to incorporate data and/or operations specific to themselves

Inherits data from more than one parent is called multiple inheritance.

37

ILLUSTRATION OF OBJECT CONCEPTS

38

Class:Library item

classmarktitle

catalogueacquireloan

Book

authorpublisheryear

operation1operation 2

Object inherits attributesand methods of parent class

Encapsulation ofdata and operationsinto a single object

Class definition

Attributes

Operations

Generalisation

MESSAGES Objects communicate by sending messages Message comprises:

Name of receiver object Operation to be invoked Optional set of parameters

When an object receives a message it causes an operation to be invoked

The operation performs the appropriate method

39

MESSAGE PASSING

40

Object:ObjectX

attribute 1attribute 2attribute 3

operation 1operation 2operation 3

Object:ObjectY

attribute 12attribute 13attribute 14

operation 12operation 13operation 14

Message 1:

to:ObjectYoperation: 12parameters: a,b

OBJECT MODELLING - LIBRARY EXAMPLE

A library system is intended to provide its users with the ability to automate the process of: Acquiring library itemsCataloguing library itemsBrowsing library itemsLoaning library items

Library items comprise published and recorded material The system will be administered by a member of the library staff Users must register with the system administrator before they

can borrow library items

41

LIBRARY EXAMPLE (CONTD.)

Library users are drawn from three primary groups:

Students, Members of staff and External users All library users have as part of their registration:

Name, Library number, Address, Account In addition the following information also required for

registration:

Students - Degree programme and admission number.

Staff - Staff number

External users - Employer details

42

STEPS IN OBJECT-ORIENTED METHOD

Most methods based on the object-oriented model share certain common analysis steps: Identify core objects

Construct the object structures defining the associations between object classes

Define the attributes associated with each object

Determine the relevant operations for each object

Define the messages that may be passed between objects

43

OBJECT-ORIENTED NOTATION USED

44

<Class name>

<Attributes>

<Operations>

(i) Class (ii) Generalisation (iii) Aggregation

STEP 1 - INITIAL CLASSES IDENTIFIED

45

Library user Library item Library staff Account

STEP 2 - RELATIONSHIPS BETWEEN CLASSES

We can identify the following relationships from the partial requirements:

(i) A library user borrows a library item

(ii) A library item is recorded or published

(iii) The system administrator registers the library user

(iv)Library users are students, staff and external users

(v) The system administrator catalogues the library items

(vi)The library assistant issues the library items

46

STEP 2 - BASIC OBJECT MODEL SHOWING ATTRIBUTES AND RELATIONSHIPS

47

Library user

Library staff

Library item

NameAddressLibrary id

borrows

TitleClassmarkCall Number

Account

registers

browses

receives issues

catalogues

staff id

loaned itemdue date

1 1,N

1,NN

1

N

1

N N

1

1

N

STEP 2 - INHERITANCE FOR LIBRARY USER

48

Library user

NameAddressLibrary id

Degree programmeAdmission number

Student

Staff number

Staff

Employer nameEmployer address

External

Account

loaned item iddue date

STEP 2 - INHERITANCE FOR LIBRARY ITEM

49

Library item

TitleClassmark

Published item

FormatLength of playContents

Recorded item

Book Journal

PublisherYear

AuthorISBN number

VolumeIssue

STEP 3 - IDENTIFYING THE ATTRIBUTES

Attributes can be revealed by the analysis of the system requirements

For example, it is a requirement that all library users must be registered before they can use the libraryThis means that we need to keep registration data about library

usersLibrary users may also be provided with an account to keep

track of the items loaned to them Library item has the attributes; title, description and classmark The library user class has the attributes; name, address and

library id

50

STEP 4 - OBJECT OPERATIONS

This step is intended to describe operations to be performed on the objects

Certain operations are implicit from the object structureThese include operations for accessing and modifying

the attribute values. These operations are assumed and we need not show them explicitly in the model

One way of identifying operations is by modelling the messages that may be passed between the objects

51

STEP 4 - MESSAGES BETWEEN OBJECTS

52

Library user Library item

Library staff

1. issue2. return3. browse

1. acquire2. catalogue3. dispose

1. register2. query

STEP 4 - OPERATIONS FOR LIBRARY USER AND LIBRARY STAFF

53

Library user

NameAddressLibrary id

Degree programmeAdmission number

Student

Staff number

Staff

Employer nameEmployer address

External

registerquery

Account

loaned item iddue date

compute fine

STEP 4 - OPERATIONS FOR LIBRARY ITEM

54

Library item

TitleClassmark

Published item

FormatLength of playContents

Recorded item

Book Journal

PublisherYear

AuthorISBN number

VolumeIssue

acquireissuereturndisposecatalogue

USE CASE AND EVENT SCENARIOS

Object operations may also be identified by modelling event scenarios for the different functions provided by the system Events are then traced to objects that react to them

Typically scenarios model the interactions between the users and the system

55

TYPICAL USE-CASE SCENARIO FOR LIBRARY SYSTEM

56

access services

Library userbrowse item

Library staff

register user

set permissionsUse Case

search criteria

user permissions

<<uses>>

<<uses>>

<<extends>>

EVENT SCENARIO FOR BORROWING ITEM

57

Library User (LU) System Library staff

Requests library item (1) Scans in LU registration (2)

accepts registration (3)

rejects registration (3)

verifies item loan to LU (4)

loans item (5)

denies loan (5)

FORMAL METHODS

Requirements specification techniques can be categorised on a “formality” spectrum

Semi-formal and informal methodsUse natural language, diagrams, tables and simple notation Include structured analysis and object-oriented analysis

Formal methods include:Based on mathematically formal syntax and semantics Include Z, B, VDM, LOTOS

58

FORMAL METHODS (CONTD.)

Provide a means for achieving a high degree of confidence that a system will conform to its specification

Do not absolute guarantee of correctness Have little directly to offer to the problems of managing

software projects However, benefits can be gained from gaining a clear

understanding of the task at an early stage

59

COMPONENTS OF FORMAL SPECIFICATION LANGUAGE

Syntax that defines the specific notation with which the specification is represented

Semantics that help to define a “universe of objects” that will be used to describe the system

Relations which define the rules that indicate which objects properly satisfy the specification

60

FORMAL METHODS NOT WIDESPREAD

Formal methods are not widely used amongst software developers

Factors contributing to slow acceptance of formal methods: Difficulty in understanding the notations

Difficulty in formalising certain aspects of requirements

Payoff is not obvious.

61

FORMAL SPECIFICATION LANGUAGES

The number of formal specification languages in use today can be broadly divided into two categories.

Model-based notations Z and Vienna Development Method (VDM)

Process algebras -based notationsCommunicating Sequential Processes (CSP), CCS and LOTOS

62

ADVANTAGES OF FORMAL METHODS Removes ambiguity Encourages greater rigor in the early stages of software

engineering Possible to verify the correctness, incompleteness and

inconsistency checking of the specification

63

DISADVANTAGES OF FORMAL METHODS

Difficult to represent behavioural aspects of problem Some requirements can only be determined through

empirical evaluation and prototyping Do not address the problem of how the requirements are

constructed Lack of adequate tool support

64

Z - A MODEL BASED FORMAL METHOD

A Z specification is presented as a collection of schemas

A Schema comprises three main parts: Name, Declarations and Predicates

Schema declarations set out the names and types of entities introduced in the schema

Schema predicate sets out the relationships between the entities in the declaration

65

USING Z Variable declarations are of the form identifier:type Predicates give properties of, and relationships between the variables A schema may be used to describe either a state or an operation

To describe a state, the declared variables form the components of the state and the predicates give the invariant properties of the state

For an operation, the declarations consist of the initial state components, the final components, the inputs and the outputs of the operation

For an operation, the predicate part describes the relation between the inputs, outputs, and initial and final states

66

Z SCHEMA

67

Schema Name

Declarations

Predicates

LIBRARY EXAMPLE

The state space of the lending library can be defined using the following schema:

68

Librarystock: P BookonLoan: Book Borrower

dom onLoan stock

SCHEMA FOR BORROW OPERATION

69

Borrow

Librarybook?: Bookreader?: Borrower

book? stockbook? dom onLoanonLoan' = onLoan {(book?, reader?)}stock' = stock

SCHEMA FOR ‘NEW’ AND ‘RETURN’ OPERATIONS

70

New

Librarybook?: Book

stock' = stock {book?}onLoan' = onLoan

Return

Librarybook?: Book

book? dom onLoandom onLoan' = dom onLoan book?stock' = stock

KEY POINTS No ideal requirements method System models can be considerably enriched by

combining different techniques Data-flow model is based on the notion that systems can

be modelled as a set of interacting functions The object-oriented approach is based on the notion that

systems can be modelled as a set of interacting objects Formal methods are based on mathematical principles

and are intended to achieve a high degree of confidence that a system will conform to its specifications

71

72

REQUIREMENTS VALIDATION

73

VALIDATION OBJECTIVES

Certifies that the requirements document is an acceptable description of the system to be implemented

Checks a requirements document for Completeness and consistency Conformance to standards Requirements conflicts Technical errors Ambiguous requirements

74

ANALYSIS AND VALIDATION

Analysis works with raw requirements as elicited from the system stakeholders “Have we got the right requirements” is

the key question to be answered at this stage

Validation works with a final draft of the requirements document i.e. with negotiated and agreed requirements “Have we got the requirements right” is

the key question to be answered at this stage

75

VALIDATION INPUTS AND OUTPUTS

List of problems

Agreed actions

Requirementsdocument

Organisationalstandards

Organisationalknowledge

Requirementsvalidation

76

VALIDATION INPUTS

Requirements document Should be a complete version of the

document, not an unfinished draft. Formatted and organised according to organisational standards

Organisational knowledge Knowledge, often implicit, of the

organisation which may be used to judge the realism of the requirements

Organisational standards Local standards e.g. for the organisation of

the requirements document

77

VALIDATION OUTPUTS

Problem list List of discovered problems in the

requirements document Agreed actions

List of agreed actions in response to requirements problems. Some problems may have several corrective actions; some problems may have no associated actions

78

REQUIREMENTS REVIEWS

A group of people read and analyse the requirements, look for problems, meet and discuss the problems and agree on actions to address these problems

79

REQUIREMENTS REVIEW PROCESS

Plan reviewDistributedocuments

Prepare forreview

Hold reviewmeeting

Follow-upactions

Revisedocument

80

REVIEW ACTIVITIES

Plan review The review team is selected and a time and

place for the review meeting is chosen. Distribute documents

The requirements document is distributed to the review team members

Prepare for review Individual reviewers read the requirements to

find conflicts, omissions, inconsistencies, deviations from standards and other problems.

81

REVIEW ACTIVITIES

Hold review meeting Individual comments and problems are

discussed and a set of actions to address the problems is agreed.

Follow-up actions The chair of the review checks that the

agreed actions have been carried out. Revise document

The requirements document is revised to reflect the agreed actions. At this stage, it may be accepted or it may be re-reviewed

82

PROBLEM ACTIONS Requirements clarification

The requirement may be badly expressed or may have accidentally omitted information which has been collected during requirements elicitation.

Missing information Some information is missing from the requirements document.

It is the responsibility of the requirements engineers who are revising the document to discover this information from system stakeholders.

Requirements conflict There is a significant conflict between requirements. The

stakeholders involved must negotiate to resolve the conflict. Unrealistic requirement

The requirement does not appear to be implementable with the technology available or given other constraints on the system. Stakeholders must be consulted to decide how to make the requirement more realistic.

83

PRE-REVIEW CHECKING

Reviews are expensive because they involve a number of people spending time reading and checking the requirements document

This expense can be reduced by using pre-review checking where one person checks the document and looks for straightforward problems such as missing requirements, lack of conformance to standards, typographical errors, etc.

Document may be returned for correction or the list of problems distributed to other reviewers

84

PRE-REVIEW CHECKING

Requirementsdocument

Problem report

Checkdocument

completeness

Check documentagainst

standards

Check documentstructure

Runautomaticcheckers

85

REVIEW TEAM MEMBERSHIP

Reviews should involve a number of stakeholders drawn from different backgrounds People from different backgrounds bring

different skills and knowledge to the review

Stakeholders feel involved in the RE process and develop an understanding of the needs of other stakeholders

Review team should always involve at least a domain expert and an end-user

86

REVIEW CHECKLISTS

Understandability Can readers of the document understand what the

requirements mean? Redundancy

Is information unnecessarily repeated in the requirements document?

Completeness Does the checker know of any missing requirements or

is there any information missing from individual requirement descriptions?

Ambiguity Are the requirements expressed using terms which are

clearly defined? Could readers from different backgrounds make different interpretations of the requirements?

87

REVIEW CHECKLISTS Consistency

Do the descriptions of different requirements include contradictions? Are there contradictions between individual requirements and overall system requirements?

Organisation Is the document structured in a sensible way? Are the

descriptions of requirements organised so that related requirements are grouped?

Conformance to standards Does the requirements document and individual requirements

conform to defined standards? Are departures from the standards, justified?

Traceability Are requirements unambiguously identified, include links to

related requirements and to the reasons why these requirements have been included?

88

CHECKLIST QUESTIONS

Is each requirement uniquely identified? Are specialised terms defined in the glossary Does a requirement stand on its own or do you have to

examine other requirements to understand what it means?

Do individual requirements use the terms consistently Is the same service requested in different requirements?

Are there any contradictions in these requests? If a requirement makes reference to some other facilities,

are these described elsewhere in the document? Are related requirements grouped together? If not, do

they refer to each other?

89

REQUIREMENTS PROBLEM EXAMPLE

“4. EDDIS will be configurable so that it will comply with the requirements of all UK and (where relevant) international copyright legislation. Minimally, this means that EDDIS must provide a form for the user to sign the Copyright Declaration statement. It also means that EDDIS must keep track of Copyright Declaration statements which have been signed/not-signed. Under no circumstances must an order be sent to the supplier if the copyright statement has not been signed.”

90

PROBLEMS

Incompleteness What international copyright legislation is

relevant? What happens if the copyright declaration is not

signed? If a signature is a digital signature, how is it

assigned? Ambiguity

What does signing an electronic form mean? Is this a physical signature or a digital signature?

Standards More than 1 requirement. Maintenance of

copyright is one requirement; issue of documents is another

91

PROTOTYPING

Prototypes for requirements validation demonstrate the requirements and help stakeholders discover problems

Validation prototypes should be complete, reasonably efficient and robust. It should be possible to use them in the same way as the required system

User documentation and training should be provided

92

PROTOTYPING FOR VALIDATION

Chooseprototype

testers

Document and extend prototype system

Developtest

scenarios

Executescenarios

Documentproblems

93

PROTOTYPING ACTIVITIES Choose prototype testers

The best testers are users who are fairly experienced and who are open-minded about the use of new systems. End-users who do different jobs should be involved so that different areas of system functionality will be covered.

Develop test scenarios Careful planning is required to draw up a set of test scenarios

which provide broad coverage of the requirements. End-users shouldn’t just play around with the system as this may never exercise critical system features.

Execute scenarios The users of the system work, usually on their own, to try the

system by executing the planned scenarios. Document problems

Its usually best to define some kind of electronic or paper problem report form which users fill in when they encounter a problem.

94

USER MANUAL DEVELOPMENT

Writing a user manual from the requirements forces a detailed requirements analysis and thus can reveal problems with the document

Information in the user manual Description of the functionality and how it

is implemented Which parts of the system have not been

implemented How to get out of trouble How to install and get started with the

system

95

MODEL VALIDATION

Validation of system models is an essential part of the validation process

Objectives of model validation To demonstrate that each model is self-

consistent If there are several models of the system, to

demonstrate that these are internally and externally consistent

To demonstrate that the models accurately reflect the real requirements of system stakeholders

Some checking is possible with automated tools Paraphrasing the model is an effective checking

technique

96

DATA-FLOW DIAGRAM FOR ISSUE

Checkuser

Checkitem

Issue item

User details

User status

Item status

Issued item

Update details

Library card

Requested item

97

PARAPHRASED DESCRIPTION

Check userInputs and sources User’s library card from end-userTransformation function Checks that the user is a valid library

userTransformation outputs The user’s statusControl information User details from the databaseCheck i temInputs and sources The user’s status from Check userTransformation function Checks if an item is available for issueTransformation outputs The item’s statusControl information The availability of the itemIssue i temInputs and sources NoneTransformation function Issues an item to the library user. Items

are stamped with a return date.Transformation outputs The item issued to the end user

Database update detailsControl information Item status - items only issued if

available

98

REQUIREMENTS TESTING Each requirement should be testable i.e.

it should be possible to define tests to check whether or not that requirement has been met.

Inventing requirements tests is an effective validation technique as missing or ambiguous information in the requirements description may make it difficult to formulate tests

Each functional requirement should have an associated test

99

TEST CASE DEFINITION

What usage scenario might be used to check the requirement?

Does the requirement, on its own, include enough information to allow a test to be defined?

Is it possible to test the requirement using a single test or are multiple test cases required?

Could the requirement be re-stated to make the test cases more obvious?

100

TEST RECORD FORM The requirement’s identifier

There should be at least one for each requirement. Related requirements

These should be referenced as the test may also be relevant to these requirements.

Test description A brief description of the test and why this is an objective

requirements test. This should include system inputs and corresponding outputs.

Requirements problems A description of problems which made test definition difficult

or impossible. Comments and recommendations

These are advice on how to solve requirements problems which have been discovered.

101

REQUIREMENTS TEST FORM

Requirements tested: 10.(iv)

Related requirements: 10.(i), 10.(ii), 10.(iii),10.(vi), 10. (vii)

Test applied: For each class of user, preparea login script and identify the services expectedfor that class of user.

The results of the login should be a web pagewith a menu of available services.

Requirements problems: We don't know thedifferent classes of EDDIS user and theservices which are available to each user class.Apart from the administrator, are all otherEDDIS users in the same class?

Recommendations: Explicitly list all userclasses and the services which they can access.

102

HARD-TO-TEST REQUIREMENTS

System requirements Requirements which apply to the system as a whole. In

general, these are the most difficult requirements to validate irrespective of the method used as they may be influenced by any of the functional requirements. Tests, which are not executed, cannot test for non-functional system-wide characteristics such as usability.

Exclusive requirements These are requirements which exclude specific behaviour. For

example, a requirement may state that system failures must never corrupt the system database. It is not possible to test such a requirement exhaustively.

Some non-functional requirements Some non-functional requirements, such as reliability

requirements, can only be tested with a large test set. Designing this test set does not help with requirements validation.

103

KEY POINTS

Requirements validation should focus on checking the final draft of the requirements document for conflicts, omissions and deviations from standards.

Inputs to the validation process are the requirements document, organisational standards and implicit organisational knowledge. The outputs are a list of requirements problems and agreed actions to address these problems.

Reviews involve a group of people making a detailed analysis of the requirements.

Review costs can be reduced by checking the requirements before the review for deviations from organisational standards. These may result from more serious requirements problems.

104

KEY POINTS

Checklists of what to look for may be used to drive a requirements review process.

Prototyping is effective for requirements validation if a prototype has been developed during the requirements elicitation stage.

Systems models may be validated by paraphrasing them. This means that they are systematically translated into a natural language description.

Designing tests for requirements can reveal problems with the requirements. If the requirement is unclear, it may be impossible to define a test for it.

MASTER THESIS

http://www.bth.se/fou/cuppsats.nsf/all/03a48c3772d5b49ac12574ff002e6fd4/$file/Requirements%20Validation%20Techniques%20(RVTs)%20Practiced%20in%20Industry%20-%20Studies%20of%20Six%20Companies.pdf