New Role of Requirements Engineering in Software Development


Since there are increasing needs of rapid software delivery, low development cost, and quick responsiveness to requirement changes for software development in many areas, especially in the business world, the traditional discipline of ‘requirement first’ is not valid for many types of software projects any more. Therefore, it forces us to discover new approaches to implement requirements engineering (RE) process in software engineering.


Requirements are expectations of the stakeholders or customers which specify how the software should behave. They describe the properties and feature of the required software system. Therefore, requirements provide both guidelines and constraints for software development. Requirements engineering process is a set of activities which aim to understand and identify the desires of the customers, deal with requirement conflicts and changes, and refine stakeholders’ expectations into specifications which can be feasibly implemented by software developers.

According to the paper [1], no matter what the detailed RE process is, there are some vital components in RE process.

  • Elicitation: Identify and gather sources of information about the software system.
  • Analysis: Understand the requirements of the customers including overlaps and conflicts.
  • Validation: Check whether the requirements are what stakeholders expect.
  • Negotiation: Reconcile requirement conflicts in order to reach the consistency.
  • Documentation: Document all the requirements in formal documents.
  • Management: If requirement changes occur, they should be managed carefully.


Fig. 1 The activity cycle of the requirements engineering process [1]

The relationships among these basic elements are shown in Fig. 1. In practice, the RE process iterates continuously during the software development.

New Challenges for RE

In the last century, the waterfall model has presented a great impact on software engineering. It emphasises that the system requirements should be complete and consistent before the software development process begins. Once the system requirements have been defined, no significant change is expected to occur during the software development since that may lead to restart or doom the project. In practice, it is obvious that the initial assumptions of defining complete and consistent requirements before the software development process are unfeasible, especially, for those large scale projects. Moreover, requirement changes are inevitable, since customers may obtain new visions about the problems which lead to requirement changes. Furthermore, there are also some other factors such as the business environment and policy changes which may also give rise to changes in the software requirements.

Due to those essential drawbacks, traditional discipline is no longer useful for a majority of the projects today. There are four main challenges which lead to rethinking the role of RE process in software development [1].

  • New software development approaches such as construction by configuration arise. The dominant method used in software development is reuse now, especially in the business world. Briefly, construction by configuration means assemble and integrate existing systems and components to create new systems. Therefore, the software requirements depend on not only the expectations of the customers but also the capabilities of existing systems and components.
  • Application quickly delivery. Business environment is changing incredibly rapidly. As a result, new software applications are required to be designed, implemented, and delivered as soon as possible.
  • The requirements change increasingly quickly. Due to the changing business environment, it is evitable that that new requirements may be emerged and current requirements may be changed within short intervals.
  • The consideration of return-on-investment (ROI). Based on RIO, reuse may become one of the most efficient approaches applied by most companies.

Integrating RE with system development

In order to deal with the challenges described above, RE process and system implementation should be integrated. As a guideline, Ian Sommerville [1] introduced three important approaches to tackle these problems, among which, I think concurrent RE and RE with commercial off-the-shelf (COTS) acquisition may be solutions with the most potential.

Concurrent RE

In concurrent RE, we use a software outline to start system development process. During the software development, not only RE activities including elicitation, analysis, validation, and negotiation are concurrent, but the RE process and other processes such as system design and implementation are concurrent as well. This concurrent approach is applied in agile methodologies such as extreme programming (XP) where RE and other processes are integrated.

As mentioned in the paper [1], there are three main advantages using concurrent RE.

  • Process overheads may be lower. Less time will be spent on analysis and documentation for requirements, since requirements can be captured more precisely and rapidly.
  • Critical requirements can be identified and implemented in the early stage. Communications between software engineers and stakeholders can be more efficient, because of the concurrency of different RE activities.
  • Respond quickly to requirement changes. Due to the iterative cycles of requirement identification and documentation, we can respond to requirement changes more quickly with relatively lower costs.

However, documentation will become a problem in XP, since XP software development is based on the stories and scenarios on cards. There is no formal documentation and software engineers usually discard them after implementing the system. The possible solution may be that we can extract key words and behaviors or critical services from customers’ descriptions and then document them for future uses in requirement analysis and change management.

RE with COTS acquisition

So far, COTS systems are already available in most areas. If we can successfully develop a new system using COTS systems and configure them to interoperate with each other, it is obvious that this new system will have lower development costs and quick software delivery.

There are two aspects that will influence the RE process with COTS acquisition. One is the selection of COTS system. The other is the interoperability of COTS systems.

In COTS acquisition, it is usually impossible to find one specific COTS system which matches all the requirements. However, if we identify the key requirements carefully, there should be a set of COTS systems that can fully or partly match these critical requirements. After that, we can consider adapting and extending more detailed requirements based on the capabilities of the candidate COTS systems. This process is called procurement-oriented requirements engineering (PORE) [2] and it will continue until the most appropriate COTS system is discovered.

Companies using various software systems are always concerned about the interoperability between new systems and systems that have been already deployed. From a RE perspective, the interoperability can be simply achieved by using open interfaces and standards. However, this kind of requirement is not enough to deal with practical problems [3]. Therefore, Soren Lausen [4] defined a new type of software requirement called open-target requirement, in order to lower the risk of failure in integrating COTS systems.


Traditional RE discipline of ‘requirement first’ is no more valid for many types of software project, especially, for large scale projects. Moreover, new challenges such as rapid software delivery, low development cost, and quick responsiveness to requirement changes in software development in many domains also force us to rethink the role of RE process in software engineering. Therefore, the idea of integrating RE process with system implementation arises. Concurrent RE process, which has been applied in agile methodologies such as XP, is one of the potential solutions providing quick responsiveness to requirement changes. The other one is to tackle with those demanding challenges using RE process with COTS acquisition based on reuse. Due to the changing business environment and rich resources of COTS systems, COTS acquisition is quite attractive to business companies. Although this approach is limited used in business applications, it has the potential to be extended to other domains such as embedded systems. According to the challenges and characteristics of today’s software engineering, it is arguable that integrated RE process will become popular in software development.


[1] I. Sommerville, “Integrated requirements engineering: A tutorial,” Software, IEEE, vol. 22, no. 1, pp. 16–23, 2005.

[2] N. A. Maiden and C. Ncube, “Acquiring cots software selection requirements,” Software, IEEE, vol. 15, no. 2, pp. 46–56, 1998.

[3] B. Boehm and C. Abts, “Cots integration: Plug and pray?” Computer, vol. 32, no. 1, pp. 135–138, 1999.

[4] S. Lauesen, “Cots tenders and integration requirements,” Requirements Engineering, vol. 11, no. 2, pp. 111–122, 2006.

[5] W.-T. Tsai, Z. Jin, P. Wang, and B. Wu, “Requirements engineering in service-oriented system engineering,” ICEBE 2007. IEEE International Conference on e-Business Engineering. IEEE, 2007, pp. 661–668.