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)
Basics
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.
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
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
Mastering the Requirements Process
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.
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.