Using Design Explanation within Formal Object Oriented ... - CiteSeerX

Using Design Explanation within Formal Object Oriented Method Lemai Nguyen Paul A. Swatman School of Management Information Systems Deakin University Victoria, Australia Graeme Shanks Department of Information Systems The University of Melbourne Victoria, Australia April 7, 1999 Abstract This paper reports the results of an action research project which studied the benefits of documenting the evolution, and the rationale for the evolution, of a requirements specification. The benefits which design explanation offers designers (as documented in the literature) suggested an investigation with a view to understanding the potential contribution of the IBIS (Issue Based Information System) approach. The paper reports an investigation into the use of ad hoc design explanation, in which design decisions were documented as they were made using the IBIS notation. This study finds both strengths and weaknesses in the approach. It reveals ways in which IBIS might be used more effectively and leads us to suggest a further study into the complementary use of ad hoc and post hoc design explanation approaches.

1

Introduction

This paper reports findings of an action research study into the use of design explanation1 within the requirements engineering process. Requirements engineering is a creative design process, and can be best described as opportunistic (Guindon, 1990). Consequently, if it is not well monitored, managed and controlled the requirements engineering process might be rather chaotic. In terms of project and process management, there are some clear concerns: • most requirements engineering methods involve different views of requirements, expressed in different representation forms and evolving in parallel over a long period of time. For example, in Booch’s Object-Oriented approach (Booch, 1994), requirements can be expressed as static structure models and/or interaction models. These models reflect different views of (perspectives) but they all concern the 1 Generally, design rationale is information which explains and justifies the reasoning behind a specification. In our approach, however design rationale is used with emphasis on explanation.

1

same underlying system. Consequently, these requirements models may evolve in parallel while still maintaining some semantic correspondence with each other. This is a rather complex process and the understandability of a requirements specification tends to be problematic. Analogous work in domains as diverse as legal decision making (Toulmin, 1958), general design (Fischer et al., 1991), collaborative work (Kaplan et al., 1992) and software design (MacLean et al., 1991; Lee, 1990) suggests that knowledge of how a requirements specification, including all different models, has evolved would be very valuable for the improvement of the specification process and the models developed during this process. • requirements are characteristically volatile (Christel and Kang, 1992). Curtis et al. (1988) found that the requirements volatility causes major difficulties during the software development process. As changes to requirements are unpredictable, the requirements traceability and the rationale underlying the requirements evolution become very significant information. • requirements engineering is claimed to be a communicative and social activity to support the resolution and integration of different viewpoints of different groups of clients, managers, requirements engineers, developers/implementors and end-users. This social aspect is also referred to as a co-operative process by, for example, Pohl (1993) and Loucopoulos and Karakostas (1995). We focus on the need to have a mechanism for supporting this activity of knowledge sharing and communication between clients and specifiers and within a team of specifiers. These concerns led us to seek an approach which would provide us with not only a description of requirements models (at any stage of the development process), but also with information of how requirements models develop as they do and why they have a specific form at any stage. Having argued that the requirements engineering process cannot be deterministic, we have taken a descriptive approach to documenting requirements evolution and its rationale. Benefits of using design explanation are well documented in the literature. They include: • improvement of decision making. Design rationale may raise crucial issues, rationalise discussions and avoid missing important considerations about requirements by each designer as well as by a group of designers (Fischer et al., 1991; Conklin and Yakemovic, 1991; Dix et al., 1993). • reuse of rationale arguments in similar situations and related projects, thus enabling participants to avoid making the same decisions over and over again as the specification evolves (Yakemovic and Conklin, 1990; Dix et al., 1993; Fischer et al., 1991). • explanation of a specification. It is important to understand a specification in terms of its relationship to possible alternatives and/or other similar projects (MacLean et al., 1991). • assistance in communication between various participants including stakeholders, users, specifiers and other developers (Dix et al., 1993; MacLean et al., 1991). In this paper, we study the potential benefits of IBIS (Issue-Based Information Systems) (Conklin and Yakemovic, 1991), an ad hoc design explanation notation, in documenting requirements decisions as they occur. The structure of the paper is as follows: • a description of the project, 2

• our observation and interpretation of what happened, • our reflection upon the benefits of IBIS and how to use it effectively, • conclusions and suggestions for future research.

2 2.1

Background information of the project Formal Object-Oriented Method (FOOM)

The requirements engineering process used in the research project was FOOM (Swatman, 1996). FOOM is based on a synthesis of socio-organisational theory (Checkland and Scholes, 1990), the object-oriented approach MOSES (Henderson-Sellers and Edwards, 1994) and the mathematical formal specification language Object-Z (Duke and Rose, 1995). An introduction to FOOM is included in Appendix A. For the purpose of this paper, however, it is sufficient to understand that the specification developed during the FOOM process is definitively represented using the formal language Object-Z and illustrated with text and structured diagrams based on MOSES. At an abstract level, FOOM, like most major requirements engineering methods is based on the principle of an evolving requirements model. We believe, therefore, that the choice of FOOM as the requirements engineering method to be used in this project is not a major factor in constraining us in generalising from the outcome of the research.

2.2

Issue-Based Information Systems (IBIS)

There are two main approaches to capturing design explanation, ad hoc and post-hoc. In the former, design decisions are structured around specific problems encountered and are recorded in the chronological order in which they are made. In contrast to this, the latter concentrates on the logical design space around an artefact, which can be restructured by the post hoc consideration of its alternatives. In other words, while the two approaches may share some similarity in their notations, their processes and foci are different. In the ad hoc approach, as time progresses and design decisions are made, each design discussion is non-intrusively recorded and coded using a notation, such as IBIS (Kunz and Rittel, 1970; Conklin and Yakemovic, 1991). Each ad hoc argumentation document explains a decision within the context of a specific problem at hand. However, in the post hoc approach, argumentation documents can be constructed only at intervals, typically between phases of the active designing process. Each post hoc argumentation document represents a retrospective and logical examination of the design space around the artefact (MacLean et al., 1991). In order to describe the evolution of requirements, we initially adopted a process-oriented ad hoc approach. A number of notations of this approach were considered for use in the study including IBIS (Issue-Based Information System) (Kunz and Rittel, 1970; Conklin and Yakemovic, 1991), REMAP (Ramesh and Dhar, 1992), Toulmin (Toulmin, 1958) and COED (Kaplan, 1990). Among these notations, IBIS was chosen for a number of reasons. First, the IBIS notation is simple and intuitive, thus, it could be used in a non-intrusive way. Second, it is widely used—IBIS was tested and used in a number of large-scale, real-world projects in design 3

and planning during the 1970-80s (eg. a German inter-departmental government committee for information networks, university planning, the United Nations, the Commission of European Communities, and the German Parliament) (Fischer et al., 1991; Kunz and Rittel, 1970). Last, empirical studies have found that IBIS is useful and beneficial. A report on a field study into using IBIS to capture design rationale information in a hardware and software systems development project over two years (Yakemovic and Conklin, 1990) found that IBIS assists group decision making and memory. Another study, including both construction and design rationale (using PHI, an IBIS descendant) components (Fischer et al., 1991), demonstrated that an integrated design and argumentation-based environment overcomes deficiencies of either domain-oriented or argumentation supporting tools used in isolation. IBIS is a method for planning and representing design meetings, developed first by Rittel in the 1970s. It takes the form of design questions or problems (Issue2 ), possible answers (Position) and arguments (Argument) for and against the positions (see Figure 1). The central activity is the generation and evaluation of positions using arguments. The decision to select a position or discard all but one position resolves an issue. An issue may question, generalise or specialise another issue, and that may lead to other sub-issues with positions and arguments. itIBIS, gIBIS (graphic IBIS), and PHI (procedural hierarchical IBIS), and REMAP (Ramesh and Dhar, 1992) are IBIS variations. Although IBIS is preferred for its intuitiveness, it is restricted by the local context and lack of explicit goals and outcomes of argumentation (Lee, 1990; Ramesh and Dhar, 1992). Our project is concerned with these restrictions. objects to Position

Argument

responds to Issue responds to

supports Argument

Position generates Sub-Issue

Figure 1: IBIS notation Among a number of different variations of the IBIS notation, itIBIS (intended text IBIS) (Yakemovic and Conklin, 1990), a textual form of IBIS, was chosen for our project for its simplicity and flexibility. In fact, itIBIS may be used irrespective of the technology available—not even a word-processor is required. A description of itIBIS is included in Appendix B.

2.3

The requirements engineering project

The project within which the FOOM process was used was the requirements engineering phase in the development of a customisable design support tool. The project was undertaken a university research and development environment in Australia. This in2 Issue/Position/Argument with capital letters refers to element of an IBIS Issue, argument/issues with lower case letter are used in general meaning.

4

vestigation took place over 6 months. A small team of three consisting of: a FOOM specifier/researcher, a FOOM developer and an expert in design explanation was involved. Automated tools are considered by many to be useful for supporting the creation and documentation of argumentation (e.g. Shanks et al. (1994)). A number of different tools have been designed. The common weakness of these tools is that they are each dedicated to a particular argumentation model and are, thus, inflexible. The Meta-Argumentation Workbench (MAW), developed by Shanks et al. (1994), was based on a meta model which was found to underlie a wide range of design explanation notations. The MAW may be customised to allow rationale to be collected and represented in a wide range of notations. In the project which forms the basis of study the MAW was remodelled in an ObjectOriented style and was enhanced in a variety of ways including: supporting the integration of design explanation and design objects; and recording the dynamics of the documentation process. This project was later extended to the development of a sophisticated FOOM CASE tool (Nguyen et al., 1998) which supports the integration of design explanation and the evolution of FOOM specifications.

2.4

Research approach

Figure 2: Action research cycle in the project The research approach chosen is action research (see Figure 2). According to Checkland (1991), action research can be described in terms of an intellectual framework (F) within which the learning is defined, a methodology under study (M) and a real-world application (A) where M is applied. From this view, our research process can be described as consisting of: • declaration of the framework, methodology and application (F, M and A), • application of the methodology and observation of its application • interpretation and analysis of observational data collected. The reflection is made upon F, M and A. Specifically, F is the framework of ideas within which systematic documentation and representation of arguments made during the requirements engineering process may explain the evolution of requirements specifications and improve the understandability and traceability of the requirements specifications. M is the application of the IBIS notation within 5

FOOM. Decisions about FOOM requirements would be recorded in chronological order as they are made. A is the specification of requirements for a FOOM CASE tool to control the evolution of the FOOM requirements, which is described in the previous subsection.

3

Observation and interpretation

The process of applying IBIS to document the FOOM process was observed and recorded in a research diary. Specifically, research data included questions and issues concerning the use of IBIS within FOOM, FOOM modelling decisions (structured in the IBIS notation) and intermediate states of the FOOM specification. More than 350 Issues and Sub-Issues were recorded in our research diary. Each Issue/Sub-Issue is associated with a number of Positions and Arguments. The data were qualitative and supported meaningful interpretation of the situation by the researcher/actor. The data collection required a frequent and flexible switch by the researcher between the roles of actor and interpreter. We interpret the specification process as follows. The FOOM process can be described as cyclic, each cycle consisting of the elicitation, modelling and evaluation (validation) activities (see Appendix A for more details). At the beginning of the project, we expected the complexity of the requirements specification would increase over time as illustrated in Figure 3. Circles depict cycles of the FOOM process: E depicts elicitation, M modelling and V evaluation. As the time goes by, models within the specification grow more complex and complete: more and more objects/classes are identified and their specifications are refined.

Figure 3: Qualitative interpretation of expected FOOM process We associated a set of IBIS arguments with the specification to explain decisions taken. Indeed, IBIS arguments were created and accumulated in parallel with the evolution of a FOOM specification expressed in different forms of object-oriented diagrams and a formal Object-Z document. To support documentation of the process, requirements models were versioned. Figure 4 illustrates the evolution of both FOOM models and IBIS documents. In terms of the three activities of elicitation, modelling and evaluation, the application of the IBIS notation is illustrated in Figure 5. Overall, the IBIS concepts were used to structure our discussions. During the modelling process, ad hoc arguments about requirements problems were structured using the IBIS notation every time a decision was made. Each IBIS argument represents a specific, local requirements problem/decision. Over a period 6

Figure 4: Documenting the FOOM requirements evolution and the rationale using IBIS arguments of time, the documentation of requirements problems as they occur resulted in a linear stream of IBIS arguments (see Figure 6). When it came to evaluating different modelling options, relevant information was extracted from the IBIS base. IBIS arguments were also used during the elicitation activity.

Figure 5: The application of IBIS within the FOOM process One unexpected result was that the evolution of complexity of the FOOM specification was not in accordance with our expectation (see Figure 3) but rather exhibited occasional but major restructuring (see Figure 7). This result does not appear to be caused by the use of IBIS, but rather to be thrown into sharp relief by our research focus. There were a number of crisis points during the process. These crisis points occurred when requirements addition/modification suggested that the model should not evolve further without being restructured. This could be explained by the inevitable increasing entropy during the modelling process. At these points FOOM models were restructured on the basis of • the simplification of the models, 7

Figure 6: A linear stream of IBIS arguments is formed

Figure 7: The evolution of the complexity of FOOM models • other elicited information, or most often • the set of IBIS documents currently held. Reflection on this application of IBIS found both strengths and weaknesses. Overall, the IBIS arguments supported decision making during the modelling process. Especially at crisis points, the IBIS base provided a structured and useful source of information for the evaluation and simplification of FOOM models. However, as the process progressed, it became clear that the benefits of using IBIS came at an increasing cost. A detailed discussion and analysis is contained in the following section.

4

Reflection

4.1 4.1.1

Is IBIS useful? A summary of findings

The evidence described in more detail in the next subsection shows that • the IBIS notation provides a useful and effective mechanism to describe the FOOM process, including discussions about requirements and modelling activities, 8

• the IBIS notation also supports communication between participants3 , • the IBIS arguments provide a useful source for the extracting of relevant rationale information when needed. but that, the approach exhibits some limitations: • the locality of IBIS arguments and • the lack of context where an Issue is discussed. Due to these limitations, extracting the IBIS information which documents each specific construct or decision becomes problematic. These limitations suggest the complementary use of a post hoc design explanation approach. 4.1.2

An analysis of findings

During the process of acquiring and analysing requirements for the CASE tool (see Section 2.3) we recorded all conversations between specifier and clients and structured the conversations in the itIBIS form. Indeed, requirements engineering activities including discussions, reasoning and decisions about requirements and extensive changes to object-oriented diagrams and Object-Z documents are documented as they occur. The IBIS notation with its narrative spirit is used for dynamic recording of requirements identification and refinement (through discussions about requirements). By putting requirements in the form of Issue, Position and Argument we naturally highlight ambiguities, hidden problems and assumptions. For example Issue A (see Appendix C) records a conversation between three participants to consider whether to allow involuted links in node-link Model /Argument 4 . This Issue documents and explains the following change to an Object-Z specification: from

Link

to

Link

Node

Node

Link is a kind of Node

Link is a kind of Node

links :↓ Node× ↓ Node

links :↓ Node× ↓ Node

∀(f , t) : links • f 6= self ∧ t 6= self ∧ f 6= t

∀(f , t) : links • f 6= self ∧ t 6= self A Link is not allowed to link it self to another Node/Link

A Link is not allowed to link itself to another Node/Link Involuted links are not allowed

...

...

Documentation of the requirements engineering process using IBIS also helps us to build a better understanding of that process. For example, we discovered that although the 3

We use participants to refer to all people involved in the delivery of a complete FOOM specification including specifier and clients. 4 Italic words denote classes in the requirements model for the FOOM CASE tool (see Section 2.3).

9

process illustrated in Figure 3 did occur when we considered that process at a high level of abstraction, a closer focus on the development of the requirements specification revealed a significant departure from the form which the standard literature would suggest (illustrated in Figure 3). The IBIS record of the project describes decisions and changes to the model as time progresses. The critical decisions and significant changes to the model that were captured, show clearly that the process was not smooth but rather it involves occasional restructure and simplification of requirements models (see Figure 7). Although the departure from the smooth and incremental evolution is revealed in the IBIS documents, it occurs independently of the use of IBIS. Our experience was later confirmed by further studies of professional requirements engineering practice in which a variety of methods were used (Carroll and Swatman, 1998) but where IBIS was not used. Communication between participants involves discussion about requirements in all three forms of FOOM specification. IBIS supports the preparation of a meeting’s structure, the connection of issues as discussed in different meetings, and the explanation of a specification. In this project, we used IBIS in all three of these ways. Often, unsolved issues and/or questions about requirements and proposed solutions necessitate a meeting and form its structure. Issues, Positions and Arguments permit quick reference to decisions made or Positions left open in previous design meetings. IBIS also supports the explanation of previous decisions and the state of the requirements specification. This is very useful for the specifier and participants when discussing an Object-Z fragment. The IBIS-structured documentation provides a useful and accessible information source for tracing and extracting requirements concepts related to a requirements problem, especially at crisis points. These concepts are expressed in Positions and Arguments. The IBIS Issues are captured at different times in different local situations/contexts due to the ad hoc characteristic of the approach. They form a linear stream (see Figure 6) and explain the path to a particular requirements model. In this IBIS-structured documentation, there may often be a number of Issues related to a single requirements problem. For example, there are a number of Issues relating to definitions of and relationships between Decision-Model -Argument (see Figure 8). These issues explain the changes made to the Object/Class model (from two binary to one ternary relationship) and the Object-Z specification of these classes. Issues B, C and D (see Appendix C) are examples of such arguments. These Issues were retrieved and used in considering the two following modelling options: Decision

Decision

change : Model × Model arguments : P Argument

change : Argument → 7 (Model × Model ) The class Decision records a change from a Model (a version) to another Model (another version) The change is supported by a set of arguments. In other words, this class records references to the evolution of models and the underlying rationale.

The class Decision records a change from a Model (a version) to another Model (another version) The change is supported by a set of Arguments. ∀ arg : argument • arg.basedon = change(first) ∧ arg.concerns ⊆ change(first).structure∪ change(second ).structure

∀(arg, (m1 , m2 )) : change • arg.concerns ⊆ m1 .structure ∪ m2 .structure

...

... 10

(a) Extract from specification version 3.2

(b) Extract from specification version 3.3

Figure 8: Two possible solutions were considered repeatedly

It follows that Issue B (see Appendix C) not only promotes better reasoning around different definitions of the class Decision, but also generates a Sub-Issue. Later the resolution of this Sub-Issue and other related arguments lead to a restructure of the requirements model (see Figure 9).

Figure 9: Extract from specification version 6 This demonstrates the usefulness of the IBIS notation in the provision of retrievable (retraceable) working memory and results in the reduction of time and effort by the specifier. Similar results have been reported in Conklin and Yakemovic (1991) and Shum and Hammond (1994). As demonstrated in the previous example, the IBIS base was used to trace back all arguments and issues related to a specific requirement. This is particularly important at crisis points (see Figure 7). We also find that the IBIS-structured documentation supports the audit trail of the evolution of a specific component of the requirements model e.g. an object or a class. In contrast to textual specifications, FOOM requirements can 11

be split into discrete components. This characteristic is shared with other requirements engineering methods making use of “structured” models. We have also noted that when clarifying a FOOM component, participants often need to refresh their knowledge about previous decisions. The IBIS structure permits tracking down all decisions (selected Position: *P) and Arguments (AS and AO) that have been made among a number of related itIBIS arguments about the component. However, early in this requirements engineering project, we also found some limitations of IBIS. First, we experienced what have been described as the weaknesses of IBIS in the restriction of local context and weak connection to the whole design (Ramesh and Dhar, 1992). In our project, the IBIS Issues are structured around a local and partial problem as it occurs and with little consideration of the global systems requirements. The locality of ad hoc arguments leads to the difficulty in extracting relevant and desired information from the large IBIS base. This is depicted as a dotted line in Figure 5. This difficulty was also experienced by Conklin and Begeman (1988) and Conklin and Yakemovic (1991). Conklin and Begeman (1988)[page 306] developed the graphical hypertext software tool gIBIS for building and managing a large IBIS information base. Conklin and Yakemovic (1991)[page 371-372] used this tool in an attempt to overcome difficulty in managing the large IBIS base. We however conceptualise this problem in a different way. Evidence shows that the linear stream of IBIS arguments tends to explain how we get there, however, it is often not clear why in the end a particular specification has a certain form. We believe that a global holistic view is needed. Therefore, to overcome this limitation we suggest constructing a post hoc analysis around the specification rather then around a local problem. This analysis would be constructed at a separate time at intervals between phases of the active modelling process rather then during the modelling process. Further research is required into supplementing ad hoc with post hoc design explanation within requirements engineering. In fact, this research into has been already commenced. QOC (MacLean et al., 1991) has been chosen to supplement IBIS. Requirements discussions are recorded using the IBIS notation. The IBIS arguments then are converted to QOC analyses when needed. The QOC analyses are used in isolation from the IBIS base for the evaluation of modelling options. Both IBIS and QOC documents are attached to a particular model or a transition under discussion. The process of using the two notations in combination is being observed. Second, we also experienced problems due to a lack of explicit context in the IBIS notation. IBIS argumentation does not document the situation in the context of which an Issue is generated. The knowledge of the situation surrounding the original debate about an Issue is desirable when reappraising the Issue (these events may be separated by a considerable time) and is important when examining the Issue in relation to other Issues/SubIssues. To more fully describe the Issue, we have added a description of the “Context”. Therefore, each IBIS fragment describes a detailed situation (Context) and why (Argument) a decision (Position) is taken to address a problem (Specific Issue). The use of the additional element will also be further examined in our future research.

4.2 4.2.1

Using IBIS more effectively A summary of findings

To support the traceability of requirements, we structure a graph/network of requirements specification versions and attach the IBIS arguments to document the network. In using the IBIS notation to structure the requirements evolution and to record the rationale for 12

the evolution, the findings: • highlight two types of arguments, • suggest attaching each argument to particular FOOM components, • suggest an investigation into the use of a post hoc approach of design explanation as complementary to IBIS, • confirm the advantages of the direct use of IBIS by a FOOM specifier. 4.2.2

An analysis of findings

We have found that there are two types of arguments: confirmation of a version and confirmation of a transition (which may be a rejection of some parts of the current version). Issue C and D (see Appendix C) are two examples of these two types (for the sake of brevity we do not include the details of Positions and Arguments). Issue C confirms the current solution at the time when the Issue was generated (see Figure 8(a)). However, when returning to this Issue in another Issue (Issue D), in order to record static state, changes and dynamic transitions of Model , we decided to have a ternary relationship. This suggested changing our requirements model (see Figure 8(a)) and the new version (see Figure 8(b)). These findings suggest a need to specialise the class Decision. Two types of design decision are Documentation, containing arguments about the appropriateness of a Model , and Transition, holding arguments for a transition from one version to another. Potts and Takahashi (1993) specialised the effect of an argument on a requirements element into five categories: refinement, clarification, merge, split and retraction. However, we believe our classification is adequate and appropriate to structure the evolution graph of requirements specification versions (see Figure 10).

Figure 10: A FOOM evolution network We attach our arguments to particular components involved in a specific change rather than to the whole of a FOOM model as originally proposed. Indeed, Issues A, B, C 13

and D are related to a part of the specification (see Figure 8 and associated Object-Z fragments) rather than to the whole specification. There are also other issues related to the maintenance of semantic mappings in FOOM, e.g. one real-world object appears in different models within a FOOM specification (again this situation is common to most model-based requirements methods). The integration of the IBIS arguments into specific requirements (design objects) also enhances the traceability of FOOM components. The use of IBIS in relation to version control must be examined carefully. For example, the specifier traces back all issues related to a part of the model involved in the transition between two versions. These issues can be divided into different groups representing different areas of concern, e.g. how to represent the relationship of Decision, Model , and Argument, how to specify operations of Project and Argument, and how to specify the constraint in the Object-Z specification of the class Decision... Every single change does not require a transition to a new version. Two important questions concerning version control arise: • when is it sensible to release a new version? At the beginning of the research every decision generated the release of a version. However, the number of versions of Object-Z models grew very rapidly compared to the number of versions of structure diagrams. We decided that the concepts of specification, model and version need to be further clarified. • do we need and how can we structure a representation of the current logical space to assist us to evaluate two versions? There is a common dilemma: whether to keep a current version or to release a new version. As mentioned previously, the restricted locality of IBIS Argument leads to difficulty in comparing FOOM specification versions. So, how do we evaluate collections of arguments related to different specification versions? Again, these questions also indicate that the sole use of IBIS may not be adequate for an effective use of explanation information within the requirements engineering process. A post hoc logical analysis might be used to complement IBIS. This strengthens the suggestion for future research. In relation to the direct use of IBIS by a specifier we have found that it assists in: • achieving a close connection between the specification artefact and the explanation information. • avoiding possible misinterpretation, which we believe would occur to a much higher degree if an outsider-scribe was used (i.e. being more confident with data collected). Indeed, the interpretation of facts, especially the description of the context via the element “Context”, reflects a rather subjective view on the part of the specifier.

5

Conclusion

This study suggests that design explanation is useful within the requirements engineering process. The FOOM requirements evolution and the rationale for the evolution are documented using the IBIS notation. Specifically, discussions and decisions are recorded as they occur and explanation documents written in the extended IBIS notation developed 14

during this study (itIBIS with “Context”) and are attached to the requirements. Our experience in using IBIS indicates this approach would improve the decision making activity and the understandability of requirements specifications and support process management and communication between different participants. In consequence, this would increase confidence in the conformance of the specification to the user’s requirements, and in its consistency and appropriateness. Nevertheless, due to the limitations, extracting information/concepts related to a specific problem from a large number of local IBIS arguments was problematic. To overcome these limitations, further research will be conducted with a view to investigate • the benefits of supplementing the ad hoc IBIS arguments with additional rationale structured using a post hoc design explanation notation, and • how best to organise the two types of explanation information to support the requirements engineering process.

References Booch, G. (1994). Object-oriented analysis and design with applications, Benjamin/Cummings series in object-oriented software engineering, 2nd edn, Benjamin/Cummings Pub. Co., Redwood City, Calif. Carroll, J. and Swatman, P. A. (1998). The process of deriving requirements : Learning from practice, Proceedings of the ninth annual Australasian Conference on Information Systems, Sydney Australia. Checkland, P. (1991). From framework through experience to learning: the essential nature of action research, in H.-E. Nissen, H. Klein and R. Hirschheim (eds), Contemporary Approaches and Emergent Traditions, IFIP, Elsevier Science Publishers B.V., NorthHolland, pp. 397–403. Checkland, P. and Scholes (1990). Soft Systems Methodology in Action, John Willey and Sons Ltd. Christel, M. G. and Kang, K. C. (1992). Issues in requirements elicitation, ESC-TR-92012 CMU/SEI-92-TR-12, Software Engineering Institute Carnegie Mellon University, Pittsburgh Pennsylvania 15213. Conklin, E. J. and Begeman, M. L. (1988). gIBIS: A hypertext tool for exploratory policy discussion, ACM Transaction on Office Information Systems 6(4): 303–331. Conklin, E. J. and Yakemovic, K. B. (1991). A process-oriented approach to design rationale, Human Computer-Interaction 6: 357–394. Curtis, B., Krasner, H. and Iscoe, N. (1988). A field study of the software design process for large systems, Communications of the ACM 31(11): 1268–1287. Dix, A., Finlay, J., Abowd, G. and Beale, R. (1993). Human-Computer Interaction, Prentice Hall International (UK) Ltd, Cambridge, chapter 5, pp. 180–190. Duke, R. and Rose, G. (1995). Formal Object-Oriented Specification and Design Using Object-Z, Software Verification Research Center, Department of Computer Science University of Queensland. 15

Fischer, G., Lemke, A. C., McCall and Morch, A. I. (1991). Making argumentation serve design, Human-Computer Interaction 6: 393–419. Fowler, D. C. (1996). Formal Methods in a Commercial Information Systems Setting: the FOOM Method, PhD thesis, Centre for Information Systems Research Swinburne University of Technology, Melbourne Australia. Fowler, D. C. and Swatman, P. A. (1997). FOOM: Structure and Process, Proceedings of the Second Australian Requirements Engineering Workshop, Sydney Australia. Fowler, D. C., Swatman, P. A. and Wafula, E. N. (1995). Formal methods in the IS domain: introducing a notation for presenting Object-Z specifications, Object-Oriented Systems 2(2): 99–127. Guindon, R. (1990). Knowledge exploited by experts during software system design, International Journal Man-Machine Studies 33: 279–304. Henderson-Sellers, B. and Edwards, J. (1994). BOOK TWO of Object-Oriented Knowledge The Working Object, Prentice Hall. Kaplan, S. M. (1990). COED: A conversation-oriented tool for coordinating design work, in A. Finkelstein, M. J. Tauber and R. Traunmuller (eds), Human Factors in Information Systems Analysis and Design, IFIP, Elsevier Science Publishers B.V., NorthHolland, pp. 123–142. Kaplan, S. M., Tolone, W. J., Bogia, D. P. and Bignoli, C. (1992). Flexible, active support for collaborative work with conversation builder, Proceedings of the ACM Conference on Computer-Supported Cooperative Work, Toronto Canada, pp. 378–385. Kunz, W. and Rittel, H. W. J. (1970). Issues as Elements of Information Systems, Technical Report Working Paper No. 131, Studiengruppe f¨ ur Systemforschung Heidelberg Germany and the Science of Design University of California Berkeley. Lee, J. (1990). SIBYL A tool for managing group decision rationale, Proceedings of the Conference on Computer-Supported Cooperative Work CSCW90, The Association for Computing Machinery, Los Angeles US. Loucopoulos, P. and Karakostas, V. (1995). System requirements engineering, McGrawHill Book Company Europe. MacLean, A., Young, R. M., Belloti, V. and Moran, T. (1991). Question, Option, and Criteria: Elements of design space analysis, Human-Computer Interaction 6: 201–250. Nguyen, L., Swatman, P. A. and Shanks, G. (1998). Supplementing process-oriented with structure-oriented design explanation within formal object-oriented method, Proceedings of the Australian Software Engineering Conference, Adelaide Australia. Pohl, K. (1993). Three dimensions of requirements engineering, Proceedings of the Fifth International Conference on Advanced Information Systems Engineering (CaiSE93), Springer-Verlag, Paris, pp. 275–292. Potts, C. and Takahashi, K. (1993). An Active Hypertext Model for System Requirements, IEEE Software pp. 62–68. Ramesh, B. and Dhar, V. (1992). Supporting systems development by capturing deliberations during requirements engineering, IEEE Transactions on Software Engineering 18(6): 498–510. 16

Shanks, G., Sargeant, R. J. and Abeyatunge, S. (1994). A meta-argumentation workbench, Proceedings of the OZCHI, Computer Human Interaction Special Interest Group of the Ergonomics Society of Australia, Melbourne Australia, pp. 153–157. Shum, S. B. and Hammond, N. (1994). Argumentation-based design rationale: what use at what cost?, 40: 603–652. Swatman, P. A. (1996). Formal Object-Oriented method — FOOM, in H. Kilov and W. Harvey (eds), Object-Oriented Behavioural Specification, Kluwer Academic Publishers, Boston US. Toulmin, S. E. (1958). The use of Arguments, Cambridge University Press, London. Wafula, E. N. and Swatman, P. A. (1996). FOOM: a diagrammatic illustration of Object-Z specifications, Object-Oriented Systems 3(4): 215–242. Yakemovic, K. C. B. and Conklin, E. J. (1990). Report on a development project use of an Issue-Based Information Systems, Proceedings of the Conference on ComputerSupported Cooperative Work CSCW90, The Association for Computing Machinery, Los Angeles US, pp. 105–118.

A

An introduction to Formal Object-Oriented Method

FOOM is based on three theoretical pillars: • a modified object-oriented notation, MOSES (Henderson-Sellers and Edwards, 1994) which provides the benefits of object-orientation, such as modularity, abstraction, classification, encapsulation and polymorphism, • the mathematical specification language Object-Z which provides precision, and therefore may offer deep insights into the problem being specified, moreover, it also supports the object-oriented structure of specifications, • a socio-organisational theory based on Checkland and Scholes’s (1990) Soft Systems Methodology which promotes open different subjective interpretations by various people involved in the development of a specification and addresses the social context within which the system will be used. The FOOM approach also includes a number of structure and process components, techniques and recommended activities (Fowler and Swatman, 1997). According to Fowler and Swatman (1997) the FOOM process model is described as cyclic. Figure 11 shows the FOOM modelling process. Each cycle is composed from information analysis, modelling and validation. During the information analysis process, the clients’ requirements are interpreted, analysed and structured. During the modelling process, in which requirements models are constructed, informal, semi-formal and formal modelling techniques are used in parallel (see Figure 11). During the validation process, the results from the modelling process are evaluated and conflicts identified from the formal modelling are solved by client-validators. The FOOM deliverables are a number of specification documents in three tiers: • an executive summary, 17

Figure 11: FOOM modelling process Fowler and Swatman (1996) • Event Chain diagrams with some Object-Z fragments to facilitate the validation of system behaviours, • modified MOSES Object/Class diagrams, Inter-Object Communication diagrams with complete Object-Z and textual documents. The first document, an executive summary, is prepared for managers in the form of a very high level overview of the functionality of the system in textual form, supplemented by informal diagrams. The second document, Event Chain diagrams linked to fragments of the formal specification, represents the behaviour of the system. This section of the specification is used to explain the behaviour that is defined by the specification to the clients responsible for accepting it (validators). The third document, a complete Object-Z specification is provided with explanatory material, including static and dynamic objectoriented notations adapted from MOSES. The last section of the document is aimed at designers and implementors. The detailed description of these diagrams and the semantic mapping between them can be found in Fowler (1996), Fowler et al. (1995) and Wafula and Swatman (1996). A more comprehensive overview of the method can be found in Fowler and Swatman (1997).

B

itIBIS

itIBIS (Conklin and Yakemovic, 1991) is a textual form of IBIS. The indentation in itIBIS represents the hierarchy of Issues. P? represents a position being considered. *P represents an accepted position. -P represents a rejected position. AS and AO represent supporting and objecting arguments respectively. To describe the issue fully, we have added a description of the “Context”. Therefore, each IBIS fragment describes a detailed situation (Context) and why (Argument) a decision (Position) is taken to address a problem (Specific Issue). 18

For simplicity IBIS and itIBIS are used interchangeably in this paper. Appendix C provided some itIBIS examples extracted from our research diary.

C

IBIS (itIBIS) argumentation extracted from research diary

An argumentation document is a node-link diagram constructed according to a certain notation. A notation defines a set of node types, link types and linkages allowed between them. Issue A discusses whether an involute link should be allowed in an argumentation document, i.e. whether a link can connect a node to itself. Specific Issue A Specifier: Is it possible to create a link connecting a component within an argument to itself within any existing design rationale notation? Context To specify a constraint for Link in Object-Z. The specifier asks two other participants for clarification of the relationship between an argument’s components. In trying to answer the question, we broaden the context of argumentation to modelling notations in general. -P 1 No, the involute link is not allowed in Arguments. (Suggested by The specifier and Participant 1.) AO Specifier: For example, the marriage relationship between two persons, as in Entity Relationship modelling. However, in IBIS I cannot find any link from a specific Issue, Position, or Argument to itself at the level of instances. What about other notations? AS Participant 1: Agrees and confirms that we cannot link an issue instance to itself. -P 2 Participant 2 suggests specialising the notation. AS Participant 2: The approach we are approaching allows us to define rules on connections but only at the class or type level. There is no facility for us to define rules at the object/instance level (e.g. to disallow involuted link). Sub-Issue A1 How do we disallow involute links? -P A1.1 Specifier and Participant 2: define a subclass of link called non-invlink with constraint. AO Specifier: We choose not to do it for simplicity. *P 3 Specifier: The involuted link is allowed. AS Participant 2: Give users the flexibility to decide when to use involuted links. Issue B clarifies our understanding of the class Decision in the context of the relationship between Argument and Model . An Argument discusses a Model and may support changes to the Model . A Decision records the outcome of the Argument, i.e. to or not to make changes to the Model . Specific Issue B What is a Decision?

19

Context To clarify an understanding of the relationship between three classes Decision, Model and Argument. This issue, therefore, is related to a number of arguments around this relationship (one ternary or two binary ones?). -P 1 A Decision records references to the evolution of Model (s) AND the underlying rationale. AS This definition supports the relationship between Argument and Model . AS This definition expresses the relationship between the three classes elegantly. *P 2 A Decision records a set of Arguments which support that decision. AO We may have a Decision with an Argument not related to the relevant Model s. AS This definition supports the specialisation of the class Decision to two subclasses. See the following sub-issue. Sub-Issue Context There are two types of Decision: to change or not to change a Model (!) We have decided on an acyclic structure for the evolution graph, therefore there must be two Model s involved in each Decision. These Model s may be different or identical (two copies of the same content). This approach, however, does not reflect both the static and dynamic states of requirements clearly. Should we have two kinds of Decision? ?P Not to specialise Decision and record changes to a model using δ. ?P To specialise Decision to two subclasses: to support a transition from a Model to another different Model and to support not to change a Model . During the project, the relationship between the classes Decision, Argument and Model was discussed many times. Issues C and D are two examples of such discussions. Specific Issue C How to understand the relationship of Decision, Argument and Model . Context In the current model there are three binary relationships between Decision, Model and Argument. However, a decision for a transition involves two models and an argument. We discuss how best to represent this. *P Keep the current model with three binary relationships between these classes. ... Specific Issue D How to record static state, changes and dynamic transitions of Model . Context We discuss recording decisions about requirements and how to attach arguments to models and transitions. (See the related issue on how to understand the relationship of Decision, Argument and Model , Issue C.) *P This can be modelled as a ternary relationship between these three classes. ...

20