\documentstyle[a4wide]{article}    % Specifies the document style.

                           % The preamble begins here.
\title{Semantics of Computer System Requirements from
Multiple Perspectives}
\author{Ann M Wrightson}    % Declares the author's name.
\date{December 1995}

\begin{document}           % End of preamble and beginning of text.

\maketitle                 % Produces the title.

%\abstract

\section{Introduction} 

Situation semantics is particularly well suited to providing a 
semantic account of 
computer system requirements because it supports, as an 
essential part of its underpinning theory, first, a multiplicity
of viewpoints, and second, partial characterizations of
complex aspects of the real world.
 
When forming a concept of a new proposed
software-intensive system, the system can be conceptualized
as an aggregation
of co-operating agents, some human, some machine.
Some of the machine agents may be known (existing components
for which there is already a specification, i.e. 
about which there is already a theory). When preparing a
requirement model, unknown machine agents
are identified, and each needs a theory constructing about
it which reflects accurately all the roles it plays in the system.
This is a design process. 
This paper describes an explicit semantic abstraction
to underly this design process, accommodating in particular
multiple perspectives and traceability in requirements.

Through its uniform treatment of machine and
human agents in supporting multiple perspectives, the model 
also supports explicit information about
human agents in the system, i.e. information (a theory)
from the system
point of view about the human agents, and also
information (a theory) from a human (well, a rather abstract human) 
point of view about the rest of the system.
This integrated 
presentation has  
two desirable charactersitics from a requirements engineering
point of view: encouraging full status of human factors,
on the same footing as other design constraints; and consequent integration 
of their consideration throughout the design process,
rather than as a separate
phase or distinct stakeholder-type interest (with potentially
lower status, implicit or explicit).

 Natural (or near-natural) 
language occurs extensively in requirement documents. When (part of)
the meaning of
a requirement expressed in natural language is
made precise as part of designing a formal specification,
then if the specification is soundly related to the requirement,
there should be an identifiable link between the meaning of the
(natural language) requirement, and the meaning of the formal
specification. Situation semantics provides an explicit theory
to account for these semantic links. 

At the other end of the system
development, the human and machine agents in a system often
communicate using something which looks rather like natural language,
but which is clearly not quite the same thing. Still, the main
reason for having it look like natural language would seem to
be that at least to the humans in the interaction, it is
understood in a similar way. That is, it should be useful to
treat it as having a similar semantics.

This provides the justification for applying situation semantics to
communications between machine and human agents, and to requirement statements
which involve such communications. It is interesting
that when you do that for the interaction between
a machine agent and a human agent in the system, both the machine
agent's theory about the human, and the human's theory about the
machine agent, appear as essential parts of the meaning of
the utterances involved in the interaction. This provides as a bonus
another angle on designing and evaluating an interface (not
a replacement for other approaches, but a possible useful tool
in the kit in an area where a variety of approaches is desirable). 
 
\section{Representing Requirement Information}

A well-established informal way of gathering and
analysing requirements in a methodical manner is to take information 
about the desired operation of the system from a number of (human)
agents; take into account the interfaces needed to existing 
subsystems (machine agents); and using this information
write a specification
for the new components (machine agents) required to realize the proposed
system.
 For a recent example of this approach, 
see \cite{GoFodHiRa95}.

In documenting a requirement, both as a notional whole
and during elicitation, several kinds of structure
are important. Some of it derives straightforwardly from
the content; other important aspects are the sources of the information,
eg different user groups,
and configuration management (version control and cross-referencing).
In addition, the purposes of a requirement representation
include supporting good design decisions in designing a system,
and for this,
all the relevant information needs to hang together in an 
understandable way, together with additional technical information
such as defaults and overall design constraints.

The abstract model outlined below is hopefully 
a first step to providing 
this in a usable form. The technical infrastructure used is {\em situations}
and {\em information flow} from situation theory
\cite{Devlin94,BARWISE89,BarGabHar95}, and theories as {\em databases} with 
well-defined update semantics from Labelled Deduction Systems (LDS)
\cite{GabbayLDS}. I would also like to acknowledge the G-MARC project
\cite{BolJonTilFurGre94}, as one of the inspirations for this approach,
along with Marvin Minsky's agent model of cognition \cite{MinskySM},
the visions of closely-coupled interaction in \cite{HarMin91} and
a story of which I can only remember the title ``Hot Shot'', 
and the memory system of Simonides of Ceos
\cite{ArtMem}. 

\section{Overview of the Semantic Theory}


It is assumed
that all requirement information is part of some agent's view of
the system; further, that the requirement information from
any agent can be regarded as clumps of information about 
(one or more) {\em situations} which are of significance to
and recognized by ({\em individuated} in situation theory terms)
that agent. These agents may be human or machine.
 
What an agent knows about a situation it individuates, can be
regarded as its theory about that situation. The whole of the
information from a particular agent is a collection of
these situations. This collection will have some
appropriate structure, for example to show dependencies,
time order, or how a complex situation is made up from several
simpler ones.

To formalize this, a situation is modelled as an Labelled Deduction 
(LDS) {\em database},
along the lines of the LDS presentation of situation logic given in
\cite{GabbayLDS}, pp 47-49.
Using LDS allows the representation and reasoning 
used to vary between situations, within a
uniform framework. It also allows precise characterization of how
a theory about a situation grows (eg during elicitation of
requirements, using the LDS concepts of {\em update semantics}
for a {\em database}. This allows the model to reflect 
how additional
information interacts with what is already there to yield a new
(updated) theory---clearly essential for modelling the growth
of a requirement model during elicitation, 
and also to reflect incremental changes to system concepts during and
after the `requirements phase' of system development. 
Another benefit of tthe LDS approach is that the 
labelling  enables the theories 
constructed from various points of view to keep track of
where the various pieces of information come from, and use 
local defaults and assumptions without propagating them throughout
the system model.

Although not the main reason for choosing LDS for this work, it
is interesting that the LDS concept of `a logic'
is intended amongst other things to model {\em practical} 
reasoning by an intelligent agent---a
logic embodied and active (cf \cite{GabbayLDS}, p17). 

Representing this to a developer is quite a challenge. With 
growing familiarity with hypermedia, a suitable representation
may well be ramified structured document, which can be accessed 
according to operational scenario(s) for the system, or using
the system structure as it develops.
This would entail integrating, in a hypermedia framework, text, 
illustrations which may be graphics or other media, and
design artefacts such as formal specifications and prototypes for
selected agents.

\bibliographystyle{alpha}
\bibliography{../sit,../req,../hci,../scrit,../kn,../logic,../me,../misc}

\end{document} 


\relax 
\@writefile{toc}{\string\contentsline\space {section}{\string\numberline\space {1}Introduction}{1}}
\citation{GoFodHiRa95}
\citation{Devlin94,BARWISE89,BarGabHar95}
\citation{GabbayLDS}
\citation{BolJonTilFurGre94}
\citation{MinskySM}
\citation{HarMin91}
\citation{ArtMem}
\citation{GabbayLDS}
\citation{GabbayLDS}
\@writefile{toc}{\string\contentsline\space {section}{\string\numberline\space {2}Representing Requirement Information}{2}}
\@writefile{toc}{\string\contentsline\space {section}{\string\numberline\space {3}Overview of the Semantic Theory}{2}}
\bibstyle{alpha}
\bibdata{../sit,../req,../hci,../scrit,../kn,../logic,../me,../misc}
\bibcite{BARWISE89}{Bar89}
\bibcite{BarGabHar95}{BGH95}
\bibcite{BolJonTilFurGre94}{BJT{$^{+}$}94}
\bibcite{Devlin94}{Dev94}
\bibcite{GabbayLDS}{Gab94}
\bibcite{GoFodHiRa95}{GFHR95}
\bibcite{HarMin91}{HM91}
\bibcite{MinskySM}{Min87}
\bibcite{ArtMem}{Yat75}


\newcommand{\etalchar}[1]{$^{#1}$}
\begin{thebibliography}{GFHR95}

\bibitem[Bar89]{BARWISE89}
J~Barwise.
\newblock {\em The Situation in Logic}.
\newblock CSLI Lecture Notes no. 17, 1989.

\bibitem[BGH95]{BarGabHar95}
Jon Barwise, Dov Gabbay, and Chrysafis Hartonas.
\newblock On the logic of information flow.
\newblock {\em Bulletin of the IGPL}, 3(1), 1995.

\bibitem[BJT{\etalchar{+}}94]{BolJonTilFurGre94}
D~Bolton, S~Jones, D~Till, D~Furber, and S~Green.
\newblock {\em Using domain knowledge in requirements capture and formal
  specification construction}, pages 141--162.
\newblock Academic Press, 1994.

\bibitem[Dev94]{Devlin94}
K~Devlin.
\newblock Situation theory and the design of interactive information systems.
\newblock In D~Rosenberg and C~Hutchison, editors, {\em Design Issues in CSCW}.
  Springer-Verlag, 1994.

\bibitem[Gab94]{GabbayLDS}
Dov~M Gabbay.
\newblock Labelled deductive systems, volume 1 --- foundations.
\newblock Technical Report MPI-I-94-223, Max-Planck-Institut f{\"u}r
  Informatik, Saarbr{\"u}cken, Germany, 1994.
\newblock Draft, work in preparation for publication via OUP.

\bibitem[GFHR95]{GoFodHiRa95}
P~A Gough, F~T Fodemski, S~A Higgins, and S~J Ray.
\newblock Scenarios---an industrial case study and hypermedia enhancements.
\newblock In {\em RE95}. IEEE Computer Society Press, 1995.

\bibitem[HM91]{HarMin91}
Harry Harrison and Marvin Minsky.
\newblock {\em The Turing Option}.
\newblock 1991.

\bibitem[Min87]{MinskySM}
Marvin Minsky.
\newblock {\em The Society of Mind}.
\newblock Macmillan, 1987.

\bibitem[Yat75]{ArtMem}
Frances Yates.
\newblock {\em The Art of Memory}.
\newblock Penguin, 1975.

\end{thebibliography}

