Obtaining Requirements - Requirements Engineering Perspective

splashburgerInternet and Web Development

Oct 22, 2013 (3 years and 7 months ago)

161 views

Obtaining Requirements

-

Requirements Engineering Perspective


By Robin Beaumont

e
-
mail:
robin@organplayers.co.uk

Thursday, 12 January 2012
Version
3





Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
2

of
32





How t hi s document shoul d be used:

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 par
t 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.


Who thi s document i s ai med 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 pe
ople 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 thr
ough this document.

Robin Beaumont





Contents

1.1

Prerequisites

................................
................................
................................
................................
.............

4

1.2

Required Resources

................................
................................
................................
................................
..

5

2.

Learning Outcomes

................................
................................
................................
..............................

6

3.

Introduction

................................
................................
................................
................................
........

8

3.1

The Proble
m with Expert Introspection

................................
................................
................................
...

8

4.

Methods Used to Gain Requirements

................................
................................
................................
..

10

4.1

The Say
-
Do Problem

................................
................................
................................
...............................

11

5.

Domain Analysis

................................
................................
................................
................................
.

13

5.1

What i
s a Domain?

................................
................................
................................
................................
..

13

5.2

What is a Domain Expert?

................................
................................
................................
......................

13

5.3

Domain Model

................................
................................
................................
................................
........

13

5.4

Domain A
nalysis and the Stages of Requirements Engineering

................................
.............................

15

6.

Problems with Requirements Elicitation

................................
................................
..............................

18

7.

The Domain Expert
-

Your Role After the Course

................................
................................
..................

20

8.

Scenario Analysis

................................
................................
................................
................................

20

9.

Requirement Engineering Standards

................................
................................
................................
...

21

9.1

ISO 9000
-
3

................................
................................
................................
................................
..............

21

Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
3

of
32

9.2

IEEE Standard 830 1993

................................
................................
................................
..........................

22

10
.

3 Cs UV

................................
................................
................................
................................
...........

23

11.

Classifying Requirements

................................
................................
................................
.................

24

12.

Summary

................................
................................
................................
................................
........

24

13.

MCQs

................................
................................
................................
................................
..............

26

14.

Web Links

................................
................................
................................
................................
.......

28

15.

References

................................
................................
................................
................................
......

30



Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
4

of
32


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.

The systems view of the world describes everything using three basic aspects. What are they?

2.

I mention the 5 ‘W’s and

H to consider when describing a system. What do they stand for?

3.

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 sys
tems development methods:

1.

What are the names of the two most common methods of developing Information systems?

2.

What are the three levels found in the ‘functional specification’?

3.

What are the main stages of the Waterfall method?

4.

What does PIR stand for?

5.

What is the more modern name for a systems analyst?

6.

What are the two main types of prototyping?

7.

What is the other name given to evolutionary prototyping?

8.

What is the audit cycle similar to?

9.

If I develop a system and gradually add different modules to it, w
hat type of prototype is it?

10.

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 ans
wers 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 in
volvement in systems development

-

You should feel confident to be
able to answer the following questions

1.

What is ‘top managers strategic withdrawal’ (Newman and Rosenberg 1985)?

2.

Johnson and Scholes 1993

divide stakeholders across several dimensions provi
de an example of two?

3.

One particular group of stakeholders can present significant problems
-

who are they?

4.

Traditionally what is often the measure of success of an information system?

5.

Baroudi J J

Olson M H Ives B 1986 demonstrated that certain relationships existed in the systems
development context. What were they?

Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
5

of
32

6.

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/virtualclass
room/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.

Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
6

of
32

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.




Learning outcome

Tick
box

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
McDerm
id (1989)



Be able to describe the purpose of Scenario analysis in Requirements Engineering along with
an overview of how it is carried out



Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
7

of
32

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




Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
8

of
32

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 d
efinitive
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 metho
ds such as eXtreme Programming.

In this
chapter
, we will introduce

the various approaches used to achieve this, along with the associa
ted
problems. This
chapter

provides an

overview

or the more 'quantitative' techniques. Another
chapter

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
chapter
, while several other
chapter
s will
concentrate on more quantitative techniques.

The process of obtaining requirements can basically be viewed from a qua
litative (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 obtaini
ng, 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 describin
g 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
e
ngineering 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 th
eir 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
Introspe
ction'.



3.1

The Problem w
ith 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
Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
9

of
32

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 some
thing 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 comp
etent 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

pr
oposed
Information System (IS).



Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
10

of
32

4.

Methods Used to Gain Requirements

Some of the methods used to collect information are listed below.

1.

Interviews:



tutorial



unstructured



structured



protocol analysis (describing tasks)

2.

Meetings:



brainstorming



Joint Applica
tion 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 thi
s 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

attitude

in
the
chapter

concerne
d 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 f
irst 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 b
een 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 o
n 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 onli
ne, transaction
-
based systems..
While this technique has been
Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
11

of
32

used successfully, a r
ecognized 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
the group. For integration, JAD is dependent on the sk
ills 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 organizati
on 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 softwar
e
to
facilitate

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 opinio
ns of representative potential customers of new products (Goguen and Linde 1993 p155).
Focus groups suffer

from (or have the advantage depending upon your viewpoint)

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 collec
tion, 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, wh
ether 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
structur
es 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 P
rocess 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 analy
sis?) 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

The Say
-
Do Problem

Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
12

of
32

"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



Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
13

of
32

5.

Domain Analysis

The above paragraphs have described a few of the techniques available to modellers for discovering
requirements. For a more detailed disc
ussion, 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 de
veloping 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 long
er
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 vo
cabulary.

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 d
omain, 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 th
is concept latter.


5.3

Domain Model

Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
14

of
32

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
chapter
s 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 Do
main Model.

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 Fre
e Online Dictionary of Computing:
http://wombat.doc.ic.ac.uk/foldoc/


The amount of information given in this
chapter

does not provide you with the expertise to produce a
Domain Model only to be aware that such things exist along with their purpose.

Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
15

of
32

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 '
F
eature

Oriented Domain Analysis (FODA)
', taken
from



http
://www.sern.enel.ucalgary.ca/charmi/Courses/97
-
98/ENEL619.02/FuSeminar.html

this link is
no longer
active but
similar

information
is
now available at:

http://www.sei.cmu.edu/reports/90tr021.pdf

"Nu
merous 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 Softwar
e 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:

Context Analysis
: defining the extent (or bounds) of a domain for analysis

Doma
in Modelling
: providing a description of the problem space in the domain that is addressed by software

Architecture Modelling

(Architecture= software + hardware)


1. Context Analysis

The resulting knowledge from the context analysis provides the domain ana
lysis 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 analysi
s 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
applications do and how the applications work. The

activities (or analyses) conducted during the domain
modelling phase provides an understanding of the:

Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
16

of
32

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 interrelat
ed 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 arch
itecture(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 t
he domain design activity in the
overall concept of Domain Engineering.

(end of abstract)


The above method is only one of many intende
d to help define requirement and a
s Goguen an
d 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 medic
s amongst you, I would imagine you can well understand the situation. Rather than
presenting

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 ph
ase 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 thr
ee. They suggest that the elicitation stage should be divided into the following steps:


Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
17

of
32



Exercise
4.

Christel M G Kang K C 1992 Issues in Requirements Elicitation Technical Report CMU/SEI
-
92
-
TR
-
12 ESC
-
TR
-
92
-
012 Software Engineering Institute Ca
rnegie Mellon University Pittsburgh, Pen
nsylvania 15213 available from:

http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.012.html

(click
on the downloa
d report
button
). Link Active
05/01/2008

-

11/01/2012
.

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?



Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
18

of
32

6.

Problems w
ith Requirements Elicitation

The traditional IS development project rarely had
a domain expert, and the relationship between
the users and modellers was sim
ple.

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
c
lassic
book is well worth a look
not just for the cartoons.






A more measured approach to suggesting the problems with requirements elucidation is the list provided by
McDermid 1989, given below:

a.
Problems of scope:

1.

The boundary of the system is ill
-
d
efined.

2.

Unnecessary design information is given.

b.
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.

c.
Problems of volatility:

1.

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.

Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
19

of
32

Ivy Hooks
1994
Managing Requirements

in "Issues in NASA Program and Project
Management: A Collection of
Papers on Aerospace Management Issues". Winter 1994

and
Managing Requirements for a System of
Systems

2004 are fascinating reading
:

http://www.reqexperts.com/papers.html

(a
ctive 12/01/2012
)

Ivy Hooks describes, in very clear terms, some of the real problems encountered with NASA projects and RE.
Please re
ad the article bearing in mind:

The
1994 article is old and s
he was working with the old waterfall development method wher
e any change to
the requirements meant the completion of a Review Item Disposition (RID) form along with a complex
procedure.



Read carefully the paragraph concerning accountability.



When reading the section concerned with th
e Space Station Requirements (p7
), think how a similar
scenario might be applied to the NHS Electronic Health/Patient Record Project!

She and Kristin
Farry

has also produced a book, Customer centered products: creating successful products
through smart requirements management, which is a

excellent read and most of it available on google books:
http://books.google.co.uk/books?id=HVvwMGGQqpoC


Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
20

of
32

Tom G
ilb

(and Kai Gilb)

also has a website
http:
//www.gilb.com/

and discusses similar topics to Ivy Hooks,
specifically
Kai's

chapter download
entitled
evolutionary project management chapter 10.

From the above

exercise and material
, we can see that one of the most important problems concerning the R
E
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 domai
n 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
chapter

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.


7.

The Domain Expert
-

Your Role After th
e 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:






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 o
f 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)
latter
.


Exercise
6.

Do you believe that the current course you are undertaking is helping you fulfil the role I sug
gest 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 hospit
al.

Modeller

Users

Domain Expert

Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
21

of
32

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
chapters

(see:
http://www.robin
-
beaumont.co.uk/virtualclassroom/case_tutorials.htm

)
. There is even a requirements elicitation method based
upon the development of scenarios called

SBRE

(Scenario B
ased Requirements Elicitation,
Holbrook 1990).


9.

Requiremen
t 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


(
http://homepages.feis.herts.ac.uk/~3com0027/REST(25).HTML)

(active 05/01/08

-

12/01/2012
)
:


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 regardi
ng 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 nee
d. 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:

Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
22

of
32

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

discussi
on 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 f
urther
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:

1.

providing a basis for client
-
developer agreement regarding system functionality

2.

reducing the development effort

3.

providing a basis for cost estimation and project planning

4.

providing a baseline for product validation and verification

5.

facilitating transfe
r or re
-
use of product (for clients and developers)

6.

providing a basis for enhancement

The IEEE standard:

1.

is aimed at software not system requirements

2.

focuses on providing an external or 'black box' view of the software required

3.

can be used to create a

requirements document directly, or to create a more specific standard

4.

does not cover project requirements

5.

does not recommend the use of any specific tools, methods or notations

6.

suggests several possible ways of organising a requirements document



Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
23

of
32

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

-

statem
ents 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 forwar
ds, 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:

1.

Correct

2.

Complete

3.

Consistent

4.

Unambiguous

5.

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
several

p
opular book
s

on the subject of
not only developing user requirements but also software management in general (
see
http://www.gilb.com/
).

In the exercise below you will consider what he has to say about quantifying requ
irements.

Exercise
7.

Gilb T.1997 Towards the Engineering of Requirements. Requirements Engineering 2 165
-
169 Springer
-
Verlag
London. The article is available online at:
h
ttp://rej.co.umist.ac.uk/Volume
-
2/Issue
-
3/Viewpoints.html

you
need to logon via the university to gain access.

Read the article particularly
noting section 6:

"Things we can do to improve Requirements Engineering Practices
"
:

1.

We must define requirements cle
arly 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 (ambig
uous, unclear, inconsistent) specification to be used as
inputs to other work processes.

Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
24

of
32

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 mo
re realistically.

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 disti
nction 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
.

He has written much since the above article but I feel that it is still very relevent.


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 l
evel 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 t
he 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
-
92
-
012 Software Engineering Institute Carnegie Mellon University Pittsburgh, Pen
nsylvania 15213 available from:
http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.012.html

(
click the download report
button
). Link Active 05/01/2008

-
1
2/01/2012
. [You
has already looked at this as

part of 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.


12.

Summ
ary

This
chapter

has introduced you to the 'requirements' aspects of systems development from a quantitative

perspective. It has not only focused on

describing the various techniques available for you to use to ensure you
capture

all the necessary informa
tion
but also the common problems encountered with this activity.
Information was also provided describing the various standards that relate to 'requirements'.

Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
25

of
32

You will be introduced to the actual skills required to
collect the detail

in

several other
cha
pter
s; the
chapter

concerning qualitative techniques will give you practice in developing ethnography skills while the Modelling
chapter
s will focus
once again on

more quantitative techniques

allowing you to collect detailed requirements
,
principally UML.

Possibly the most important aspect of this
chapter

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 elsewher
e, but just to remind you, here
is a nice diagram from a
paper discussing this topic:






Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
26

of
32

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.

Carrying out an in
-
depth analysis of user requirements by way of cognitive walk thoughts

b.

Guessing what the user requirements are for someone else

c.

Focu
sing in a highly structured way the user requirements of a known user

d.

Focusing on the possible requirements of an expert user

e.

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.

A reputable technique

b.

A technique that should only be used by highly trained modellers

c.

A technique that is not considered to be reputable now
-
a
-
days

d.

A t
echnique that requires one to attend a certified course

e.

A technique that should never under any circumstances be used

f.


3. What is the say
-
do problem?
(one correct answer)

a.

The inability to describe what one is doing due to a neurological deficit

b.

The inabili
ty to describe what one is doing due to the rarity of carrying out the task

c.

The inability to describe what one is doing due to the complexity of the movements

d.

The problem exhibited in some languages to provide adequate words


4. The characteristic of a dom
ain is:
(one correct answer)

a.

It has a set of clearly defined roles

b.

There is a particular jargon associated with it

c.

It possesses exclusivity

d.

It possesses a set of unique procedures


5. A domain expert is:
(one correct answer)

a.

A software tool which provides
context specific help

b.

A form of expert system

c.

A person who possesses domain knowledge

d.

A person who has worked in a specific domain


6. A domain model is:
(one correct answer)

a.


A specification of requirements for a particular domain for an information system

b.

A specification of the processes in a domain

Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
27

of
32

c.

A specification of the training needs for a domain

d.

A specification of the generic requirements that can work in a number of dom
ains


7. Requirements engineering has been said to be:
(one correct answer)

a.


An exact science

b.

An immature discipline

c.

A mathematical specification technique

d.

An unnecessary process

e.

A stage to be carried out late on in the system development life cycle


Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
28

of
32

8.

Scenario analysis helps:
(one correct answer)

a.

Teach the prospective users about the system

b.

Uncover unstated requirements

c.

Suggest data requirements for databases

d.

Specify costings

e.

Provide a method of debugging code


9. The ISO 9000
-
3 standard is concerned
with:
(one correct answer)

a.


Washing machine functioning

b.

Software development

c.

Behaviour with clients

d.

Professionalism

e.

Specifically elucidating user requirements


10. What are the '3 Cs UV' criteria?
(one correct answer)

a.


Correct, complete, consistent, Unambiguous, Verifiable

b.

Correct, complete, costed, Used, Verifiable

c.

Connected, complete, consistent, Unambiguous, Valued


11. Requirements are often divided into the following categories:
(one correct answer)

a.


User and cli
ent defined

b.

Functional and system

c.

Functional and non
-
functional

d.

Critical and non critical

e.

Interface and system




14.

Web Links

Didar Zowghi
(
http://www
-
staff.it.uts.edu.au/~didar/

) is one of the main re
searchers concerned with

Requirements Engineering
, and until recently provided a number of web resources
(
http://www.jrcase.mq.edu.au/seweb/r
equirements/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.i
t.uts.edu.au/re/
.

Ian Alexander is
a Systems Engineer specialisi
ng 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


Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
29

of
32

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
-
12
th 2008



Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
30

of
32

15.

References

Anderson R J 1994 Representation and requirements: The value of ethnography in System design. Human
-
computer 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
-
92
-
012 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 P
ayne 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. Dorse
t 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/V
olume
-
2/Issue
-
3/Viewpoints.html

Goffman E 1961 Asylums. Penguin Books.

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 Interfac
e 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.

Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
31

of
32

Hill W C Holland J D 1
992 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 i
n "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.

McDe
rmid 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 Obse
rvation 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, Cule
mborg,
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', Administr
ative 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.

Health Informatics

Obtaining Requirements
-

introduction
-

Requirements Engineering Perspective

Robin Beaumont robin@organplayers.co.uk
C:
\
Program Files
\
neevia.com
\
docConverterPro
\
temp
\
NVDC
\
65F95925
-
D732
-
4529
-
AEFC
-
CAA2442B90E2
\
splashburger_5aadc83f
-
45b4
-
4a14
-
a2fb
-
4f233804db86.docx

Page
32

of
32

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.





Document details:

First written 1999

Latest version:

12/01/2
012 10:42

Author details:

Robin Beaumont
robin@organplayers.co.uk



File
:
C:
\
HIcourseweb new
\
chap5
\
s5
\
requirements_quant
\
obtaining_reqs_quantitative.doc