It is no doubt that the requirements definition is the most critical phase for the success of a project (Browne and Rogich, 2001; Robertson
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
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
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
On the other hand,
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
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
An Example of Stakeholder Matrix.
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
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
4.2.1 Simulation Mechanism
The simulation mechanism evaluates index
Based on the above parameters, the simulation mechanism evaluates
In the simulation mechanism,
In Eq. (5),
denotes the convergence rate of the communication density on the requirements domain
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
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
In this numerical example, goals, simulation conditions, and parameter values are assumed as follows:
- Index S of each stakeholder: 0.8 or more,
- CMH of each stakeholder: 10.0 unit time or more.
- 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
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
In Eq. (7),
denotes the minimum convergence rate of the requirements domain
In Eq. (8),
denotes the maximum convergence rate of the requirements domain
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
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.
Stakeholder Matrix of Numerical Examples.
Figure 6 and Figure 7 show the S-CMH plan which indicates the changes of index
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
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
The planning period, which satisfies the goals of both index
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
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
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