This is a response article to the “New Role of Requirements Engineering in Software Development” article by s1214282.
Summary of the main article
In this article author mentions that the emerging trends coming from the business environment have an impact on software engineering and proposes ways of coping with them. Author states that nowadays stakeholders expect the software to be of good quality, delivered in a timely fashion and within the budget. To meet that, developing companies have to gather software requirements from the project stakeholders using one of the requirements engineering processes. By weighing the pros and cons of traditional requirements-first model with agile iterative requirements elicitation model, author states that iterative requirements elicitation model is the most applicable one for both large and small software development initiatives.
Even though on the surface the author may be by in large right, I tend to disagree with some of the points that are being made in the article.
The need for Requirements Engineering
Figure 1. Source: Applied Software Measurement, Capers Jones, 1996
As displayed by the graph above, the cost of amending the software code increases as the project progresses through its lifecycle. Projects that start developing the right software (meeting customers’ functionality expectations) as soon as possible, will face significant time and budget advantages, as the error fixing is not left until later on in the project when amendments in the code are more expensive. Therefore, I do agree with the author’s statement that it is important to ensure the requirements engineering processes are in place in the business. There are many methods of requirements engineering depending on the development processes in place in the business or the nature of the project developed. The two prominent categories of requirements engineering are requirements-first approach, where requirements are specified before coding begins, and coding-first approach, when coding starts even if the requirements are vague.
Requirements Engineering in the context of large software development
A software product may start with being born-large. For example, a new information system for NHS would have to be considered holistically from the beginning, rather than starting small with only a couple of functions and then expanding. This may be because many functions would be interdependent and have to be included in the product in the initial release. This would be to account for a large number of stakeholders that the system would cater for and environment elements, such as massive databases, that it would interact with.
Large systems such as the NHS information system would be developed for a long period of time. Possibly even several years to embrace all the variables that the system have to cover. It would also have a significant budget and therefore a lot of money on stake should the project fail. The risk management would be of the highest priority for a project this size. The decision-making process would have to take account of many risks of future errors, obstacles in NHS IT infrastructure and such. Therefore, the initial requirements engineering would have to take a long time before the plan for the development of the system is clear and ready to be implemented.
Requirements-first approach would be therefore better in the context of such a large system. It would bring structure to the development process, as engineers would have a clarity on what functionality will be developed and at which point. Clear specification would help their day-to-day decision making and make them less likely to amend the code later on. Clarity would also benefit the investors of the project. They would want to see tangible project plans with clear scope and deadlines to assess their return on them and to justify their investment. Agile methodologies may not provide such clarity. They base on code-first principle and start the development without knowing exactly what the finished product will do or look like. Agile methodologies therefore may find better use in contexts where risk management is less of a challenge.
Requirements Engineering in the context of small software development
Author states that concurrent development is better than requirements-first, as:
“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.”
This is correct however only applicable in the context of small software development. In it, analysis and documentation are not as important as time-to-market therefore limiting the bureaucracy will benefit these projects, as they will have more time to contribute to value-adding activities, such as coding. However, in the context of large systems, it is this bureaucracy that may prove to be highly value-adding, as it will diminish the project’s risk and therefore the likelihood of a costly failure.
“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.”
That is true in contexts where there are not that many stakeholders. For instance, having a customer of the product on site to advise on the development whenever needed would work for small agile teams with one customer as the main stakeholder. In a bigger context, the communication may not be as efficient, as there are many stakeholders to contact and negotiate the changes with, which agile methodologies do not make time for as much.
“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.”
Responding “quickly” and “with relatively lower cost” may be again only relevant in small development context. In large and complex systems it may be a case that changing one area of the code will trickle down into many others. Therefore it is crucial to clarify any anticipated obstacles at the requirements stage. This will diminish the likelihood of future, expensive changes.
I tend to agree with the conclusion that agile methodologies bring advantages to software development that improve the time-to-market, budget and quality of finished software products. However, in the context of large scale systems, I believe that traditional requirements engineering works better.
 Charette, R.N., 2005. Why software fails [software failure]. IEEE Spectrum 42(9). pp. 42-49.
 Damian, D. and Chisan, J., 2006. An Empirical Study of the Complex Relationships between Requirements Engineering Processes and Other Processes that Lead to Payoﬀs in Productivity, Quality, and Risk Management. IEEE Transactions on Software Engineering 32(7), pp. 433-453.
 Hofmann, H.F. and Motors, G., 2001. Requirements Engineering as a Success Factor in Software Projects. IEEE Software 18(4), pp. 58-66.
 Kolp, M., Mylopoulos, J. and Castro, J., 2002. Towards requirements- driven information systems engineering: the Tropos project. Information Systems, 27(6), pp. 365-389.
 Sommerville, I., 2005. Integrated Requirements Engineering: A Tutorial. IEEE Software 22(1), pp. 16-23.