the call for military budget reductions as well as expanded military duties (e.g. .... 10-20 members, who p r e f d to meet h t c ~ f a c e. (Nunamaker et al. ... meeting facilitator first creates a file containing a one sentence question ..... Proceedingsof the Tenth International Conference on Informntion Systems,. Boston Ma, Dec.
Enterprise Analyzer: Electronic Support for Group Requirements Elicitation Robert M. Daniels, Jr.* J. F. Nunamaker, Jr.*
Alan R. Dennis* Joseph Valacich**
* Dept. of Management Information Systems Karl Eller Graduate School of Management University of Arizona, Tucson, Arizona
**Decision and Information Systems Dept. School of Business Indiana University, Bloomington, Indiana
ABSTRACT
could be saved each year (Byrd, 1990). In an attempt to improve the productivity of managing installations, the U.S. Army has started the Installation Support Modules (ISM) Project. The objective of the ISM Project is to develop a set of integrated information systems that will support the management of the installation. This project has a budget of $172 million through 1995 to develop an army-wide system that will be installed at all U.S. Army, National Guard and Reserve installations world-wide (Byrd, 1990). This integrated information support system will assist in the management of the varied activities that occur at each site (e.g., linking tactical and strategic systems with the installation sustaining systems, managing the arrival and departure of personnel, performing daily landlord functions, sharing information across functional areas, etc.).
This paper reports two cases in which groups from the U.S. Army used an automated meeting environment to define the functional requirements of two modules of a large integrated information system. The process used for these sessions is called Enterprise Analyzer, a combination of tools, facilities, facilitation, and processes that blends aspects of both Computer Aided Software Engineering (CASE) and the University of Arizona's GroupSystems Electronic Meeting System (EMS). The paper describes the evolution of the Enterprise Analyzer concept as it matured throughout the two elicitation and refinement sessions. These experiences led us to develop new techniques, tools and procedures for group requirements elicitation, which have been used during three later sessions and will be used in future sessions. 1.0
Glenda Hayes*
Historically, military information systems have concentrated on providing information up and down the chain of command, rather than sharing data across a single level. The ISM project must address the need to share information both vertically and horizontally. The project management felt that a systems development effort of this scope and complexity presents a tremendous challenge, and that traditional requirements definition techniques would be inadequate to meet the necessary time and budgetary constraints. As a result, they established Life Cycle Management processes and procedures specifically for the ISM project (Byrd, 1990). An examination of the facilities and research history of the University of Arizona, (Chen et al., 1989, Konsynski et al., 1984, Nunamaker et al., 1989b) convinced the ISM management that the resources needed to enhance their software life cycle were available.
Introduction
The recent push for democracy in Eastern Europe has been a catalyst for change throughout the world. This change has resulted in a reduction in East-West tension, spumng the call for military budget reductions as well as expanded military duties (e.g., "the war on drugs"). Lt. Gen. Jerome B. Hilmes recently observed that the "Armyof the '!%sand beyond will face significant challenges due to changes in missions and commitments" resulting in the need to actively pursue opportunities to improve organizational effectiveness as the domain of activities expands while operational budgets contract (IMA Viewpoint, 1990). The U.S. Army currently spends $5 billion annually and employs over 250,000people to operate the many Army, National Guard and Reserve installations in the U.S. and worldwide. However, there is currently no common integrated method for managing installations. This results in poor communication and coordination, information redundancies, and non-standardization both between installations and between functional areas at a single post. Consequently, the U.S. Congress and Army administrators have identified this lack of standardization for installation management as a primary concern. For example, if installation management productivity could be improved by 5%, more than $250 million and 12,500man-years of effort
0073-1129/91/0000/0043$01 .OO 0 1991 IEEE
This paper reports two cases in which groups from the U.S.
Army used an automated, facilitated environment to define Functional Descriptions (FD) for separate ISM modules, and the evolution of the processes and procedures used to elicit the systems' requirements. In order to comply with Department of Defense @OD) regulations, the FD for each separate module of the ISM must be written before development of that module is authorized. The automated process used to support this requirement is called Enterprise Analyzer; a combination of tools, facilities, facilitation, and processes that blends aspects of both
43
Computer Aided Software Engineering (CASE) and the University of Arkma‘s Groupsystems Electronic Meeting System (EMS). The first two &roups to use Enterprise Analyzer finished their module’s FD and have begun the next phase of the module’s development.
These techniques can be used to collect and refine system Specification. Additionally- these techniques are particularly valuable for complex projects that span several user Organizations and disciplines (Martin, 1990). Group approaches to system development provide several potential advantages. First,the overall functional requirementS are described very early in the process. This allows all participants to be well aware of the collective thoughts on the functionality of the new system (Wood and Silver, 1989). Seamd, the system becomes well defined much earlier than is the case when several users have to be queried in tum (Simpson, 1988). Third, a document resulting from these work sessions becomes a collective design document, partiaUy authored by each participant. This collaborative document is less likely to be challenged later in the project, than a document that was prepared exclusively by the analyst (Wood and Silver, 1989). The participants are less likely to misunderstand parts of a document, when they have invested time creating it, than if they were only required to read and approve it.
The remainder of the paper will be divided as follows. Section 2 briefly reviews current systems analysis and design practices. Section 3 describes our EMS environment and how it can contribute to increased group productivity. Sections 4 and 5 discuss both cases and the lessons learned from these sessions. Section 6 discusses new techniques, tools, and p d m that are being inoorporated into the process. The conclusion discusses insights gained during our efforts to provide enhanced support for group requirements elicitation. 2.0
Systems Analysk and Design Radices
The MIS literature still contains articles about the evergrowing applications bacltlog, which give examples of systems which are delivered late andor over budget (Boehm, 1987, Broolrs, 1987, Cerveny and Joseph, 1988, Jordan et al., 1989,and Leben, 1989). While CASE technology is used to d u c e these problems, it is only part of the solution (Norman, 1988). Most CASE products do not support the en& Systems Development Life Cycle (SDLC)(Gibson et al., 1989). A recent issue of the Communications of the ACM, focuses on revisions to the SDLC to recognize the iterative nature of the development process (Henderson-Sellers and Edwards, 1990). Software development is progressing toward an approach that uses problem modelling and decomposition throughout the analysis and design phases (McGregor and Korson, 1990).
JAD sessions use a designated scribe to record the verbal comments of the session participants, either by filling out paper forms or Using a computer. J A D meetings supported by automation, where the scribe uses an inkgakd CASE tool such as Excelerator and a large screen monitor at the front of the mom, have beeh more effective in producing better designs than those using only forms and flip-charts (Martin, 1990). The information submitted by the group during J A D meeting is primarily verbal, thus the number of people that can effectively participate in a J A D Session seems limited by the inherent dysfunctions (productivity and process losses) present in meetings of large groups (Steiner, 1972, Thelen, 1949, Wood and Silver, 1989, Mamn, 1990).
CASE products typically emphasize either the specification and design phases (“upper” CASE) or the program generation and testing phases (“1ower“CASE) of the SDLC. CASE tools that support automatic code generation require that the systems’ requirement specifications be captured in a structured, unambiguous syntax such as the syntax of PSUPSA (Teichrow and Hershey, 197‘7). Requirements elicitation typically has been a non-automated phase, in which the systems analyst sequentially interviews the necessary people one-on-one. Either a single analyst will have to spend weeks interviewing people, or a team of analysts will have to coordinate their interviews and consolidate their findings. Regardless, the analyst@) must consolidate the interview results and resolve umflicting requirements of several separate intended users. This resolution process may require decisions based more on business or political issues than technical questions. This may be outside the skills and knowledge of the analyst (Simpson, 1988).
3.0
The University of Arizona’s GroupSystemsEMS
The University of Arizona’s Electronic Meeting Systems (EMS) research has focused on making groups more productive with the aid of technology. An EMS combines computer technology, procedures, and facilitation to make group meetings more manageable and to provide an environment capable of Capturing and organizing information from multiple sources. This has potential for relieving the systems analysis bottleneck by helping the p u p create a shared vision of the new system. Our primary focus has been on supporting large groups that meet at the same place and time - legislative sessions (Dennis et al., 1988, DeSanctis and Gallupe 1987). This focus arose from work with a variety of organizations in which project teams were assigned pgtasks (Nunamak et al., 1988). The teams typically consisted of 10-20 members, who p r e f d to meet h t c ~ f a c e (Nunamaker et al., 1987).
Recent software development literature discusses rapid applications development (RAD) and accelefated design (AD) to encompass newer techniques, such as Joint Application Design (JAD) (Simpson, 1988,Martin, 1990).
There is growing evidence that use of an EMS can i m p v e the productivity of large groups with messy problems (Nunanmlux et al., l987,1988,1989a, Dennis et al., 1990).
44
Topic Commenter (TC), facilitates idea generation on a structured list of topics. TC operates like a set of index cards, with each card having a separate label. The cards can also be arranged in a hierarchical structure. Participants select a card, which opens a window and allows comments to be entered or prior comments by others to be read. TC, like EM, allows both parallel communication and anonymous entry of comments and ideas.
Tools have been developed to support several generic group tasks such as idea generation, idea organization, and consensus building. The general design for Groupsystems builds on three basic concepts: 1) the provision of a variety of software tools that support various group processes and tasks,and 2) a meeting facilitator who provides premeeting planning, in-meeting group process support, and in-meeting technical support, and 3) the use of a specially designed meeting mom. 3.1
The purpose of Group Matrix is to allow a group to form a consensus of opinions about the nature of the relationships between elements of any two sets. Each participant can simultaneously select a relationship, from a groupdefined list of relationships, for any intersection of elements in the two sets. This relationship is recorded in the participant’s individual view of the matrix, while the average of all participant entries for each cell is displayed in the group view of the matrix. Different colors are used to display the level of agreement within the group for each cell, based on a threshold set by the facilitator. A red background signifies disagreement for the cell, green is agreement, and blue represents too few votes for determining the agreement/disagreement status.
GroupSystems Tools
Many first generation EMS were taskdriven, as defined by Huber, in that they were designed to support one task (Huber, 1984). Second generation EMS, such as Groupsystems, provide a software toolkit, similar to a DSS model base (Sprague, 1980), that are collections of specific tools to support various group processes. EMS which provide toolkits are activity driven (Huber, 1984), in that they have components to support specific group activities (such as idea generation and voting) rather than being one indivisible system to support the entire process of one meeting (such as decision making or negotiation).
3.2
The key advantage of the toolkit approach is flexibility. For example, each tool provides a different approach to support a particular activity. One may support a highly structured interchange of messages, while another may provide little structure. The tools can easily be mixed and matched, and used in whatever order the group believes is most effective. This philosophy enables new tools to be easily added to the toolkit. The selection of which tools will be used for a specific meeting is done during a preplanning meeting between the session facilitator and the group leader(s). The EMS tools used in requirements elicitation meetings with the Army are described below. During the meeting itself, the system is restrictive, in that group members use only those functions, tools and p r o c e d m determined to be the most appropriate for the situation. There are more than a dozen tools in the Groupsystems Toolkit (see Dennis, et al., 1988, Valacich, Dennis, and Nunamaker, forthcoming). Rather than discuss all of these tools, we present only those that were used in these cases: Electronic Brainstorming, Topic Commenter, and Group Matrix.
Meeting Facilitator
The facilitation activities for requirements elicitation meetings can be divided into four categories: Initialization, Communication, Modelling, and Reporting. The initialiition activities include creating the object descriptions in the repository for information and the programs to access that information. Data is entered into the repository during the session directly by the participants, imported from previous work done by the group, and imported from Groupsystems tools used during the session. The communication activities consist of helping the group use specific tools for idea generation, organization, and alternative evaluation. The modelling activities consist of refining the relations and descriptions stored in the repository. The reporting activities consist of accessing data from the repository for loadiig into tools, refreshing the group’s memory, or for production of the deliverable document. Meeting support at Arizona is typically provided by members of the Groupsystems staff, under the direction of a primary facilitator who runs the meeting. For simplicity we use the term facilitator to refer to any of the support staff, who may be assisting during the session. In addition to the specific functions listed above, the facilitator has a variety of other duties. First, the facilitator assists in session agenda planning by working with the group leader(s) to highlight the principal meeting objectives. Specific Groupsystems tools are then mapped to each meeting activity. Second, the facilitator provides technical support. The facilitator selects, initiates and terminates the specific software tools, and guides the group through the technical processes necessary to work on the task. This reduces the amount of training required of the participants
w)
is an idea generation tool Electronic Brainstorming in which participants enter comments anonymously into separate files that are randomly shared throughout the group on a local area network (LAN). With EBS, the meeting facilitator first creates a file containing a one sentence question, which is then distributed to each participant. Each participant adds comments and ideas (up to 5 typed lines) to this file and sends it back on the LAN to exchange for another randomly drawn file. The participant reads the comments contained in the new file and adds to them, before exchanging the file for a new one. In this way, many separate electronic conversations can take place simultaneously.
45
by removing one level of system complexity. Finally, the facilitator provides group dynamics support. The facilitator assists the group leader(s) by running the meeting, maintaining the agenda and assessing the need for agenda changes. This leaves the group leader free to participate as another member of the group. 3.3
would have to be captured in phases 1,3, and 9 is included in the template FD. Therefore, much of the terminology, rules, goals and system specifications were presented to the participants, rather than gathered from them. Furthermore, the ISM management provided the participants with the goals, mission statement, assumptions and constraints that make up the bulk of phases 3 and 4.
Meeting Room The Critical Success Factors for each module were already stated in the Army regulations, so phase 5 was also largely bypassed. Many of the data elements and forms and reports currently in use were already defined in documents that the participants brought with them, which reduced the amount of time spent in phase 10. The descriptions of the cases that follow contain explanations of the tools that were used in the various phases to capture the remaining data.
Arizona currently operates three EMS meeting rooms, with two additional facilities scheduled to open in 1991. All facilities provide participant work areas (i.e. tables or desks) arranged to provide a central focus at the front of the room. Each participant is provided with a separate networked, hard disk-based, color graphics microcomputer workstation that is recessed into the work area. One or two workstations serve as the facilitator’s consoles which are used to control the EMS. At least one large screen video display is provided as an electronic blackboard, with other audio-visual support also available (typically white boards and overhead projectors). Adjacent to the meeting mom is a control room for the electronics, and a laser printer and copier to provide immediate hardcopy printouts. A software video switching system enables information from any workstation to be displayed on any other workstation(s). A software remote keyboard controller enables the facilitator to control the keyboard of any workstation(s). See Dennis, et al. (1988) and Nunamaker, et al. (1988) for more information on these facilities. 3.4
4.0
Case 1: In- and Out-Processing
The objective of the Army In- and Out-Processing modules is to support the activities that occur when soldiers and civilians are transferred to/from an installation (e.g. new assignment, discharge). Given that a typical post assignment lasts 3-4 years, 25-33% of all Army personnel go through an In-Process and/or Out-Process each year. Although In- and Out-Processing activities are governed by U.S.Army regulations for soldiers (the proposed systems must also include the capability to process civilian employees), these regulations are very broad, requiring much local interpretation at each installation. Thus, Inand Out-Processing activities differ widely from one installation to another, particularly between domestic installations and European or Asian installations. The objective of the ISM project was to develop a generic system that could support all activities required by regulations in a standard way, yet be sufficiently flexible to support any local requirements instituted by the installation commander.
Phases of the Enterprise Analyzer Process
Table 1 presents a summary of the Enterprise Analyzer process. We believe the process is flexible enough to be used in any information system design project. The group is expected to iterate through the phases as often as needed and it is not necessary to follow this order. The ISM project staff was able to supply several parts of the specifications that were common to all of the ISM modules, so the Army’s meetings started with a review of this information and then skipped some of the phases.
In-Processing consists of updating the installa$on’s records with information provided by the incoming soldier while Out-Processing consists of updating the installation’s records and providing the soldier with a packet of . information for establishing his records at the next installation. By regulations, there are 17 separate functional departments with whom the soldier must interact on In-Precessing (e.g. ID card station, medical, dental, security clearance, finance, housing, provost marshall, education, etc.) and 15 of those 17 also require Out-Processing. Each installation may also require additional steps in the process (e.g. to ensure that soldiers have returned all borrowed items from the recreation center). Soldiers typically spend three days to In-Process and three days to Out-Process. Since the installations do not necessarily have computer systems (or compatible computer systems), most information is transferred between bases on paper records, although a standard Army-wide information system provides access to some basic
The Functional Description for each module must conform to the DOD-7935A standard. The standard includes major sections listing detailed characteristics, design considerations, the environment, security, the development plan, and cost factors. Appendices to the document list other information such as: readiness and performance requirements, related project documentation, existing and proposed data flows, functional processing steps, interacting organizations, inputs and outputs, and telecommunications requirements. The ISM project staff created a template FD for all of the groups that includes the information that applies to all of the modules. The template FD that is used is approximately 100 pages long before any module specific information is added to it. Most of the information that
46
each of these activities as defined by the FD.
information (which in some cases requires 1-2 days to access for each data request). The soldier’s records are typed at each installation, either into the local information systems or paper files, which are maintained separately by each of the 17 functional areas at each installation.
The group then used Topic Commenter (TC) to define the process requirements. The cards were hierarchically arranged so that each high-level process had a card, under which a series of more detailed cards were provided (e.g. critical success factors, peculiarities, reports, forms, data elements). Each participant was instructed to work only in the area for which hdshe had direct knowledge (e.g. medical for the doctor, education for the education counselor). At the end of the day, one member of the group realized that the others present were unaware that there was an Army regulation listing the high-level process that the group had spent the day identifying and presented a copy to the group.
The objective of the first meeting was to gain a broad understanding of the In- and Out-Processing activities so that a Functional Description (FD) of the target system could be developed. Prior to this meeting, four installations had developed systems to support different aspects of In- and Out-Processing, although none completely covered the full scope. Given the competitive relationship between installations, it was important, politically, that one of these systems was not officially or unofficially selected as the prototype for the Army-wide system. The FD resulting from this meeting was to serve as the foundation for the initial system prototype.
Thus, the second day began with the group being informed of the Army regulations and instructed to use the high-level procedures defined in the regulations. The facilitator then went through several high-level process descriptions in detail with the group to teach them the format and the type of information needed. The group continued to define the requirements (phases 6 and 7)until lunch time. One of the design features of TC (and most other GroupSystems tools) is that once text is entered and submitted to the group, it cannot be changed directly (to prevent other group members from editing or deleting the ideas entered by someone else). This proved to be a problem for this task, as several items entered previously needed to be corrected. Therefore, after lunch, the work-to-date was provided in a read-only format while a new session of TC was started to enable group members to document what changes were needed in the prior work. That night the Arizona staff consolidated the requirements and the changes and loaded the results into a series of WordPerfect (WP) files, one file for each of the 17 high-level processes.
As there were a large number of variations between installations, it was essential to include representatives from each of the 17 functional areas, from all of the major geographic commands (e.g. US.,Europe, Korea, Pacific) and from the functional commands (i. e., Training and Doctrine Command (TRADOC), and Forces Command (FORSCOM) responsible for the actual fighting soldiers). The participants consisted of 18 non-commissioned officers (NCOs) and civilian employees responsible for the 17 activities that make up In- and Out-Processing. These individuals had experience/expertise with only their portion of the entire process, except for their experiences with being transferred themselves. The group was designed to be able to identify the tasks each soldier must complete in order to be processed out of one installation and into another. Five representatives from the ISM project, the Office of the Army Chief of Staff, and the Army Institute for Research in Management Information, Communication and Computer Sciences (AIRMICS) were also present. 4.1
On day three, each group member used the W files to further refine the description of the processes and to include the definitions of any sub-processes under that high-level process. By the end of the day, the requirements elicitation was complete. However, there were many similarly defined data elements. That evening, the files were searched to produce a complete list of 1100 data elements and which processes they were used in (phase 8). The last day was spent working through this list (using the large video display as an electronic blackboard) to identify duplicate items, clarify names and verify which process used each data elements (phase 11). Five hundred items were examined by the time the meeting ended at noon. A draft of the FD was created immediately after the end of the session by inserting report files into the Army’s FD template.
TheMeeting
The meeting lasted four days and the agenda followed the order suggested in Table 1, but skipping the phases in which the information was available from the ISM project. After a brief introduction to the goals of the session, the participants began with Electronic Brainstorming (Em) to discuss the problems and issues (phase 2) with current Inand Out-Processing practices from the point of view of the soldier. The next step was the identification of the major high-level processes of In-Processing and Out-Processing (phase 6). The people involved in the planning of the meeting were unaware that recently released Army regulations listed and described the manual activities in the processes, so the group was asked to develop an independent list of the processes. The participants verbally suggested candidates to the meeting facilitator, who documented and displayed the emerging list of processes on a large video display. Once these were documented, the facilitator described the type of information needed for
4.2
Lessons Learned
This session was generally regarded as a success by the participants, the ISM project team, and the outside
41
observers. The ISM deputy project manager (the group leader for this session) observed that it would have taken four weeks to obtain this much information from a manual session. One significant difference she noticed between this session and the previous 9-week noncomputer-supported requirements elicitation session was the absence of ”turf wars” between different functional areas, that had been common in the nonamputer-supported session. The initial FDs for In- and Out-Processing were completed by the ISM system analysts from the meeting output 45 days after the end of the meeting. As of this writing, the system is being. prototyped at an Army installation in Idaho Falls, Idaho.
tuition assistance for university courses. Finally, it manages the Veteran’s benefits and counselling pertaining to education. There are 243 ACES counselors Army-wide who are responsible for more than 700,000 soldiers. During 1989, it is estimated that ACES counselors made more than 850,000 transactions. In general, ACES is not computerized. Soldiers’ transcripts are recorded manually on forms that follow the soldier from installation to installation. There are currently four computerized systems that have been developed at different installations to assist ACES counselors in managing this activity. Only two systems have complete documentation. Prior to this meeting, an ACES manager, on loan to the ISM project, developed an initial FD that began to integrate these! four systems. Eighteen officers (ranging from lieutenant to It. colonel) responsible for managing the ACES activities participated in the session, with another four observers from ISM, the Chief of Staff‘s Office and AIRMICS. Once again, the participants were selected to represent the four major ACES functions, and all geographic/functional Army Commands.
There were clearly several opportunities for improving the computer-supported process. First, the users had some difficulty in initially understanding the form in which the requirements were to be specified. It was only after working through several examples and exploring the structure on their own that most users truly understood what was needed. Second, there needed to be a way to edit previously entered comments. While there is a need to trace system decisions back to the requirements elicitation phase, this applies more to the final document, rather than the intermediite dmfts.
5.1
The second meeting covered five days. After a brief introduction to the goals uf the session, the participants began with ElectroNc Brainstorming (EBS) to discuss problems facing ACES. Next, after a 1-hour instruction session describing the information needed for the requirements, the group broke into four groups, c o n q n d i i g to the four main ACES responsibilities, and began defining the requirements using the electronic repository update forms. In this activity, the participants were asked to identify each process, the forms used by the process, the reports generated by the process, and the data elements associated with the process ( a combination of phases 7and 8). The progran required the participants to use automatic connections to reach all related data for a process (e.g. forms, reports). Unfortunately, the participants got lost traversing these Connections and complained that the program was too complex. As a result, the participants were given an alternate program for editing the tecords of the process file, form file, report file, and data element file directly, leaving the linkages of phase 8 to be defined using Group Matrix later in the week. The participants were very comfortable with this process, which continued into the following day. By noon, it became clear that not a l l members the group clearly understood what information was needed for the FD. The facilitator spent another hour reviewing the work to date and walking through three examples in detail. By the end of the day, the group felt that all processes, reports, forms, and data elements were identified.
Third, the requirements elicitation structure was not adhered to when the users worked using WP. This required the ISM system analysts to spend a non-trivial amount of time adjusting the form of the requirements in producing the FD. Thus, a more restrictive tool that enforced the proper requirements structure was needed (wood and Silver, 1989). Finally, the unstructured text form of the requirements made it difficult to identify the data elements. Considerable time was spent searching the files to produce a complete list of data elements and which processes they were used in. It was an arduous task to structure the output from the first group; therefore, a goal for the next meetings was to create a tangible structure that could be easily manipulated. Two tools were added to the process to create the added structuring ability: Group Matrix, and a set of data entry programs for parallel group input to the repository, which were developed using the LAN version of dBASE III+. 5.0
TbeMeeting
Case Ik EDMWACES Education Management
The objective of the Education Management ISM module is to support Army Continuing Education System (ACES) activities. ACES performs four basic activities, but is not responsible for the actual teaching of courses. First, it is responsible for managing a variety of services in support of the ACES instruction programs, such as counseling soldiers on education opportunities, administering standardized tests (e.g. SAT), and maintaining soldiers’ transcripts. Second, it manages the Army-run onduty education programs, such as English as a seoond language, and specific Army skills programs. Third, it manages off-duty programs, such as
Day three began with the group linking the forms and reports to the specific ACES pmcesses using Group Matrix. All reports and forms defined in the repository were loaded
48
automatically into Group Matrix. During this process, it became clear to the group that only one half of the necessary reports and forms had been defined. Thus, half of the workstations ran Group Matrix (see Figure 1) while the other half used the repository update programs to append additional reports and forms. These newly added reports and forms were then matched to pnx;esses in subsequent matrices. Then the output files, from the Group Matrix d o n s , containing the form name, the process, the relationship (in this case "USES")and the number of participants who selected that relationship, were imported into the repository. Once all the information generated by the group was formatted and s t o d in the qository, the facilitator could use queries to determine the consistency and completeness of the data (phase 10).
suffered from a lack of "hands-on" detailed knowledge of future requirements elicitation sessions, we will attempt to get representation from both the activity management (i.e. officers) as well as those that actually perform the activity (i.e. NCOs).
UR activities. In
6.0
The DBMS we used to implement the repository, the network version of dBASE HI+,proved to be inadequate in suppating these users for this type of activity. Its method of handling concurrency for rec~rdupdates and additions, locking entire records or entire files @&er, 1988), proved problematic. The techniques we developed to sidestep the locking problems were only PQltiaUy successfuf; users frequently encountered loch which slowed them down and increased frustration. The need for a DBMS with more sophisticated concurrency control was clear.
Group Matrix was then used to relate p~ocesses to data elements, using the relationships "USES" and "GENERATES.' This activity identified many additional data elements, so Group Matrix and repository upaate programs were run concurrently (as in the prior meeting). This process continued over to the next day. The remainder of the meeting was spent providing detailed descriptions for the data elements and identifying and resolving similarly named data elements. 5.2
Current Status and Future Directiom
After the EDMIS Session, we obtained a new DBMS platform, DataFlex from Data Access Corporation. Dataflex allowed everyone in the mom to access the same reconl simultaneously, only locking one field at a time and only as long as it took to save the new value. Dataflex also made it easy for us to create a Common User Access (CUA) style interface for updating the repository, (see figure 2). We were able to implement the data model we had used in the second Session in DataFlex. This allowed us to concentrate on refining the other tools used in the process, such as the Group Matrix.
Lessons Learned
Once again, the session was generally regarded as a success by the participants, the ISM project team,and the outside observers. The ISM deputy project manager (the group leader for this session) felt that this session had produced substantially better results than the previous Session. The FD was completed 60 days after the meeting.
A major enhancement to Group Matrix enables more than me matrix to be provided to the group at one time. Previously, only one matrix could be active at a time so all group members had to complete a matrix before the next one could be started. Given the unequal responsibilitia of the group members, this resulted in some members being v g r busy while others were not, causing them some frustration. Group Matrix was also modified to extend the maximum capacity to exceed 500 columns by 500 rows.
Howevex, we identified several more opportunities for improving this process. First, our experiences with Group Matrix suggest that it is a valuable tool for allowing &roups to quickly establish the relationships between sets of related information. However, a memory limitation of the program prevented us from creating matrices larger than 80 by 80. As there were more reports and forms than could fit into one matrix, they had to be clustered into s e v d d e r lists. Then each of these lists would be merged. This problem wasparticularly severe with the p"c"es and data elements, which had to be divided into SIX chunks.
Some of the matrices that were used to document existing relations had only a few cells that contained conflicts, since there was no significant overlap among participant's expertise. We decided that in these situations, storing every participant's opinion could be inefficient and u ~ e c e ~ ~ a r y . So, another version of Group Matrix has been developed @interprise Matrix) that will store one opiniodcell, as well as comments that can be attached to each cell. This will significantly reduce the disk overhead for using this tool and greatly extend the maximum size of matrix that can be generated. Group Matrix continues to be useful for designing new systems and recording conflicting Opinions.
Some other lessons we learned pertain to the management of the requirements elicitation meeting. As in the prior meeting, the participants had difficulty understanding the specific information needed (particularly the level of detail) for the requirements elicitation. The importance of properly training the users cannot be overstated. Another difference between this meeting and the prior meeting, was that the participants in this meeting were the officers responsible for the activities while those in the prior meeting were the NCOs actually performing the activities. While the second session benefitted from the officers' broader understanding of the issues involved with ACES, it
We ran three later Sessions to build functional descriptions for the following systems: the Installation Command Group, Orders and Records Management, and the Civilian Personnel Offices. The installation command group
49
meeting participants were all high ranking officers, who were trying to design an executive information system for the installation commander. The orders and records participants included both officers and NCOs, and they designed two systems simultaneously, one for orders and one for records management. The civilian personnel office meeting participants were civil service employees ranging from GS12 to GS15, and they also evaluated a number of existing systems as part of the design effort. The last session also used a graphical browser (Valacich, 1988) to validate the relationships and a group prototyper for designing menus and data entry screens.
experiences in developing an environment for information systems requirements elicitation. While there are more development activities that can benefit from simultaneous group input, we feel that our system takes a first step in bridging CASE and EMS technologies.
Our research agenda follows the recommendations from the "Future Directions" section of the Chen et al. paper (1989). We want to support three major formats to elicit and/or represent information to users: structured statement, graphic, and matrix. We want to facilitate interpersonal communication and coordination during development meetings and provide tools for structuring the information supplied by the meeting participants. We want to provide an easily customized means of storing information, yet allow the information to be ported to CASE tools so that it is available throughout the life cycle.
Brooks, Frederick P. Jr., "NOSILVER BULLET Essence and Accidents ~. Of Software Engineering," Em COMPUTER, April, 1 9 8 7 , ~ 10-19.
7.0
Chen, Minder, and Jay F. Nunamaker Jr., "MetaPlex: An Integrated Environment for Organization and Information Systems Development, " Proceedingsof the Tenth International Conference on Informntion Systems, Boston Ma, Dec. 46,1989, pp. 141-151.
References Baker, Richard H.,@AS? III PLUS Multi-userApplicarions, TAB Books Inc.,Blue Ridge Summit, PA, 1988. Boehm, Barry W., "Improving Software Productivity," lEEE COMPUTER, September, 1987,pp. 43-57.
Burkhard, Donald L., "Implementing CASE Tools," Journal of S y s r m Management, May, 1989,pp. 20-25. Byrd, Col. Wayne, ISM Project Manager Communication, 1990.
-
U.S. Army, Personal
k e n y , Robert P., and Daniel A. Joseph, "A Study of the Effects of Three Commonly Used Software Engineering Strategies on Software Enhancement Productivity,"Infoormation and Management, Vol. 14,1988, pp. 243-251.
Conclusion
Enterprise Analyzer combines facilitation and software tools to improve the requirements elicitation phase of the systems development life cycle. We believe that group requirements elicitation can be a very effective process. We are continuing to conduct research for further improving the process.
Chen, Minder, Jay F. Nunamaker, Jr., and E. Sue Weber, "ComputerAided Software Engineering: Present Status and Future directions," DATABASE, Spring, 1 9 8 9 , ~7-13. ~.
Dennis, A.R., J.F. George, L.M. Jessup, J.F. Nunamaker, Jr. and D.R. Vogel, "Information Technology to Support Electronic Meetings," MIS Quarterly, 12:4, (December, 1988), 591424.
The Enterprise Analyzer process does not depend solely on technical solutions; it is important to have a good facilitatorlanalyst to lead the session and to train participants to use common data entry conventions to describe the system. Any information that is relevant to the project needs to be made available before the session begins, in order to avoid duplication of effort during the precious meeting time. The agenda must also account for whether the participants have hands-on experience with the task, or managerial experience. Re-meeting planning was found to be a critical success factor for these meetings. We have found that these types of meetings require significantly more planning, than the non-system development-type meetings that we also have experience facilitating (e.g., Dennis et al., 1990). It is important that group leaders carefully identify the right meeting participants, the objectives of the meeting, and the meeting deliverables.
Dennis, A.R., A.R. Heminger, J.F. Nunamaker, Jr. and D.R. Vogel, "Bringing Automated Support to Large Groups: The Burr-Brown Experience," Information and Management, 18:3,March 1990,111-121. DeSanctis, G. and B. Gallupe, "A foundation for the study of group decision support systems," Management Science, 33, (1987), 589-609. Gibson, Michael L., Charles A. Snyder, and R. Kelly Rainer, "CASE: Clarifying Common Misconceptions, " Journal of System Management, May, 1989,pp. 12-19. Henderson-Sellers, Brian and Julian M. Edwards, "The Object-Oriented Systems Life Cycle,"Communicationsof the ACM, September, 1990,pp. 142-159. Huber, G.P., "Issuesin the Design of Group Decision Support Systems,"
MIS Quarterly, 8 3 , (September 1984), 195-204. IMA Viewpoint, Washington D. C., Policy and Strategy Directorate U.S. Army, Vol. I:l,page 1, 1990.
Stand alone CASE tools can improve the efficiency of the individual analyst, but Norman and Nunamaker (1988) found that analysts using them didn't rate improved communication as one of the primary benefits of the tools. Collaborative CASE tools, such as Enterprise Analyzer, can allow large project teams to work effectively, and shorten the entire life cycle. This paper has reported our
-
Jordan, Pamela W.,Karl S.Keller, Richard W. Tucker, and David Vogel, 'Software Storming: Combining Rapid Prototyping and Knowledge Engineering,"EEJl COMPUTER, May, 1989,pp 3947.
50
Wood.Jane, and Denise Silver,JointApplicationDesign:How to Design Quality Systems in 40% Lcss lime, John Wiley and Sons, New York,
Konsynski, Benn R., Jeffrey E. K O t t e m , Jay F. N d a , and Jack W. Stott, "PLEXSYS-84 I n t e f l d Developmeat EnViromnmt for Information System," Journal of Management hformarion Systems, Winter, 1984-85.Vol. 1, No. 3, pp. 64-104. h . 9
M&,
J=,
1989.
"TAD Workshop Help Capture Design Specifications,"
PC WEEK, February 12,1990,pp. 58.
Table 1: The Process of Enterprise Analysis
M&, James and Joe Leben, Snategic I$iowion Planning Mdhodologies. &mnd Edition, Prentice Hall, Engelwood Cliffs, 1989.
Major Phases 1.
Plan the Session and Set the Agenda a. Customize Requirements Language Definition b. Establish Rules for the Requirements Language c. Define Terminology used in Descriptions 2. Identify Problems and Isnres with Current System 3. Identify Goals, Objectives and Mission Statement 4. Identify Underlying Assumptions and Project Constraints 5. Identify and Rank Business Meanues and CSF 6. Identify and Define the Key High-Level Pmcesses 7. Decompose High-Level P r o c a m 8. Identify Information and Control Flows Among Processes a. Define Documents (e.g. reports, forms) b. Link Documents to Processes (e.g. sources, uses) 9. Define Other System Specifications a. Performance Requirements b. Security Requirements c. Interface Standardization Requirements d. Disaster Recovery Requirements 10. Prototype Cycle a. Define Prototype Domain b. Create Prototype c. Formally Define Prototype i. Data Elements ii. Data Stores iii. Program Modules iv. Relationships v. screens vi. Control Flows vii. Object Types 11. Validate System Definition
McClure, Carma, CASE IS S O F T W m AUTOMATION, Prentice Hall, E n g l e w d Cliffs, 1989. McGregor, John D. and Tim Korson, "Introduction to the issue, Guest Editors' Communicarions of the ACM, September, 1990,pp. 38. Necco, Charles R., Nancy W. Tsai and Kreg W. Holgeson, "Current Usage of Case Sothvare,"Journalof Systenu Management, May, 1989,pp. 6-11. Norman, Ronald J., Gail F. Corbitt, Mark C. Butler, and Donna D. McElroy, 'CASE Technology Transfer: A Case Study of Uormccessful Change," Journal of Sysrems Management, May, 1989, pp. 33-37. Nomum, Ronald J., and J. F. Nunamaker, Jr., "AnEmpirical Study of Information Systems Professionals' Productivity Perceptions of CASE Technology,"Promedingsofthe Ninth Annual InternationalConfeence of Infomation Sysrems, Minneapolis, Mn, November 30-December 3,1988. Nunamaker Jr., J.F. ,Applegate, L.M. and Konsynski, B.R. "Facilitating Group Creativity with GDSS,' Journal of Management Information Sysrems, 3:4, (spring 1987), 5-19. Nunamaker Jr., J.F. Applegate, L.M. and Konsynski, B.R., "Computer-AidedDeliberation: Model Management and Group Decision $upport,'Journal of Operations Research, November-December, (1988), 826-848. Nunamaker Jr., J.F., D. Vogel, A. Hemiager, B. Martz, R. Grohowski and C. McGoff, "Group Support Systems in practice: Experience at IBM,"Decision Supporl Systems, 5 2 , (1989a), 183-196.
Cross-phase Activities Documentation of Conflict Documentation of Interdependencies Analyze for Consistency, Completeness and Correctness Schedule Project Activities Import and Export Data and Information Prepare Status Reports Revise and Review Previous Entries
Nunamaker Jr., J.F., J.F. George, J.S. Valacich, A.R. Dennis, and D.R. Vogel, "Electronic Meeting Systems to Support Information Systems Analysis and Design," In Cotte-.W.W. and J.A. Senn (Editors), Sysrem Analysis and Design:A Researnh Straregy,New YotkJohn Wiley and Sons, 1989b. Simpson, W.Dwain, New Techniques in software Projea Management, John Wiley and Sons,Inc. New York, 1988. Sprague, R.H., "AFramework for the Development of Decision Support Systems,"MIS Quarrerly,44, December 1980,l-26. Steiner, I.D..Groupprocessandproducrivity,NewYork:Academic Press, 1972. Teichroew, Daniel and E.A. Hershey, "PSLIPSA A computer-aided Technique for Struclured Documeatation and Analysis of Information Processing System," IEEE Transactions on SojiwareEngineering, Vol. SE-3, NO. 1, Jan1 9 7 7 , ~41-48. . Thelen, H.A., "Group dynamics in instruction: Principle of least group size,"School Review, 57, (1949), 139-148. United States of America, Department of Defense, Militarysrandard, DOD-SID-793SA, 1988.
51
A
3.1.2.3
Evalu
DA12
A
DA42 A DA42 A DA46 A DA46
A
DA46 A DA46 A DA46
BOTH
Row: 1, Column: 1 DETERMINE QUALIFICATION REQUIREMENTS A
DA1256
Incentive Award Nomination and Approval
Figure 1
... ... iii ... :... j iii ... ... i... ii ... ... E ... i... ii ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
I .
,
~
Level Number:
