Using group support systems and joint application development for requirements specification

Using group support systems and joint application development for requirements specification Liou, Yihwa Irene, Chen, Minder.. Analysis is presented of the use of group support systems G

Using group support systems and joint application development for requirements specification

Liou, Yihwa Irene, Chen, Minder Journal of Management Information

Systems Armonk: Winter 1993-1994 Vol 10, Iss 3; pg 25, 17 pgs

Abstract

The increasing use of integrated computer-aided software engineering (CASE)

environments is shifting the bottleneck of systems development from physical design and coding to upstream activities, particularly requirements specification Analysis is

presented of the use of group support systems (GSS) and joint application development (JAD) in the context of CASE environments to facilitate the requirements specification process Examination is offered of the relevance of GSS, JAD, and CASE to

requirements specification An integrated framework is proposed that is augmented by a domain-analysis methodology Results of a pilot study that evaluated 2 process models using tools of a GSS, GroupSystems, for requirements specification are discussed

1 INTRODUCTION

The emphasis of systems development is shifting to the front end of the systems

development life cycle[12, 20] One of the major reasons is that errors made in the early stages of information systems development are costly Most errors found in the systems building process can be traced back to incorrect system requirements or misinterpretation

of the correct ones The cost of correcting erroneous requirements of a system in its operation stage is at least a hundred times greater than correcting them at the

requirements definition stage[3] The advent of application generators and code

generators greatly reduces the programming effort required for building information systems The increasing use of integrated computer-aided software engineering (CASE) environments is shifting the "bottleneck" of systems development from physical design and coding to upstream activities, particularly requirements specification Therefore, the challenge of systems development has become "building the right system by defining the right one" instead of "building the system right."

Many people are involved in developing a complicated software project because no one possesses all the knowledge required Domain-specific knowledge about an application and its environment as well as technical knowledge about systems development have to

be incorporated into a cohesive framework to create a good software requirements

specification (SRS)[1] The elicitation of requirements is a collaborative effort among managers, users, and system analysts One of the major factors that causes

misunderstandings in the systems development process is the complexity of the

communication and decision making among members of a project team[5], and

communication breakdowns are most likely to occur when requirements are elicited from

a heterogeneous group

Traditionally, the requirements specification process is conducted by systems analysts through a series of one-on-one interviews with users and/or managers However,

difficulties in conducting serial interviews with users/managers individually to identify system requirements include: (1) it is a lengthy and time-consuming process; (2) users and managers may have conflicting definitions and perceptions of a system's problems and objectives These conflicts must be resolved by individual members through several iterations of follow-up interviews Sometimes, as when one person misinterprets another's statements and assumes that they are in agreement, a conflict may not even be recognized

to exist (3) The integration of users' views into a coherent set of system requirements is particularly difficult because of the diversity of users' backgrounds and differing usage of terminology

Since the development of information systems has long been recognized as a joint effort among systems developers, users, and managers, the need to support collaborative

activities during the application development process is evident Though CASE tools have been used in various stages during the systems development life cycle to improve software productivity, there is no direct support in most CASE tools for direct

interactions among project team members However, group support systems (GSS), an emerging technology designed to facilitate human interactions, may be used separately or

in combination with joint application development (JAD), a facilitated systems

development methodology, to support collaboration among project team members in the applications development process The purpose of this article is to explore ways to integrate GSS and JAD with CASE tools to improve the effectiveness of requirements specification Next, we discuss enabling technologies for requirements specification

2 ENABLING TECHNOLOGIES FOR REQUIREMENTS SPECIFICATION

Several technologies are available for supporting the requirements specification process CASE tools designed to support the system development life cycle include analysis, design, code generation, and documentation JAD may be considered as a facilitation method for supporting systems development meetings GSS address the need for an electronic meeting environment that provides support for collaboration in the systems development process The current status of these technologies and their relevance to requirements specification are discussed in this section

2.1 COMPUTER-AIDED SOFTWARE ENGINEERING

Upper CASE tools are designed to support systems planning, analysis and logical

design[10] They are used in the application of various structured techniques including data modeling using entity relationship diagrams, process modeling using data flow diagrams, and structured design using structure charts Each structured technique

supports the modeling of only one or two aspects of a system, however Structured texts, structured graphics, and matrices are the representation formats used in most CASE products to present the specification of a target system Structured graphics are used extensively to support the graphic notations employed by structured techniques while structured texts are very useful in listing detailed information about a system Matrices

can be used very effectively to show binary relationships between two types of entities used in information systems planning Additional functions provided by several CASE tools are requirements traceability, consistency and completeness checking, and project repository It is assumed by CASE vendors that systems analysts are able to elicit

requirements from users in informal formats and then to translate and specify those requirements using the formal specification languages supported by CASE tools

Most existing CASE environments, however, do not explicitly provide a mechanism to facilitate software project meetings[10] They do provide version and configuration control mechanisms via check-in and check-out procedures that allow several systems developers working on the same project to share information stored in a repository However, these mechanisms are only used by systems developers and are designed to prevent them from directly interacting with each other Support for requirements

elicitation (particularly in a group meeting) is a critical functionality missing from

existing CASE research and products[9] Davy[13, p 15] stated that "current

implementations of CASE tool technology encourage an individual approach to work, even if they provide multi-user capability However, analysts improve the quality of their work by discussing and reviewing it with colleagues CASE tools are useful, but they are

no substitute for interactive group discussion Until more responsive interfaces are available we will only be able to make limited use of them."

There is increasing use of JAD-like facilitated meetings for building systems using CASE tools JAD workshops provide an interactive group discussion mechanism for project team members to define system requirements Increasingly, CASE tools are used directly during JAD sessions at the back end to document the information generated during these sessions The essentials of JAD are explained in the next section

2.2 JOINT APPLICATION DEVELOPMENT (JAD)

While the need to support collaborative requirements elicitation exists, there are very few systems development methodologies that directly support group interactions in face-to-face meetings Joint application development (JAD), also known as joint application design, a group-oriented analysis and design methodology originally developed by IBM

in 1977, is an exception [2, 6, 34] This methodology features an intensive structured workshop where participating end users are assisted by information systems personnel and guided by an experienced session leader The leader has previously interviewed managers and users to define the scope and objectives of the project and determine who should be participants of a JAD workshop

A JAD workshop usually lasts for three to five days and consists of many sessions It is usually initiated by an executive sponsor who is the owner of the system project and who also is responsible for resolving major conflicts, if any, during a JAD session Typically, JAD session leaders use overhead projectors to present information collected during the JAD preparation phase and use flip charts and magnetic cards to capture informal

requirements generated by the soup Scribes translate and document the requirements

captured in the session, using standardized forms Many organizations recently have started using prototyping tools or CASE tools to support JAD workshops[4, 6, 24]

The success of a JAD workshop relies mainly on the skills of the session leader in

managing processes, applying structured techniques to facilitate the group's deriving requirements, and handling the group's dynamics Documents generated from the

workshop include screen and report formats, definitions of entities and data elements, a description of work flows, and specification of systems functions JAD not only provides

an environment for more thorough recall of key requirements but also encompasses perspectives from different functional areas and from users and managers[33]

In summary, the essentials of JAD are (1) a focused workshop facilitated by JAD leaders and scribes, (2) users' participation and management's commitment, (3) the development

of shared requirements and design specifications, (4) application of structured procedures and methods, and (5) an accelerated approach to meeting a specific time frame

Moreover, JAD provides the following benefits: (1) reduced time and cost in

requirements elicitation, (2) improved communication among project team members, (3) provision of appropriate channels to resolve conflicts and build consensus, and (4) improved quality of workshop outcomes, such as flow charts, screen designs, and

systems specifications

There are some problems with the traditional JAD, however First, all JAD participants may not be equally involved Only the comments of the most vocal may be captured Second, analysts are limited in their ability to judge group consensus in real time Third, the products of the workshop have to be compiled and documented manually which can

be very time-consuming These problems would largely be resolved by using GSS during facilitated JAD sessions First, participation would be encouraged and enhanced with the anonymity feature of GSS, at the same time the communication bandwidth is expanded

by adding an electronic communication channel to the verbal communication channel Second, evaluation tools such as rating and voting can be used to assess group consensus

in a timely fashion Third, the discussions and deliverables of the workshop can be captured by GSS Compilation and documentation become unnecessary

2.3 GROUP SUPPORT SYSTEMS (GSS)

Group support systems (GSS) are integrated computer and communication systems that support group work Other common terms referring to the same concept include, but are not limited to, groupware, group decision support systems, and collaboration technology GSS facilitate communications, coordination, and decision making by structuring the processes and contents of teamwork The goals of a GSS are to reduce the process loss associated with disorganized activity, member dominance, social pressure, inhibition of expression, and other difficulties commonly encountered in groups and, at the same time,

to increase the efficiency and quality of the end results [14, 28, 31] Research findings on the impacts of GSS on groups have shown that the use of a GSS increases task-oriented communication [16, 31], the quality of decisions, and group members' satisfaction and confidence[15]

There is an increasing trend toward using computer and communication systems to support such group techniques as brainstorming Recent developments in CSCW and GDSS are rooted in earlier efforts to support collaborative work in software development [14, 18] GSS have been proven useful in such tasks as idea generation[25, 26], business planning[15], crisis management[27], and knowledge acquisition[22, 23] GSS

technologies make group meetings more productive by supporting rapid access to

information and message exchanges, by providing better group memory management and feedback, and by facilitating more structured group interaction processes[29] Groups supported by GSS technologies are able to use more complex group modeling tools to create and explore a wider range of alternatives[17] In addition, using a GSS often increases participation, reduces meeting time, and improves the quality of meeting results, especially when large groups are involved in complicated tasks[14, 15]

Examples of commercialized GSS include Ventana's GroupSystems VTM, Lotus

NotesTM, and VisionQuestTM GroupSystems VTM provides a set of tools to facilitate electronic meetings, same time/place or different time/place These tools include

Electronic Brainstorming, Idea Organization, Voting, Group Matrix, GroupOutliner, Team Graphic, and GroupWriter[19] Lotus NotesTM is a group communication product that allows people to create, assemble, organize, distribute, and access shared information Notes is appropriate for the development of document-oriented and mail-enabled

applications, such as customer tracking and group discussion[30] VisionQuestTM provides tools organized under an executable agenda to facilitate face-to-face as well as dispersed group meetings[32] These tools include Brainwriting, Comment Cards, Rating, Ranking, and Scoring Most GSS are designed to provide collaboration support to

business teams in communication, coordination, planning, decision making, project management, and document preparation In addition, they have been used to elicit

requirements from project team members and acquire knowledge from experts[22]

3 USING GSS TO SUPPORT JAD AND CASE

Research results indicating positive outcomes of using GSS for systems development activities have made it appear that an ideal approach would be to employ the JAD

methodology with appropriate GS S tools to support requirements elicitation Therefore, equal participation may be achieved, group consensus may be assessed in real time, and semiformal specifications may be generated in group meetings and recorded

electronically [21] Moreover, results from requirements elicitation sessions can be exported and transformed into specific formats supported by existing CASE tools to speed up the systems development process

3.1 A FRAMEWORK

The trend toward user involvement in systems development, particularly in requirements analysis and specification, has been accelerated by the advent of CASE tools and the use

of prototyping in systems building Requirements elicitation calls for intensive

interactions among system developers and users in face-to-face meetings in the software development process[11] Systems developers are better able to work closely with users

in defining system requirements when it is possible to show them CASE tools-generated graphical models that represent the system's functionality and structures

Traditional serial requirements elicitation techniques such as interviews, questionnaires, and observations are appropriate only for eliciting individual views and requirements of a system from users It is very difficult to apply these techniques to a large-scale project due to miscommunications among project members and the amount of time required by the conflict resolution process Group techniques can be used to facilitate the

requirements elicitation from groups, however Structured Brainstorming Systems[20] which has been implemented in GroupSystemsTM[28], is one example of the use of such techniques

An ideal approach may be to employ GSS in JAD sessions to accelerate the requirements elicitation Figure 1 depicts an overview of the integration of GSS and JAD into a CASE environment Systems specifications, screen designs, and flow charts generated during the GSS-supported JAD sessions can then be used as inputs to CASE tools for formal systems specifications, code generation, and documentation

Many GSS applications have consistently fallen short of expectations, and conflicting reports of the usefulness of GSS to facilitate various group activities call attention to the importance of adopting a methodological approach to using GSS[29] The success of GSS may depend on the nature of the application domains in which they are introduced

and the methodologies employed in using them The existence of a methodology for guiding the use of GSS possibly could have prevented earlier possible misuse and abuse

of GSS Based on our experiences in using GSS in knowledge elicitation, systems

analysis and design, and business planning, we have developed a domain analysis

methodology (DAM), which is independent of any specific GSS, to support requirement elicitation using GSS, JAD, and CASE tools

3.2 A DOMAIN ANALYSIS METHODOLOGY

A methodology consists of a predetermined set of tasks grouped into stages and

supported by various techniques, methods, and tools (figure 2) The domain analysis methodology (DAN is composed of a set of methods and tools to assist users in analyzing the domain and to match appropriate group support tools to the processes of various group activities In essence, this methodology is designed to make it possible to examine the problem faced by a group in such a way that GSS can be used appropriately to

facilitate group meetings DAM has been developed by incorporating knowledge

engineering and software engineering principles and techniques to support the group process of information systems analysis and design Requirements elicitation can be viewed as knowledge acquisition activities in which participants contribute individual understandings of the application domain of an information system A requirements engineer should be designated to manage the requirements elicitation process using DAM The six stages are described below

1 SCOPE THE PROJECT The primary tasks involve defining project scope and

identifying stakeholders DAM is user-driven The identification of systems problems is the first step In addition, stakeholders (i.e., individuals, organization units, and outside entities) who have stakes and different aspects of problem domain should be identified Requirements engineers should work with several key persons and experts in the domain

to define the scope of the project and to determine schedule and allocate resources The results of this stage should be: a well-defined project scope, a list of stakeholders, a preliminary description of the problem domain, and a temporary project schedule and resources allocation plan

2 DETERMINE REQUIREMENTS SPECIFICATION PROCESS The procedure for defining the requirements specification process involves: (1) identifying the requirements

to be acquired and their sources and (2) selecting specification methods for representing requirements Requirements engineers should use the concepts, languages, and

terminologies from the application domain as much as possible to specify the

requirements The outputs of this stage should include a defined requirements

specification process and selected methods to represent specifications

3 DESIGN A GROUP PROCESS MODEL TO ELICIT REQUIREMENTS A group process model designed at this stage would elicit requirements from various users and experts Group tasks should be determined and sequenced The interactions among project team members and the underlying group requirements elicitation process should

be determined Group communications and interactions should be encouraged so that group synergy and consensus can emerge in the group requirements elicitation process A sequence of group sessions should be designed to elicit and synthesize requirements acquired from each participant Selection of participants and definition of capacity in which each of them will serve at each session should be defined at this point The desired patterns of interactions should be specified, including the specific structures of the messages to be used by participants in information exchange, the mechanism for sharing information about the system specified, conflict resolution strategies, the timing and constraints of interaction, and the media to be used for communication

4 SELECT AND CONFIGURE A GSS AND CASE TO SUPPORT THE PROCESS MODEL A set of group techniques and group support tools to facilitate appropriate group interactions in the process model is defined in this stage CASE tools should also

be chosen and configured to support the selected specification methods and the group activities A domain-specific group process model that consists of a sequence of group activities supported by a set of group support tools to facilitate the acquisition of

requirements should now exist Information used by and generated from tools can also be specified Other preparations for the JAD sessions should be made at this stage

5 FACILITATE GSS-SUPPORTED JAD SESSIONS The next stage in DAM would be

to conduct group sessions based on the specified group process model The appropriately configured GSS would be used to facilitate group interactions, to capture semistructured requirements from nontechnical users and managers Group dynamics in the process

should be monitored so that unexpected individual and group responses can be managed promptly

6 CONCLUDE JAD SESSIONS To conclude JAD sessions, the semiformal

requirements acquired from the requirements specification sessions should be converted into formal user and engineering requirements specifications, using modeling techniques supported by existing CASE tools Use of either the existing import/export facilities in GSS and CASE or customized software bridges should make the conversion process much easier Because information captured in CASE tools can be represented in various formats and analyzed for completeness and consistency, the results could be fed back to the participants for the refinement of the requirements The finalized specifications should then be evaluated by the requirements engineers, signed off by the participants, and stored in the CASE repository for use by other downstream activities in the systems development life cycle

DAM has been used to customize GSS to support crisis planning[27], group knowledge acquisition for an expert system[22, 23], and organizational modeling[8] It has been proven to be useful In DAM, GSS are used to support requirements elicitation in

facilitated group sessions for systems analysis and design The methodology can improve the effectiveness of traditional JAD sessions, particularly in information strategy

planning, business area analysis, and conceptual systems design

The session results can be easily converted into CASE Data Interchange Format (CDIF) [7] or proprietary formats for specific CASE tools in order to import the session results directly into CASE tools Therefore, the nature of the scribe's job in GSS-supported sessions is changing from recording information to operating CASE tools and GSS tools JAD facilitators always have been in short supply because they need to have skills in many different disciplines With the support of GSS, the cognitive burden of JAD

facilitators to manage group dynamics is reduced Facilitators need less knowledge about requirements specification processes or methods because the methods are embedded in the reusable GSS-supported group requirements specification process models Less skillful and inexperienced JAD facilitators will be able to run GSS-supported JAD sessions successfully

4 AN ASSESSMENT OF THE INTEGRATED APPROACH: A PILOT STUDY

Two aspects of the integrated approach were evaluated in a pilot study One pertains to the sequencing of steps proposed in the DAM and the other pertains to the process models used to conduct requirements elicitation meetings

4.1 RESEARCH DESIGN

The primary objectives of the study reported here were (1) to validate steps and actions specified in the domain analysis methodology in a real project, and (2) to assess

comparative task effectiveness, satisfaction with the meeting process, satisfaction with the GSS, and group cohesiveness of two process models utilizing various group tools

The independent variable studied was the use of different tools in the process model The generic process included four major steps: (1) generating and identifying system

functionalities, (2) prioritizing functionalities, (3) verbally discussing the prioritized list

to gain group consensus, and (4) expanding detail description and specifications on a few selected important functionalities (figure 3) Two specific process models were

employed Groups assigned to process model A used the Electronic Brainstorming tool while groups assigned to process model B utilized the Idea Organization tool for step 1 Both groups used the same tools: Voting and the GroupOutliner, for steps 2 and 4,

respectively

The dependent variables included task effectiveness, satisfaction with the meeting

process, satisfaction with the GSS, and group cohesiveness Task effectiveness was measured by the quality, manner, content, and outcome of the discussion Satisfaction with the meeting process was measured by participants' perceptions of its efficiency, coordination, satisfaction, and effectiveness Satisfaction with the GSS was measured by participants' feelings about using GroupSystemsTM during the meeting Group

cohesiveness was measured by how well members of the group felt they had worked together Both pre-and postmeeting questionnaires were collected from participants Times to complete the requirements specification session appeared to be very similar; groups assigned to process model A averaged 75 minutes while groups assigned to process model B averaged 70 minutes