To appear in Proceedings of ICRE’98
Defines standard
Replaced/Superseded by document(s)
Cancelled by
Amended by
| File | MIME type | Size (KB) | Language | Download | |
|---|---|---|---|---|---|
| practicalVPs.pdf | application/pdf | 45.66 KB | English | DOWNLOAD! |
Provides definitions
Review
Good paper. Recommended reading.
More detailed pointers to the useful areas this paper may become available in a future update to this website/CDROM.
Abstract
This paper introduces an approach to multi-perspective requirements engineering
(PREview) which has been designed for industrial use and discusses our practical
experience in applying PREview. We have developed a flexible model of viewpoints
and, using examples from an industrial application, show how this can be used to
organise system requirements derived from radically different sources. We show how
‘concerns’, which are key business drivers of the requirements elicitation process,
may be used to elicit and validate system requirements. They are decomposed into
questions which must be answered by system stakeholders. We briefly describe the
process of using PREview which has been designed to allow incremental
requirements elicitation. Finally, we discuss some practical considerations which
emerged when the approach was applied in industry.
Introduction
It is now widely accepted that a multi-perspective approach to requirements
engineering can, potentially, lead to requirements specifications which are more likely
to satisfy the needs of a diverse set of system stakeholders. Good requirements
engineers will always consider these different perspectives but viewpoint-oriented
requirements engineering methods which explicitly identify and separate different
system viewpoints [1-3] are not widely used in practice.
One reason for this is that, in our experience, most viewpoint-oriented methods do
not cope well with the messy reality of requirements engineering. A method may be
conceptually elegant but this elegance is a straitjacket when requirements engineers
attempt to apply these methods to real systems. It is not easy to define and discover
viewpoints, stakeholders insist on using their own notations and terminology to
describe their requirements, requirements engineering is carried out to a tight schedule
so it is not always possible to collect all desirable information and political and
organisational factors influence technical requirements.