5 Chairholder's Relevant Research Progress to Date
My research activities throughout my career have been concerned with the human-technology interface and the development of methodologies and tools for modeling it through the elicitation of conceptual and organizational models. For my doctoral research I developed an operational cognitive modeling system based on the axiomatic structure of Kelly's personal construct psychology and implemented this in interactive computer programs that elicited and analyzed the conceptual structures of individuals and organizational groups [68-71, 91]. The evaluation of this system involved me in field studies with Imperial Chemical Industries (ICI) and with the manufacturers supplying Marks and Spencer in order to study problems of personnel selection and manufacturing quality control [71]. Over the years I have collaborated with many research groups internationally to port the tools I developed to operate on successive generations of computers, and to support their application in a wide range of applications from manufacturing and management to education and clinical psychology [72, 73, 75-85, 87].
In the 1980s we proposed that these tools be used for knowledge engineering in the development of knowledge-based or "expert" systems [35], and demonstrated their use in knowledge elicitation for the development of accounting systems [76]. This proposal and demonstration aroused major industrial interest and resulted in a fruitful period of collaboration with Boeing Computer Services [5], Neuron Data [33, 34], and other industrial research groups [29, 90] in the late 1980s that generated a new family of knowledge modeling tools based on my original design [6-10, 37, 38, 84-86].
Because of the demands of practical knowledge engineering we extended the methodologies and tools to support knowledge management at every stage of the modeling process: from hypermedia systems to handle a large and heterogeneous collection of knowledge sources in a range of media; through knowledge structuring using repertory grid and concept mapping techniques deriving from personal construct psychology; to knowledge formalization using semantic networks and terminological logics resulting in computational knowledge structures [37, 90]. Even though these methodologies and tools were originally targeted on knowledge-based system development, it was clear to me from my previous studies with industry that they could be used for organizational studies and knowledge management even when the target was not to build an artificial intelligence system [41, 92, 97].
Meanwhile, in my teaching at the University of Calgary I was not only involved in cognitive science, human-computer interaction and artificial intelligence, but also became responsible for the required course on software engineering. Since the syllabus already encompassed the technicalities of algorithms, programming, and so on, the focus of this course is on the management of software manufacturing processes, the specification of requirements, the definition of a system satisfying these specifications, and the evaluation of the system against the requirements. It became clear to me that much of the research on knowledge engineering was directly applicable to problems of requirements elicitation and tracking [87], and to the modeling of software manufacturing processes, and I encouraged one of my masters students to investigate the use of knowledge modeling in software maintenance [49]. In my senior undergraduate course on advanced information systems I introduced students to the conceptual modeling tools and provided them for use in their own project specifications [74, 88]. Similarly, in my graduate teaching I tutored students in the use of the tools to frame their research requirements and to model the differential understanding of their research topics with students and faculty in their research groups [82]. I also undertook longitudinal studies of the knowledge processes involved in other technical research groups in the university [92].
Much of my research was undertaken within the Knowledge Science Institute (KSI) which was established at the University of Calgary in 1985 with a mandate to study the knowledge economy and knowledge processes in science and engineering. My colleague in the KSI, Dr Brian Gaines, has close links with the Division of Manufacturing Engineering (DME) at the University of Calgary, and he collaborated with Dr Douglas Norrie of the DME in the application of the knowledge management methodologies and tools to the management of the research of an international project on Intelligent Manufacturing Systems (IMS) that involves 31 organizations in 14 different countries [30]. They have also applied the methodologies and tools to the management of the manufacturing life cycle [31], and we jointly have applied them to the management of knowledge flows in education [32, 89]. The outcome of these various studies indicate that knowledge-level workflow tools, as we now call them, are applicable to any goal-directed human activity involving the coordination of the knowledge processes of a goal-directed team. One of the partners in the IMS consortium was IBM France who modeled software engineering as a manufacturing process and whose studies encouraged my own development of a similar conceptual framework for the software manufacturing life cycle.
My original research studies included group knowledge elicitation and modeling tools [71], and we have previously developed groupware versions of the knowledge modeling tools and applied them to the coordination of various knowledge engineering and manufacturing processes [80, 81, 84]. The international structure of the IMS project made it important that these tools be made available over the Internet, and much of our research in the past two years has been concerned with re-engineering them to operate in client-server mode over the World Wide Web [39, 40, 88]. There are security problems in operating through the web, and recently one of my graduate students has developed an administrative system for the Faculty of Kinesiology as part of his masters research that explicitly addresses the security issues [58]. Web servers and browsers now offer a highly cost-effective client-server technology which addresses security issues, and I propose to develop the knowledge-level workflow tools around this, reusing the existing methodologies and tools already developed and collaborating with colleagues in KSI to extend them. The main focus of research in the Software Engineering Research Network will be on the effective application of these tools to software manufacturing processes rather than on the development of the tools in their own right.
6 State of the Art in Software Engineering
Enterprises world-wide have to operate in an environment of increasingly rapid change and increasingly strong competition. This is leading to major and continuing restructuring as the enterprises that survive adapt to change. Principled restructuring is based on defining the basic goals of the enterprise, identifying the processes currently supporting those goals, reengineering the processes to serve the goals more effectively, and maintaining the quality of those processes by a program of continuous process improvement. In the literature this approach may be seen as a combination of business process reengineering [47] and total quality management [20, 44].
Basili and Caldiera [1] warn that the approaches for improving quality in conventional manufacturing do not work especially well for software manufacturing, and different models are required. The Department of Defense Software Engineering Institute (SEI) at Carnegie-Mellon University has been the major innovator in defining the processes involved in software manufacturing and in developing quality models for their management and improvement. Humphrey [51] discusses the problems in the software industry, and the myths that are widely believed. One myth is the widespread belief that some technologically advanced tool or method will provide a magic answer to the software crisis. This is not only wrong, but it is dangerous in Humphrey's opinion. Technology is vital for long-term improvement, but unthinking reliance on an undefined "silver bullet" will divert attention from the need for better process management. When asked to name their key problems, few software professionals even mention technology. Their major concerns are: open-ended requirements, uncontrolled change, arbitrary schedules, insufficient test time, inadequate training, and unmanaged system standards.
The effective use of software technology is limited by several factors: an ill-defined process, inconsistent implementation, and poor process management. These problems must be addressed first [51].The SEI has developed a five-level software process maturity framework (Figure 1) which is based on the software experience of the SEI staff and industry, and has been found reasonably to represent the status and key problem areas of many software organizations.
Figure 1: Five levels of SEI software process maturity framework
(1) Initial
Characteristics: Chaotic--unpredictable cost, schedule, and quality performance.
Needed Actions: Planning (size and cost estimates and schedules), performance tracking, change control, commitment management, Quality Assurance.
(2) Repeatable
Characteristics: Intuitive--cost and quality highly variable, reasonable control of schedules, informal and ad hoc process methods and procedures.
Needed Actions: Develop process standards and definitions, assign process resources, establish methods (requirements, design, inspection, and test).
(3) Defined
Characteristics: Qualitative--reliable costs and schedules, improving but unpredictable quality performance.
Needed Actions: Establish process measurements and quantitative quality goals, plans, measurements, and tracking.
(4) Managed
Characteristics: Quantitative--reasonable statistical control over product quality.
Needed Actions: Quantitative productivity plans and tracking, instrumented process environment, economically justified technology investments.
(5) Optimizing
Characteristics: Quantitative basis for continued capital investment in process automation and improvement.
Needed Actions: Continued emphasis on process measurement and process methods for error prevention.
In 1989 and 1990, the Software Engineering Institute (SEI) carried out assessments of software processes, involving 167 projects in the USA and 196 projects in Japan. The results of these assessments show that: 86% of the US organizations (98% in Japan) are at level 1 (initial) ; 13% (1% in Japan) are at level 2 (repeatable); 1% (0.5% in Japan) are at level 3 (defined); 0% (0% in Japan) are at level 4 (managed); 0% (0.5% in Japan) are at level 5 (optimizing). These assessments clearly point out the problematic state of most software development processes.
In 1987 and 1990, the SEI conducted process assessments at the Software Engineering Division of Hughes Aircraft, which led to a concrete action plan (e.g. formation of a software engineering process group, implementation of quantitative process management, enhancing the training program, and standardizing an effective review process). Carrying out this action plan resulted in: the division's progress from level 2 (repeatable) to level 3 (defined); an estimated annual saving of about $2 million; successful control of the effects of changing software requirements; improvement in the quality of work life. Another example of the SEI approach to process improvement is that of Raytheon, which started its software engineering initiative in 1988. Over a period of 3-4 years: the average annual savings in cost of quality was $5.8 million, productivity gain was 29%, investment in process improvement was $1 million.
6.2 Knowledge-Level Workflow Tools
Process restructuring generally involves major changes in work practice. Existing processes have been largely determined by the technologies available to support them. Much of the business process reengineering literature is concerned with more effective processes that are predicated on new computer and communications facilities, and involve major changes in work practice to make effective use of them [18, 59]. Conversely, from a technological perspective, it is ineffective to introduce new technologies in the workplace unless work practice is reengineered at the same time. The workplace of the future is not that of today with the addition of advanced computer and communication technologies. It requires a fundamental reassessment of all aspects of the enterprises involved. However, principled restructuring of enterprises effectively requires empirical data derived from applications experience. It requires modeling tools to support the planning process. It requires workflow tools that package the functionality of the new technologies into humanly usable systems, and integrate that functionality with existing information systems. The models and the systems must be based on deep models of organizational cultures, discourse and coordination practice, and must be themselves supported through documentation and training that facilitates their deployment [28, 63].
In terms of computer technology, research on shared ontologies and knowledge interchange formats is fundamental to modeling and supporting organizational knowledge flows [62]. Knowledge sharing formats [25] such as KIF [43] and Ontolingua [46], and agent protocols such as KQML [26], are already in use in DARPA-funded concurrent engineering projects such as SHADE/PACT [19]. The use of computer-based concept maps to manage knowledge processes has been studied in the context of hypertext systems and resulted in implementations and studies [12, 93].
Mediator [31] is a layered system that utilizes these technologies to provide knowledge-level workflow tools to model and manage the manufacturing life cycle. It is an open architecture information and knowledge management system in which the sub-systems are geographically dispersed and involve different application packages, not necessarily designed to work together, multiple platforms, protocols and forms of user interface. The function of Mediator is to provide a knowledge support system for all those involved in the manufacturing process from requirements through design, engineering, production, to maintenance and recycling. It is designed to facilitate communication, compliance with constraints including physical restrictions and legal obligations, and to generally represent knowledge about any activity or sub-system relevant to the manufacturing process. The primary user interface to Mediator is through visual languages allowing the general representation of semantic systems through graphical symbols. The application layer uses particular instances of these visual languages with application-specific semantics and a visual appearance designed to be natural to use in the context of the specific application. The process layer supports agents as light-weight processes triggered by user interaction with the visual languages, and also triggered by other agents [19]. The communication layer supports object-oriented protocols for knowledge and data interchange such as STEP, Ontolingua and KQML [4]. A version of Mediator supporting synchronous collaboration is currently being developed in GroupKit [64], an open-architecture software system for the rapid development of groupware applications.
There are many problems associated with requirements engineering, including problems in defining the system scope, problems in fostering understanding among the different communities affected by the development of a given system, and problems in dealing with the volatile nature of requirements. These problems may lead to poor requirements and the cancellation of system development, or else the development of a system that is later judged unsatisfactory, has high maintenance costs, or undergoes frequent changes. By improving requirements elicitation, the requirements engineering process can be improved, resulting in enhanced system requirements and potentially a much better system.
Dobson and his colleagues [4, 22] argue that evolving requirements are now the norm, rather than the fixed requirements associated with the waterfall life cycle model used in the past. This approach recognizes problem uncertainty and proceeds by validating problem representations against stakeholders' perceptions rather than the older outdated method of verifying proposed solutions against a static problem statement. In May 1995, the Communications of the ACM published a special issue on requirements engineering. In the introductory article, Holtzblatt and Beyer [50] identify how to devise a successful requirements definition process, and conclude that requirements is about people talking effectively to each other.
Requirements engineering can be decomposed into the activities of requirements elicitation, specification, and validation. Most of the requirements techniques and tools today focus on specification, i.e., the representation of the requirements. Christel and Kang [14] address elicitation concerns, those problems with requirements engineering that are not adequately addressed by specification techniques. An elicitation methodology is proposed to handle these concerns. This new elicitation methodology strives to incorporate the advantages of existing elicitation techniques while comprehensively addressing the activities performed during requirements elicitation. These activities include fact-finding, requirements gathering, evaluation and rationalization, prioritization, and integration. Taken by themselves, existing elicitation techniques are lacking in one or more of these areas.
Requirements engineering is a key problem area in the development of complex, software-intensive systems:
"The hardest single part of building a software system is deciding what to build. ...No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later." [11]
Issues involved in this problem area include: achieving requirements completeness without unnecessarily constraining system design; analysis and validation difficulty; changing requirements over time [14]. A requirement is defined by IEEE:
"(1) a condition or capability needed by a user to solve a problem or achieve an objective; (2) a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents; (3) a documented representation of a condition or capability as in (1) or (2)." [52]
The IEEE Standard Glossary of Software Engineering Terminology defines five other types of requirements in addition to functional requirements: performance requirements, interface requirements, design requirements, implementation requirements, and physical requirements [52]. Loucopoulos and Champion define requirements engineering as
"the systematic process of developing requirements through an iterative process of analyzing a problem, documenting the resulting observations, and checking the accuracy of the understanding gained" [55]
which is supported by Costello and Liu:
"Requirements engineering is the process of conceptualizing, specifying, and validating the specification of the required behavior of the system." [17]
Rzepka [65] decomposes the requirements engineering process into three activities:
1. elicit requirements from various individual sources;
2. insure that the needs of all users are consistent and feasible; and
3. validate that the requirements so derived are an accurate reflection of user needs.
This model implies a sequential ordering to the activities, with elicitation done once at the very beginning of the process though, actually, the process is iterative. Many of the current techniques used in knowledge engineering were designed to carry out exactly these types of processes.
6.4 Knowledge Engineering and Requirements Engineering
Early research on knowledge acquisition for knowledge-based systems emphasized the acquisition of the knowledge assumed to underlie human expertise in areas such as medical diagnosis, where conventional system analysis and software engineering had failed to provide computer emulation of the expertise. This led to the "expertise transfer" paradigm in which the primary function of knowledge engineering was seen to be the transfer of a human expert's knowledge to a computer system:
"Knowledge acquisition is a bottleneck in the construction of expert systems. The knowledge engineer's job is to act as a go-between to help an expert build a system. Since the knowledge engineer has far less knowledge of the domain than the expert, however, communication problems impede the process of transferring expertise into a program. The vocabulary initially used by the expert to talk about the domain with a novice is often inadequate for problem-solving; thus the knowledge engineer and expert must work together to extend and refine it. One of the most difficult aspects of the knowledge engineer's task is helping the expert to structure the domain knowledge, to identify and formalize the domain concepts." [48]
This discussion is still valuable today in characterizing the problems of eliciting knowledge from human experts. However, as numbers of knowledge-based systems were developed of increasing scope it became apparent that human experts were only one source from which knowledge was being acquired. Knowledge engineers are pragmatic in developing systems based on every available source of relevant information. It also became apparent that the status of the "knowledge" assumed to underlie human expertise was itself problematic:
"Knowledge can be represented, but it cannot be exhaustively inventoried by statements of belief or scripts for behaving. Knowledge is a capacity to behave adaptively within an environment; it cannot be reduced to representations of behavior or the environment." [16]
That is, the overt knowledge that we see in text, diagrams and computer data structures, and the invisible "knowledge" that we impute to human experts to account for their skilled behaviors are two distinct entities. It is simplistic and misleading to assume that the process that leads to the emulation of human expertise in a computer program is one of transferring knowledge--"expertise transfer" is an attractive metaphor but it leaves open the questions of what is expertise and how it may be transferred. A better metaphor might be one of modeling, that the emulation involves building a model of the expertise, where a "model" is according to Webster's dictionary:
"a representation, generally in miniature, to show the construction or serve as a copy of something."
There are clearly parallels between this account of knowledge engineering and similar phenomena in requirements engineering [45]. The software engineer would like to have those who are expert about the system requirements express them clearly, concisely and completely in terms permitting implementation--that is to make their "knowledge" of the requirements overt so that the requirements may be made operational. However, the supposed knowledge may be vague, incomplete and incorrect in its initial form, and the actual knowledge that informs the system design may only arise through a process of "elicitation" which is in fact better seen as one of modeling since what is elicited did not pre-exist but has come into being through the elicitation process.
This emergent nature of requirements has led to the criticism of the "expertise transfer" notion in knowledge engineering being paralleled by similar criticism of the "requirements capture" notion in requirements engineering:
"There is much talk of requirements capture, as if requirements were butterflies to be caught and pinned down in a specification cabinet. In reality, of course, this is not so; requirements are often much better thought of as being elicited through such techniques as ethnomethodological study, structured interviews, dramaturgical exercises, and so on. The shift of emphasis from the requirements process as being formalising the explicit to making explicit what is merely implicit is clearly correct, but does not go far enough in many cases of organisational requirement, where the problem is one of envisioning the future rather than understanding the present." [23]
This quotation characterizes one significant aspect of both knowledge and requirements engineering--the way in which models emerge out of a process of anticipation. Another significant common aspect is the need for the `junk' which may also emerge to be removed--that the models should be minimal in expressing only requirements, not the scaffolding of past experience on which they may be based. McDermid has characterized a good requirements specification as one which:
"says everything which the designer needs to know in order to produce a system which satisfies the customer/users--and nothing more" [57]
6.5 Modeling Methodologies--KADS, PCP and Soft Systems Methodologies
There have been two major modeling methodologies developed in knowledge engineering: the KADS methodology [66] focusing on the derivation of the formal representation; and the second, the PCP methodology [38], focusing on the derivation of the mediating representation. There are also basic modeling techniques in software engineering such as Checkland's [13] soft system methodology.
6.5.1 KADS: a Structured Approach to System Development
The KADS methodology is the outcome of a number of ESPRIT project activities centred at the University of Amsterdam but involving researchers and practitioners from many institutions, countries and disciplines. KADS is intrinsically a modeling approach with seven types of model distinguished [66]:
An organizational model provides an analysis of the socio-organizational environment in which the knowledge-based system will have to function. It includes a description of the functions, tasks and bottlenecks in the organization. In addition it describes how the introduction of a knowledge-based system will influence the organization and the people working in it.
An application model defines what problem the system should solve in the organization and what the function of the system will be in this organization. In addition to the function of the knowledge-based system and the problem that it is supposed to solve, the application model specifies the external constraints that are relevant for the development of the application.
A task model specifies how the function of the system, as specified in the application model, is achieved by defining tasks that the system will perform. Establishing this relation between function and task is not always as straightforward as it may seem. Given a goal that a system should achieve, there may be several alternative ways in which that goal can be achieved. Which alternative is appropriate in a given application depends on the characteristics of that application, on the availability of knowledge and data, and on the requirements imposed by the user or by external factors.
The model of cooperation contains a specification of the functionality of those sub-tasks in the task model that require a cooperative effort between the agents to whom the sub-tasks have been distributed. Some of the sub-tasks will be achieved by the system, others may be realized by the user. The result is a model of cooperative problem solving in which the user and the system together achieve a goal in a way that satisfies the various constraints posed by the task environment, the user and the state of the art of knowledge-based system technology.
Building a model of expertise is a central activity in the process of knowledge-based system construction. It distinguishes knowledge-based system development from conventional system development. Its goal is to specify the problem solving expertise required to perform the problem-solving tasks assigned to the system. The KADS methodology focuses on expertise as the behavior that the system should display, and on the types of knowledge that are involved in generating such behavior, abstracting from the details of how the reasoning is actually realized in the implementation.
Together, the model of expertise and the model of cooperation provide a specification of the behavior of the artifact to be built. The model that results from merging these two models is similar to what is called a conceptual model in database development. Conceptual models are abstract descriptions of the objects and operations that a system should know about, formulated in such a way that they capture the intuitions that humans have of this behavior. The language in which conceptual models are expressed is not the formal language of computational constructs and techniques, but is the language that relates real world phenomena to the cognitive framework of the observer. In this sense conceptual models are subjective.
The description of the computational and representational techniques that the artifact should use to realize the specified behavior is not part of the conceptual model. These techniques are specified as separate design decisions in a design model. In building a design model, the knowledge engineer takes external requirements such as speed, hardware and software into account. Although there are dependencies between conceptual model specifications on the one hand and design decisions on the other hand, building a conceptual model without having to worry about system requirements makes life easier for the knowledge engineer.
6.5.2 PCP: Personal Construct Psychology in Conceptual Modeling
Several methodologies and tools that have been highly influential in knowledge acquisition research have been based on personal construct psychology (PCP), Kelly's formal, constructivist model of the epistemological processes whereby people acquire expertise [54]. In 1980, Shaw and Gaines suggested that the tools developed by Kelly for eliciting personal models, would provide a useful development technique for expert systems [35], and performed a validation study of the elicitation of the BIAIT methodology from accountants and accounting students using computer-based repertory grid elicitation [76]. Boose in an independent parallel study reported success in a wide range of industrial expert system developments using computer elicitation of repertory grids [5], and since then many knowledge acquisition systems have incorporated repertory grids as a major elicitation technique [8, 21, 27, 42, 78].
The repertory grid is, however, only one technique for knowledge acquisition that may be derived from personal construct psychology. The formal model proposed by Kelly is highly general because of its system-theoretic derivation from the single primitive process of making dichotomous distinctions. Consideration of the recursive processes of making distinctions between distinctions leads to hierarchies of distinctions having both the generality and the complexity to encompass any model from the informality of human cognitive processes to the formality of mathematical, axiomatic systems [36]. Kelly presented his work as the foundations of a psychological system and emphasized the intensional basis of distinctions as personal constructs that could differ widely between individuals leading to very different personal models of the world. However, the same system is applicable to shared social constructs and impersonal formal constructs based on intensional definitions of distinctions in communal terms, or extensional definitions in concrete terms. Thus, the notion underlying personal construct psychology provide a universal foundation for modeling methodologies.
Personal construct psychology may be analyzed in a way that leads naturally to the formal derivation of KL-ONE-like knowledge representation schema [85]. Many tools have been based on personal construct psychology, including later developments of the repertory grid and visual languages for semantic networks [10, 38].
6.5.3 Checkland's Soft Systems Methodology
Checkland [13] developed soft systems methodology in response to the failures of more conventional approaches to tackle problems that are hard to define, known as `soft' problems. Such `soft problems' are encountered frequently in organizations and cannot be solved by the same techniques that are used to solve `hard' problems. There is a fundamental difference between hard systems and soft systems thinking. Hard system methodologies assume that the `problem'(as they have defined it) has a definite solution and has a number of goals that can be satisfied. Therefore hard systems are concerned with answering how questions. (That is how to solve the problem.)
Soft systems methodology deems the term `the problem' as inappropriate, as it is such a narrow view of the situation. Soft systems recognize that there is not a single problem, but many problems to be solved, so the term `problem situation' is used instead. Emphasis is placed on the what as well as the how. (For example, what is the problem?) Thus the goals of soft systems are much more complex than goals of hard systems which can be achieved and measured. The processes involved in the soft systems methodology are as follows. The analyst (referred to as the problem solver), with extensive help from the managers and users within the organization (referred to as problem owners), creates a rich picture of the problem situation. The rich picture is a subjective perception of the problem in a pictorial form. The rich picture will include the organization's system under review, the people within it and the tasks performed. The rich picture is used as a discussion aid with the problem owner. Problem themes are extracted from the rich picture by the problem solver. He will add conflicts between personnel or functions within the organization, communication problems and supply problems. The rich picture is used to identify problems and inform the problem owner of the situation, rather than develop possible solutions. The use of the rich picture is much better than traditional methods for stimulating managers and users--to reveal the "real" problems within the organization. Once a complete rich picture has been developed, the problem solver uses it to create a root definition. Checkland defines the root definition as:
"... a concise, tightly constructed description of a human activity system which states what the system is. "
Soft systems methodology is a framework for system analysis that provides very powerful techniques for the analysis of systems with human and social components, and has been widely applied to difficult problem areas [96]. There are seven stages of system analysis in soft systems methodology. The initial stages are concerned with system analysis and the later stages with system design.
Checkland's methodology prescribes six essential components of a system that must be identified at the conceptual modeling stage. A system is defined through a transformation carried out by people who are the actors within it. The system affects beneficially or adversely other people who are its customers and there is some agency with power of existence over it who is its owner. The system has to exist within a outside constraints forming its environment and the whole activity of system definition takes place within an ethos or weltanschauung that affects our views of it. The methodology is essentially pluralistic in emphasizing that there will generally be multiple choices for most or all of these components, and the particular choices made will result in different system models.
There are natural links between personal construct psychology and soft systems analysis, and repertory grid techniques have been applied to the computerization of the conceptual modeling processes involved. Shaw and Gaines have used grids to develop a soft systems requirements analysis for a citizen ID system [77]. For example, one set of grids elicited in this study was from citizens on "who to inform when I change address".
ORDIT is a requirements engineering methodology that uses soft system analysis to implement Mumford's [60] socio-technical approach in which the system is viewed as a whole by placing it within the broad operational environment, with the user and computer as integral parts of the system [23]. The aim of the ORDIT project is to develop a methodology that will enable designers to reason about organizational goals, policies and structures, and the work roles of intended end users, and hence identify and support the requirements for the system.
The problem of determining system boundaries in complex systems has shown up mistakes made in the original boundaries, and the ORDIT techniques have provided a rich environment for the representation of the organizational structure and the relationships between the roles of agents, information flows, and resource management [3]. The ORDIT approach uses enterprise modeling to provide a framework for reasoning about the system as a component of a wider environment where the organization has needs which are served by the model. Responsibilities and relationships are modeled rather than activities, and information is modeled from the point of view of the contracts involved. The process includes the identification of the requirements owners together with their positions and roles in the organization, and the identification of the user community, and others affected by the system together with their roles and responsibilities in the organization [22, 95].
6.6 Trends in Requirements Engineering
The NATURE project is a large ESPRIT initiative based in Aachen, Germany, investigating novel approaches to requirements engineering. They argue that such approaches are necessary because the environment in which requirements engineering has to operate has changed dramatically since the current methods were invented. The task of requirements engineering has moved from supporting the early phases of individual projects, to accompanying the whole life cycle of complex, long-lived human-machine systems in a rapidly changing organizational environment. The NATURE framework addresses these new demands by defining a novel framework based on the idea that requirements engineering is a continuous process of establishing visions of different stakeholders in a complex context. Around this framework, NATURE has developed three specific theories. The requirements domain theory gives advice on what context knowledge is relevant and how to organize it. The requirements process theory offers a unified process metamodel in which a small set of building blocks covers a larger spectrum of process guidance strategies with more flexibility than other software process or workflow models. The knowledge representation theory aims at defining what domain and process knowledge to capture, and how to manage this knowledge using an effective mix of informal, semi-formal and formal representations [53].
One of the long-standing problems addressed by the NATURE project is that of non-functional requirements--how the goals of reliability, performance, accuracy, or security can be incorporated into the requirements and design process [53]. This issue is also addressed by Mylopoulos and colleagues [61] who present a process-oriented framework for non-functional requirements in terms of interrelated AND/OR goals. Jarke and Pohl [53] suggest the use of ethnographic techniques recommended by Sommerville [94].
Sommerville and Rodden [94] recommend the integration of computer supported co-operative work (CSCW) with professional software where there are multiple end-users cooperating explicitly or implicitly. Ethnography is one way of revealing actual rather than formal organizational structures, which are the ones which must actually be supported, and he has devised methods for incorporating ethnographic techniques and existing methods of requirements analysis. Blyth and Chudge [3] also recommend the use of CSCW to support conversations which mediate cooperative work and support the mutual creation of, commitment to, and discharge of obligations as discussed in the ORDIT project.
In 1991, the Software Engineering Institute held a workshop to investigate process-related problems in requirements engineering [67]. The overall recommendations and conclusions included:
