Upload
anthony-waters
View
214
Download
0
Tags:
Embed Size (px)
Citation preview
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