Feature Articles: Software Development Technologies
Improving the Planning and Requirements Definition Process
The first process in software development is the planning and requirements definition. In this process, the stakeholder requirements must be organized, and the requirements for implementing the software must be clarified. However, many issues arise with this process in practice, and improvement is therefore needed. In this article, we introduce our activities related to improving the planning and requirements definition process, including studying trends in research and practice.
Keywords: software development, requirements definition, planning
A survey by the Information-technology Promotion Agency (IPA)  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  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).
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) *1—a requirements engineering knowledge system, ISO/IEC/IEEE*2 29148 —a standard related to requirements engineering, and the Software Life Cycle Process Japan Common Frame (SLCP-JCF) .
The first edition of REBOK was released by the Japan Information Technology Services Industry Association (JISA) in 2011. It provides a set of common knowledge shared and used by stakeholders consisting of both users and developers, and for both enterprise/business software systems and embedded software systems, except for domain specific knowledge. The requirements engineering process is shown in Fig. 1. It configures the four key knowledge areas of (1) elicitation, (2) analysis, (3) specification, and (4) verification, validation, and evaluation in an incremental and iterative way. It aims to provide appropriate knowledge to all the stakeholders involved in the requirements engineering process at appropriate levels of expertise; the stakeholders include corporate management, end-users, project managers, and software developers.
3.2 ISO/IEC/IEEE 29148: 2011
ISO/IEC/IEEE 29148: 2011 covers processes and products related to the engineering of requirements for systems and software products and services throughout their life cycle. It provides additional guidance in the application of requirements engineering and management processes for requirements-related activities in ISO/IEC 12207 and ISO/IEC 15288. It includes perspectives from areas beyond software such as the business or project that is the basis for the system and the operation of the system, as shown in Fig. 2.
3.3 Software Life Cycle Process Japan Common Frame (SLCP-JCF)
The Software Life Cycle Process Japan Common Frame (SLCP-JCF) was created in 1994 in Japan with the goal of eliminating misunderstandings among stakeholders involved in software development. It provides comprehensive regulation of tasks and roles needed in the areas of business analysis, business design and software-related planning, requirements definition, development, operation, and maintenance as well as various other related activities. SLCP-JCF 2007 was published in 2007 and incorporates the idea that there are fundamental issues to be addressed in the process from business and project planning through to requirements definition and enhancing the operation and user processes. SLCP-JCF 2013 was published in 2013, with improvements made to the requirements definition, operations, and service processes.
4. Initiatives related to planning and requirements definition
The NTT Software Innovation Center is studying the following areas related to planning and requirements definition.
4.1 Planning and requirements definition process
As stated previously, there are many stakeholders in the planning and requirements definition process. To achieve smooth communication among them, they must have a common understanding of what sorts of procedures need to be implemented, what steps need to be taken, what inputs and outputs are necessary, and what they each must accomplish with respect to the software development project.
Accordingly, we have been studying planning and requirements definition processes that clarify and standardize the procedures that must be implemented for planning and requirements definition, for defining the styles of deliverables, and for clarifying the division of roles.
Also, as discussed earlier, requirements change during the planning and requirements definition process due to changes in the environment or adjustments made between stakeholders. These changes in requirements also require changes in the schedule or functions to be realized, which have already been agreed upon by stakeholders. Consequently, we are also studying requirements management processes that enable effective management of any changes made to requirements and analysis of the effects of adopting the changes.
We believe that application of these processes we have been studying will help to advance software development projects by achieving mutual understanding among multiple stakeholders.
4.2 Study of methods and techniques used in the planning and requirements definition process
Although procedures and outcomes are decided during this process, the work could proceed more smoothly if certain know-how or skills were applied such as knowledge of writing requirements documents in ways that reduce ambiguity. We are therefore also creating and organizing examples of such know-how and skills.
4.3 Participation in REBOK Working Group (WG)
REBOK has been presented at international conferences related to requirements engineering . The English edition of REBOK is under construction in order to meet the expectations of many people in research and industry. Initiatives to support the use of REBOK are also being undertaken. We are participating in planning for the REBOK WG and are contributing to activities that promote REBOK.
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% .
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.