A ‘requirement’ in a general sense represents something of value to the person or group that expressed it. In business analysis, requirements typically identify functions and capabilities needed from a ‘system’. Typically although not necessarily, this will be an IT system.

Estimated reading time: 12 minutes

What is a requirement in business analysis?

Requirements in business analysis can be the start point for any of the following:

• Building a system or system component
• Buying a ready made system or system component
• Creating an invitation to tender (ITT) for the supply of a computer system or system component

Whilst there is no universally agreed, ‘standard’ definition of the term, ‘requirement’, the definition from the IEEE is well known.

IEEE definition of a requirement

IEEE (Institute of Electrical and Electronic Engineers) offers the following definition:

• A condition or capability –
• needed by a user to solve a problem or achieve an objective –
• that must be met by a system or system component to satisfy a contract, standard, specification or other formerly imposed document.

The IIBA also use this definition. 

Other definitions of a requirement in business analysis

There are plenty of other definitions of a requirement in business analysis. For example, requirements are often described as ‘features’ of a ‘system’ needed by a user or an organisation.

Although a ‘system’ may be an IT application, it might also be a,

• Purely manual activity
• Business process or other activity within an organisation

What I like about the IEEE definition is the emphasis on solving a problem and realising an objective. Before proposing or acquiring a solution it is essential to understand the underlying problem.

Objectives and problems

Organisations have ‘business objectives’ and strategies for achieving them. These set the direction of travel for the organisation. Problems stand in the way of reaching the desired destination.

Organisations must establish programmes and projects to acquire the capabilities to overcome the problems and so achieve their business objectives.

Business requirements

Business requirements give the rationale for an investment in a particular capability. They explain, in ‘business’ terms, why the organisation needs it. Soren Lauesen refers to ‘goal level’ requirements. Justification of an investment in developing a requirement into a working product is also the aim of a business case. Business cases quantify the benefits, costs, risks, and impacts associated with such investment.

Project objectives and requirements

Programme and project objectives identify the capabilities that they will create. Another term sometimes used for these objectives is ‘high level’ requirements. Some people argue that lack of precision in terms such as ‘high level’ make them meaningless.

Requirements specify the details of a desired capability, i.e. its features, functions and characteristics.

Discovering the requirements

Spelling out the objectives and the problems in a way that helps to identify the actions that are needed to achieve success helps business analysts and stakeholders to ‘discover’ the requirements. This is often easier to say than to do.

Problem owners need a solution

To do it, we need to identify the people who have the objectives and the problems; these are the problem owners. They have the biggest interest in finding a solution. They will have requirements, even if they have difficulty expressing them.

The problem owners become requirements owners, also known as stakeholders. Business analysts need to work with them to understand their perspectives on the world they work in.

Even when working with the stakeholders, it is not always easy to define problems, objectives and requirements in a way that makes remedial actions obvious. A good approach is to break this task into small steps.

Solving problems

What business analysts cannot do

Business analysts are not usually able to instantly supply a ready made solution. Projects do not usually end by ‘turning on a tap’ from which benefits immediately flow.

What business analysts can do, usually

Business analysts can work with the stakeholders to identify the capability or capabilities that will allow them, the stakeholders, to solve their own problems and achieve their objectives.

Requirements describe the desired capability. The capability may be tailor made according to the requirements specification, or it may be available for purchase, ready made. Either way, it must be tested and then introduced into the organisation.

Note that even if a capability is purchased, e.g. as a ready made software product, there will usually still be a lot to do to get it operational. It’s a tool, and therefore only as good as the people who use it. The business stakeholders need to work with the tool in order to achieve the anticipated benefits.

Spelling out the problem

To make sure we identify the best tool, we need to go back to the problem. We can ask questions, such as,

• Have we clearly defined the problem?
• How big is the problem?
• What is its impact on the business?
• How much is it costing?
• What risks does the problem present?
• What are the links, if any, to other problems?
• How critical is it compared to other problems?
• What are the specific benefits of solving the problem?
• Can the benefits be quantified?

The answers to these, and perhaps other questions, will help everyone to understand what they are dealing with.

An example close to home

A problem that everyone has is that food loses its freshness, or goes off, if kept for a few days. People need a capability to prevent that. There is more than one option to solve this, e.g.

• Eat everything immediately
• Get a fridge
• Buy less food at more frequent intervals
• Keep it in a cold room

Sometimes, as with the fridge, a potential solution already exists; the project team just needs to be aware of it. And of course, they need to purchase a product that is appropriate to their situation. For example, are they buying for a home or a hotel?

The availability of a ready made ‘solution’ brings us to another consideration. Does the organisation go with that ‘solution’, or does it rethink other possible ways of solving the problem?

Innovation and projects – Eureka!

For most organisations, most of the time, if a ‘good enough’ capability exists, it makes sense to go with it. For example, car manufacturers probably do not completely rethink ways of slowing and stopping a car every time they design a new model.

To rethink everything from the ground up, seeking innovation, sounds like research. That is typically expensive and unpredictable. It’s not how most projects are run. Therefore development teams seek to create environments to encourage the possibility of achieving ‘eureka’ moments that result in innovation without adding risks to the project.

An example from a different domain

The USA wanted to explore the surface of mars. The could not say, “We need a ‘mars rover’”, because it did not exist.

So they would have had to agree on exactly what they meant by terms such as ‘explore’ and ‘surface’.

Even when the idea of a mars rover began to evolve, the team had to decide exactly

• What it needed to be capable of doing
• The characteristics (‘qualities’) of its build, e.g.
  • Surviving in a hostile environment
  • Receiving and transmitting messages in a ‘timely manner’ 200 million miles from earth
  • ….

And then there were related problems, such as,

• Getting the rover to mars
• Finding a suitable landing spot
• Landing
• Getting the little helicopter to fly in low gravity
• Preventing the rover from being damaged or blocked by rocks
• Returning the rock samples to earth

Of course, I’m guessing all this; I’m not a rocket scientist. But I’m sure that the team must have developed a detailed list of capabilities and qualities in such a manner.

And then of course there was the little matter of how to actually design, build and pay for these capabilities and qualities. These are extraordinarily complex and inter-weaved problems.

Back to earth

Although most of us will never be involved in such a complex project, there are parallels between it and the implemention of change programmes using IT, e.g.

• Defining objectives
• Determining the root problem(s)/key objectives
• Developing a set of required capabilities
• Defining the build qualities of the components
• Specifying the interfaces between the components
• Building, and paying for, the capabilities and qualities
• Coordinating the efforts of a team

Delivering the capability

Once we have spelled out the problems/objectives and identified the capability needed to solve/achieve them, we then need to consider the best way of providing that capability. From the many possible options for a solution, we need to determine the optimal one, and we need to define and justify what we mean by optimal for the situation at hand.

This is likely to mean enlarging the team, e.g. to include people from other areas of the business, from IT, or external consultants.

Developers cannot deliver a solution

The final part of a project is sometimes described as ‘delivering the solution’. In reality, as discussed above, it is delivering the means, a ‘tool’, that can be used to achieve a solution. In the end, it is the stakeholders themselves who must achieve their own objectives.

Assuming that the team working with the stakeholders has identified the right requirements, and delivered the optimal capability, the problems will only be solved if the stakeholders can use the capability effectively.

Once the capability has been delivered, there is relatively little that business analysts and developers can do to actually achieve the business goals. This is why it is usually not strictly correct to say that a development team delivers a solution. They deliver the means to achieve a solution.

Another challenge

Different perspectives

A challenge for anyone seeking to understand people’s requirements is that the problem owners, the stakeholders, are unlikely to all share the same view about the ,

• Objectives
• Nature of the problem
• Required capabilities
• ….

and so on.

The stakeholders are individuals and groups of individuals with their own perspectives, cultures, ambitions, needs and agendas. They do not all share the same idea of value.

Putting all of this together frequently results, to a greater or lesser extent, in conflict.

The business analyst as facilitator

To resolve such issues, a business analyst needs to be a great facilitator and negotiator. They need great ‘people skills’.

What’s in a name?

The difficulty in deciding what we mean by a requirement in business analysis is increased with the use of terms such as,

• Business requirement
• User requirement
• Software requirement
• Feature

and so on.

These terms are often used interchangeably. It is often a safe bet that an organisation does not have an agreed set of definitions for these terms.

The value of standards

Business analysts could lead an initiative to define a restricted set of preferred terms and definitions. They could then define how to develop and write each type of requirement.

This would be a great start to improving an organisation’s ability to develop actionable requirements. For a start, it would make it easier for a diverse team to recognise requirements when they see them.

I have always found it useful to make the list of preferred terms as small as possible; this can help to avoid overlapping terms and ‘philosophical’ discussions about meaning.

Common classes of requirement in business analysis

Probably the most well known classes, or groupings, of requirements are:

• Functional requirements
• Non functional requirements

Functional requirements

Functional requirements are what they say they are, i.e. descriptions of the functionality needed by the capability that will enable the stakeholders to achieve success. There are a number of established ways of discovering and documenting them, e.g.

• Traditional, ‘the user shall be able to ….’ text descriptions
• Use cases
• User stories
• Decision tables

There are a number of ways of writing functional requirements. This article explores five of them.

Capiro has a free mini course for learning about use cases.

Non functional requirements

Many people agree that the term ‘non functional requirement’, is pretty awful. Perhaps this is because the concept is so wide ranging that it is extremely difficult to come up with something better.

Generally, the term refers to characteristics of the build and operation of the capability defined by the functional requirements. As with the difference between a fridge for a home and a hotel. Functionally, they are presumably very similar, or they wouldn’t be a fridge. But the build qualities, size, and cost are likely to be very different. Mistakes with non functional requirements can be very expensive.

Elements of a requirement in business analysis

Requirements must contain the following elements:

• A stakeholder who has a need
• Statement of the need
• Rationale for the requirement, i.e. why the requirement is necessary
• Acceptance criteria, that is, a means of testing the delivered capability to verify that it satisfies the requirement: a requirement must be testable

Expressing a requirement in business analysis

There are many means of expressing a requirement, for example:

• ‘Traditional’ narrative description, e.g.
  • ‘The ‘user role/system’ shall be able to ….
• Use cases that,
  • identify the user role that has the need
  • provide a brief description of the function
  • typically include scenarios that describe the situations in which the function will be actioned.
• User stories that,
  • identify the user role that has the need
  • briefly describe the need
  • identify the rational for the requirement
  • state how the finished product can be tested, i.e. the acceptance criteria
    • Acceptance criteria may be written in the form of scenarios

The above means have many similarities although only the user stories have all the elements of a requirement built in. Traditional narrative and use cases must provide the rational and the acceptance criteria separately.

If the requirement involves many rules or conditions, i.e. ‘IF’ statements, then it is often clearer and more concise to write it as a decision tree or decision table.

A requirements process

A complete requirements process is likely to include at least the following activities:

• Elicitation, i.e. requirements discovery
• Analysis, perhaps with requirements modelling
• Recording (documentation)
• Independent review
• Testing
• Requirements management

There are of course various approaches, techniques and tools for executing the process. We shall cover these in future posts.

What is not a requirement in business analysis?

Requirement are not solutions

Requirements define the functions and characteristics needed from a solution. They represent a step in solving a problem.

Business rules are not requirements

All business rule experts that I have worked with or researched see to agree that business rules are not the same thing as requirements. Business rules exist independently of any project or IT system.

For example, see this post from Gladys Lam of the Business Rules Community.

Requirements should not say how to run the project

Requirements that describe the product should be separated from project management concerns. If the project is short of time, money or expertise, there are things that the requirements team can do, e.g.

• Functional requirements can be dropped or deferred
• Non functional requirements can be made less demanding, e.g. by relaxing performance requirements

Constraints and requirements

Constraints define limitations such as the time and money that is available for developing a capability. Realisation of the requirements must be possible within the constraints.

Constraints and functional requirements

Although project constraints such as time or money can affect how many functional requirements the team is able to implement, they do not actually alter the functional requirements; these are either present or not present.

Constraints and non functional requirements

Non functional requirements, such as those related to system performance, can often have a range of acceptable values. Project constraints might force the team to consider what values can be relaxed. This may of course result in a product that is unacceptable for its intended purpose.

Agile

Agile teams work cooperatively to agree what they can commit to producing given the project constraints. Whatever they produce, must be of value to the customers.

Whatever the project approach, time scale, budget, team size, etc., the requirements must describe what the customers need.

Recommended books on requirements

The following books have stood the test of time and remain highly relevant and useful

• Mastering the requirements process – Robertson
• Software requirements, styles and techniques – Lauesen
• Software requirements – Weigers
• User stories applied – Cohn