Whichever approach you take to running a change project, discovering and managing requirements is key to success. This article identifies eight steps that can apply to any approach, from waterfall to agile.

Estimated reading time: 19 minutes

Go for business value – Not blind adherence to a particular approach

The way that you undertake requirements elicitation and management gives credibility to your requirements specifications.

In order to achieve this credibility, you need to design your requirements elicitation process to deliver business value whilst being flexible enough to adapt to any software development and project management approach, agile or traditional.

This post, ‘Requirements elicitation – 8 steps to success’, outlines an approach in which the steps collectively aim to:

• Take a risk-based approach to requirements discovery, optimising the amount of effort devoted to requirements elicitation and analysis
• Understand the stakeholders and their differing perspectives
• Understand the business, architectural and technical context for the development
• Understand the problem to be solved or the opportunity to be realised
• Encourage partnerships with business stakeholders, product managers and product owners to remain focused on collecting requirements that will solve the business problems at hand
• Encourage partnerships with project management to ensure that the process is embedded in best project management practice
• Encourage partnerships between business analysts, architects, designers, developers and testers to efficiently develop effective and valuable products
• Establish benefits, risks and costs of each option for the architecture of a solution
• Deliver fast and deliver frequently
• Start with the project scope as small as possible and deliver something useful – then enhance it as needed by the business
• Discourage sacrificing speed of delivery for imagined ‘perfection’
• Accept that compromise based on rational argument is essential

This article assumes that requirements can come in many forms, e.g.

• Traditional (atomic), usually starting ‘The user shall …,’ or ‘The system shall ….’
• Use cases and scenarios
• Agile style epics and user stories
• Acceptance criteria
• Decision tables
• Requirements models, etc.

I believe that, with some fine tuning, the approach described here can be applied universally.

Step 1 – Establish an approach to requirements management

Requirements management has several aspects, including requirements identification, version management, change management and traceability. However effective your other requirements processes become, they are unlikely to count for much if you cannot manage these things. As an experiment, review some work in progress among your of your teams and then consider the following:

• Are different teams referring to the same artifact (requirement, user story, task description, model, …) by different names or identifiers?
• Are different teams each working with a different version of what should be the same requirement?
• Are developers discovering problems in requirements that you thought had been sorted out?
• Is anyone unable to answer questions from a product manager or a developer on why a particular user story is necessary?

If the answer to all or any of the above is no, then you don’t appear to have an issue at the moment. But if the answer is yes, it’s worthwhile taking a closer look.

Make your requirements management approach as lightweight as you like, as long as it’s not a ‘house of cards’.

Let’s look briefly at each of the aspects of requirements management mentioned above; these aspects are all related.

Identifiers

Unless you have an approach to requirements that avoids documenting or retaining anything, you need to have a means of uniquely identifying your requirements artifacts. A unique identifier is the minimum you will need to be able to manage any item created in the development process, including requirements in all their forms.

An identifier is typically a simple number, with no built in significance, e.g. it does not represent a cost centre or anything else that could potentially change over time; an identifier must remain constant for its whole life.

Version management and baselines

Hopefully nobody these days is working with the assumption that requirements will not change. For years preceding the agile movement, well run projects have accepted that this is not a realistic scenario. Therefore, to guarantee the uniqueness of an identifier, it needs to have a version number; your version numbering system should be as simple as possible but must be applied consistently and universally.

The version number needs to be updated whenever the associated artifact changes. And to be able to have confidence in the version numbers, you need a process, however simple and lightweight, that ensures a minimum effective control over changes to those version numbers.

When a particular version of an artifact has been approved, that version should be regarded as a ‘baseline’. Never directly alter a baseline. Instead, keep a copy of it then update the version number; you can now make changes to this new version.

You need to be able to quickly, confidently, and preferably effortlessly, roll back to earlier baselined (approved) versions if the situation demands it. To repeat, the copies of previous versions are all referred to as baselines; a baseline is never discarded.

Managing change

Managing change is sometimes referred to as change control which is perhaps an unfortunate term as it sounds as though it is a mechanism for suppressing change.

Change control is not an attempt to prevent change, but to ensure that:

• A change is not made on a whim
• All parties fully understand the impact and risks in making the change
• There are no unexpected and unwanted side effects of the change.

These things are particularly important on large and complex projects, and even more particularly in highly regulated industries.

In the early stages of a project, change is probably happening all the time and should not be bureaucratically controlled.

Once a baseline has been established, some control is necessary. If there are sound reasons for the change, business or technical, then it should be allowed to happen.

Some changes need to be applied immediately. Other changes can be batched and applied together in the next release.

Obviously, the change control mechanism should be as lightweight as possible in a given situation. You might consider having a hierarchy of change control bodies, from very informal, local boards, to more formal, programme wide boards. Such a hierarchy needs to be shallow so that decision making can be performed quickly.

Traceability

Another aspect of requirements management is traceability. Look to see if anyone on your project team is asking where certain requirements or completed software came from, querying their relevance to the product objectives or asking why a product has been built in the manner it has?

If the project is conducted in a highly regulated industry, someone will definitely ask these sorts of questions; if a requirement or software function is not needed, then it should not be there.

If you operate a lightweight development process with co-located project team members, producing software in short iterations, perhaps you have complete confidence that you can sort out issues of relevance and value as you go, as a natural part of your process.

But whether you rely on written or purely verbal communication, traceability is important. In an audit following a software disaster, it may be more than important.

Configuration Management

Requirements management is a sub-set of configuration management and similar principles apply. And yes, there are lots of tools out there reasonably claiming to be able to meet your requirements for requirement management, but if you don’t have a robust requirements process in place you are unlikely to be able to obtain the return on that investment. In the worst case, the tool gets jettisoned and perhaps wrongly blamed for the failure to deliver what you expected.

At the start of this article, I proposed taking a risk based approach to requirements. Configuration management may be considered as an aspect of risk management. It is a business matter to determine and assess risks and to develop policies and rules that reflect desired responses to risks; these policies will reflect the level of risk that an organisation is prepared to tolerate. It is presumably the CIO or IT Director who is accountable for ensuring that IT practice supports those business policies and rules.

A robust but simple and flexible requirements management process, appropriate to the criticality of your project, the nature of your industry, and the business policies and rules applicable to your organisation, should help to increase your speed of development, reduce the chances of errors and rework (waste and scrap) and facilitate the management of priorities and release candidates.

You can get this in place before writing a single requirement or building a single piece of software. And having set up a process that is as simple as possible, it can be iteratively refined in the light of experience.

Once an approach is agreed, it should only need fine tuning for each project. It should support projects, not get in the way.

Step 2 – Establish the system context

The following description has been written from the perspective of business systems rather than, say, embedded systems. I therefore tend to talk about the ‘business context’; the word business is being used very generally to include non commercial organisations. However, all systems will have a context, environment, or domain, in which they operate and within which the problem to be investigated lies.

This context will impose constraints on the solution to the problem. We refer to the ‘problem domain’ that defines the scope of the problem and the ‘solution domain’ that defines the scope of the solution. Typically we will need to progressively refine our initial ideas for both of these.

Business Problems, Objectives and Opportunities

Determination of the business context will typically involve determining the real problem, objective, opportunity or challenge that is affecting the organisation.

The problem may well be blocking the achievement of your organisation’s objectives. It is important to get to the root of the problem; this will allow you to develop a solution that offers the greatest value. This activity happens in the business domain and may occur well before there is any decision on whether or not to develop a software solution to the problem.

Opportunities do not generally last for long in today’s competitive environment. We need to act fast, making decisions about what to pursue and what to ignore.

Business (Feasibility) Study

For larger projects and where the nature of the problem or opportunity is unclear, we may well find it useful to undertake a study, sometimes referred to as a business study or, perhaps as a feasibility study.

This should be run as a project in its own right and will typically involve experienced business analysts and business architects working with business people, subject matter experts and relevant technical experts such as enterprise, data and solution architects.

The objective of the study is to get to the root, the essence, of the problem or opportunity and to recommend options for the way forward.

The business study should identify the size and impact of the problem, the areas affected and the priority for taking action.

The pace of change in modern organisations demands that such studies are quick but their recommendations must be well founded.

Business Processes, Rules and Concepts

Establishing the business context should also involve identifying which processes, rules and data you are concerned with when analysing and solving the problem.

Sometimes the problem can be the process, the rules or the data themselves. What we have called a business study may well be an investigation into the current business processes, business data or business rules.

Case for change

If the above activities suggest that there is a case for change, it needs to be developed to the point where it can influence the right people to call for the change to be made.

The case for change may have to be ‘sold’ to the organisation. This is the point at which an initial vision can be developed.

Additionally, initial ideas about the size and impact of the change can be assessed.

Continual and iterative improvement is often thought to be more appropriate, feasible and effective than radical change. The best advice is often to keep it as small, simple, understandable and as manageable as possible. There should also be a groundswell of support for the change. Pushing boulders downhill is easier than pushing them uphill.

The goals for the change, and the justification for the investment in the change, need to be clearly defined and prioritised. These might be considered as the real business requirements.

Initial Business Case

All of the above should feed into the development of a business case, which may be formal or informal depending on the circumstances.

The business case should define the benefits and value proposition which in turn should link back to the business objectives and be compatible with the organisation’s strategy.

Although IT may propose that something is a benefit, it is up to the business to accept or reject such proposals.

The initial business case should endeavour to identify the risks. assumptions, constraints costs and benefits of the change initiative.

Implementation of the change may involve one or more projects or even programmes. An initial road map for the change can be established.

Project Approach

Once the potential programmes or projects have been identified, you are in a position to clarify the objectives, scope, constraints and deliverables of each project.

You can also identify the most appropriate approach to running it.

Typically, optimising the scope means minimising it and identifying the minimum viable product.

Your chosen project approach should be determined by:

• The nature of the project
• The culture and experience of the organisation
• Known constraints.

Unless there are compelling reasons for delivering a product or service in one go, we would normally recommend taking an iterative, incremental approach to product development.

Project Management

Critical success factors for requirements discovery and analysis are very similar to those for project management. Ideally, you should integrate your project management or team leadership approach with your approach to requirements; we appreciate that some teams may have a cooperative approach to leadership and management.

Having identified the business context, your team will be able to more effectively identify the vision, objectives and scope for the desired product or service and consequently for the project that will deliver that product or service. These can be defined in the ‘terms of reference’ (TORs) for the project.

Step 3 – Stakeholder Analysis and Management

We should not normally proceed any further without refining our view of exactly whose problem we are trying to resolve; the problem owners are the stakeholders.

We need to identify and understand these stakeholders, the product owner(s) and the product manager(s). There are a number of approaches that can help you with stakeholder identification, stakeholder analysis and stakeholder management.

In any requirements elicitation initiative, it is vital that all stakeholders are identified. To miss one could well guarantee that your requirements will be incomplete or will contain hidden conflicts.

Step 3 should actually commence at some point during step 2.

Stakeholder Perspectives and Goals

It is important that we have a clear understanding of the perspectives, or viewpoints, of the various stakeholders.

If you have identified a single product owner, that is fine as long as they really can represent the viewpoint of all the other stakeholders that have a valid and relevant opinion on the matter.

If there is more than one stakeholder involved, you can guarantee that collectively they will have a variety of perspectives and a variety of opinions about the nature of the problem and the solution. You need to analyse these perspectives and work with everyone involved to reach a common understanding; this is often easier said than done.  You need to understand just how critical each stakeholder is to the project; be clear as to how much weight their voice carries.  There is a clear link between stakeholder management and project management.

This is the time to ascertain individual stakeholder goals for a solution to the problem;

• Are these individual goals conducive to the realisation of the project goals agreed so far?
• Do the goals of any one stakeholder conflict with the goals of another?

The business analysts will rely on their negotiation and arbitration skills. It is not always easy to resolve conflicting goals, but if it is not done immediately, things will get even more difficult when trying to agree the more detailed requirements based on those goals. There are recognised techniques for goal analysis and conflict resolution.

Take a look at the soft system approaches pioneered by Checkland and Wilson.

Team Building

In most projects, the team is all important in achieving a successful outcome to requirements elicitation.

Our approach to team building is to ensure that teams should contain not only business analysts, but also business people, subject matter experts, architects, developers, testers and various specialists.  This is a typical multi disciplinary team (MDT).

Such a team can become highly motivated and demonstrate great morale.

Some people prefer teams of specialists, others prefer teams of generalists; there is probably no single right answer on this one, and circumstances should suggest the best approach.

We may also define an extended team structure, ensuring that all stakeholders are effectively but efficiently represented; we include both business and technical stakeholders.

Finally, your general approach should continue to demonstrate close liaison with project management, however the management or leadership team is constituted.

Step 4 – Determining a Strategy for Requirements Specification

Specification styles can vary between the informal and the formal. They can also vary between sparse and comprehensive and between mainly spoken and mainly written. The choice of style can depend on a number of factors, e.g.

Project stage

• Early in the project the requirements specification can be very informal. Post-it notes and white card are commonly used to capture early ideas. Later in the project a fully documented catalogue of ‘traditional’ requirements, use cases or user stories, can be created. They may perhaps recorded on a suitable requirements management tool,

Risk

• What is the impact if something goes wrong with the product? What is the probability that this could happen? Is the project intended to create a strategically important customer facing product or is it to implement a simple change to a back office system? How familiar are you with developing this type of product? Is the development being done off shore or in-house? Are the business owners, analysts and developers all co-located? These are the sort of considerations that affect risk. A general rule of thumb is that the higher the level of risk, the more formal should be the approach to contain and manage those risks.

Purpose of the requirements documentation

• Are the requirements and user stories intended for a bespoke development, the purchase of a software package or for an invitation to tender? Will the requirements document be used as the basis of a contract?

Non functional (quality) requirements

• What is your approach to architecturally significant and the full range of other so called, non functional requirements?

Project approach

• Will the project be run according to a waterfall approach, an iterative, lean agile approach or some mix of these?

Company culture

• What is the preferred house style? How comfortable is the business in living with risk?

Preferred requirements style

• Do all of your requirements specifications have to be in the atomic, ‘the user shall ….’ style?
• Do you prefer use cases or agile user stories?
• Or are you happy with creating descriptions of user tasks and getting the developers and acceptance testers to work from these?

Use of requirements management tools

• Requirement specification tools typically come with their own templates although the user can usually modify the default set of requirements attributes.
• Many requirements tools also support the definition of user stories.
• Some tools are designed with agile approaches in mind.
• Some requirements management tools have direct links with test management and with modelling and other tools.

Use of models, simulations, prototypes and automatic code generation

• Is your approach to requirements specification primarily one of creating models?
• Do you build your models using tools that enable automatic generation of code and data bases?

Link with testing

• Ensure early involvement of the test team. They can help develop acceptance criteria that provide an immediate method of assessing the quality of the requirements.
• See also, Step 7, Requirements Verification.

Step 5 – Requirements Elicitation, Modelling and Analysis

Requirements Elicitation

Based on the strategy you determined at step 4, you are in a good position to select the most effective and relevant approaches to requirements elicitation. This may involve traditional or more agile techniques. Good requirements elicitation practices can be relevant to both approaches; try not to follow an unthinking, formulaic approach to selecting your preferred techniques.

To get an appropriate context for discovering requirements, ensure that you know which stakeholders, processes, data and business rules are involved in your project. This should normally be a subset of the context identified earlier.

Depending on the terms of reference of the project, continue with an iterative, incremental, top down approach, possibly leading to the development of user task descriptions, use cases, user stories and/or atomic level requirements as appropriate.

Elicitation proper will use a variety of techniques such as interviews and workshops where stories, scenarios, requirements and possibly ideas for solutions can be discovered.

Requirements Analysis

Requirements Analysis, is the process of examining the elicited requirements for correctness, relevance, ambiguity, conflict, testability, feasibility, and so on. Traditionally this has been a major aspect of requirements engineering.

These factors are still important in lightweight agile approaches where teams will seek to resolve issues with continual face to face meetings and workshops involving the whole team.

In all situations, I recommend taking an approach that encourages openness and high visibility.

Another aspect of our approach is to ensure that, where relevant, the architectural view is explored during requirements elicitation and analysis.

Decisions regarding the organisation of development teams and the interfaces between them should consider possible technical dependencies created by non-functional requirements as well as the more obvious connections based on functional dependencies.

Requirements Modelling

Modelling can be informal as well as formal.

Models can lead to the development of scenarios, simulations and prototypes to aid both elicitation and analysis.

There are also tools such as iRise that support making the user experience visible.

Step 6 – Requirements Validation

It is critical that prior to handing over the baselined requirements to design and development, you ensure that all the stakeholders understand and agree with what the requirements are saying. To this end we need an effective validation process.

Validation tries to ensure that all business stakeholders agree that the requirements will lead to the resolution of their problem(s).

When using an agile approach you will also need effective techniques to ensure that stakeholders understanding and agree with what is being proposed.

In theory, this should happen more easily because of the openness and inclusiveness of the approach. The challenges that can sometimes arise when working with human beings should, however, never be under estimated. This is where the business analyst’s tool kit of ‘people skills’ is invaluable.

Step 7 – Requirements Verification

There is a clear link between requirements and acceptance testing – verification.

Ensure that your requirements procedures are integrated with your verification or testing procedures from the outset, encouraging the testers to assist in the process of requirements analysis and specification. Often, the least effective person to review something is the person who created it.

Testers have a vested interest in thoroughly reviewing requirements and ensuring that they are testable.

Remember that if a requirement cannot be tested, then it’s not a requirement.

One approach associated with certain forms of agile is Test Driven Development (TDD).

Step 8 – Benefits Realisation

The benefits should have been described in the business case.

Although identification of benefits is a fairly common practice these days, it can be rare for any to check to see if the benefits were actually achieved; this is ‘benefits realisation’.

The business case should define when benefits can be expected to be realised. The process of managing benefits realisation should begin at this point.

One advantage of agile approaches that offer frequent delivery of products is that quantification of benefits and business value is easier for short term gains than when trying to predict what might happen years into the future.

For building financial cases, it is usually imperative to involve stakeholders from the Finance Department.

Gaining a qualification in requirements

Capiro offers course supporting the BCS Practitioner Certificate in Requirements Engineering.

Here are some preview lessons.