Obtaining Requirements
Requirements Engineering Perspective
By Robin Beaumont
e-mail: robin@organplayers.co.uk
Sunday, 06 January 2008Version 2
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
How th is d o cu m en t sh o u ld b e u s ed :
This document has been designed to be suitable for web based and face-to-face teaching. The text has been
made to be as interactive as possible with exercises, Multiple Choice Questions (MCQs) and web based
exercises.
If you are using this document as part of a web-based course you are urged to use the online discussion board
to discuss the issues raised in this document and share your solutions with other students.
Wh o t h i s d o c u m en t i s a im ed at:
This document is aimed at three types of people:

Those who wish to become involved in systems development but are not interested in the nuts and
bolts of programming, such people are commonly called domain experts and act a bridges between a
professional group (e.g. medics, Solicitors etc) to which they belong and IT experts.

As an introduction for those just beginning professional computer science courses.

Those at "board" level of hospitals who wish to gain greater understanding of systems development
issues.
I hope you enjoy working through this document.
Robin Beaumont
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 2 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
Contents
1.
Before you start ....................................................................................................................................... 4
1.1
Prerequisites ............................................................................................................................................4
1.2
Required Resources .................................................................................................................................4
2.
Learning Outcomes .................................................................................................................................. 5
3.
Introduction ............................................................................................................................................. 6
3.1
4.
The Problem with Expert Introspection...................................................................................................6
Methods Used to Gain Requirements ...................................................................................................... 7
4.1.1
5.
The Say-Do Problem ......................................................................................................................................... 8
Domain Analysis ...................................................................................................................................... 9
5.1
What is a Domain? ...................................................................................................................................9
5.2
What is a Domain Expert? .......................................................................................................................9
5.3
Domain Model .........................................................................................................................................9
5.4
Domain Analysis and the Stages of Requirements Engineering ............................................................10
6.
Problems with Requirements Elicitation ................................................................................................ 12
7.
The Domain Expert - Your Role After the Course.................................................................................... 14
8.
Scenario Analysis ................................................................................................................................... 14
9.
Requirement Engineering Standards ...................................................................................................... 15
9.1
ISO 9000-3 .............................................................................................................................................15
9.2
IEEE Standard 830 1993 .........................................................................................................................15
10.
3 Cs UV ............................................................................................................................................... 16
11.
Classifying Requirements ................................................................................................................... 17
12.
Summary ............................................................................................................................................ 18
13.
MCQs ................................................................................................................................................. 19
14.
Web Links ........................................................................................................................................... 21
15.
References ......................................................................................................................................... 21
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 3 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
1. Before you start
1.1 Prerequisites
This document assumes that you have the following knowledge and skills:
1. Basic knowledge of information systems - You should feel confident to be able to answer the following
questions concerning basic knowledge of Health care information systems
1.
2.
3.
The systems view of the world describes everything using three basic aspects. What are they?
I mention the 5 ‘W’s and H to consider when describing a system. What do they stand for?
Information Systems are often classified into one of three tiers. What are the names given to the
tiers?
4. James Martin in 1981 suggested Information Systems could be divided into two types. What were
they?
If you have any difficulty answering any of the above questions go to the following link and find the answers in
the document "Types of Health information systems" at
http://www.robin-beaumont.co.uk/virtualclassroom/chap12/s2/systems1.pdf
2. Basic knowledge of systems development methods - You should feel confident to be able to answer the
following questions concerning basic knowledge of systems development methods:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
What are the names of the two most common methods of developing Information systems?
What are the three levels found in the ‘functional specification’?
What are the main stages of the Waterfall method?
What does PIR stand for?
What is the more modern name for a systems analyst?
What are the two main types of prototyping?
What is the other name given to evolutionary prototyping?
What is the audit cycle similar to?
If I develop a system and gradually add different modules to it, what type of prototype is it?
If I develop a system and gradually make each of the modules have more 'bells and whistles' what
type of prototype is it?
If you have any difficulty answering any of the above questions go to the following link and find the answers in
the document "Information systems development methods" at
http://www.robin-beaumont.co.uk/virtualclassroom/chap12/s3/des1.pdf
3. knowledge of issues around user involvement in systems development - You should feel confident to be
able to answer the following questions
1.
2.
3.
4.
5.
6.
What is ‘top managers strategic withdrawal’ (Newman and Rosenberg 1985)?
Johnson and Scholes 1993 divide stakeholders across several dimensions provide an example of two?
One particular group of stakeholders can present significant problems - who are they?
Traditionally what is often the measure of success of an information system?
Baroudi J J Olson M H Ives B 1986 demonstrated that certain relationships existed in the systems
development context. What were they?
ETHICS attempts to balance three aspects, what are they?
If you have any difficulty answering any of the above questions go to the following link and find the answers in
the document " Getting Users Involved in Developing Information Systems " at
http://www.robin-beaumont.co.uk/virtualclassroom/chap12/s4/des2.pdf
1.2 Required Resources
Ability to be able to read this document while being online so that you can check out various web sites referred
to in the text.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 4 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
2. Learning Outcomes
This document aims to provide you with the following skills and information. After you have completed it you
should come back to these points, ticking off those you feel happy with.
Tick box
Learning outcome
Be able to discuss various definitions concerning "Requirements Engineering" including Goguen and
Linde's (1993)
Be able to discuss the Expert Introspection technique along with its drawbacks
Be able to describe the range of techniques available to discover User requirements
Be able to discuss the advantages and disadvantages of 'focus groups' in obtaining requirements.
Be able to describe what is meant by the term Domain
Be able to describe the Domain Expert concept and how it relates to yourself
Be able to provide a brief description of the 'Feature-Oriented Domain Analysis' process and list its
three basic phases.
Be able to relate the stages of the RE phase of IS development as described by Christel and Kang
(1992)
Be able to draw a diagram illustrating Christel and Kang's interpretation of the first of these stages
Be able to list the four responsibilities of the Requirements Analyst
Be able to define the term 'IBIS'
Be able to discuss the range of problems associated with requirements elicitation (Scope,
understanding, volatility)
Be able to describe the range of problems associated with requirements elicitation (Scope,
understanding, volatility) using the traditional method of IS development.
Using your own experience be able to provide a critique of the above requirements elicitation
problems posited by McDermid (1989)
Be able to describe the purpose of Scenario analysis in Requirements Engineering along with an
overview of how it is carried out
Be able to list two standards concerning Requirements Engineering
Be able to describe the scientific characteristics of requirements. (i.e. Correct, Complete, Consistent,
Unambiguous & Verifiable)
Be able to describe various levels of compliance into which requirements can be categorized
Be able to discuss the classification of requirements into functional and non-functional aspects
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 5 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
3. Introduction
One of the first stages in any Information System development process (termed 'lifecycle' in the trade) is
setting down the proposed requirements for the system. Such requirements may be the complete definitive
set if you are using the traditional waterfall development lifecycle or a more tentative set of basic ones if you
are using some form of iterative prototyping or more radical methods such as eXtreme Programming..
In this document, we will introduce the various approaches used to achieve this, along with the associated
problems. This document provides an overview or the more 'quantitative' techniques. Another document will
describe, and develop your skills in two qualitative methods, one borrowed from Anthropology and the other
from a radical 1960s sociological movement will be discussed in one document, while several other documents
will concentrate on more quantitative techniques.
The process of obtaining requirements can basically be viewed from a qualitative (interpretist) or quantitative
perspective. The majority of systems developers (modellers) have adopted the latter paradigm and have
chosen the term 'Requirements Engineering' (RE) to indicate the process of obtaining, documenting and
validating requirements.
Wikipeadia provides a good introduction to RE at http://en.wikipedia.org/wiki/Requirements_analysis
Guy Saward at the University of Hertfordshire, in his undergraduate course concerning RE provides a good
introduction to what RE is (http://homepages.feis.herts.ac.uk/~3com0027/CONTS(1).HTML):
"Requirements engineering is, roughly speaking, about describing or specifying what people, or organisations,
want from a computer-based system in such a way that software engineers are able to build a system that
satisfies their needs. More precisely, we can define requirements engineering as "the branch of systems
engineering concerned with the real-world goals for, services provided by, and constraints on a large and
complex software-intensive system. It is also concerned with the relationship of these factors to precise
specifications of system behaviour, and to their evolution over time and across system families." (after Zave
1994).
Note: 'software engineer' is a modern term for programmers who also have modelling and software
development management skills.
In other words, the process of RE involves eliciting, modelling, analysing and validating requirements for
systems and software. The verification of finished systems with respect to an original requirements
specification is also an important issue. A range of tools and techniques are available to support each of these
activities, and researchers in this area are currently developing ever more techniques.
We will start by looking at possibly the most common method of obtaining requirements, 'Expert
Introspection'.
3.1 The Problem with Expert Introspection
Surprisingly, one of the most common methods of developing a list of requirements is what is called "Expert
Introspection". It basically amounts to imagining what kind of system 'the expert' would want if she/he were
doing the job using this equipment, etc. It is often nothing more than prophesising, and many systems
developers now consider this technique inappropriate if not dangerous (Goguen and Linde 1993 p154).
As a modeller myself, I feel I must add something here about "Expert Introspection". While the method
(probably a better term would be habit!) has been shown to be largely invalid by researchers, modellers are
placed under a great deal of pressure to produce a set of requirements. Such requirements are expected to be
produced as soon as possible and often with minimal interaction with the client or intended users. In fact, I feel
it could be said that frequently the less time one spends with the client groups to produce the requirements
the more competent and knowledgeable one is (initially) considered to be by the client. We will now consider
other techniques of gaining requirements.
Exercise 1.
Write down ten methods you could use to find out what various stakeholders might want from a proposed
Information System (IS).
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 6 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
4. Methods Used to Gain Requirements
Some of the methods used to collect information are listed below.
1.
2.
Interviews:

tutorial

unstructured

structured

protocol analysis (describing tasks)
Meetings:

brainstorming

Joint Application Design/Rapid Application Design

focus groups

using scenarios
3.
Questionnaires
4.
Video Analysis
5.
Discourse Analysis
6.
Analysis of Current Forms Used (Form Analysis) and/or (Natural Language) Text Analysis
7.
Observation (Non- Participative and Participative)
8.
Task Analysis
9.
Domain Analysis
10. Scenario Analysis
Some of the items listed above I would have expected you to have suggested in the exercise, such as
questionnaires and interviewing. However, I would not have expected anyone to come up with 'Domain
Analysis'! The strange thing is that the list contains several qualitative techniques, yet if you asked most people
involved in obtaining requirements they would see it as a quantitative technique. Basically this is because
'requirements engineers' are not fussy about dirtying their hands with such things if they can be manipulated
to provide quantifiable output at the end of the process. We will look more at this rather bombastic in the
document concerned specifically with qualitative techniques.
I will now provide a brief description of some of the above methods:
Questionnaires: These are frequently used. However, they are often poorly produced by 'techies'. For
example, questions are often not checked first for understandability with the intended respondents, or there
are large gaps or unnecessary rigidity in the questionnaire (i.e. it is not 'fit for purpose').
Interviewing requires good interpersonal skills along with some training from which it has been shown that
modellers benefit. (I did have a reference for this assertion but seen to have lost it - any help welcome)).
JAD: "The team approach to requirements elicitation is characterized by JAD, an acronym for Joint Application
Design. JAD focuses on improving the group process and getting the right people involved at the start [Zahniser
90]. This technique has been used successfully by IBM since the late 1970s, and its advantages include the
promotion of cooperation, understanding and teamwork among users, developers and customers. Developers
help users formulate problems and explore solutions, while users share ownership of the requirements and
associated.documents.
Through the use of structured meeting procedures, facilitation protocols and visual aids, JAD enhances idea
generation and evaluation, communication and consensus generation. Guidance on using JAD is provided in
[Wood 89], which emphasizes its use for online, transaction-based systems..While this technique has been
used successfully, a recognized problem is that all of the participants funnel their ideas through a facilitator or
recorder. Thus, the recorder may inadvertently impose an interpretation on the collected data not shared by
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 7 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
the group. For integration, JAD is dependent on the skills of the recorder, much as the integration of structured
interviews is dependent on the skills of the requirements analyst. An ideal method would allow for the
transparent capture of the information discussed at the meetings and the efficient organization of this
information." (from Christel and Kang 1992 p18)
"...A JAD session can be costly, however, in terms of people and time. A JAD session may contain 18 to 25 people [Wood
89]. The JAD session is capable of producing agreement on "3 screens per half day session" [Wood 89, p111], which hints
that a JAD session for a complex, real-time system may span many days." (from Christel and Kang 1992 p50).
Rapid Application Design (RAD): This is a similar technique to JAD but most importantly comes with software
to enhance the process.
Focus Groups: This is a technique developed in market research and is often done using stimulus material such
as films, story boards or product mock-ups as a focus (hence the name), and it is commonly used to obtain the
opinions of representative potential customers of new products (Goguen and Linde 1993 p155). Focus groups
suffer from the same problems as JAD, or for that matter any method that involves group interactions, namely:
"Focus groups have the advantage of allowing more natural interactions between people than questionnaire
interviews,...However, the groups are usually not natural communities, such as people who eat lunch together,...but rather
are an ad hoc collection, constituted for the occasion by the researcher, usually on the basis of demographic
considerations. Further, although focus groups may be valuable for eliciting responses to products whose features and
trade-offs customers understand (for example, whether they would be willing to pay more for upscale gourmet dog food
for their Doberman Pinschers), they are not useful in eliciting opinions on design issues where the subjects are not experts,
and therefore must respond within the categories and structures provided by the researcher...participants may have widely
different status within the organisation, there is a danger, that some will not feel free to say what they really think,
especially if it is unpopular." (Goguen and Linde 1993 p155 -6)
Task Analysis: This involves either observing or getting prospective system users to describe how they go
about their tasks. The information collected is then structured in some way, often using diagrams. This is also
used in a technique called BPR (Business Process Re-engineering) which will be covered later in the course
including an introduction to some of the diagramming techniques.
Protocol Analysis: This is where subjects describe what they are doing and thinking (the speakers' concurrent
cognitive analysis?) while doing it. While it has been widely used in the past to specify a large number of
different systems, it is now considered to be not very useful. While there are several reasons for its failure (see
Goguen and Linde 1993 for details), I will just concentrate on just one problem below.
4.1.1 The Say-Do Problem
"People know how to do many things that they cannot [verbally] describe. It is commonplace in ethnography
that people's descriptions of how they weave a basket or choose a chief or write a program bear a complex
and opaque relation to how they can be seen to do these things when they are observed. The problem is so
familiar that it has a nickname in social science: the say-do problem; also, philosophers speak of tacit
knowledge. The moral is this: Don't ask people to describe activities that they do not normally describe, or if
you do, then don't believe the answers" (Goguen and Linde 1993 p155).
Exercise 2.
Try to write down how you tie a shoelace into a bow.
When you have tried go to http://www.fieggen.com/shoelace/index.htm
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 8 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
5. Domain Analysis
The above paragraphs have described a few of the techniques available to modellers for discovering
requirements. For a more detailed discussion, including a method for choosing the suitability of a particular
technique in a specific situation, see Davis 1982. We will now look at Domain Analysis.
With the realisation that important contextual factors were not being taken into account when developing IS,
various methods have been devised to take into account such factors. In the quantitative tradition of the
'engineering' perspective, a number of related techniques have developed since the early 1990s to analyse
'domains'.
5.1 What is a Domain?
"A domain is defined by a set of "common" problems or functions that applications in that domain can
solve/do (hence the term "application domain''). Also, a domain is typically characterized by a common jargon
or ontology for describing problems or issues that applications in it address."
(Taken from: http://www.sern.enel.ucalgary.ca/charmi/Courses/97-98/ENEL619.02/FuSeminar.html no longer
active 5/01/2008).
The important thing to note is that a domain has a common vocabulary, such as medicine, law or engineering.
In fact, I would say that medicine contains a large number of domains with each specialty having its own way of
working and vocabulary.
The previous exercise asking you to describe how to tie a shoelace is an instance where everyday language is
insufficient but at the same time does not matter in the everyday domain. However, when the tying of knots is
an important aspect of a domain, such as in sailing, a specialised language is developed to describe it.
Exercise 3.
Take a minute to browse one of the following links.
a. Knot tying notation at: http://www.earlham.edu/~peters/knotting/notate.htm
b. Delve into the world of knots: http://www.earlham.edu/~peters/knotlink.htm
5.2 What is a Domain Expert?
A domain expert is someone who understands a particular domain. They are said to possess "domain
knowledge". This applies to the majority of the Health Informatics students, whether they want to possess it or
not!
Central to the concept of a domain analysis is the domain expert and we will revisit this concept latter.
5.3 Domain Model
A domain model (Also Called a Domain Definition or Domain Specification) is a definition of the domain using
such techniques as object modelling along with data definitions. The model attempts to discover commonalties
and differences among others in the same or different domains. Eventually the idea is to develop generic
models, something that will be discussed further in the documents concerned with systems modelling. See
http://www.robin-beaumont.co.uk/virtualclassroom/contents.htm section 11. This is where you will find the
actual techniques described, along with exercises to help you develop a Domain Model.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 9 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
Another definition of a domain model, focusing on the IS aspect, is the following:
A product of domain analysis which provides a representation of the requirements of the domain. The domain
model identifies and describes the structure of data, flow of information, functions, constraints and controls
within the Domain that are included in software systems in the domain. The Domain Model describes
commonalities and variabilities among requirements for software systems in the domain.
From the Free Online Dictionary of Computing: http://wombat.doc.ic.ac.uk/foldoc/
The amount of information given in this document does not provide you with
the expertise to produce a Domain Model only to be aware that such things
exist along with their purpose.
5.4 Domain Analysis and the Stages of Requirements
Engineering
Note: The abstract below is provided for reference; you will not be assessed on the detailed content. All you
need to know is that a method exists for carrying out a domain analysis, and in this instance with FODA, the
product is a computer system specification.
Domain Analysis is the process used to produce a Domain Model and the following abstract describes a
particular technique of producing a domain model using 'Future Oriented Domain Analysis (FODA)', taken
from
http://www.sern.enel.ucalgary.ca/charmi/Courses/97-98/ENEL619.02/FuSeminar.html no longer active but
simiular information now available at: http://www.sei.cmu.edu/str/descriptions/foda.html
"Numerous Domain Analysis approaches currently exist. Each of them focuses on increasing the understanding
of the domain by capturing the information in a formal model. One such approach is the Feature-Oriented
Domain Analysis (FODA), developed at the Software Engineering Institute (SEI).
FODA defines a process for domain analysis and establishes a specific product for later use. Three basic phases
characterize the FODA process:
1.
Context Analysis: defining the extent (or bounds) of a domain for analysis
2.
Domain Modelling: providing a description of the problem space in the domain that is addressed by
software
3.
Architecture Modelling (Architecture= software + hardware)
1. Context Analysis
The resulting knowledge from the context analysis provides the domain analysis participants with a common
understanding of:
1.
• The scope of the domain
2.
• The relationship to other domains
3.
• The inputs/outputs to/from the domain
4.
• Stored data requirements (at a high level) for the domain
The product resulting from the context analysis is the context model.
2. Domain Modelling
Domain Modelling identifies and models the commonalities and differences that characterize the applications
within the domain. It provides an understanding of the applications in the domain that is addressed by
software. By systematically representing (or modelling) the functions, objects, data and relationships of
applications in the domain, domain modelling is used to define what the applications are, what the
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 10 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
applications do and how the applications work. The activities (or analyses) conducted during the domain
modelling phase provides an understanding of the:
1.
• Features of the software in the domain
2.
• Standard vocabulary of domain experts
3.
• Documentation of the information (entities) embodied in the software
4.
• Software requirements via control flow, data flow and other specification techniques
The FODA Domain Modelling phase produces a domain model which consists of three components. Each
component employs a separate analytical technique to model the interrelated components of the domain
model. An information analysis produces an information model, a features analysis produces a features model
and an operational analysis produces an operational model.
3. Architecture Modelling
This is creating the software architecture(s) that implement solutions to the problems in the domain. The
architectural modelling phase was initially defined as part of the FODA methodology. However, the process of
integrating FODA products with architectural modelling has become part of the domain design activity in the
overall concept of Domain Engineering.
(end of abstract)
The above method is only one of many intended to help define requirements. As Goguen and Linde 1993 p153
put it:
"Requirements engineering is an immature discipline, perhaps not entirely unfairly characterised as a battlefield
occupied by competing commercial methods, firing competing claims at each other, and leaving the consumers
weary and confused."
For the medics amongst you, I would imagine you can well understand the situation. Rather than presentng
you with a selection of methods, I will just present you with one more model of the stages for gaining
requirements.
Christel and Kang 1992 proposed that the RE phase of IS development contains the following stages:
1.
Elicitation of requirements
2.
Specification of requirements
3.
Validation of requirements
They concentrate on the elicitation stage as they feel that this is the most important but least formalised of the
three. They suggest that the elicitation stage should be divided into the following steps:
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 11 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
Exercise 4.
Christel M G Kang K C 1992 Issues in Requirements Elicitation Technical Report CMU/SEI-92-TR-12 ESC-TR-92012 Software Engineering Institute Carnegie Mellon University Pittsburgh, Pennsylvania 15213 available from:
http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.012.html (click at bottom of page). Link
Active 05/01/2008.
Read section 5.1 of the Christel and Kang 1992 article while considering the following questions:
1.
What are the four responsibilities of the Requirements Analyst?
2.
What does IBIS stand for?
3.
What are the five stages of requirements elucidation according to the above authors?
6. Problems with Requirements Elicitation
The traditional IS development project rarely had a domain expert, and the relationship between the users and
modellers was simple.
Clients -----------------» Developers (modellers)
This seemingly simple situation presents
some major difficulties during the
requirements elicitation phase. Gilb 1988
provides a lovely cartoon in his book
demonstrating just what can go wrong. This
excellent book is well worth a look not just
for the cartoons.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 12 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
A more measured approach to suggesting the problems with requirements elucidation is the list provided by
McDermid 1989, given below:
Problems of scope:
1.
The boundary of the system is ill-defined.
2.
Unnecessary design information is given.
Problems of understanding:
1.
Users don't fully understand their needs.
2.
Users don't understand computer capabilities and limitations.
3.
The requirements engineer doesn't understand the problem domain.
4.
Users and engineers speak different languages.
5.
'Obvious' information may be omitted.
6.
Different users have conflicting views.
7.
Requirements are vague and untestable.
Problems of volatility:
a.
Requirements evolve over time.
The list above is rather dry so to help you understand more about the problems encountered with developing
requirements, please carry out the exercise below.
Exercise 5.
Hooks I F 1994 Managing Requirements in "Issues in NASA Program and Project Management: A Collection of
Papers on Aerospace Management Issues". Winter 1994. Download from:
http://www.complianceautomation.com/papers/papers.htm (active 05/01/08)
or
http://www.complianceautomation.com/papers/ManagingRequirements.pdf (active 05/01/08)
Ivy Hooks describes, in very clear terms, some of the real problems encountered with NASA projects and RE.
Please read the article bearing in mind:
b.
The article is old. She was working with the old waterfall development method where any change to
the requirements meant the completion of a Review Item Disposition (RID) form along with a complex
procedure.
c.
Read carefully the paragraph concerning accountability.
d.
When reading the section concerned with the Space Station Requirements (p8), think how a similar
scenario might be applied to the NHS Electronic Health/Patient Record Project!
From the above, we can see that one of the most important problems concerning the RE stage is the
ineffective communication between the systems developers and the clients. The ETHICS method attempted to
offer solutions to some of the above problems by educating the users in modelling techniques and the systems
developers in gaining domain knowledge, thus reducing the language gap, more radically in the eXtreme
Programming method the two people actually sit side by side and produce the software together. You will be
aware of this technique along with others from the document concerned with getting users involved in the
development effort. An alternative strategy is to introduce a bridging function; an example of this is the formal
use of the domain expert, which will be considered next.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 13 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
7. The Domain Expert - Your Role After the Course
With the introduction of a domain expert as a bridging role, a more complex relationship exists in place of the
traditional situation. We now have something like:
Modeller
Users
Domain Expert
The domain expert possesses both expert knowledge of the domain and also a working knowledge of system
development methods and issues. Such a role is vital to rectify some of the problems encountered in gaining
requirements, such as those listed above (McDermid 1989).
One popular method of eliciting requirements called "Scenario-Based Requirements Elicitation" can be greatly
enhanced when a domain expert with additional systems development expertise is involved. This version of
this technique will be taught to you in the systems modelling module, under the name of dynamic modelling,
but for now I will provide you with a brief introduction (based upon Guy Saward 1996) on the next page.
Exercise 6.
Do you believe that the current course you are undertaking is helping you fulfil the role I suggest of being a
domain expert, that is who acts as a conduit between the modellers and users?
8. Scenario Analysis
A scenario is a 'story' that describes a particular set of actions and events, such as the process of referring a
patient to the local hospital.
Discussing scenarios helps to:
1.
generate understanding and sense of participation
2.
elicit expertise about the domain from users
3.
uncover unstated requirements
One method you can use to generate scenarios is to carry out the following steps:
1.
Identify main objects ('things' to you and me, they need not necessarily be people, ie medical
notes)
2.
Give each scenario a name (choose the simplest ones first)
3.
Develop brief textual descriptions
4.
Identify the main flow of events (use a technique similar to flow charting)
5.
Consider normal events
6.
Consider exceptional events
7.
Identify possible parallel events
You will learn a lot more about scenario analysis in the systems modelling unit (see: http://www.robinbeaumont.co.uk/virtualclassroom/case_tutorials.htm ). There is even a requirements elicitation method based
upon the development of scenarios called SBRE (Scenario Based Requirements Elicitation) (Holbrook 1990).
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 14 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
9. Requirement Engineering Standards
We will consider two in this section ISO 9000-3 and IEEE Standard 830 1993.
9.1 ISO 9000-3
The following is taken from Saward 1996
(active 05/01/08):
(http://homepages.feis.herts.ac.uk/~3com0027/REST(25).HTML)
ISO 9000-3 guidelines on applying ISO 9001 (and BS5750 and EN 29001) quality principles to the software
development process offer only very general guidance regarding the requirements stage:
'In order to proceed with software development, the supplier should have a complete, unambiguous set of
functional requirements. In addition, these requirements should include all aspects necessary to satisfy the
purchaser's need. These may include, but are not limited to, the following: performance, safety, reliability,
security, and privacy. These requirements should be stated precisely enough so as to allow validation during
product acceptance.
...The purchaser's requirements specification should be subject to documentation control and configuration
management as part of the development documentation.
All interfaces between the software product and other software or hardware products should be fully
specified, either directly or by reference, in the purchaser's requirements specification.
During the development of the purchaser's requirements specification, attention to the following issues is
recommended:
a) assignment of persons (on both sides) responsible for establishing the purchaser's requirements
specification
b) methods for agreeing on requirements and approving changes
c) efforts to prevent misunderstandings such as definition of terms, explanations of background of
requirements
d) recording and reviewing discussion results on both sides.
9.2 IEEE Standard 830 1993
More comprehensive guidance on the nature of a Software Requirement Specification (SRS) Document is given
in the recent IEEE standard 830, which now has the status of 'Recommended Practice'. You can find further
details in A. Davis, "Software Requirements: Objects, Functions and States", Prentice Hall, 1993, chap 3.
Benefits of a good SRS (i.e. one conforming to guidelines given) are listed as:






providing a basis for client-developer agreement regarding system functionality
reducing the development effort
providing a basis for cost estimation and project planning
providing a baseline for product validation and verification
facilitating transfer or re-use of product (for clients and developers)
providing a basis for enhancement
The IEEE standard:






is aimed at software not system requirements
focuses on providing an external or 'black box' view of the software required
can be used to create a requirements document directly, or to create a more specific standard
does not cover project requirements
does not recommend the use of any specific tools, methods or notations
suggests several possible ways of organising a requirements document
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 15 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
The IEEE standard describes a number of desirable properties in a 'Good Software Requirements Specification'.
Some of these relate to the content of the SRS:





correct - if and only if every requirement is one that the software shall meet
unambiguous - statements should have only one interpretation
complete - includes all requirements, defines responses to all inputs, is fully referenced etc
consistent - should not contain factual, logical or temporal contradictions
verifiable - should be able to check that the system has met the requirement
Some relate to the format:



annotated - should indicate relative necessity and relative stability
modifiable - any changes to requirements should be easy to make
traceable - visible mappings, both backwards and forwards, between the customers' initial requests,
the requirements specification and the final system eg using a traceability matrix
10. 3 Cs UV
The standards discussed above embody the scientific paradigm basically aiming to comply to the '3 C's UV'
criteria, which are the following:
 Correct
 Complete
 Consistent
 Unambiguous
 Verifiable
For requirements to be verifiable, they must also be measurable. One person who has fought for the
quantification of nebulous requirements is Tom Gilb. He has published a very popular book on the subject of
not only developing user requirements but also software management in general (Gilb 1988).
In the exercise below you will consider what he has to say about quantifying requirements.
Exercise 7.
Gilb T.1997 Towards the Engineering of Requirements. Requirements Engineering 2 165-169 Springer-Verlag
London. The article is available online at:
http://rej.co.umist.ac.uk/Volume-2/Issue-3/Viewpoints.html
Read the article particularly noting section 6:
"Things we can do to improve Requirements Engineering Practices":
1.
We must define requirements clearly and unambiguously.
2.
We must teach a discipline of specification at the systems level.
3.
We must clearly connect design to requirements.
4.
We must carry out rigorous quality control of requirements and design.
5.
We must not allow highly defective (ambiguous, unclear, inconsistent) specification to be used as
inputs to other work processes.
6.
We must not specify too much detail too early. We must systematically get the benefit of early cycles
of evolutionary deliveries, to help us re-specify requirements more realistically.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 16 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
GILB PUNCH-LINE
We cannot expect to improve software engineering design, testing and quality control until we have
considerably improved our ability to articulate quality requirements and other requirements in
unambiguously clear testable format, and until we even understand the distinction between ends
and means."
Much of the information in this article is based upon that of Billy Koen University of Texas who
published a book for Oxford University Press in 2003 on this subject
http://www.me.utexas.edu/~koen/OUP/OUP.html.
11. Classifying Requirements
In the above article by Gilb you were introduced to the idea of false requirements, which is rather idiosyncratic
to him in contrast most sources recommend the division of requirements into functional and non-functional. It
is also common practice to specify for each requirement a level of compliance such as 'Must', 'Should' or
'Optional' levels (refer back to the introduction to systems development document for more information) and
a unique number.
A traceability matrix is also sometimes included, providing an easy way of seeing the changes over time for
each requirement. The traceability matrix may simply be a set of references to particular sentences in a
narrative specification and when/ who and how each was changed.
To learn more about how requirements are classified, and how they may be improved, carry out the exercise
below.
Exercise 8.
Christel M G Kang K C 1992 Issues in Requirements Elicitation Technical Report CMU/SEI-92-TR-12 ESC-TR-92012 Software Engineering Institute Carnegie Mellon University Pittsburgh, Pennsylvania 15213 available from:
http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.012.html (select the PDF version). Link
Active 05/01/2008. [You read part of this for exercise 4]
Read section 1.1 'Definitions' of the above paper. Make sure you understand the difference between
functional and non-functional requirements by the time you have finished reading it.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 17 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
12. Summary
This document has introduced you to the 'requirements' aspects of systems development from a quantitative
perspective. It has focused on, describing the various techniques available for you to use to ensure you capture
all the necessary information, but also the common problems encountered with this activity. Information was
also provided describing the various standards that relate to 'requirements'.
You will be introduced to the actual skills required to collect the detail in several other documents; the
document concerning qualitative techniques will give you practice in developing ethnography skills while the
Modelling documents will focus once again on more quantitative techniques allowing you to collect detailed
requirements, principally UML.
Possibly the most important aspect of this document was the introduction of the 'domain expert' concept and
how this role can be extended to facilitate the system development process...a role for which you will
undoubtedly be most aptly suited by the end of the course!
Finally it must not also be forgotten that the process of elucidating and formalising requirements is within a
organisational/cultural structure and its success or failure depends upon a whole range of things, which we
have discussed elsewhere, but just to remind you, here is a nice diagram from a recent paper discussing this
topic:
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 18 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
13. MCQs
The following Multiple Choice Questions are designed to help you check that you have read through the
material thoroughly. Good luck.
1. What is basically expert introspection in the field of requirements engineering? (one correct answer)
a.
b.
c.
d.
e.
Carrying out an in-depth analysis of user requirements by way of cognitive walk thoughts
Guessing what the user requirements are for someone else
Focusing in a highly structured way the user requirements of a known user
Focusing on the possible requirements of an expert user
Getting an expert to reflect with an intended user their possible needs
2. Expert introspection in the field of requirements engineering is the following: (one correct answer)
a.
f.
g.
h.
i.
A reputable technique
A technique that should only be used by highly trained modellers
A technique that is not considered to be reputable now-a-days
A technique that requires one to attend a certified course
A technique that should never under any circumstances be used
3. What is the say-do problem? (one correct answer)
a.
b.
c.
d.
The inability to describe what one is doing due to a neurological deficit
The inability to describe what one is doing due to the rarity of carrying out the task
The inability to describe what one is doing due to the complexity of the movements
The problem exhibited in some languages to provide adequate words
4. The characteristic of a domain is: (one correct answer)
a.
j.
k.
l.
It has a set of clearly defined roles
There is a particular jargon associated with it
It possesses exclusivity
It possesses a set of unique procedures
5. A domain expert is: (one correct answer)
a.
m.
n.
o.
A software tool which provides context specific help
A form of expert system
A person who possesses domain knowledge
A person who has worked in a specific domain
6. A domain model is: (one correct answer)
a.
b.
c.
d.
A specification of requirements for a particular domain for an information system
A specification of the processes in a domain
A specification of the training needs for a domain
A specification of the generic requirements that can work in a number of domains
7. Requirements engineering has been said to be: (one correct answer)
a.
p.
q.
r.
s.
An exact science
An immature discipline
A mathematical specification technique
An unnecessary process
A stage to be carried out late on in the system development life cycle
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 19 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
8. Scenario analysis helps: (one correct answer)
a.
t.
u.
v.
w.
Teach the prospective users about the system
Uncover unstated requirements
Suggest data requirements for databases
Specify costings
Provide a method of debugging code
9. The ISO 9000-3 standard is concerned with: (one correct answer)
a.
x.
y.
z.
aa.
Washing machine functioning
Software development
Behaviour with clients
Professionalism
Specifically elucidating user requirements
10. What are the '3 Cs UV' criteria? (one correct answer)
a. Correct, complete, consistent, Unambiguous, Verifiable
bb. Correct, complete, costed, Used, Verifiable
cc. Connected, complete, consistent, Unambiguous, Valued
11. Requirements are often divided into the following categories: (one correct answer)
a.
b.
c.
d.
e.
User and client defined
Functional and system
Functional and non-functional
Critical and non critical
Interface and system
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 20 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
14. Web Links
Didar Zowghi (http://www-staff.it.uts.edu.au/~didar/ ) is one of the main researchers concerned with
Requirements Engineering, and until recently provided a number of web resources
(http://www.jrcase.mq.edu.au/seweb/requirements/requirements.html no longer active 06/01/08) the new
link to the Requirements Engineering group at The University of Technology, Sydney appears to provide much
less information http://research.it.uts.edu.au/re/.
Ian Alexander is a Systems Engineer specialising in Requirements Engineering who is a Chartered Engineer and
an Honorary Visiting Research Fellow of City University (UK). He also provides a large amount of information
about RE and systems modelling in general, as well as copies of his papers from reputable journals etc.
http://easyweb.easynet.co.uk/iany/consultancy/papers.htm
Popular Papers on requirements (i.e. writing good requirements, managing requirements etc)
http://www.complianceautomation.com/papers/papers.htm
Above includes the classic article, about NASA by Ivy Hooks which you can also get from:
http://www.complianceautomation.com/papers/ManagingRequirements.pdf
Technical report on user requirements (click on pdf at bottom):
http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.012.html
2007
15th
IEEE
International
Conference
On
Requirements
Engineering
http://www.re07.org/home/ and also provides details of the 16th to be held in Barcelona, Spain, on
September 8-12th 2008
15. References
Anderson R J 1994 Representation and requirements: The value of ethnography in System design. Humancomputer interaction 9 (2) 151 - 82
Anderson R J Hughes J A Sharrock W W 1989 Working for profit:The social organisation of calculability in an
entrepreneurial firm. Aldershot, Avebury.
Becker H S 1963 Outsiders: Studies in the Sociology of Devience. The Free Press. New York Gomm R McNeill P
1982 Handbook for Sociology Teachers. Heinemann, London.
Becker H S Geer B Hughes E C Strauss A L 1961 (reprinted 1980) Boys in white: Student culture in medical
school. University of Chicago Press.
Brodie D A Williams J G Owens R G 1994 Research Methods for the Health Sciences. Harwood Academic
Publishers. Reading UK.
Christel M G Kang K C 1992 Issues in Requirements Elicitation Technical Report CMU/SEI-92-TR-12 ESC-TR-92012 Software Engineering Institute Carnegie Mellon University Pittsburgh, Pennsylvania 15213 available from:
http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.012.html (click at bottom of page). Link
Active April 2003.
Cuff E C Payne G C E 1984 (2nd ed.) Perspectives in sociology. George Allen & Unwin.
Davis A M 1993 Software Requirements: Objects, Functions and States. Prentice-Hall
Davis G B 1982 Strategies for Information Requirements Determination. IBM Systems Journal 21 (1) 4 -30
Frakes, W.B. Kang K, 2005 Software Reuse Research: Status and Future, IEEE Transactions on Software
Engineering, 31(7), July, pp. 529-536. [discusses domain analysis]
Gause D G Weinberg G M 1989 Exploring Requirements: Quality Before Design. Dorset House.
Gilb T.1988 Principles of Software Engineering Management. Addison-Wesley Longman.
Gilb T.1997 Towards the Engineering of Requirements. Requirements Engineering 2 165-169 Springer-Verlag
London Also available online at: http://rej.co.umist.ac.uk/Volume-2/Issue-3/Viewpoints.html
Goffman E 1961 Asylums. Penguin Books.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 21 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
Goguen J A 1994 Requirements engineering as the reconciliation of social and technical issues, in Requirements
Engineering: Social and technical issues, Jirotka M & Goguen J (eds.) p. 165 - 200 London, Academic press
Goguen J A Linde C 1993 Techniques for requirements elicitation in Proceedings of RE'93: IEEE International
symposium on requirements engineering, San Dago CA, 4-6 Jan pp. 152-64
Grudin J 1989 The case against User Interface Consistency. Communications of the ACM 32 (10) [October] p.
1164 - 1173
Hammersley M 1993 Social Research: Philosophy, Politics and Practice. Sage Publications.
Heath C Luff P 2000 Technology in action. Cambridge University Press.
Hill W C Holland J D 1992 Edit wear and read wear. Proceedings of ACM CHI'92 Conference. Monterey, CA, 3 - 7
May p3 - 9.
Hjørland B, Albrechtsen H, 1995 Toward a New Horizon in Information Science: Domain-Analysis, Journal of the
American Society for Information Science, No. 6, vol. 46 (1995), pp. 400-425 [discusses domain analysis]
Holbrook H 1990 A scenario based methodology for conducting requirements elicitation. ACM Software
engineering notes 15 (1) No page numbers given in reference
Hooks I F 1994 Managing Requirements in "Issues in NASA Program and Project Management: A Collection of
Papers on Aerospace Management Issues". Winter 1994.
Humphreys L 1973 The Tearoom Trade. Duckworth, London.
Loucopoulos P Karakostas P 1995 System Requirements Engineering. McGraw-Hill.
McDermid J 1989 'Requirements Analysis: Problems and the STARTS Approach', in IEE Colloquium on
Requirements Capture and Specification for Critical Systems, Digest no. 138, Nov. 1989.
McNeill P 1990 Research Methods. Routledge. London
Patrick J 1973 A Glasgow Gang Observed. Eyre Methuen. London
Pope C Mays N 2000 (2nd ed.) Qualitative Research in Healthcare. BMJ Publications. (available online at:
http://www.bmjpg.com/qrhc - click on the Contents link and then click on Chapter 2)
Potts C Newstetter W C 1997 Naturalistic inquiry & requirements engineering: Reconciling their theoretical
foundations, in Proceedings of third IEEE international symposium on requirements engineering, Annapolis,
MN pp. 118-27
Punch M 1979 Observation and the Police: The Research Experience in Hammersley M 1993 Social Research:
Philosophy, Politics and Practice. P.181 - 199. Sage Publications.
Redican B Hedley D A 1988 A field studies project in a City Health & Leisure club. Sociology of Sports Journal 5
50 - 62
Rhode J Beaumont R 1997 Feasibility of developing & implementing a joint classification for those with learning
disabilities. IMG(A) NHS
Roberts K Brodie D A 1992 Inner-City Sport:Who plays, and what are the benefits. Giordano Bruno, Culemborg,
the Netherlands.
Robson C 1993 Real World Research. Blackwell.
Rosenhahn D 1973 On being sane in insane places. Science 179 250 - 258
Saward Guy 1996 'Requirements engineering' course material at:
http://homepages.feis.herts.ac.uk/~3com0027/CONTS(1).HTML
Silverman D 1997 Studying Organisational Interaction: Ethnomethodology's contribution to the 'new
institutionalism', Administrative theory and Praxis 19 (2) 178 - 95
Sommerville I Rodden T Sawyer P Bentley R Twidale M 1993 Integrating Ethnography into the Requirements
Engineering Process, in Proceedings of RE '93, San Diego CA. 165 - 173.
Turner R 1974 Ethnomethodology. Penguin. [Contains a set of papers including Garfinkels description of how
he came to think of the term].
Wallace A F C 1972 Culture and Cognition by J Spradley (ed.). Chandler, New York p.111 - 126.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 22 of 23
Health Informatics
Obtaining Requirements - introduction - Requirements Engineering Perspective
Document details:
First written 1999
Latest version: 06/01/2008 19:50
Author details: Robin Beaumont robin@organplayers.co.uk tel. 0191 2731150
File: C:\HIcourseweb new\chap5\s5\requirements_quant\obtaining_reqs_quantitative.doc
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Page 23 of 23