“Business Process” Oriented Requirements Engineering Process

“Business Process” Oriented Requirements Engineering Process Tomoyuki Arao, Eiji Goto, Tomoko Nagata Nomura Research Institute, Ltd. [email protected], [email protected], [email protected]

Abstract Although requirements engineering techniques and tools have become gradually recognized as ideas, it is still rare to see these ideas implemented in real projects especially for service business information systems in Japan. Through our research project, we found that there are some specific causes that prevent the requirements engineering process from being implemented in real projects and that eliminating these causes can improve the quality and productivity of the requirements engineering process. In this paper, we first present our analysis of the causes that prevent the implementation of the requirements engineering process and approaches to eliminate them. Then, we demonstrate the results from real pilot projects in which these approaches were applied. Finally, we present our ideas about the possibility of applying the approaches to other projects.

1. Introduction Requirements engineering techniques and tools have gradually become popular in Japan nowadays. However, there are still hardly few examples to be seen of these techniques or tools being adapted to real information systems development, especially in service business systems. Nomura Research Institute, Ltd (NRI) is a system integrator company that mainly deals with service business information systems such as distribution systems and financial systems. Being ordinarily responsible for the upstream of a systems development life cycle, NRI strongly recognizes that requirements engineering processes, such as requirement elicitation and verification, are essential for successful projects. However, given that, as indicated in our in-house report, the biggest reason for project failures is that “people start designing and developing systems before requirements are clearly defined,” we are still struggling with improving the requirements engineering process. We also found in our project research that most Japanese companies are fraught with the same unsolved problems[1].

We can no longer leave these problems unsolved because customers require more complex systems that cannot be defined without stating explicitly the requirements, and explicit requirements definition also becomes inevitable for division of labor necessary for larger, complex systems development. We started a research project in 2003 to take up this problem. In this paper, we first present our analysis of the causes that prevent the implementation of the requirements engineering process and approaches to eliminate these causes. Then, we demonstrate the results from real pilot projects in which these approaches were applied. Finally, we present possible lessons to be learned from applying the approaches to other projects.

2. Problem Analysis In order to elucidate the problems in current requirement processes, we briefly introduce in this section our assumptions, what the to-be requirement process is, what the as-is process is in our real projects and present an analysis of the gap between them. 2.1 To-be requirement processes What is the ideal requirements engineering process? Simply put, it would be a process that “establishes and manages accurate requirements that are sufficient for building information systems satisfied by customers.” In reality, however, since it is impossible to establish requirements at one time for both customers and vendors, a requirement process must be continuous and interactive to some degree to make requirements clear and accurate. We assume that the following four-step process is one of the patterns of to-be requirement processes from business problem analysis to system/software design. First, customers and vendors agree to a new business process to realize project goals. Second, vendors elicit and define accurate customer requirements for system/software functions according to the agreed new business process. Third, vendors define detailed system/software specifications that satisfy the customer requirements for system/software functions. Fourth, vendors manage requirement

Proceedings of the 2005 13th IEEE International Conference on Requirements Engineering (RE’05) 0-7695-2425-7/05 $20.00 © 2005

IEEE

changes quickly and accurately requirement changes from customers.

according

to

Manage Manage Requirement Requirement Change Change Quickly Quickly and and Efficiently Efficiently

Cannot Cannot Manage Manage Requirement Requirement Change Change within within the the Time Time Limit Limit

Figure 1: As-is and To-be requirement processes 2.3 Gap analysis between the to-be and the as-is People recognize the importance of requirements and no one aims directly at the as-is process. This begs the question: why is there such a huge gap between the to-be and the as-is processes? The popular idea is that people cannot know what they require before knowing the real thing. Based on the interviews we conducted, however, we assume that there are other reasons that explain the gap. First, the viewpoints of user business processes differ from those of system functions, especially in the business application systems area, because many customer requirements depend on the business process while system/software functions are basically independent from the business process. The following

ȍ ȍ

ȴ ȐȒȿȐȑȗ

ȍ

ȴ ȐȒȿȐȒȓ

ȍ

ȴ ȐȒȿȐȒȔ

ȍ

ȺȐȒȿȐȐȕ

ȍ

IEEE

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ ӝ

ӝ

ӝ

ӝ

ӝ

ӝ

ӝ ӝ

ӝ

ӝ

ӝ

Figure 2: Matrix of business process and functions Why do viewpoints of the business process differ from those of the system function? Let’s think about a business process such as “looking at business performance of the past one week before ordering” in a retail shop. This process will require a point of sales system to store records of sales data for the past one week. The ordering system should display past performance. And, if a customer wants to know the profit, a financial system will be involved. As can be seen from this case, one business process relates to many system functions. Second, no simple and practical engineering techniques that express both viewpoints exist. Certain requirements engineering techniques by which customers (users) can understand the relationships between the business process and system/software functions and by which vendors can describe system/software specifications accurately along with customer requirements based on the business process is required. Using references is one of the ways to express both viewpoints, but it requires complicated management and will not last long. Some modeling languages cannot satisfy these techniques because many customers only understand what is written in their concrete business terminology and process. Third, people who have responsibility for building information systems tend to give priority to creating outputs from a systems/software functions viewpoint. When a customer defines software requirements about the process, e.g. “looking at business performance of the past one week before ordering”, it would be better to break down the requirements from the viewpoint of the business process, because a user can decide what s/he wants the information system to do from a

Proceedings of the 2005 13th IEEE International Conference on Requirements Engineering (RE’05) 0-7695-2425-7/05 $20.00 © 2005

ӝ

ӝ

ӝ

ȍ ȍ

Elicit Elicit Customer Customer Requirements Requirements along along with with Defining Defining Specifications Specifications

ȩɓɓɕɉɎɇȀɉɔɅɍ ȀɁɃɃɏɕɎɔɓ

ȴ ȐȒȿȐȑȖ

ӝ

ȍ

Define Define System/Software System/Software Specifications Specifications According According to to Requirements Requirements

ȴ ȐȒȿȐȑȓ ȴ ȐȒȿȐȑȔ

ӝ

ӝ

ȳɔɏɃɋɔɁɋɉɎɇ ȳɅɒɖɉɃɅɓȀɉɎȀɃɁɓɅȀɏɆ ɄɅɆɅɃɔɓ Ȥ ɅɌɉɖɅɒəȀɏɆȀɒɅɓɅɒɖɅɄȀɇɏɏɄɓ

ɓɔɁɔɅɍ ɅɎɔɓ

Approximate Approximate Customer Customer Requirements Requirements Definitions Definitions

ȴ ȐȒȿȐȑȑ

ӝ

ȩɎɑɕɉɒəȀɏɎȀɓɔɁɔɅɍ ɅɎɔɓȀɏɆȀɄɅɌɉɖɅɒə

Elicit Elicit and and Define Define Accurate Accurate Customer Customer Requirements Requirements

ȴ ȐȒȿȐȐȘ

ȳɅɒɖɉɃɅȀɆɏɒȀɖɅɎɄɏɒɓȀɗ ɉɔɈ ɎɏȀɉɎɖɅɎɔɏɒɉɅɓȀɉɎȀɔɈɅȀȤ ȣ

ȍ ȍ ȍ ȍ ȍ ȍ ȍ ȍ ȍ ȍ ȍ ȍ ȍ ȍ ȍ ȍ ȩɓɓɕɉɎɇ ɔɅɍ ɐɏɒɁɒə ɏɆȀɄɅɌɉɖɅɒə ȳ ɁɖɅȀȆȀɃɌɅɁɒȀɆɉɌɅɓ ȵ ɐɄɁɔɅȀɏɆȀȤ ȣ ȀɄɁɔɅ

Leave Leave New New Business Business Process Process Ambiguous Ambiguous Continuous Reworking Reworking and and Bad Bad Quality Quality Continuous Cost & & Schedule Schedule Overrun Overrun Cost Customer Dissatisfaction Dissatisfaction Customer

Agree Agree with with New New Business Business Process Process

ȴ ȐȒȿȐȐȓ

ȴ ȐȒȿȐȐȕ

ȡ ɄɄɉɔɉɏɎɁɌȀɏɒɄɅɒȀɁɔȀɈɅɁɄɑɕɁɒɔɅɒɓ

As-Is Process

Ȣ ɕɓɉɎɅɓɓ Ȱ ɒɏɃɅɓɓ Ȳ ɅɑɕɉɒɅɍ ɅɎɔ

Ȳ ɅɃɅɉɖɉɎɇȀɓɈɉɐɍ ɅɎɔȀɄɁɔɁ

To-Be Process

ȳəɓɔɅɍ ȏȳ ɏɆɔɗ ɁɒɅ ȦɕɎɃɔɉɏɎɓ

Ȳ ɅȍɒɅɃɅɉɖɉɎɇȀɓɈɉɐɍ ɅɎɔȀɄɁɔɁ ɄɁɔɁ Ȳ ɅɃɅɉɖɉɎɇ ɏɒɄɅɒ ɂə ɖɅɎɄɏɒɓ

2.2 As-is requirement processes In many projects, however, the To-be process is just an empty theory. We found from real projects that the as-is requirement process of many real software projects is as follows. First, customers and vendors remain ambiguous about the new business process. Second, vendors define customer requirements to some degree but not to a detailed level. Third, vendors elicit customer requirements on the spur of the moment while they design system/software specifications. Fourth, vendors cannot manage requirement changes quickly and accurately because there are too many requirement changes. In the interviews conducted with participants in real projects to clarify the as-is process, project members said that “customers tend to decide system/software specifications without verifying what is going on in the real business process” or “it is hard but inevitable to change the requirement elicitation process, including customers’ behaviors.”

matrix of the business process requirements and system/software functions from a real project describes how one business process is related to several system functions and vice versa.

System/Software Req.

Constraints

Detailed Req.

System/Software Req.

Scenarios

Business Process Scenarios

Business Rules

Detailed Req.

System/Software Req.

Constraints

Detailed Req.

System/Software Req.

Business Rules

Detailed Req.

Constraints

Detailed Req.

System/Software Req. System/Software Req.

System/ Software Specification

System/Software Function

IEEE

Detailed Req.

System/Software Function

Business Process

System/ Software Specification

System/ Software Specification

System/ Software Specification

System/ Software Specification

Figure 3: Requirement Information Model The information model can be defined as a matrix that has business process requirement lines and system/software function rows. That is, business process requirement lines represent customers’ viewpoints. Each business process requirement line represents each basic requirement by a business process such as “Stock Taking” or “Delivery of Reserved Goods” (Customer’s viewpoint). All requirement elements, such as business detailed requirements, scenarios, business rules and system/software requirements, are managed and grouped under each business process requirement. Each system/software function row represents system/software functions such as “Receiving Shipment Data” or “Issuing Temporary Statements of Delivery.” We define each system/software specification at a point of intersection between a business process requirement and a system function. Each software specification of one system/software function should be written separately for each business process. In other words, a specification is a specification of one function to realize requirements from one business process requirement. Hence, each specification is separated by business process requirements. It is possible to sum up software specifications from both a business process and system/software functions viewpoint. That means we could make requirement specification documents from both a user’s and software engineer’s point of view. (See [2] for more about modeling requirements) 3.2 Requirements Engineering Process Next, we defined the requirements engineering process based on the requirement information model. The most important point is to merge the process of eliciting business requirements and functional requirements into one along with the information

Proceedings of the 2005 13th IEEE International Conference on Requirements Engineering (RE’05) 0-7695-2425-7/05 $20.00 © 2005

Business Rules

Scenarios

System/Software Function

3.1 Requirement information model To realize a technique by which customers (users) can understand the relationship between the business process and system/software functions, we defined a requirement information model that contains both viewpoints. We assumed the requirements for the requirements information model to be as follows. • The model should have requirement elements that cover business process requirements to system/software specifications. The requirement level is divided into adequate layers from business process requirements to system/software specifications. • The model should have a structure that describes system/software specifications from both the system function and business process points of view and makes the relationships between business process and system/software functions visible. • The model should have a simple structure that is comprehensible for people who do not have software engineering backgrounds. All relationships should be defined as 1:n relationship to make traceability simple and manageable. The number of traces should be minimized as long as relationships between the business process and system/software functions can be expressed. Based on these requirements, we defined our requirement information model.

Business Process

System/Software Function

In this section, we present our approach to fill the gap between the as-is and to-be processes. In our research project, we tried to make a requirement information model and support the requirements engineering process and tool that will make it possible to elicit detailed requirements from the business point of view and concurrently describe system/software specifications along with that.

Business Requirement Viewpoints (Customer’s viewpoints)

Ӹ Process Ӹ Business Flow

3. Approaches to fill the gap

System/Software Viewpoints

Project Goal

familiar business environment viewpoint. However, people give priority to documents that have formats written from system functions viewpoints only because system functions viewpoints are inevitable for building systems. On the other hand, business process viewpoints tend to be given less weight. As a result, requirement specifications of the business process viewpoint tend to be found here and there in system functions specifications. Sometimes people omit the writing requirement from the business point of view.

model. We assumed the prerequisites for the requirements engineering process to be as follows. • The process should clearly define requirements for each business process in the first place to make clear customers’ viewpoints. • The process should elicit detailed requirements for each business process along with customers’ viewpoints. • The process should define system/software requirements as point of intersection of a business process requirement and a software/system function. Based on the prerequisites for the requirements engineering model we defined the phases of the requirements engineering process. • Phase 1 (Eliciting and Verifying Business Process Requirements Viewpoints) You should define business process requirements viewpoints along with goals of a project and agree among stakeholders including customers, users and vendors. • Phase 2 (Eliciting and Verifying Detailed Business Process Requirements) You should elicit detailed customer business process requirements. Every elicited requirement should be managed under each business process requirement. Using a scenario is effective to let stakeholders visualize the business process. • Phase 3 (Eliciting and Verifying System/Software Specification) You should elicit and verify system/software specifications. The verification should include consistency with related business requirements. You can use the matrix when you verify specifications with customers. 3.3 Requirements Engineering Tool We also developed a repository tool that can manage all the requirements based on the information model. Although we tried to implement market tools at first, we ultimately created it ourselves using Microsoft Access and Excel because it seemed that a lot of customization was required to satisfy our requirements for our support tool. With the tool, all the requirements can be stored in a database, and requirement specifications can be generated from both the business and system/software points of views.

4. Implementation in the Pilot Project We implemented this model and process and these tools to a real project involving a distribution center

information system and were able to obtain remarkable results. 4.1 The Pilot Project The pilot project was an enhancement project that adds functions for handling new kinds of products and interfaces for new vendors to an existing distribution center information system. The project lasted three months and cost 40man/month. The main stakeholders included members of the distribution department and information systems department at the customer’s company who were able to participate at most of the meetings where requirements were elicited and verified. We elicited requirements throughout the meetings and summarized them into requirement specification documents. The approaches described in section 3 were implemented with tailored modifications and adjustments, and we were able to get excellent results. 4.2 Results of the Pilot Project It seems real to us that many requirements are elicited and fixed in earlier phases than with the former process. In Phase 2 of the process, we felt that wasted efforts commonly found in the past decreased. There was a huge drop in the number of repetitions of the same discussions or state of confusion. Since we analyzed every discussion and requirement according to business process requirements using scenarios and put them into the repository tool, we were able to discuss the requirements constructively based on past discussions and agreements. Also in Phase 3 of the process, we were able to map out every requirement and defined system/software specifications according to the requirements without fail. Next, we present quantitative effects, how requirements are elicited earlier and accurately and how this affects the quality of design by implementing the model and process. The comparison project is a project before implementing the model and process with the same customer and project members. • Requirements Eliciting Speed and Accuracy We tried to verify that we could elicit requirements more quickly and accurately than ever. However, since it was impossible to list numbers for the comparison project because it has no status or requirements number tracking, we substituted figures for the minutes of meetings for the number of requirements and allocated them according to process and time. As a result, we found that in the pilot project 80% of requirements are elicited in earlier requirement analysis phases and few additional requirements

Proceedings of the 2005 13th IEEE International Conference on Requirements Engineering (RE’05) 0-7695-2425-7/05 $20.00 © 2005

IEEE

are elicited in later design phases, while a lot of requirements are elicited in the design phases in the comparison project.

•

•

Figure 4. Requirements Quantity in time scale Design Quality Improvement In order to see the design improvement, we compared the number of errors and recovery costs in acceptance tests by process for those for which the error causes were stated. As you can see in the figure, errors with causes attributed in the SRS phase decreased dramatically. That indicates that the quality of the SRS phase improved dramatically relative to programming development and unit tests.

•

• Before Before

Software Requirements Specification

Unit Design

Unit Test & Development

# of Errors Recovery Cost(MH)

Number of errors in SRS phase decreased relatively in the pilot project when the new RE process was implemented.

After After

Software Requirements Specification

Unit Design

Unit Test & Development

Figure 5. Errors by causal process

5. Lessons learned from other projects We are now trying to expand the implementation of this model and process to other in-house projects and also trying to make the process an organizational standard process. From the trial, we were able to take away several lessons. • You cannot start this process until business viewpoints are almost fixed. In the pilot project, the new business process is relatively clear from

the starting point of this project. However, for bigger and new projects, the goal of a project tends to be ambiguous and furthermore the business process requirements unit unstable. If you cannot wait until business process requirements are fixed, you cannot arrange the requirements alongside the business process requirements units. You should share the requirement model with every stakeholder. Although the main stakeholders in the pilot project could participate in most of the meetings, many projects do not proceed in such a manner. If you cannot share the requirement matrix with every project member, you should cut down the matrix into a size that can be shared with the people who are actually involved in the project. Requirements engineering process planning is inevitable for tailoring the model to each project. Although the matrix structure is common for all business application systems, the precision or number of requirement layers varies according to the characteristics of each project. Especially in the case of tailoring the system to a big project with a new customer, you should construct a detailed requirements engineering plan, because sharing the requirements engineering concept and plan is inevitable for implementation. Without training project members and leaders, implementation will fail. The most important part of this process is prioritizing the customer’s viewpoints. This idea sometimes encounters resistance among project members. Hence, a project leader should understand and promote adapting the process to the project team’s needs.

6. Conclusion Through the research project, we found that having both the customer and system viewpoints integrated in the information model and engineering process is effective for improving the quality of requirements. Although more work and research needs to be done to implement this concept , we believe that this idea will expand as an organizational process in our company and free us from project failures stemming from the requirements engineering process. In addition to that, we hope that this model and process will evolve as a foundation for other requirements engineering technologies and other processes. References [1] Tomoyuki Arao, “Expectations for Requirements Engineering”, SEC journal, IPA Vol.2, 2005 44-49 [2] Robertson, James & Suzanne, “ Mastering the Requirements Process”, Addison-Wesley, 1999

Proceedings of the 2005 13th IEEE International Conference on Requirements Engineering (RE’05) 0-7695-2425-7/05 $20.00 © 2005

IEEE

Proceedings of the 2005 13th IEEE International Conference on Requirements Engineering (RE’05) 0-7695-2425-7/05 $20.00 © 2005

IEEE