An Event, Activity and Process Based Methodology for Requirements Elicitation and its Application to an Educational Information System

Usha V Subramanian

usha @ bits-pilani.ac.in Birla Institute of Technology & Science, Pilani, Raj

Abstract The least attention been paid to requirements engineering resulted in the software development effort facing myriad problems, ranging from incomplete requirements to inconsistent design and improper implementation. We look at one phase of requirements engineering - requirements elicitation. We propose a methodology that allows the requirements elicitor to bring forth the requirements in a methodical manner. It is domain specific and addresses information systems. We have borrowed certain concepts from system simulation - event, activity and process - in developing the methodology. Our methodology provides a mechanism by which the myriad operations of any information system are drawn forth and elicited appropriately using a two-model approach, viz. hierarchical-process model. No assumption, however, is made as to how the analysis or design need be ultimately performed beyond the requirements elicitation phase. We use the illustrative example of a University’s information system to explain the use and efficacy of the methodology.

1. Introduction

The field of requirements engineering has evidently witnessed the widest gap between the state of art and the state of practice [1,2]. Theories and techniques exist, shown to be useful and applicable. Many software developers do not adopt these techniques during the software development process, thus leading to the widening of the already existing gap between art and practice. That requirement engineering, well defined by [3,4,5,6], is an activity that encompasses a number of phases within itself speaks of the enormous effect it would have in the software development process, if done erroneously. Thus the growing area of requirements need more automation and new development methods [7]. The first step in requirements engineering is requirements elicitation [7, 91. The elicitation process is submerged in the analysis with little or no explicit consideration. Analysis is the process of examination of a complex system, its elements and their relations. It is an activity that breaks a whole into component parts. Elicitation, on

the other hand, brings out the essence of the requirements of a system. We are trying to present here a viewpoint of synthesis by using a hierarchical-process model by having the envelope of an event, activity and process approach to the elicitation phase of requirements engineering. The methodology limits to information system applications. Using the methodology, we understand the functioning of the system “as is”. It does not eliminate use of business process reegineering. The methodology can be applied all over again to elicit requirements for the reengineered system.

2. Role and Importance of Requirements Elicit at ion

Understanding requirements is a difficult task. It provides the basic framework upon which the entire software development process rests. It is difficult as

it involves interactions between the end-user and the developer using natural language the end-user may not provide complete and correct requirements

0 requirements are often volatile in nature Quality of software is measured often in terms of reliability and maintainability. Reliable and maintainable software emerges only if the underlying requirements are elicited correctly. Requirements can be analyzed, specified, validated and verified only if they are brought out in a form that is equally correctly understood by the developer and the customer. This process of identifying and bringing out the requirements of a system to-be is termed as requirements elicitation. Figure 1 illustrates the role and place of requirements elicitation in the software development process leading to design. From Figure 1, we see that the process of requirements elicitation is closer to the customer needs than any other stage of software life cycle. The elicited requirements are further understood, analyzed and specified in concrete terms by the requirements analysts. We present here a methodology to elicit requirements of an information system.

188 0-7695-0509-0/99 $10.00 0 1999 IEEE

Figure 1.

* raw requirements

t gathered by

refined

reay;emnts requirements

elicitor

elicited by

L/-f--- 1 focussed

requirements

I examined by

analyst

designers

strqctured utilized by

through to resf of the life cvcle

3. An Event, Activity and Process (EAP) Approach to Requirements Elicitation

Our basic hypothesis is "if every operation within a subsystem of an organization is drawn forth it would be easier to generate focussed requirements". This premise is valid, as any information system is an aggregation of various operations belonging to different subsystems, working in tandem, to achieve the desired objectives of the organization. The EAP methodology adopts a two- model approach to elicit requirements. We use the hierarchical model to capture the organizational structure, the underlying framework for any information system. We then use the process model that depicts the actual functioning of the system. The first step in the methodology is to develop the hierarchical model of the organization investigated. Thus we look at an organizational setup at three levels:

at the top level, we have the organization 1. its basic goals

Cycle

2. 3 . interface between subsystems 4. external environment at the intermediate level, we have the subsystems of the Organization 1. their basic goals 2. 3 . external interface (export/import of entities

at the lowest level, we have the processes of a subsystem 1 . their purpose 2. the collection of events and the associated state

changes 3. the processes 4. the activities 5. external interface (exporthmport of entities

its subsystems and their functions

operations within and their interactions

from other subsystems)

to/from other processes)

189

A partial hierarchical structure of the University considered in our illustrative example is given below in Figure 2. The hierarchical structure provides the infrastructure on which the entire process of eliciting requirements of the organization rests. Each process, the entities at the lowest level, comprises of objects, both human and inanimate (referred to as "actors" [11,12,13] in UML parlance), interacting with one another to complete the tasks. By capturing the responsibilities of

the human objects and utilities of inanimate ones, our methodology results in a set of focussed requirements. The methodology is flexible and incorporates any number of levels for an organization. Understanding the system from an organizational perspective allows the elicitor to trace requirements in a more systematized manner. While drawing forth the organizational structure, we capture the details of the personnel in the organization. We later map the employee to the human objects participating in the process to accomplish a particular task.

top level

Academic Admissions intermediate Registration & & Placement level 1

Counseling Division Unit

> intermediate

Figure 2. Partial Hierarchical Structure of The University (BITS, Pilani, India)

The process model incorporates the three essential concepts, namely event, activity and process. A process is a collection of events ordered in time. An event is a happening in time that changes the state of the system. An activity is the time elapsed between two related events. A process, in our methodology, refers to a set of tasks, at the lowest level of the organizational hierarchy. Any organization would typically have n such processes, working independently or in tandem, to achieve the goal of the organization. Thus we note the top-level objective being achieved by a large set of lowest-level tasks. The flow of entities across various processes can be represented coherently with the help of process scenarios, the arrival of entities through event scenarios and interaction of entities through activity scenarios. To understand how the process model brings out the initial set of requirements, we use a sample process (shown as a leaf node in Figure 2), namely Handling

Request for Application. Using the BITS (Birla Institute of Technology & Science, India) method of application acceptance and processing, an illustrative example is taken for demonstrating the methodology. Candidates seeking admission send in a request for an application form by enclosing a bank draft towards the cost of the application form. The admissions unit of the Institute processes them, which involves

0 separation of the bank draft from the request 0 entering the details of the candidate in a register

sending the bank draft to the concerned authority 0 generating address slips 0 sending an empty application form along with a

copy of the information bulletin to the candidate 0 reduce the stock count for empty application form

and information bulletin by 1 entering the details of dispatch in a register

190

In: Request Packet

Out: ADDlication Packet

Figure 3. Handle Request for Application

To model the processes, EAP methodology considers the following distinct entities,

the organization. The event, arrival of a Request Packet, triggers the process Handle Request for Application. The

0

e 0

0

0

0

e e

The

entities that are received by each process Request Paiket is a composite object, when separated entities that exist after the process is completed results in two simple objects namely Request for entities that leave the process Application and Bank Draft. The separation activity entities that get separated into sub-entities within the requires a human inVOhement, which is depicted using process the notation of a human. The details of the candidate who entities that get concatenated into a single entity sends in a request are sent to a Data The process within the Drocess shown in Figure 3 represents only handling requests for the human objects that handle the various tasks folders to store entities within the process containers where entities are made available within the process

diagrammatic representation of a process (leaf node in Figure 2) is given in Figure 3. The methodology does not introduce the use of new graphical notations to represent the processes. It also does not incorporate any element of design. Figure 3 depicts what transpires within a process pertaining to the leaf nodes in the hierarchical structure of

application. Any such request needs to be responded which is also depicted in the process. In order that the process described above results in a focussed set of requirements, we need to qualify both the inanimate and human objects. The human object's tasks within a process reflect the responsibilities of that person in the process, and hence in the overall system. The inanimate objects depict their utilities in the process. For each object in the process the data attributes that are perceived necessary are given in Table 1. For composite objects, the attributes would normally be other simple objects.

19 1

Object Attributes

Respc H-

Object #1

Request Packet Request for Application Data Store

Human Object

#2

#3

Request for Application Bank Draft Name of Candidate Address A list of {Name of Candidate, Address} Number (to identify uniquely within a process) Code (that which identifies uniquely within the organization) Responsibilities

sibilities (with reference to Figure 3) Responsibilities

b Separates the Request for Application and Bank Draft from the composite object Request Packet Gets the data from Request for Application entered in the Data Store Stores the Request for Application in the Request for Application Holder Generates Address Slip from the Data Store for every candidate who has made a request Removes a copy of the Information Bulletin from the Information Bulletin Holder and decrements the count of information bulletins in the holder Removes a copy of the Empty Application Form from the Empty Application Form Holder and decrements the count of empty application forms in the holder Gets a copy of Information Bulletin and Empty Application Form from Human Object #2 Makes a composite object Application Packet Pastes the Address Slip on the Application Packet Gets the out objects, Bank Draft and Application Packet, details entered in the DisDatch Register

b

b

b

b

b

b

b

b

b

Table 3. Inanimate Objects and Their Utilities

b maintains current number of information bulletins with itself

Using the details presented in Tables 1, 2 and 3, it is possible to generate focussed requirements for Handle Request for Application process. The hierarchy of the organization depicted earlier is included while generating the requirements. Each level in the hierarchy is numbered uniquely that enables the elicitor to identify where a process belongs in the overall system. A sample is shown below. 1 The University (BITS, Pilani, India) 2.3 Admissions and Placement Unit 1.3.3 Admissions Processing Group 1.3.3.2 Handle Request for Application

To separate the Request for Application and Bank Draft bom the composite object Request Packet To get the data from Request forApplication entered in the Data Store Stores the Request for Application in the Request for Application Holder To generate Address Slip from the Data Store for every candidate who has made a request To remove a copy of the Information Bulletin fi-om the Information Bulletin Holder and decrements the count of information bulletins in the holder To remove a copy of the Empty Application Form from the Empty Application Form Holder and decrements the count of empty application forms in the holder To get a copy of Information Bulletin and Empty Application Form from Human Object #2 To make a composite object Application Packet To paste the Address Slip on the Application Packet

J To get the out-objects, Bank Draft and Application Packet, details entered in the Dispatch Register

The sample shown above could be automatically generated from the stored responsibilities for each human object. As attributes of every object is also maintained, knowledge of the utility of each of these objects can also be known. An elicitor’s tool based on the methodology

J

J

J

J

J

192

enables the elicitor to harness data and generate focussed requirements. A prototype tool has already been developed which incorporates many of the features listed above.

4. A Process Scenario Illustration

A process is considered dormant until an event occurs that triggers the process into action. The arrival of the event could be an entity from another process within the organization. This relates two or more processes together using which we can generate the scenarios. Process scenarios are just another way of looking at the complete system. Data is maintained about each out object from a process. One of them may be the process to which it is being sent as an in-object. Using this information we can draw a scenario showing the connection between two or more process. As an example, let us take processes Generate Admitted List #I and Send Admission Information. The event that triggers the process Generate Admitted List #I is time (depicted using a clock). The activities within the process get completed and it sends two out-objects to the process and Send Admission Information, which in turn sends two out-objects to external entities. This, depicted as a scenario, is as shown in Figure 4. The above scenario shows two processes in sequence. This assists the elicitor in comprehending the system better and also in detecting any gaps in requirements gathering.

I Process Generate Admitted j List #I - - - - - -

Figure 4. Process Scenario: An Illustration

5. Attributes of a Good Requirements Specification: How Does Our Methodology Help?

The two-model approach results in the elicitor getting to know the system from two perspectives. If some information get omitted while gathering the requirements from one perspective, it is possible the anomaly may be known easily. For instance, while constructing the hierarchical structure, if an entity at some level is excluded, the gap could be detected easily when the process model is built. Completeness and consistency are characteristics that are not easily quantifiable. The two-model approach adopted can help us again in getting the requirements that may be close to completeness and consistent. As examples, we give below two very simple exclusions that could have occurred while drawing for the requirements and how the methodology helps us in such situations. Many such checks and balances can be performed using our methodology. 0 if the out-object of a process pi becomes the in-object

for process p,, the non-existence of either may be easily known if the in object for a process pi is an object from an external source (outside the organization) instead, the gap can still be known as each process only represents a very small task in the organization. Thus, process pi would be interacting with other processes to get a larger task completed.

The methodology in this way attempts to reduce incompleteness. Inconsistency checks too can be performed. 0 an object's attribute indicates what it holds as data.

Thus, a composite object contains other simple objects as data. While breaking composite objects into simple objects, all simple objects must be derived from the composite object. Any omission leads to inconsistency in getting the requirements.

The methodology supports verifiability as each operation in the process is captured and depicted pictorially. A missing link between two objects within a process, between two processes within subsystems or between two levels in the organizational hierarchy could be known well in advance, at the stage of eliciting the requirements. One need not wait until the requirements engineering phase is completed to detect these anomalies. Every requirement drawn can be thus verified far more easily. The methodology provides implicit mechanisms for updating any item in both the models. All it requires is redrawing of the diagrams that generates a new set of requirements. Elicitation procedure, being closer to user needs, is the first step in acquiring the requirements of the system. If

193

every operation as the end-user perceives is captured and documented, either through the help of a tool or manually, each atomic requirement generated at the end of the requirements engineering phase can be traced backwards, termed as horizontal traceability by [lo]. Every requirement elicited using the methodology depicts one simple operation within a simple process of a subsystem in an organization. Thus, these may be usable in later stages of the software life cycle, to compare and contrast "having understood" from "to have understood". System simulation concepts, namely process, events and activities, are embedded into the methodology implicitly.

Every process is a collection of events that happen with the process of the organization. For instance, Handling Request for Application is a process that is a collection of events such as the arrival of the Request Packet, separation of the Request Packet into Request for Application and Bank Draft, generation of an Address Slip etc. Any happening of an event in the system does change the state of the system. The arrival of the Request Packet triggers the process performs the necessary tasks. This changes the state of the system from what it was prior to the arrival of that event. An activity denotes the time elapsed between two related events. All events captured in a process are related events. For instance, the event separation of Request Packet to the generation of Address Slip is an activity that denotes the time elapsed between these two related events.

Using these key concepts from system simulation, the methodology is well suited to work for a large number of processes for information system domain.

6. What the EAP Model Can Do?

The following points highlight the features of the EAP model.

The model permits to look at the development of the system, by force, from an organizational point of view. This enables the elicitor to get the understanding of the overall structure of the organization for which the information system needs to be developed. It allows mapping of every process to the leaf node in the hierarchical structure thus ensuring a two-way check for capturing the needs of the user. It lets every human object interacting in the process to be mapped with the actual personnel employed in the organization. This again ensures a dual check for the developer. As each process depicts a task in the organization, a collection of such processes can form the basic first requirements of the system.

5.

6.

7.

8.

7.

The model actually captures the execution of a process of the organization by clearly showing the interactions between various objects in the system. The process description allows

knowledge of data stores required for a process 0 knowledge of stock requirements of a process The incoming and outgoing data is depicted as part of the process description. This enables the elicitor to be aware of how processes are connected and what data are transferred between them. Maintenance of data of every object, link and the process (using RBDMS-like tables) itself leads to capture of important pieces of information about the organizational tasks.

Comparison with Other Methodologies

The importance of requirements elicitation had opened up numerous opportunities for researchers and practitioners. Some of the methods used for comparison in [8] were Issue Based Information System (IBIS), Feature-Oriented Domain Analysis (FODA), Joint Application Design (JAD), Controlled Requirements Expression (CORE), etc. More recent techniques have been Quality Attribute Risk and Conflict Consultant (QARCC) [ 191, Traceability of Object-Oriented Requirements (TOOR) [20], Requirments Collection, Reuse and Documentation (RECORD) [21] and many more. Each method emphasizes different aspects for capture of requirements. While RECORD stresses on the end-users role in giving requirements, QARCC uses a knowledge base and allows for identification of potential conflicts among requirements early in the life cycle. TOOR permits tracing of requirements and treats relationships among requirements as objects. Recent methodologies and techniques for requirements elicitation look at the process level details. There is bound to be similarities between one or more techniques. It is thus important to highlight the value addition a technique gives over another. We provide a comparison between the most popularly used use case model [ll-181 as a requirement capture model. Though use cases are more commonly used for object-oriented system development, a comparison is made to highlight EAP model's usefulness in requirements capture. Significantly, the EAP model does not assume any paradigm of software development. The other technique that bears resemblance to the work is ARIS toolset [22]. Use cases are used, in various forms, in the system development. The EAP model does not assume how the phases beyond elicitation would be handled. The EAP model attempts to give a set of requirements in a structured manner, keeping the bigger picture of the organization in mind. It is a pure requirements elicitation technique with a robust support of data base. The data

194

base details, as should be applied to make this technique work, has been developed and thoroughly tested. Every process in the EAP model is akin to a use case. In fact each task within a process can also be depicted as use cases. Thus we say a process in the EAP model is

U = { u i } , i = l , 2 ,..., n where ui is a task within a process.

Use case model captures of requirements by looking at an atomic action the actor performs in the system. The process is a use case, which can be exploded into many such atomic actions, in other words, use cases. The E M model adds more value to the use of use cases. Use cases plainly capture the actors and their perception of the working of the system. Each use depicts how the actor uses the system. The EAP model, in addition, provides other support information which makes the requirements capture more robust.

8. Conclusions

The necessity to generate focussed requirements that subsequently helps the analysts to perform a better task in the software life cycle has been the main motivation behind the development of the methodology. This can be termed as the elicitor’s methodology as it focuses on capturing the initial requirements for a system. Being able to capture every task using diagrams enable the elicitor to look at the requirements from a functional viewpoint. The utility of every interacting object would be known and the responsibilities of the human objects captured. Requirements are largely verbose, cumbersome to handle and difficult to comprehend. This methodology attempts to reduce the inane difficulties associated with requirements presenting the workings of an organization using a pictorial language than a natural language.

9. Acknowledgements

I sincerely thank my advisor, Dr. A.P. Mathur, Professor, Computer Science Department, Purdue University, West Laffayette, USA for his guidance and valuable suggestions. I also thank my mentor, Dr. K.R.V. Subramanian, Associate Professor, Computer Science & Information Systems Group, BITS, Pilani, Rajasthan, INDIA for his help and encouragement at the time of writing this paper.

10. References

1. Davis, Alan M. & Hsia, Pei, “Giving Voice to Requirements Engineering”, IEEE Software, March 1994,

2. Siddiqi, Jawed & Chandra Shekaran, M., “Requirements Engineering: The Emerging Wisdom”, IEEE Software, 1996, pp. 15-19.

pp. 12-15.

3. Palmer, James D. & Fields, N. Ann, “An Integrated Environment for Requirements Engineering”, IEEE Software, May 1992, pp.80-85.

4. Thayer & Dorfman, “System and Software Requirements Engineering”, IEEE Computer Society Press Tutorial, 1990.

5. Zave, P., “Classification of Research Efforts in Requirements Engineering”, Proceedings of the Second IEEE International Symposium on Requirements Engineering (RE’95), IEEE Computer Society Press, York,

6. Loucopoulous, P. & Champion, R.E.M., “Knowledge- Based Support for Requirements Engineering”, Information and Software Technology 31(3) : 123-135, April 1989.

7. Roman, Gruia-Catalin, “A Taxonomy of Current Issues in Requirements Engineering”, IEEE Computer, April 1985,

8. Christel, Michael G. & Kang, Kyo C., “Issues in Requirements Elicitation” , Technical Report, Software Engineering Institute, Carnegie Mellon University, USA, September 1992.

9. Raghavan, Sridhar; Zelesnik, Gregory & Ford, Gary, “Lecture Notes on Requirements Elicitation”, Software Engineering Institute: Information Management, 1994.

10. Gotel, Orlena Cara Zena, “Contribution Structures for Requirements Traceability“, Ph.D. Thesis, Imperial College of Science, Technology and Medicine, Department of Computing, University of London, August 1995.

11. Jacobson, I. M. et al, Object-Oriented Software Engineering - A Use Case Driven Approach, Addison-Wesley Publishing Company, Wokingham, England, 1992.

12. Booch, Grady, Rumbaugh, James and Jacobson, Ivar, The Unified Modeling Language User Guide, Addison-Wesley, First Edition, 1999.

13. Pooley, Rob and Stevens, Perdita, Using UML: Software Engineering with Objects and Components, Addison- Wesley, First Edition, 1999.

14. Bos, van den A.R. et al, “Use Cases”, httn://wwwhome. cs. utwente. nI/-om nri / MEE / misonO14/.

15. Meyer, Bertrand, “OOSC2: The Use Case Principle”, //www.eli.com/ eli/ vl/n2 I hmluse-cases/.

16. Kenworthy, Edward, “Use Case Modeling: Capturing User Requirements ” , httn:/ /www.~~~.C~~.uk/-~0001039/PracGuides/n~ use cases .htm.

17. Ham, Gary A., “Four Roads to Use Case Discovery: There is a Use (and a Case) for Each One”, httn://www.stsc.hil I.af.mi I/CrossTalk/lY98/dec/ham.asp.

18. Hurlbut, Russell R., “The Three R’s of Use Case formalism: Realization, Refinement,, and Reification”, htt~://www.iit.edu/-rhurlbut/xpt-tr-97-06.html.

19. Identifying Quality-Requirements Conflicts, IEEE Software, March 1996, pp.25-35.

20. An Object-Oriented Tool for Tracing Requirements, IEEE Software, March 1996, pp.52-64.

21. Proceedings NWPER’96, Nordic Workshop on Programming Environment Research, Aalborg, Denmark, May 29-31, 1996.

22. ARIS Toolset: The Leading Tool for Business Modeling, Analysis & Optimization, h~tp:l/www.cehhonie.oom.

U.K., March, pp. 214-216.

pp. 14-21.

,

195