Requirements Engineering – an Introduction

Requirements engineering is a term that covers a variety of methods and approaches which share the objective of improving the quality and delivery of requirements.

It includes:

requirements gathering

the initial identification and documentation of requirements


requirements management

tracing the requirements through to the completion of an IT development to verify their delivery.

This article is an introduction to requirements engineering.

Brief History

Requirements have always been part of IT development but a specific discipline arose from problems that were identified.

The Standish CHAOS report (1995) quoted the following issues as challenging projects:

1. Lack of User Input 12.8%

2. Incomplete Requirements & Specifications 12.3%

3. Changing Requirements & Specifications 11.8%

4. Lack of Executive Support 7.5%

5. Technology Incompetence 7.0%

6. Lack of Resources 6.4%

7. Unrealistic Expectations 5.9%

8. Unclear Objectives 5.3%

9. Unrealistic Time Frames 4.3%

10. New Technology 3.7%


Problems related to requirements make up 37% of project problems. ‘Lack of User Input’ is included as this causes significant problems with requirements.

Another study quoted in Managing Software Requirements: A Use Case Approach (Addison-Wesley Object Technology Series) identified the relative cost of fixing errors in an IT project from the requirements phase through to building and beyond into maintenance.




A requirement should simply be a clear and measurable statement of user need. If we look at this statement piece by piece, it provides an indication of why it can be so challenging.

What is ‘user need’?

It is easier to describe what it is not. For example, if it describes some aspect of the behaviour of the system, it is not a user need and is the user’s idea of a solution. If in doubt, it is best to keep asking the question why (or variations) until the underlying requirement is understood.

To borrow an example from Use Cases – an Introduction,

the user is credit checked when opening a bank account.

This appears reasonable but when we ask ‘why they are being credit checked?’, the answer is only customers who have a good credit score should be able to open an account. If we ask ‘why is a good credit score important?’ then the answer is to exclude customers who have a low likelihood of default on any loans.

The underlying requirement is:

accounts should only be offered to customers who are unlikely to default on loans (i.e. have a low credit score)


This topical (but fictional!) example shows it is worth persisting to understand the real, underlying requirements.

Otherwise, the business analyst does not really understand the business objectives and strategy. The analyst cannot work effectively without this understanding.

Also, it proves very difficult to assess both the quality and ‘fit’ of the design and verify (or test) the final product’s ability to support the requirement if they have not been uncovered.

What is ‘clear and measurable‘?

Clear means unambiguous and there are many different ways in which we can write requirements that are ambiguous.

It is impossible to verify that a requirement has been satisfied in the final product if it is not measurable.

There are many techniques to gather the requirements and ensure the quality which include use case modelling which is covered here – Use Cases – an Introduction.

For more on requirements quality, see Requirements engineering and quality



Non-functional requirements (for more detail, see Non-functional requirements article)

Non-functional requirements (also known as constraints) describe the desired characteristics or properties, not the actual behaviour. It is crucial these are also traced through to and satisifed by the solution and can, in some cases, require significant effort (and cost) to be supported.

The business may request:

system is available 24 hours a day, 365 days a year.

This can be very expensive and, in reality, most businesses don’t actually need this level of availability to their systems and couldn’t justify the expenditure. It would be critical, however, for software that manages power stations and the additional engineering cost would be justifiable. The business analyst should question and challenge whether this is the real requirement.

If the business provides access to their products through the internet then this will allow 24 hour access but it would not (normally) be deemed critical that access is provided at 4am on a Wednesday morning. In terms of priorities, it would be desirable but not critical. The business analyst will question to determine whether somethig less than 24 hour availability is required.


Requirements management

The other component of requirements engineering or requirements management is traceability. It is crucial to demonstrate during and after an IT development that, as well as the requirements being of high quality, they will be delivered (design and build) and they have been delivered (test).

Requirements exist at many levels of detail. The highest level relate directly to the business objectives and strategy. Further requirements provide more detail on the specifics of the business objectives and can be traced back to the highest level of requirements.

Tracing into design and build

It is necessary to trace the detailed requirements into design artefacts which may include:

  • Use cases – provide a narrative descrbing how the users will interact with the system in support of the requirements
  • Technical documents – these detail the solution specifics and come in many forms (e.g. interaction diagrams, physical data model)


Prioritisation of requirements enables discussions about cost and also supports business change which is inevitable in any project which lasts longer than a few months.

This will arise due to a number of reasons (examples only):

  • changes within the competitive environment
  • changes within the organisation itself (technical or business)
  • regulatory changes.

Any project which doesn’t recognise the inevitability of change and plans accordingly is destined to fail. It is possible to remove or defer some requirements using the priority which provides contingency to absorb critical requirements that arise later in the project.

It is important to have effective techniques available to prioritise requirements on a project – if it is left to the business to decide,  the majority will tend to be critical! There are many techniques avalable which use, for example, voting systems or a notional amount of money which the stakeholders can choose to ‘spend’ on their preferred requirements.


Word of warning

Although it is critical to the success of a project to produce high quality requirements and trace them through to delivery, that does not make it desirable to document all requirements to the nth degree at the outset. It is all about timing – at the start of the project, it is important to understand the scope of the project and high level requirements. Insisting on all the detail at this stage will only lead to ‘analysis paralysis’ and cause the project to stall.

A risk-based approach is preferable where the whole scope is sketched out initially and the most challenging or critical areas of requirements are tackled first. The detail of the requirements are drawn out area by area and, if an iterative approach is followed, it is possible to deliver parts of the system early. This is the most effective way of identifying necessary change – it is often not until the users see an actual functioning system that they provide the richest feedback and identify what they really wanted 😉

As you can see requirements engineering and requirements management covers a wide variety of concerns.

Thank you for reading this article, please make comments if you have questions, disagree or wish to discuss further


Related Books

Writing Better Requirements compact and easy read which covers writing quality requirements and verifying. Also, lightweight introduction to requirements gathering.

Mastering the Requirements Process robust Volere method for creating quality requirements and very explicit methods. Greater detail on requirements gathering. Also deliver an excellent course.

About Alex Papworth

12 Responses to “Requirements Engineering – an Introduction”

Read below or add a comment...

  1. alexpapworth says:

    I’ve certainly found this to be the case. Often there is a desire to impose a change freeze to control costs which is strongly resisted. We need to move away from controlling change to managing change. All change costs and can affect timescales but if you give the business the tools, they can make informed decisions about change. My preference is adopting agile approaches which embed change into the process.

  2. Robert Sprigge says:

    Changing Requirements

    I’ve seen projects where a list of ‘requirements’ was frozen for 18 months. However Business is not frozen – it changes every day and it’s unrealistic to believe otherwise, whatever some Project Managers may think.


  1. […] Establish requirements (see Requirements Engineering – an Introduction) […]

  2. […] representation of the project life cycle. It should be read at the start of the V (top left) with user requirements, follow the V down to code and back up to Acceptance testing (top right).  Acceptance testing can […]

  3. Business Analyst Document Templates…

    Requirements Engineering – an Introduction |…

  4. […] requirements (see Requirements Engineering – an Introduction) […]

  5. […] management skills, to help implement and/or improve requirements processes and practices and to define, for a given initiative, the tasks to be performed, the techniques to […]

  6. […] with offshoring, not least the quality of the analysis that arises and risks that arise (see Requirements Engineering for an explanation of costs incurred by poor […]

  7. […] representation of the project life cycle. It should be read at the start of the V (top left) with user requirements, follow the V down to code and back up to Acceptance testing (top right).  Acceptance testing can […]

  8. […] The initial task for the business analyst is to create a requirements plan which will determine the team required, the stakeholders , other involved parties and the approach to be taken.  The business analyst’s responsibility though the remainder of the project is often referred to as requirements engineering. […]

  9. […] The remainder are often overlooked. It is very important to devote the effort extracting these as they can be critical to the project success and a significant contributor to cost which will increase if they are identified later in the project (for more information on costs attributed to late identification of requirements, see Requirements Engineering – an Introduction) […]

  10. […] and consultant. I have read and commented on one of his books in one of my articles (see Requirements Engineering Part 1). Ian’s presentation style was engaging and interesting. It was fairly obvious he was […]

Leave A Comment...