Stakeholders often belong to different groups – geographic, work roles,
interest groups, etc. Furthermore there are often differences between
individual stakeholders in these groups. A single requirements
document or specification for all stakeholders is not suitable for such
cases. Rather we need a process and method that enables us to
represent different stakeholder viewpoints or perspectives, and that
enables us to handle and live with inconsistencies between
requirements. Kotonya and Sommerville (1998) provide a useful review
of the reported viewpoint approaches in the literature. As you can see
from this review there is no agreed definition of a viewpoint.
The slide provides a simple definition of a viewpoint – a partial
specification of the future system’s properties from the perspective of
one or a coherent group of stakeholders. That is, if we put all of the
viewpoints together, it provides us with a complete specification of the
stakeholder’s requirements for the future system. However, things are
never that simple. Requirements in different viewpoints can often
overlap and as well as be inconsistent, and provide real challenges for
requirements engineering processes and software tools.
Viewpoints have been the subject of considerable academic research in
the 1990s, although there has been little concrete influence on practice,
methods and software tools. This slide reviews two approaches: others
are discussed in chapter 7 of Kotonya & Sommerville (1998).
Kotonya G. & Sommerville I., 1998, ‘Requirements Engineering Process and Techniques’, John Wiley.
Viewpoints: A Simple Library Example
The two VOSE-style viewpoints shown describe requirements,
expressed as structured analysis models, for a university library system.
One, from the viewpoint of the librarians, shows requirements for loan
information, in the form of a ERD. The other, expressed as a DFD,
shows the loaning process from the viewpoint of student borrowers. Look
closely at the two viewpoints together: it is surprising how much
information can be gleaned from the differences between the two
viewpoints. These differences can then inform further requirements
acquisition, refinement and perhaps negotiation.
Differences between these viewpoints include: terminological
differences, e.g. ITEM and BOOKS, LOAN & BORROW?;
inconsistencies, e.g. LOAN has three attributes (date, time and status)
and relationships with both ITEM and BORROWER, while LOANS has
an information input which only mentions book details, and not
information about the borrower; possible conflicts, for example are
students happy with a maximum loan limit of 6 books
This list can go on. However, one of the limitations of the VOSE
approach is its limited solutions to handle such problems. In reality, the
constraints, knowledge and level of precision and formality needed to
provide software to assist detection of these problems are too great. As a
result, meaningful industrial solutions to handle core viewpoint problems
are still some way away.
Reference: Reference: Neil Maiden (2011) Requirements Engineering Lecture Notes