It is no doubt that the requirements definition is the most critical phase for the success of a project (Browne and Rogich, 2001; Robertson et al., 2005; Berenbach et al., 2009). Both practitioners and researchers have recognized that the decisions made in this phase strongly affect the following phases in the project and even the life cycle of the product, service, or results created by the project. For example, Blanchard (2004) argues that the greatest opportunity for influencing life cycle cost is during the early phases of system development.

Many researchers have studied the requirements definition phase. Requirements engineering, for example, is an active research community in this field. Most of the researches in requirements engineering has focused on a requirements definition process or elemental technologies for requirements definition activities in the process. These research studies deal with the assessment and improvement of the requirements process. The requirement process improvement models, however, provide almost no methodologies or tools to manage the requirement definition process as a project. However, each project has its own QCD (Quality, Cost, and Delivery) goals, and the requirements definition phase should also be managed to attain the goals as a part of a project.

For managing a project, project management (Project Management Institute, 2008) has been widely implemented in practice. However, most of the tools and techniques of regular project management are applicable after defining WBS (Work Breakdown Structure) (Project Management Institute, 2008). WBS is a hierarchical decomposition of the work to be executed by a project team to accomplish the project objectives. Thus, WBS cannot be made without determining deliverables and the associated works of the project. Since the require-ments definition is the process to determine these deliverables, WBS cannot be fully determined in advance. In addition, the works would be significantly changed by stakeholders’ requirements according to the progress of the phase. Thus, regular project management processes and techniques cannot be applied to the requirements definition phase as it is.

Based on these circumstances, a “drifting management” or a “wait-and-see management,” which manages the process unsystematically based on the experience of a project manager, is often applied to the requirements definition phase. It is obvious that poor management at the requirements definition phase results in poor quality, cost overrun, or late delivery of the requirements definition, and therefore in project failures. Nevertheless, studies on management of the requirements definition phase have been limited. Nguyen and Swatman (2003), for example, studied management of requirements process from the view point of complexity of a system. However, they proposed no management framework and mechanisms for the requirements definition phase. Ishii (2006) proposed a project management framework for the requirements definition phase, although detailed management mechanisms of the framework were not presented.

Accordingly, in this paper, we present a framework and mechanisms of communication-centered project management (CCPM) to manage the requirements definition process based on the situation of communicationoriented activities among stakeholders. In addition, we present a communication-centered project plan (CCPP) with a planning method.

In this paper, we define requirements as documentted specifications which are developed as mutually acceptable agreements among stakeholders as products or services to be implemented. A stakeholder is defined as a group, an organization, or an individual who affects or is affected by the project. Namely, the primary goal of the requirements definition phase is to develop documented specifications, which describe the logical design to fulfill stakeholders’ requirements for the following phases of the project.

Several researchers have studied the characteristics of the requirements definition process. Sommerville and Sawyer (1997), for example, indicate the process as a spiral model, which iterates elicitation, analysis, and negotiation cycle until the requirements definition meets an acceptable level of completeness. Nguyen and Swatman (2003) state that the requirements definition process involves both the incremental building and the occasional radical reorganization of the requirements. Hickey and Davis (2004) describe a requirements definition process as a parallel model where requirements definition activities are performed interactively and in parallel through a series of requirements elicitation technique selection. Based on these observations, we assume that the requirements are defined through interactive processes between documentation-oriented activities and communication- oriented activities as shown in Figure 1.

Documentation-oriented activities consist of requirements elicitation, analysis, producing specifications and documentations, and validation (Wiegers, 2006). These activities also include communications among stakeholders to confirm detailed agreements requiring no negotiation. Although these activities are not simple, they can be formalized to some extent, and are primarily technical in nature.

Communication-oriented activities, in contrast, are basically ill-structured activities related to the requirements’ conflicts among stakeholders, i.e., setting objectives, coordinating activities of each stakeholder, conflict recognition and resolution, and change management.

In the setting objectives, stakeholders agree to common objectives of the project. In the coordinating activities, each stakeholder is assigned to some requirements definition activities. The process of conflict recognition, negotiation, and resolution, called the negotiation cycle, are activities to identify requirements conflicts by both formal and informal communications among stakeholders, and these activities resolve conflicts through the negotiation process (Gr?nbacher and Seyff, 2005). Regarding conflict, we define it as an undesirable state in which incompatible or discrepant requirements among stakeholders arise. It arises inevitably in most projects. These are basically clarified, and mutually acceptable documented specifications are gained through communication- oriented activities. In change management, the project plan, such as assignment of stakeholders’ activities, time schedule, is revised to reflect the changes of requirements.

In the negotiation cycle shown in Figure 1, stake holders try to reveal more detailed and in-depth requirements, and find solutions to resolve conflicts by exchanging offers and counteroffers, or proposing alternatives for mutual gain. Regarding topics of negotiation and resolution, KAOS goal models (van Lamsweerde, 2001) and Win-Win model (Boehm et al., 1994) provide typical conflict management models.

In any case, these activities basically depend on communications among stakeholders, thus they are difficult to plan and control from the standpoint of project management. For instance, termination conditions of the cycles cannot be clearly defined in advance. In practice, the number of documented specifications, man-hours (MH) spent, and the length of the phase are usually used as conditions to close the phase. However, such conditions are not reasonable because they gradually become clear according to the progress of negotiation cycles.

In these circumstances, we can say that managing communication-oriented activities is a critical factor for the success of the requirements definition phase and the project.

At the requirements definition phase, we assume that the documented specifications are obtained as a result of interactions of documentation-oriented activities and communication-oriented activities among stakeholders. Moreover, communication-oriented activities play an important role within the interactions because indepth requirements can be clarified through conflict recognition and resolution by these activities. Thus regular project management, which mostly focuses on the results and time spent by the documentation-oriented activities without considering the progress associated with the communication-oriented activities, cannot be applicable for the requirements definition phase as it is.

In this paper, we present the framework and mechanisms of CCPM for the requirements definition phase. The CCPM focuses on communication-oriented activities, which play a role in setting the common objectives of the project, coordinating works, resolving the requirements conflicts through negotiation cycles, and managing the changes of stakeholders’ requirements throughout the phase.

In the CCPM, we propose evaluation of the state of communication-oriented activities based on communication density, which means the time spent among stakeholders for the activities during a certain period. We assume that the more requirements are agreed on among stakeholders according to the progress of the requirements definition, the smaller communication density is thus necessary. In addition, we propose evaluation of the state of the documentation-oriented activities by the total MH spent for the activities. We assume that the adequate total MH to be spent can be determined in advance based on the characteristics of the project and the past project records.

Figure 2 shows a framework of CCPM. The goals consist of indexes which reflect the states of both the communication-oriented activities and the documentation- oriented activities. In the project plan, each communication density between a pair of stakeholders is assumed throughout the requirements definition process, and is used to control requirement definition activities. For example, several requirements definition activities are delayed when the high communication density is observed to avoid the excess communication-oriented activities among stakeholders beyond their capability.

A plan of total time spent for the documentationoriented activities is also made. For example, MH spent for documentation-oriented activities of each stakeholder is monitored, and the project team formation, such as the number of project staff, is changed to perform documentation-oriented activities effectively. Namely, the number of project staff is increased when the total MH spent is not sufficient to satisfy the goals. In addition, the goals would be modified when the current goals cannot be attained by corrective actions.

The CCPM uses certain kinds of information, i.e., performance measures, a project plan, and corrective actions, all of which function to control a requirements definition process at each planning period. Namely, the deviations of performance measures from a project plan are analyzed, and corrective actions are taken at each planning period if necessary.

As the performance measures, we use the rate of structured requirements (index S), which is assumed to reflect the communication density of each stakeholder, for communication-oriented activities, and the cumulative MH spent (CMH) for documentation-oriented activities. If index S is equal to zero, it means all the time in a planning period is spent for communication-oriented activities, and no system specifications are formally documented. In contrast, if index S is equal to one, it means all requirements conflicts are resolved, and all the time can be spent for documentation-oriented activities without negotiation cycles.

As a project plan, we developed a CCPP consisting of an S-CMH plan and an RDA plan. An S-CMH plan indicates progress made on index S and CMH of each stakeholder at each planning period. An RDA plan indicates when and which stakeholders start requirements definition activities on each requirements domain, which is a set of similar requirements areas where any of the stakeholders would have requirements. Modification of the plan, such as change of project team formation, shifting the period to start requirements definition activities of each requirements domain, is considered as a candidate of corrective actions when the progress of requirements definition activities deviates from the plan significantly.

Regarding index S, Ishii (2006) defines it as a ratio of total MH spent for communication-oriented activities against the total MH stakeholders hold in a planning period, based on the assumption that all the stakeholders spend all their working hours doing these tasks. However, stakeholders do not always spend all their working hours for the requirements definition activities. Each stakeholder takes a different amount of time for these activities. In this paper, therefore, we define index S for each stakeholder. In addition, we define slack time in order to consider MH spent except for requirement definition activities. Namely, we define Eq. (1) as index S of stakeholder j at the i-th period.

where MMH_i^j denotes MH spent for the communicationoriented activities of stakeholder j at the i-th period, Base_MH_i^j denotes total MH of stakeholder j at the i-th period.

MMH_i^j is obtained by adding up the communication density between stakeholder j and other stakeholders at the i-th period as denoted in Eq. (2).

where CT_i^d (j,k) denotes the communication density of stakeholders j and k on the requirements domain d at the i-th period. Namely, it is defined as CT_i^d (j,k) = (j’s MH for the communication-oriented activities to communicate with k at the i-th period)/ Base_MH_i^j. In addition, l and ns denote the number of requirements domains and the number of stakeholders associated with a requirements definition, respectively.

Base_MH_i^j consists of MMH_i^j, TMH_i^j, and Slack_i^j of stakeholder j at the i-th period as denoted in Eq. (3).

where TMH_i^j denotes MH spent for documentation-oriented activities of stakeholder j at the i-th period, Slack_i^j denotes MH which is used for other activities except for the requirements definition of stakeholder j at the i-th period. Because Base_MH_i^j is a fixed positive value, and MMH_i^j and TMH_i^j greater than or equal to 0.0 in a period, Slack_i^j takes a negative value when requirements definition activities in a planning period request the more activity time than each stakeholder has. The negative Slack indicates an unsound situation of the requirements definition phase because overtime activities are demanded in a period.

On the other hand, CMH_i^j is defined as cumulative MH spent for stakeholder j until the i-th period as denoted in Eq. (4). It indicates the progress of producing documented specifications through documentation-oriented activities.

The CCPP method makes a project plan (CCPP) consisting of an S-CMH plan and an RDA plan through the following two stages.

In stage one, a set of requirements domains and stakeholders are identified. Moreover, the dependency of requirements domains and the initial communication density between stakeholders of each requirements domain are determined. As a result, a stakeholder matrix is created. In stage two, a CCPP, which satisfies the goals of index S and CMH of each stakeholder within the shortest project term, is made based on the stakeholder matrix. In this paper, we use a simulation-optimization method (Boesel et al., 2003) to find a project plan.

The stakeholder matrix, shown in Table 1, indicates the relations of requirements domains and stakeholders on requirements definition. In Table 1, the requirements domain column indicates areas where any of the stakeholders would have requirements. The mark “+” indicates the corresponding stakeholder who would have requirements onTable 1 shows that stakeholder A has requirements on Business rule and Process domains. Dependency indicates the sequence to start requirements definition activities of each requirements domain. Table 1, for example, shows that requirements definition activities on the Process domain can be started after having started requirements definition activities on the Business rule do main. Initial communication density indicates the time spent for communication-oriented activities between stakeholders of each requirements domain at the first planning period.

Figure 3 shows brief steps for making a stakeholder matrix. The step of “Identify requirements domains and corresponding stakeholders” identifies requirements domains and stakeholders concerning the requirements definition as well as determines dependency among requirements domains.

A large number of studies have been performed in the field of stakeholder identification. Sharp et al. (1999) proposed a network-based stakeholder identification approach to discover all relevant stakeholders of a specific system. Woolridge et al. (2007) recognized stakeholders as a source of software project risk, and proposed an outcome-based stakeholder risk assessment model. Moreover, Pacheco and Tovar (2007) provided a review of stakeholder identification literature and an overview of the state-of-the-art methods in the field of stakeholder identification. In this paper, we assume that those methods can be applied to the step of “Identify requirements domains and corresponding stakeholders.”

The step of “Determine initial communication density of each requirements domain” shown in Figure 3 determines the initial communication density corresponding to each requirement domain. We assume this is determined based on difficulties of defining the requirements as well as experience, skill, and knowledge of stakeholders regarding the domain. For example, high communication density will be assumed if the requirements domain is complex, and if creating documented specifications is difficult.

In stage two, CCPP consisting of an S-CMH plan and an RDA plan is made by using a simulation-optimization method based on the stakeholder matrix prepared in stage one. Figure 4 shows an overview of the simulation-optimization method consisting of a simulation mechanism and an optimization algorithm.

In the method, the simulation mechanism evaluates index S and CMH of each stakeholder in each planning period. The optimization algorithm searches a CCPP which achieves the goals of index S and CMH of each stakeholder at the shorter project term by changing the planning period where requirements definition activities of each requirements domain start.

4.2.1 Simulation Mechanism

The simulation mechanism evaluates index S and CMH of each stakeholder in each period based on the simulation parameters, i.e., the initial communication density between stakeholders in each requirements domain; and an RDA plan indicating periods to start requirements definition activities of each requirements domain under dependency constraints.

Based on the above parameters, the simulation mechanism evaluates MMH_i^j by Eq. (2) and Eq. (5) as well as CMH_i^j by Eq. (6), which is derived from Eq. (3) and Eq. (4). S_i^j is evaluated by Eq. (1) using the MMH_i^j obtained by Eq. (2).

In the simulation mechanism, S_i^j and CMH_i^j are evaluated based on these equations in the order from i equals 1 until both S_i^j and CMH_i^j satisfy their own goal.

In Eq. (5),

denotes the convergence rate of the communication density on the requirements domain d at the i-1 th period. Namely, the communication density in each period is sequentially determined by the communication density and the convergence rate at the previous period. The convergence rate can be determined in several ways depending on the characteristics of the requirements domain, relevant stakeholders, and communication modes (Ocker et al., 1998) employed. An example of the convergence rate definition is introduced in the next chapter.

4.2.2 Optimization Algorithm

As a simulation-optimization method, a large number of approaches can be applied. For example, metaheuristic optimization algorithms (Morton and Pentico, 1993), such as a generic algorithm, a simulated annealing method, and so on, are potential candidates. In this paper, we use a simple evolutional search algorithm which improves an initial plan on a step-by-step basis under a fixed project formation throughout the planning periods. The algorithm, consisting of the following four steps, is used for demonstrating the effectiveness of CCPP and the significance of CCPM at the requirements definition phase, and thus it is not intend to achieve the global optimum plan.

Step 1: Set requirements definition activities as forward planning basis under the dependency constraints of each requirements domain. Make an initial plan by the simulation mechanism. Set the initial plan as the current S-CMH plan and RDA plan.

Step 2: Based on the current RDA plan, shift one planning period later for starting requirements definition activities of each requirements domain one-by-one, and make project plans by the simulation mechanism.

Step 3: If any improved plan compared to the current plan is found in Step 2, go to Step 4. Otherwise, set the current plan as the final plan, and terminate the algorithm.

Step 4: Set the most improved plan in Step 2 as the current S-CMH plan and RDA plan. Go to Step 2.

In Step 3, the plan which satisfies goals of index S and CMH of each stakeholder in the shorter project term is recognized as a better plan. If the project term is the same, the plan which satisfies the goals of index S in the smaller CMH is recognized as the better plan.

We apply the CCPP method to an information system development project, which implements a production planning system in a company. The system consists of functions of production planning, purchasing, and distribution planning. Organizations related to the example project are corporate management, distribution, sales, production and purchasing, and information systems. Stakeholders are managers or staff who belong to these organizations.

Requirements domains to be defined in this project are business rules, business processes, business functions, business cycles, interfaces, materials, code structures, and information systems infrastructure, feasibility studies, pre-requirements studies, and general requirements reviews. The dependency of these requirements domains is shown in Figure 5. For example, the dependency indicates that requirements definition activities for the Pre-requirements studies domain should start first among all the activities. On the other hand, the General requirements reviews should start last.

In this numerical example, goals, simulation conditions, and parameter values are assumed as follows:

5.2.1 Goals

- Index S of each stakeholder: 0.8 or more,

- CMH of each stakeholder: 10.0 unit time or more.

5.2.2 Conditions

- Dependency of requirements domains: defined as shown in Figure 5,

- Time in a planning period: 1.0 unit time for all periods,

- Initial communication density between stakeholders (CT0d (j,k): 0.04 unit time for all requirements domains d,

- Base_MHij: 1.0 unit time for all j and i,

- Slack: less than or equal to 0.0 unit time for all stakeholders.

The value of CT₀^d (j,k) is set so that MMH_i^j at the 1st period is more or equal to 1.0, if stakeholders start all the requirements definition activities simultaneously.

5.2.3 Convergence rate

In this numerical example, the convergence rate in Eq. (5) is defined as Eq. (7) applying the logistic curve under the assumptions, i.e., the convergence rate will change within a range at each planning period; the convergence rate will increase with an increase in index S corresponding to the requirements domain; and the ratio of the convergence rate increase will decrease with an increase of index S.

In Eq. (7),

denotes the minimum convergence rate of the requirements domain d. S_i^d denotes the minimum index S within the stakeholders associated with the requirements domain d at the i-th period. C^d is a parameter to control the convergence rate of d between the range of the minimum and the maximum rates, and is obtained by Eq. (8).

In Eq. (8),

denotes the maximum convergence rate of the requirements domain d.

In this example, the values of

are set to 0.05 and 0.25, respectively, so that it takes 10 periods or more to make CT_i^d (j,k) less than 0.05 for all d.

Table 2 shows a stakeholder matrix which is made based on the conditions described in the previous sections. In Table 2, the correspondence relationship among requirements domains and stakeholders is determined in consideration of the characteristics of a production planning system. In practice, the experienced system analysts play important roles in leading the requirements definition to success. Since the analysts basically work with stakeholders, we assume that they are included in each stakeholder activity shown in Table 2 in this case.

Figure 6 and Figure 7 show the S-CMH plan which indicates the changes of index S and CMH, respectively, during the 1st to the 40th planning period. In those figures, CCM indicates index S or CMH planned by the CCPP method. On the other hand, WSM indicates index S or CMH in the case of applying the wait-and-see management, where all requirements planning domains start requirements definition activities from the first planning period without considering stakeholders’ situations in each planning period as well as the dependency of requirements domains.

A and D in the Figure 6 and Figure 7 indicate the stakeholders. Stakeholder A satisfies the goals at the shortest project term. On the other hand, stakeholder D satisfies the goals last among all the stakeholders.

Figure 8 shows the RDA plan which indicates the planning period to start requirements definition activities of each requirements domain in the CCM plan. In the CCM plan, the starting period of each requirement domain is shifted forward by the optimization algorithm in order to improve index S and CMH under the constraints of requirements domain dependency. On the contrary, all the requirements domains are started at the first planning period in the WSM case.

5.4.1 Effectiveness of the Communication-Centered Project Planning (CCPP) Method

As shown in Figure 6 and Figure 7, the CCPP method reduces the period to satisfy the goals compared to that of the WSM case. Namely, stakeholder A satisfies the goal of index S at the 27th period and the goal of CMH at the 21st period in the CCM case. On the contrary, stakeholder A satisfies the goal of index S at the 34th period and the goal of CMH at the 36th period in the WSM case. Namely, stakeholder A reduces by 7 and 15 the planning period, and stakeholder D reduces by 8 and 13 the planning period to satisfy the goal of index S and the goal of CMH in the CCM case, respectively, compared to that of the WSM case.

The planning period, which satisfies the goals of both index S and CMH, is the 28th period in the CCM case and the 40th period in the WSM case. Therefore the CCM case can reduce MH spent for 12 planning periods compared to that of the WSM case.

5.4.2 Significance of CCPM

The S-CMH plan obtained as a CCPP provides further insights into management of the requirements definition phase. For example, index S is useful to monitor the situation of a requirements definition phase. The planning periods where index S is equal to zero as shown in Figure 7 in the WSM case indicate a panic situation because the time spent for requirements definition activities is equal to or more than all the time stakeholders have within a planning period. In addition, an unexpected change of index S, such as large fluctuations, constant decline, and so on, indicates an out of control situation of the process. Namely, index S can be used as a performance measure to control a requirements definition process in a healthy situation.

In addition, an S-CMH plan can provide information about the bottleneck stakeholder who affects the progress of the phase. In this example, stakeholder D is recognized as the bottleneck because stakeholder D is the last stakeholder to attain its goals. In addition, the bottleneck requirements domain can be identified by analyzing the communication density of the bottleneck stakeholder. We can say that identifying the bottleneck stakeholder and requirements domains in advance is useful to manage the requirements definition phase.

In this paper, we analyze a requirements definition process, and present a framework and mechanisms of CCPM and a CCPP with a planning method. We demonstrate the effectiveness of the CCPP and its significance at the requirements definition phase by numerical examples.

The CCPM employs index S reflecting the communication density between stakeholders for the communication- oriented activities and CMH indicating the MH spent for the documentation-oriented activities as performance measures of the requirements definition phase. Index S increases with a decrease in the communication density. Since the decreasing communication density indicates smaller negotiation time spent to resolve requirements conflicts, we assume that index S can indicate the progress of requirements definition. In addition, we make the CCPP as a project plan consisting of an SCMH plan and an RDA plan, by a simulation-optimization algorithm using a stakeholder matrix.

There are several possible future research areas for CCPM for the requirements definition phase. For example, the detailed management mechanisms, which evaluates deviations from a project plan based on index S and CMH at each planning period, and modifies an RDA plan in order to maintain the project performance, should be studied. The effectiveness of CCPP should be validated using live project data in several application areas.