Improving the Planning and Requirements Definition Process

1. Introduction

A survey by the Information-technology Promotion Agency (IPA) [1] found that although achievement levels for quality, cost, and delivery (QCD) targets for software development projects are gradually improving, a number of problems still remain.

To solve these problems, we have been focusing on improving the planning and requirements definition process of software development projects. This is the phase in which it is determined what is to be achieved by the software and what return on investment can be obtained.

The IPA survey also investigated the causes when QCD objectives were not met. It found that, from the developer perspective, 35% or more of the projects had problems at or before requirements definition, and from the user perspective, this figure was approximately 90%. In other words, many developers and users recognized problems in the planning and requirements definition process.

Generally, problems that occur in this process are due to differences between what the users really need and what the developers think they are supposed to build. If developers develop software based on a misunderstood view of what users need, the developed software will not meet user needs. As a result, all of the work up to the point where the difference was detected must be reworked. Several researchers have pointed out that the cost of this rework increases rapidly as the time it takes to discover the error increases. A recent survey [2] reported that the cost of fixing a requirement error discovered in the system operation phase costs 68 to 110 times more than what it would cost if discovered during the planning and requirements definition process (see Table 1).

Table 1. Relative cost to correct a requirement defect depending on when it is discovered.

2. Challenges of the planning and requirements definition process

Here, we discuss the various challenges that arise in the planning and requirements definition process.

(1) Diversity of stakeholders

The term stakeholders refers to the group of people who are involved in a software development project or are affected by the project. Generally, the stakeholders in such a project can be divided into users and developers. Users include end-users who will be using the software, and others such as the information technology department and management, for example, the chief information officer. Similarly, developers include software engineers, vendor project managers, and management, for example, the chief technology officer. The perspectives of each of these stakeholders are different, and they often have conflicting interests. Because of this, stakeholders sometimes have contradictory requirements, and these must be adjusted in order to reach agreement on what will be achieved with the software. Thus, as the number of stakeholders increases, dealing with the contradictory requirements in this way becomes more difficult.

(2) Changing requirements

In the planning and requirements definition process, requirements from stakeholders are adjusted, and agreement is reached on the function and performance of the software. However, these functions and/or performance may need to change in the requirements process due to omissions in the requirements or later changes in the environment. Handling such changes often results in scheduling delays or degraded quality. Also, adding requirements causes wide-ranging effects if they conflict with other existing requirements, as the existing requirements then need to be re-examined, and adjustments need to be made with the relevant stakeholders.

(3) Ambiguity in requirements documentation

Because the purpose of planning and requirements definition is to reach agreement among stakeholders, documentation of these requirements is extremely important. However, if requirements definition is ambiguous, multiple readers of a requirement may have a different understanding of what it means, or they may be confused as a result of interpreting a requirements statement in different ways.

If the stakeholders have differing expectations regarding the function that the software will have due to such ambiguity in the documentation, reworking will be necessary. For example, even if the developers follow the requirements definition, they may understand them in a way that is different from the users’ intentions because of the ambiguous specifications, and all of the work starting from the design phase will need to be reworked.

3. Standards and guidelines related to the planning and requirements definition process

Interest in the planning and requirements definition process has increased recently, and consequently, there has been an increase in the number of related standards and guidelines being published. This section describes the Requirements Engineering Body of Knowledge (REBOK) [3]^*1—a requirements engineering knowledge system, ISO/IEC/IEEE^*2 29148 [4]—a standard related to requirements engineering, and the Software Life Cycle Process Japan Common Frame (SLCP-JCF) [5].

4. Initiatives related to planning and requirements definition

The NTT Software Innovation Center is studying the following areas related to planning and requirements definition.

5. Study of the state of development

The improvements achieved at a German company as a result of initiatives they introduced are shown in Fig. 3. By performing requirements definition and other upstream processes soundly, they were successful in reducing the cost and time required for later processes, and were able to reduce the overall development cost by 27% and the development time by 36% [7].

Fig. 3. Cost and time changes of software development in (a) individual development phases and (b) overall.

We hope to achieve the same kinds of improvements by studying the planning and requirements definition processes and the techniques used in those processes.

In this study, it will be necessary to understand the issues involved in the early process through surveys and other means, and to incorporate input from those involved in actual development.

References

[1]	The Information-technology Promotion Agency, Japan, “2012 Survey of the State of the Software Industry,” Apr. 2013 (in Japanese).
[2]	K. Wiegers, “More About Software Requirements: Thorny Issues and Practical Advice,” Microsoft Press, 2006.
[3]	JISA REBOK WG (ed.), Requirements Engineering Body of Knowledge, Version 1.0, Kindaikagakusha, 2011 (in Japanese).
[4]	ISO/IEC JTC1/SC7, “IEEE Std. 29148: 2011, IEEE Systems and software engineering—Life cycle processes—Requirements engineering,” 2011.
[5]	The Information-technology Promotion Agency, Japan, “Common Framework 2013,” (in Japanese).
[6]	M. Aoyama, T. Nakatani, and S. Saito, “REBOK Manifest: Towards a Requirements Engineering Body of Knowledge,” Proc. of the 18th IEEE International Requirements Engineering Conference (RE 2010), IEEE Computer Society, pp. 383–384, Sydney, Australia.
[7]	M. Broy, “Opportunities and Challenges in Software Engineering for the Next Generation Automotive,” Proc of the IEEE 35th Annual Computer Software and Applications Conference (COMPSAC 2011), Munich, Germany.