Response article to the “New Role of Requirements Engineering in Software Development”

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.


[1] Charette, R.N., 2005. Why software fails [software failure]. IEEE Spectrum 42(9). pp. 42-49.

[2] Damian, D. and Chisan, J., 2006. An Empirical Study of the Complex Relationships between Requirements Engineering Processes and Other Processes that Lead to Payoffs in Productivity, Quality, and Risk Management. IEEE Transactions on Software Engineering 32(7), pp. 433-453.

[3] Hofmann, H.F. and Motors, G., 2001. Requirements Engineering as a Success Factor in Software Projects. IEEE Software 18(4), pp. 58-66.

[4] Kolp, M., Mylopoulos, J. and Castro, J., 2002. Towards requirements- driven information systems engineering: the Tropos project. Information Systems, 27(6), pp. 365-389.

[5] Sommerville, I., 2005. Integrated Requirements Engineering: A Tutorial. IEEE Software 22(1), pp. 16-23.

One thought on “Response article to the “New Role of Requirements Engineering in Software Development””

  1. I agree that we need Requirements Engineering and Agile development methodology is bring advantages to software development  because it provides opportunities to assess the direction of a project throughout the development lifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a potentially shippable product increment. By focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology is described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction.The Agile methodology is a disciplined approach to managing projects or product development where there is still considerable uncertainty and ambiguity at the early stages of the project. It enables you to start “now” and work with what’s certain and unambiguous and progressively move the  “uncertain and ambiguous” items  to the “certain and unambiguous” work queue.The Agile methodology is a defined process that makes it easier for a project team to deal with complexity and coherence using an incremental discovery approach.The Agile methodology ensures that the limited resources in a project are always allocated to tasks that represent the “high business value” workThe Agile methodology ensures that the time between the idea and the delivery has a short feedback loop to enable any corrections to be made early. The longer the feedback loop the greater the cost of the corrections times a multiplier effect. This short feedback loop enables quick and early adaptations to business changes.The Agile methodology reduces churn and replaces it with a steady predictable rhythm (cadence). This steady predictable rhythm reduces variability in the work and improves the teams productivity and quality. This steady predictable rhythm aids and improves the quality of decision-making. This steady predictable rhythm enables the team to build and work to predictable realistic schedules that are more likely to be met 99% of the time than the artificially set, mandated from the top, unrealistic schedules that are least likely to be met and cause untold disruption to projects time, cost, productivity and quality. The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can develop software at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” is less likely to impede a team from making progress. And because a team’s work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world. Agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to continuously replan their release to optimize its value throughout development, allowing them to be as competitive as possible in the marketplace. Development using an agile methodology preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released.

Comments are closed.