The last twenty years has witnessed the increasing awareness and recognition of the importance of requirements engineering in software development. And a lot of methods, techniques and principles are proposed by academics to better engineer requirements. However, as a matter of fact, very few of them have been widely adopted in industry. Someprojects even skip requirements engineering entirely or partly, despite of its importance. Moreover, the role of requirements engineering hasn’t been widely accepted in industry as it should be. As a result, the current practice of requirements engineering in industry really seems to fall behind with the current academic research. What causes this big gap between academia and industry is well worth considering and studying.
Requirements engineering, usually regarded as the first phase in the software development, lays the foundation of the software to be built. It’s reported that errors in requirements usually have a bigger influence on the software and cost more to repair than errors made in other phases. Therefore, it’s worthwhile putting great efforts on requirements engineering for developing good software.
However, requirements engineering is very difficult. Requirement is perhaps the most people-oriented and least tangible concept in software development, where it largely depends on the stakeholders and they often change their minds unexpectedly. Besides, practitioners have to distinguish what features/properties the software really needs to have from what the stakeholders want and negotiate with them to resolve any conflicts. There is also a danger of misinterpretation when eliciting requirements from stakeholders, which consequently results in ill-defined or unclear requirements. With those difficulties both in nature and in practice, it’s hard to produce a great requirements specification.
From the above perspective, requirements are important and difficult to obtain accurately. Despite of its inherent difficulty, one of the top requirements problems in practice is the lack of stakeholder input. This problem, to some extent, indicates that current requirements engineering techniques and methods are not suitable or effective to produce good quality requirements, which is due to the low productivity from communications with stakeholders. Different stakeholders hold different views of requirements according to their distinguishing roles and interests for the software to be built. Therefore, requirements need to be understood from different perspectives. Hence, different eliciting strategies should be applied to different groups of stakeholders.