The importance of requirements

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.

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.

You may also be interested in this article relating to setting and achieving goals.

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.