Automating Software Requirements Generation from Business ...

Automating Software Requirements Generation from Business Process Models Oktay Türetken1, Onur Su2, Onur Demirörs1 1 Middle 2

East Technical University, Informatics Institute Aydın Yazılım ve Elektronik Sanayii A.Ş., Turkey E-mail: [email protected]

Abstract. Automated requirements generation is foreseen to be one of the possible solutions for decreasing or removing some of the problems originating from requirements and to decrease the effort expanded during the requirements phase. This study first proposes a method for generating software functional requirements from business process models, and then introduces a tool that supports the method by automating the generation of requirements in natural language. The benefits of utilizing such a method and the tool are discussed. The developed method and the tool have been tested within two large military project and the results are presented.

1

Introduction

While requirements are the most important assets of software engineering, it also the most error prone and the impact of these errors are severe. Industry surveys show that requirements errors are abundant in software projects and can easily consume 25%– 40% of the total project budget [28]. According to The Standish Group, lack of user input, incomplete requirements, and changing requirements are the major reasons that cause projects to be delivered with missing functionalities, off schedule and over budget [24]. A survey conducted by ESPITI (European Software Process Improvement Training Initiative) reveals that according to the software engineers participated in the survey, the requirements elicitation and management are the two largest problematic areas in software development projects [9]. The 1994 study of Capers Jones discovered that requirements errors contribute more than one third of the total delivered defects pile [15]. It is easy and cost effective to fix problems caused by requirements in the early stages. The relationship between cost and requirements errors has been determined by a study which is performed at various companies including GTE, TRW, IBM and HP. Davis [6] summarized a number of these studies accordingly as much as a 200:1 cost saving can be achieved between the requirements stage and maintenance stage. The methods, tools and techniques have difficulty in addressing the problems we face with increasing expectations from software intensive products that lead to an increase in the number and complexity of requirements. New methods, approaches and tools that will reduce the problems associated with requirements and also support automating requirements engineering activities have become a necessity.

2

Oktay Türetken, Onur Su, Onur Demirörs

As the number of requirements for software intensive systems is high, it is difficult and time consuming to put together requirements in a structured way. Traditionally software requirements are written in natural language and in most projects by more than one person. As more engineers work on integrated parts of documents, consistency becomes a major problem and the task to find and correct these errors is complicated. Most of the time it is even difficult for a reviewer to decide whether these requirements are written on purpose or there are requirements which are skipped. Moreover, it is possible to write the same requirement in different styles, therefore the recipients of the requirements document have to adapt to different styles of writers. If requirements are consistently written in a structured way, comprehensible documents can be generated so that clients can understand and validate the resulting requirements. Although critical, elicitation and documenting the initial requirements of customers is only part of the whole task. Software requirements frequently change during the process of gathering them. Manual changes are annoying, time consuming and error prone. One way to address these problems is to automate functional requirements generation. Automating requirements generation is a challenging but also a rewarding research area. Its challenge is mostly due to the difficulties related with the identification and representation of customer’s need. The rewards include minimizing effort of non-value-added tasks such as rework and documentation and improving the quality as well as the ability to modify the requirements documents. A number of tools have been developed to assist or automate requirements activities to handle the increased number of requirements. Current software engineering tools mainly focus on software requirements and use approaches starting directly with software requirements and their specifications. There is an extensive lack of tool support for system level requirements- their generation and specification. The use of natural language in requirements documentation is still prevalent and plays a valuable role in software development. However, there are still no good way of using natural language and modeling together in a synergetic way [10]. In this study, we first propose a method for generating software functional requirements from business process models and second, introduce an add-on tool that supports our method by automating the generation of requirements. The “KAOS” has been developed as part of the studies we performed in our research that generates system level software functional requirements from business process models [21]. The tool enables the construction of requirements within a short time, enables reconstruction based on changes in business processes, constructs sentence structures consistently to improve understanding and enables requirements management tools to ease further requirements based tasks. We base the notion of functional requirements generation on business process models and we have experimented and validated our approach and the tool in two large military projects. As a business process modeling notation, we utilized the Extended Event Driven Process Chain (eEPC) for representing the process models so that roles, inputs, outputs and their relationships could be shown precisely, and functions could be presented in natural business language. For business process modeling, we used “ARIS Toolset” [12] where our tool is integrated with. The remainder of this paper is structured as follows: In Section 2, we briefly review and discuss the related work on requirements engineering and business process

Automating Software Requirements Generation from Business Process Models

3

modeling. In Section 3, we introduce our method for generating functional requirements from business process models. Section 4 presents the results of the case projects.

2

Related Work

Modeling business processes in order to understand the way the users perform their activities and accordingly derive the requirements of the software manually based on the behavior depicted on the model, is a common practice in software development. These models used in software development (generally called “requirements models” [25]) focus on depicting the functional interaction between users’ critical or relatively complex work processes. These visual requirements models, including; data flow diagrams (DFD), entity-relationship diagrams (ERD), state-transition diagrams (statecharts), use case diagrams, activity diagrams and class diagrams; provide a common understanding shared between project participants. Functional requirements of the system or the software written in project documents (requirements specifications, request for proposal, etc.) are generally based on these models. However, the traceability and the interaction between these models and requirements (represented in natural language) are generally missing. The process models and the requirements are mostly not complete and/or correct right at the first time they are elicited [26]. They are generally not fed into succeeding phases until numerous iterations are performed on them. Thus, there is a high probability of inconsistency occurring between both sides. In general, requirements written manually are changed and if done, those changes are backtracked to process models. In remaining sections, we briefly discuss the fundamentals of the related research fields and review the related work on requirements engineering and business process modeling. 2.1

Requirements Engineering

Requirements are the raw materials of software intensive projects so they are the most important assets that software intensive projects own. However, there are no universally accepted definitions for the terms ‘requirements’ and ‘requirements engineering’. Bray refers requirements as the effect that client wishes to be brought about in the problem [4]. Commonly cited definition for requirements is the one brought by the IEEE Standard glossary of software engineering terminology [13]: • A condition or capability needed by a user to solve a problem or achieve an objective. • A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. • A documented representation of a condition or capability as in 1 or 2. In software engineering, requirements engineering mainly encompasses activities of developing requirements of the system through an iterative analysis of the problem,

4

Oktay Türetken, Onur Su, Onur Demirörs

specifying the resulting observation, checking the validity of the understanding and performing activities for managing the process itself. Wiegers [25] splits the domain into “requirements development” and “requirements management” sub-domains. Requirements development consists of eliciting, analyzing, specification and verification sub-activities in which the requirements for a software or softwareintensive system are gathered, evaluated, documented, and confirmed. Requirement management mainly encompasses activities of defining the requirements baseline, reviewing, evaluating and incorporating proposed requirements changes, keeping project plans current with the requirements, maintaining the traceability between requirements and design, source code, and test cases, and tracking the whole process throughout the project. There are number of studies performed to classify requirements with respect to their type, abstraction level, origin of source, and etc. One common classification scheme differentiates requirements into two types; functional and nonfunctional. Functional requirements refer to the things the product must do. Non-functional requirements (also referred as quality or performance requirements) represent the properties, or qualities such as usability, portability, integrity, efficiency, robustness, and reliability that product must possess. Considering the abstraction level, Lausen [16] classifies the requirements as: • Goal level, describing business goals; • Domain level, describing activities that go on outside the product; • Product level, specifying what should come in and out of the product; and • Design level, referring the ones that are stated in software requirements specifications document. Weigers [25] differentiate the functional requirements mainly as; business, user, and functional requirements. Business requirements represent high-level objectives of the organization or the customer. User requirements describe user goals or tasks that the users must be able to perform with the product. Functional requirements (behavioral requirements) specify the software functionality that the developers must build into the product to enable users to accomplish their tasks. In our case projects (Section 4), the requirements produced (both manually and automatically) from business process models are system requirements allocated to software. With respect to the classifications discussed above, the requirements are functional and product level requirements. They describe the functions the software should do, and due to the abstraction level set for business process models, they are product level, i.e. they specify high level inputs and outputs coming in and out of the software. With respect to the scheme introduced by Weigers, the requirements are user requirements since the process models describe the tasks performed by the users (actors). There are many factors affecting the practice of writing good requirements. However, there are some explicit and well known ideas that an individual requirement statement should exhibit. First of all, a requirement sentence should be complete, correct, feasible, necessary, unambiguous, prioritized and verifiable [25]. These characteristics ensure that individual requirement statements are well-written. In order requirements sentences not to cause any confusion and misinterpretations, they should be well structured [27]. Well-structured statements help requirements to increase their understandability, clearness and correctness. Although, there is no agreed format for

Automating Software Requirements Generation from Business Process Models

5

the base constructs of a requirement sentence, there are shared structural components [1, 27] which define a set of constructs such as: • Actor/Owner such as people, system • Action (Activity, task) such as read, write • Target or Object (Input, Output objects) such as message, information carrier (if exists) • Condition (if exists) • Constraint (if exists) 2.2

Business Process Modeling

Business process modeling has become a major focus of attention in many fields. These include but not limited to business process management (BPM), workflow management, software process improvement (SPI), business process reengineering (BPR), and enterprise modeling (EM). Although these fields generally exploit process models for different purposes, one way or another, process modeling becomes the center of their frameworks. There are many attempts for the definition of ‘process’. A general perspective from software engineering and BPR community defines a process as “a set of partially ordered steps or activities intended to reach a common goal” [5, 18]. We can highlight the key features of a process as follows: A process is composed of a set of interacting activities (steps, tasks, processes). There exist certain information flow and relationship between these activities. It has known inputs. It is designed to accomplish a goal. It should be assigned roles (human, team, machine), allocated resources and monitored. It is specific, structured, and managed. A business process is generally the central concept used for process modeling. It describes activities within the business and how they relate to and interact with the resources in the business to achieve a goal for the process [8]. A model is an abstract representation of the reality; it is an explicit structure that a system may reason about [5]. It reveals what its creator believes is important in understanding or predicting the phenomena modeled. Thus, a process model is an explicit structure representing an abstraction of process that represents selected process elements that are considered important to the purpose of the model and can be enacted by a human or machine. A business process model cannot be totally accurate or complete [8]. We can refer a process modeling language or notation as a medium which a process model is represented with. Any component of a process is a process element. Following is a list of constructs that is generally considered as the basic set of process elements exploited. • Agent (human, owner, user, actor, machine) is an entity who performs a process element. • Activity (task, action) is a stage of a process that has an input, an output and some intermediate results (artifacts, products) • Artifact (product) is an outcome created by the enactment of an activity.

6

Oktay Türetken, Onur Su, Onur Demirörs

There are other constructs that can be used to highlight the other dimensions of a process such as the ones representing the pre-conditions (conditions to be satisfied before an activity executes), post-conditions (conditions the environment will be in after the activity is performed), specific goals to be aimed for performing a process activity, any application that will support the performance of an activity, and so on. We discussed the constructs of requirement statements in above section. Since, both process models and requirement statements represent an action to be performed by an actor (system, user) with or without a support of a system, the constructs constituting their structure are conventionally similar. In different domains, business processes are modeled with certain motivations, but providing better understanding for the key mechanism of the processes and acting as a basis for improving the current structure have generally been the primary reasons for business process modeling. In addition to these, process models commonly act as the basis for creating suitable information systems that support the business [8]. Business process models can be used as an efficient instrument for identifying processes that will be supported by an information system or by a part of it. This drives us to specifying the key requirements of those systems. In our case projects, while maintaining and benefiting the general purposes for process modeling, specifying the requirements of these systems was our primary objective. The details of the requirements elicitation process we followed in our case projects are discussed in Section 4. 2.3

Tool Support for Requirements Engineering

There are several applications used for assisting requirements engineering processes. One of the classifications of these tools has been carried out by the International Council on System Engineering (INCOSE) from the system engineering point of view [14]. INCOSE classify requirements engineering tools into two main categories: “Requirements Management” and “Requirements Generation” tools. Requirements management tools include the requirements classification tools, requirements capture and identification tools, and requirements traceability tools. “Requirement classification tools” help engineers classify requirements based on work to be done so that requirements activity can be scheduled and tracked. “Requirements capture and identification tools” aid engineers in separating requirements from gathered information. Some of these tools use natural language processing (textual requirements capture tools) and others use requirements models for eliciting requirements. “Requirements traceability tools” enable the engineer to link requirements to their source, to changes in requirements, and to modeling elements that satisfy the requirements. They provide traceability through the successive documents which are used to review the system development. Tools such as RequisitePro [11], DOORS [23], CaliberRM [3], and CARE [20] are contained in requirements traceability tools. “Requirement generation tools” utilize system simulation results, performance allocations, mission scenarios, and design constraints to generate requirements in an organized and traceable manner [14]. Automatic functional requirements generation from the business process models is a new issue and the tool we have developed and used in our experimental study is the

Automating Software Requirements Generation from Business Process Models

7

only one we could pinpoint in the literature that automatically generates functional requirements in natural language from business process models. In terms of INCOSE’s classification, we can hardly put our tool in one of the categories. Considering its aim, it is a requirements generation tool though its functionality is unlike to other generation tools. From the way it functions, it is more alike to tools for requirements elicitation and can be categorized as a requirement capture and identification tool. We encountered a unique work by B. Berenbach which is closest to the work of our study. In his study, Berenbach aimed to generate requirements from UML models [2]. Although there is little of information about the details of his study, certain guidelines and algorithms are utilized to generate the requirements from UML usecase diagrams. However, considering the constructs of use-case diagrams (focusing on actors and activities), the completeness of requirements statements generated from them becomes an issue. In this case, other important information related with such dimensions like inputs processed and outputs generated, conditions indicating control information that are structuring a requirement statement are left hidden or can be added manually to generated requirements. In addition, considering the overall intention of use-case diagrams, these diagrams focuses on the modeling the interaction between the users and the solution system. Thus, this main objective does not make them an appropriate candidate for developing a complete business process model of an organization for the purpose of understanding the current business structure, generate an improved target model and allocate software to certain processes for the purpose of supporting them.

3

Requirements Generation from Business Process Models

In this study, our proposition is that, if we model the business processes with a suitable process modeling notation which enables us to represent the necessary process attributes with appropriate process elements, and concur to use these in a consistent manner, we can manually or automatically generate functional user requirements from these models. In order to enable this, we first identified a set of process elements for capturing necessary process information. Fig. 1 displays these process elements and their relationships. In our experimental study, we have adopted eEPC (extended Event-driven Process Chain) [15] process modeling notation for our models. With the necessary constructs and flexibility to adapt new ones or modify the existing, eEPC was well-suited for our objectives. The following paragraphs give brief descriptions for the process elements: • Process (Function) is the activity performed on an object in order to support one or several business objectives • Event(s) represents a state that triggers and initiates a process • Actor(s) is the entity performing or is responsible for the activity • Input(s) is a resource input to a process and consumed during the processing • Information(s) is entity fed into a process and used as a part of the transformation process. Unlike inputs they are not consumed. Templates

8

Oktay Türetken, Onur Su, Onur Demirörs

• •

or standards are examples of information. A software requirements specification document can be ‘input’ for ‘software design’ process, while a specific design template can be ‘information’ for that activity. In eEPC, we differentiate inputs form information with using different color tones for two Output(s) is a final object produced or resulted out of that process Application System / Software Module represents the whole or a part of an information system that will support the process.

Application System/ Software Module

Event

supports

activates

Actor

Information

carries out

Input

provides input for

provides input for

Process (Activity)

creates output to

Output

Fig. 1. Process Elements Events define the state or condition that starts and ends a function, so events are always that start or the end nodes of the eEPC diagrams. One or more events can trigger several functions and a function can also result in several events. In order to illustrate these splits/joins and processing loops in eEPC, we use rules (or connectors) that are represented by a circle. Thus, in addition to the process elements depicted in above figure, there are rules (and, or, xor, etc.) that are used for specifying the logical links between events and functions. Fig. 2 presents two examples of rule usage. Routing is Available

Resources are Checked

AND rule

Release Operation

Check Supplier Offer

XOR rule

Supplier Quote is Accepted

Supplier Quote is Rejected

Fig. 2. Rules (connectors) in eEPC [12] A process model can be hierarchically structured across any number of levels by assigning more detailed models to every function within a model. Sentence Structures: With the scheme introduced in Fig. 1 and Fig. 2, we developed a sentence structure for requirement statements to be generated from the models. The

Automating Software Requirements Generation from Business Process Models

9

functional user requirements are generated for the activities in the lowest level of the process hierarchy. Generated statements are numbered according to their level in the hierarchy. The sentence structure for English is as follows: When , The System shall enable to enter as input to by using . The sentence constructs will differ for different languages. In our case studies, we utilized sentence constructs developed for Turkish language. Due to its characteristics (variety of suffixes and associated rules), constructing sentences for Turkish was more difficult but it was satisfactory. Constructs can be modified for different languages and additional constructs can be utilized for different purposes. Particularly in “to-be” process modeling, the process modelers, while adhering the rules of notation semantics, keep in mind (and visualize) the statements to be generated from the models and name process elements correspondingly. Advantages of this are two fold. It decreases the possibility of errors occurring during generation, and also provides a standard and consistent utilization of process elements and certain conventions in process modeling. Examples: In this section, we give examples of process models and requirement statements generated from them. In order to focus on the mechanism of generation, we give a simplified hypothetical example of two activities related with student registration. Fig. 3 displays an eEPC model for ‘student registration’ and ‘student course registration’ activities. A small icon on the right bottom of a function indicates the existence of a lower level process model for that function. Lower level process model represents the activities and other constructs that compose the higher level function. Any actors, input- output objects, or application systems related with that function is represented in lower levels.

10

Oktay Türetken, Onur Su, Onur Demirörs

New Student Arrived for Registration

Student Registration

Student Record is Created

Student Opens Course Registration User Interface

AND rule Student Course Registration

Student Registered to Courses

Fig. 3. Example: Student Processes Fig. 4 displays the lower level eEPC model for student registration. There are two main functions performed by the department secretary. First, she validates the acceptance of the student by checking the accepted student list, and then she creates the new student record in the system.

Automating Software Requirements Generation from Business Process Models

11

Fig. 4. Example: Student Registration As the model depicts (Fig. 4), the first activity is not supported by a system and performed manually by the department secretary. Thus, the requirement statement will only be generated for the second activity. The generated requirement for that function with respect to the sentence construct is as follows: 1.1. When new student arrived for registration is accepted student, The System shall enable department secretary to enter student personal information as input to create student record. Fig. 5 depicts the activities performed in student course registration process. The generated requirements are as follows: 2.1. When -student record is created AND student opens course registration user interface- OR incorrect user account information is entered in Course Reg. UI, The System shall enable student to enter user account information as input to login. 2.2. When student logins for course registration, The System shall enable student to enter course code as input to register new course by using list of courses offered. As can be noticed, when generating the statement for ‘login’ function, events (prestates) for that function are merged with related logical operators.

12

Oktay Türetken, Onur Su, Onur Demirörs Student Course Registration

Student Record is Created AND

Student Opens Course Registration User Interface

Student Affairs Information System

User Account Information

OR Incorrect User Account Information is Entered in Course Reg. UI Login Student XOR

List of Courses Offered Student logins for course registration Course Code

Register

New Course Student Registered to Courses

Fig. 5. Example: Student Course Registration Tool Support: Once process models are developed in accordance with the defined rules, the generation mechanism is not so complex that it can be automated with a tool that integrates with the process modeling environment. In our case projects, we used ARIS Toolset for modeling processes and our tool (KAOS) was developed using the ARIS Scripting language which is based on Visual Basic for applications. It is an addon tool to ARIS Toolset and designed to support the process of generating functional requirements in natural language by fully automating it. The tool can generate requirements for each application system or software module separately. Functional requirements can optionally be filtered according to application systems or software modules, so that only the functional requirements of the selected system can be generated. With assigning priorities to functions in process models, the requirements can be prioritized and can be sorted accordingly. Two numbering options exist for requirements statements. Outline numbering (hierarchical) and plain numbering (1, 2, 3 …) can be selected and applied during generation. The resulting list is presented in a MS Office Word file where specific templates can be applied and headings, footers can be pre-set. However, there is an ongoing effort on supporting events and generation of conditional statements. Details of the functionalities and architecture of the tool is presented in [21].

Automating Software Requirements Generation from Business Process Models

4

13

Experimental Study

We tested the validity of our method and tool in two case projects. We have experienced the planning phase of the acquisition life cycle in the context of acquiring two large innovative military applications. The projects targeted Request for Proposal (RFP) preparation for two different but closely related C4ISR sub-systems for the Turkish Land Forces Command (TLFC). In this paper, the projects are coded as A and B due to security constraints. Descriptions of the original processes are not provided for the same reason. However, we briefly describe the characteristics of the projects to provide insight on the implementations of our approach. Both projects required taking a system viewpoint to map domain requirements to hardware, software, and telecommunication components. Estimated sizes for the software components of these systems as well as the number of staff involved, and the duration and total effort utilized for the acquisition planning process by our project office are given in Table 1. Table 1. Information on Case Projects Project A B

Duration (months) 8 13

Effort (personmonths) 18 26.5

Number of METU Staff 11 9

Estimated Size (Function Point) 10,092 25,454

The requirements elicitation process we utilized in the projects included four technical sub-processes; concept exploration, analysis and modeling of current business processes, modeling of the target system, system requirements definition, and quality assurance activities; verification and validation. “Concept exploration” process was performed to get insight into the domain by reviewing previous documents and interviewing with process owners. “Analysis and modeling of current business processes” was performed to understand the current business processes with their business flows, inputs, outputs, and responsible bodies. “Modeling of the target system” was performed to describe IT oriented target system. Within this process, we identified process enhancements and defined hardware and software components of the system. “System requirements definition” was performed to generate the target systems’ software, hardware, and telecommunication requirements. Based on the models of the target system, we utilized our approach to generate the user-level system functional requirements allocated to software. Finally in requirements elicitation phase, we performed quality assurance activities including the verification among outputs of the requirements elicitation process and validation of these outputs against customer expectations. The details of the process we followed in case projects are presented in [7]. We generated the requirements manually from target business process models in project A, and automatically from target business process models using KAOS tool in project B. Since the requirements were generated manually in project A, a small organizational unit of the domain (approximately 1/10 of the model system in terms of size) was selected as pilot, and its user-level functional requirements were defined as a trial by the whole workgroup. The experience of the pilot study was then used in

14

Oktay Türetken, Onur Su, Onur Demirörs

planning the rest of the user-level functional requirements elicitation efforts. Three teams of workgroup were formed to define the functional system requirements for all other organizational units and worked in parallel for the rest of the process, which benefited the workgroup in defining a standard way of working and in time saving. By using 210 business process models, the manual generation of 10092 FP requirements document took 40 person-days. The number of functional system requirements was about 400 in pages, and about 1380 in number of basic requirements, each composed of 3 sub-requirements on the average (e.g., 1a, 1b, 1c). In project-B, the requirements were generated automatically from target business process models using KAOS tool. With adaptations specific to our project, we utilized eEPC for modeling processes. After modeling target business processes using the notation’s conventions at required detail, the tool benefited in time saving for requirements definition. 295 business process models are instantiated by the KAOS tool and 1270 user-level functional requirements were generated. The generation took 30 minutes. On the other hand, results showed that 517 generated requirements (40.7 % of generated requirements) required corrections and they were corrected on process models in 3.5 person-days.

5

Conclusions

In this study, we introduce a method for driving and specifying requirements of a system from process models where notations and tools developed for business processes reengineering are utilized. The process based approach to requirements engineering is not new, but the way we utilize the business process models in the context of requirements generation is one of the unique studies performed to harmonize these two concepts. This approach not only helps organizations to define the requirements of the acquired system, but also, enables them to identify the big picture and focus on improvement opportunities. While being an effective way to identify IS requirements, modeling business processes created visibility and consensus among different stakeholders of major IT projects. Although business process modeling requires significant effort, it brings various advantages as automatic generation of software functional requirements was possible in project B. In order to overcome some of the difficulties of process modeling, we stressed on utilizing the notations, tools and techniques that are user oriented. Our approach brought about a common structure both for developers and users for process modeling and the standard format for requirement statements. This simplified the understanding, verification, validation and management of these artifacts by all stakeholders. Currently, the systems for which we completed acquisition planning have entered into the development phase. The TLFC has decided to integrate the development of projects A and B, since corresponding systems are complementary, and their requirements are easy to integrate due to definition at similar levels of granularity. The TLFC has suspended the release of the Request for Proposal, and decided to complete system and software requirements specification stages by its own,

Automating Software Requirements Generation from Business Process Models

15

specifically by assigning responsibility to one of its departments that develops inhouse systems and software. The development group has used elicited system requirements as a basis for their planning as well as for requirements specification. They are currently generating use case specifications and scenarios based on userlevel functional system requirements. Finkelstein et. al. visions the future of requirements engineering and related tools in what they call “literate modeling” [10]. In this vision, modeling and natural language documentation are seamlessly bound together and the functionality of CASE tool and of requirements management tool are usable together in a truly integrated manner. What we believe is that this study, from the perspective we bring, is one of the first steps taken through achieving this integrity both in conceptual and in technical aspects. As a future work, we plan to improve the functionalities of KAOS tool. Morphological generators can be integrated into KAOS tool so that corrections applied to the requirements sentences can be minimized. As mentioned, we are still working on the automatic generation of conditional sentences. Another area for future work is automatic estimation of software size from target business process models in function points. There is already an ongoing MSc. thesis study on this subject.

6

References

1. Bayias, P.P., T. Hadzilacos: The Requirements Engineering Process of OASigmaHSigma: An Industrial Case Study. ESEC/FSE 99 Conference. Toulouse, France (1999) 2. Berenbach, B.: The Automated Extraction of Requirements from UML Models. Proceedings of the 11th IEEE International Requirements Engineering Conference (2003) 3. Borland Software Corporation: CaliberRM. http://www.borland.com/caliber/ (Sep. 2004) 4. Bray, I.K.: Requirements Engineering. Addison Wesley Publishing Company (2002) 5. Curtis, Bill, Marc I. Kellner, Jim Over: Process Modeling. Communications of the ACM, Vol. 35, No.9 (1992) 6. Davis, Alan M.: Software Requirements: Objects, Functions, and States. Englewood Cliffs, NJ: Prentice-Hall (1993) 7. Demirors, O., C.Gencel, A. Tarhan,: “Utilizing business process models for requirements elicitation”. Proceedings of the 29th Euromicro Conference (2003) 409 - 412 8. Eriksson, H.-E. and Magnus P.: Business Modeling with UML: Business Patterns at Work. John Wiley & Sons (2000) 9. European Software Process Improvement Training Initiative (ESPITI): User Survey Report (1995) 10. Finkelstein, A., W. Emmerich: The Future of Requirements Management Tools. In: G. Quirchmayr, R. Wagner and M. Wimmer (eds), Information Systems in Public Administration and Law. Oesterreichische Computer Gesellschaft (2000) 11. IBM: Rational RequisitePro. http://www-306.ibm.com/software/awdtools/reqpro/ (Sep. 2004) 12. IDS Scheer: ARIS Method, IDS Scheer AG. (2003) 13. IEEE Std 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology. Los Alamitos, CA: IEEE Computer Society Press (1990)

16

Oktay Türetken, Onur Su, Onur Demirörs

14. INCOSE Tool Database Working Group: Tools Survey: Requirements Management (RM) Tools. Content Owner: William L. McMullen, International Council on Systems Engineering, http://www.incose.org (2002) 15. Jones, Capers: Revitalizing Software Project Management. American Programmer 6(7) (1994) 3–12. 16. Lausen, S.: Software Requirements-Styles and Techniques. Addison Wesley Publishing Company (2002) 17. Leffingwell, D., Widrig, D.: Managing Software Requirements: A Use Case Approach, 2nd Edition, Addison Wesley (2003) 18. Lindsay, Ann, Denise Downs, Ken Lunn: Business processes—attempts to find a definition. Information and Software Technology, 45. (2003) 1015–1019. 19. Robertson, S., and Robertson, J.: Mastering the Requirements Process. Addison Wesley Publishing Company (1999) 20. Sophist Ltd.: CARE. http://www.sophist.de (Sep. 2004) 21. Su, Onur: Business Process Modeling Based Computer-Aided Software Functional Requirements Generation. MS Thesis. Middle East Technical University, Informatics Institute (2004) 22. Sutcliffe, A.: Scenario-based Requirements Engineering. Proceedings of the 11th IEEE International Requirements Engineering Conference (2003) 23. Telelogic AB.: Doors. http://www.telelogic.com/products/doorsers/ (Sep. 2004) 24. The Standish Group International, Inc.: The CHAOS Report (1995) 25. Wiegers, K.E.: Software Requirements, 2nd Edition. Microsoft Press (2003) 26. Wiegers, K.E.: Creating a Software Engineering Culture. New York: Dorset House Publishing (1996) 27. Wilson, W.M.: Writing Effective Natural Language Requirements Specifications. Cross Talk, May (1999). 28. Yourdon, E.: Managing Software Requirements. Addison Wesley Publishing Company (2000)