What's inside?

What's in this slide deck and why it matters

This is a primer on the role of Requirements Management and Gathering in a project for digital change, and a brief comparison between the ways prominent project management methodologies in the industry handle Requirements Management.

It's background to help you

It's a resource to help you, the reader, understand the context of why and how Artificer will be using Requirements Management to help produce a digital Solution. It also aims to highlight the differences between our use of Requirements and any previous uses of them you may have seen (from any exposure to previous technology projects or the industry broadly).

Less talk from us

By reading this primer, you're helping us to focus most of our collaborative time on listening to what your needs are, rather than us talking about what we're going to do for you.

Questions still welcome

If you still have questions, don't worry, we're eager to answer them. In the meantime, grab your beverage of choice and let's get started.

What is Requirements Management?

Some fundamental terms as we use them

Let's start with the foundational terms used during the work of traditional Requirements Management.

Requirements Management

Refers to overall discipline of planning, monitoring, analysing, communicating and controlling how a project is run to produce an output that meets Requirements; in this context, a technology project aiming to solve business problems

Business Requirements

Traditionally, it is a specific category of Requirements alongside other categories like 'Functional Requirements' and 'Technical Requirements' (more on this later). It is sometimes used in reference to all requirements of a Solution; for instance a 'Business Requirement Document' or 'BRD' may be the only Requirements document created in a project

Business Analysis

The consulting process where business processes are analysed in order to derive and confirm requirements. Specialists in the field are 'Business Analysts' or 'BAs' and the discipline encompasses all aspects of Requirements discovery, documentation, validation as well as stakeholder identification and process analysis and improvement

Project Management

The day to day operational execution of the project, handled by 'Project Managers' or 'PMs', who are educated on how to integrate Requirements Management practices into their operational management of the project

But what is a 'Requirement'?

Getting really specific for a moment

Beware the plain english interpretation

When we adopt the plain english word 'requirement' in a technology project, you would expect it simply means 'something we require of the technology'. The truth is however, use of the word 'requirement' is for lack of a more precise term.

What shouldn't be a 'Requirement'

For example, one might specify that it is a requirement for an web application to use a Python-based web framework or even more specifically use Django (a popular Python-based web framework). Adopting this level of specificity is a Solution (as distinct from a Requirement), even though one might state truthfully that 'using Python is a requirement'.

A Requirement that would be met by such a Solution would be The Solution must allow custom scripting on the server-side and use an established framework. See how this Requirement does not commit to a specific technology at the stage of defining Requirements.

It may be the clear choice of Solution to this Requirement is Python's Django framework; but you would make this technology choice as part of designing the Solution when you can see all the other Solutions and a full set of Requirements.

So how then do we define a Requirement?

It's best to think of a Requirement as a clearly expressed need that a Solution must meet, along with an outcome that meeting that need facilitates. Care should be taken not to constrain the designer of the Solution to a pre-determined outcome. It's not always clear while gathering Requirements what impacts tying one part of the Solution to a particular technology might have.

'Traditional' Requirements Management

Conventional grouping by audience

What groupings existed?

The traditional approach to Requirements Management grouped Requirements into categories aimed at different audiences. Managerial audiences were sometimes able to set broader requirements, with the details being left to technical or operational teams.

The terms adopted in these approaches are still used today, so it's worth understanding them, even if a different approach can be adopted to streamline your project.

How did it happen

The Venn Diagram adjacent shows an example of how Requirements may have historically been designed and for which audiences. In this example, the Requirements would have been segregated into these categories so that each audience in the business could confirm that the Solution was meeting all the requirements they had for it.

This information feeds into a specification; and this implies not only that Requirements are statements of how a Solution is to be built, but they are a type of test against which the resulting Solution can be measured.

Ultimately, there is no hard rule; an organisation can decide on its own approach, and many do.

When should it be done?

When is the right time to define your project's requirements?

Different Project Management methodologies mandate different approaches to Requirements Management and define Requirements at different times. Let's consider the two most popular approaches to Project Management in the software industry.

In Waterfall

In a traditional 'Waterfall' Project Management methodology, the full set of Requirements (higher and lower levels) are defined and are often organised into the traditional categories from the previous slide.

This is done to allow for consumption by different audiences within the organisation (technical, non-technical and management audiences). Project work only occurs if it aims to meet a Requirement, otherwise it is considered outside of the project's scope.

In Agile

In 'Agile' Project Management methodologies, higher-level Requirements are defined first (sometimes called an 'Epic'), and more granular Requirements are identified before discrete blocks of work (called 'sprints'). You don't necessarily know what the detailed requirements will be for each area of the solution until you start its sprint.

Which methodology is better?

Waterfall vs Agile, or something else entirely?

Which methodology works best for a given project depends on many factors, including:

• the participants in the project, their preferences and experience
• the scale and scope of the project
• the level of accountability you need to provide to executive management/investors/directors
• the type of technology project (software development vs configuration)
• the underlying complexity of the technology (after all, its hard to plan a journey into the unknown)

What approach does Artificer recommend?

It's too early to say what will be the best approach for your project. We might even propose to use a blended approach incorporating elements of the popular methodologies, or adopt a different methodology for defined blocks of work.

What is most important to understand at this stage is that whatever the approach, a set of high-level Requirements is a pre-requisite to ensuring that work performed translates into actual progress. If you proceed without defining any Requirements, you risk overlooking something fundamental and proceeding down an undesirable path. This could be an unsuitable technology choice, a poor design decision or simply incorrect task prioritisation, normally leading to wasted work.

Because we can't recommend a specific approach right now, let's go over a brief introduction to both Waterfall and Agile approaches and explore some of their benefits and pitfalls. This will help you in the future to understand why we might recommend a specific approach.

Chasing waterfalls

The traditional Waterfall software project management approach

What is it

A traditional Waterfall project management methodology has at least five stages. It starts with (1) Requirements Gathering, then progresses through (2) Design, (3) Implementation (sometimes 'Development'), (4) Verification (sometimes 'Testing') and (5) Maintenance (sometimes 'Deployment' or 'Go-Live'). Specific terminology and approaches vary across the industry.

Why it works

The waterfall model still works today because it makes it easy to estimate and forecast costs for project upfront. It's easy for consultants or developers to prevent scope creep and demonstrate the capability to adhere to a budget.

Its problem

The fundamental problem with Waterfall is that any change to Requirements identified at later stages of the project are often costly (because work must be redone) or impossible to accommodate (e.g. for technical reasons). In short, mistakes made in Requirements Gathering carry through to the entire project. You want to be confident your detailed Requirements are correct before you exit the first stage.

How it does Requirements Management

Requirements Gathering is the essential first stage of the Waterfall methodology and usually produces detailed documentation. Requirements Management is also ingrained into each stage as a way to prevent both scope creep, budget blow-out and to ensure quality and business relevance of the Solution.

The rise of the 'Agile' methodology

Agile was created to challenge the traditional approach

What is it

Agile is a group of project management methodologies designed to prevent wastage of work by allowing detailed definition of Requirements to happen iteratively while work is being performed. This happens by breaking down work into discrete and scope-restricted time periods ('sprints') and trying to get as much done as possible within the sprint.

Why it works

Project participants (including the client) are freed to respond to changes that might have happened since project start, or adapt work to take into account information that is newly discovered because of work done in previous sprints. Agile works because putting smart, motivated people together and giving them a broad direction can be enough to get great software that fits the business well.

Its problem

It sacrifices upfront planning for open-ended work that doesn't necessarily have an end date. The client is forced to trust that Agile will work faster and better than Waterfall. Contracting for a sprint can also feel like a commitment of real money for no guarantee of an outcome at a particular time; so it can be less desirable where deadlines or budget constraints apply.

How it does Requirements Management

High-level Requirements (usually called an 'Epic') are used to plan sprints. A meeting to start the sprint allows project participants define the detailed Requirements for that sprint, with the benefit of all previous sprints and giving regard to the Epic. The client will usually approve the details of the Requirements at that meeting, and then the work starts.

How are High-Level Requirements gathered?

In short, we tailor our approach to each project

The tools used

There are many tools in the toolbox to reach for when discovering Requirements. Examples of some commonly used techniques are:

• Interviews, questionnaires and process walkthroughs
• Workshops and focus groups
• Direct observation and/or job shadowing
• Document/output analysis (for instance where existing paper-based processes exist, or where specific outputs must occur)
• Process mapping and flowcharts (helpful where requirements have to be gathered by correspondence)

We might think we've got the right approach to gathering Requirements at the start, but in reality it might require a combination of these and other tools in order to get a proper picture of a project's High-Level Requirements.

Present vs Future State

Because the project doesn't exist in a vacuum, its important to keep front of mind the process of organisational change. This depends on a thorough understanding of the present state of the process, and a definition of the future state that is as defined in a manner proportionate to the complexity of the project.

What's the process like

It's a dynamic and iterative process in which it's impossible to overcommunicate or ask a bad question. It's all about discovery and thinking about the way things are and they way they should be. Challenge your assumptions and biases, ask 'why not'; basically dare to dream, and the worst case scenario is that you come up with a Requirement that you later have to abandon.

What do Requirements look like?

Lets paint a visual picture of some example requirements

You can, in theory, write your Requirements in any format, as long as you remember that a well-defined requirement should clearly articulate:

1. what stakeholder's need should be met by the Solution
2. what outcome does meeting the stakeholder's need facilitate/achieve
3. (and if applicable) how well, by reference to any objective qualitative measures, the outcome should be achieved

User Story Format

The User Story format has become one of the most dominant Requirements formats in many domains of software development and implementation; it's easy to write and to relate to. Here are some examples of User Stories in a table for an accounting software system.

Requirements and their role in QA

How well-defined Requirements drive quality assurance

Requirements and Acceptance Testing

The gathering of Requirements feeds into the area of Acceptance Testing, which is critical to defining an acceptable outcome for both the service provider and the client. By defining outcomes at the Requirements Gathering stage, you enable the creation of a framework for testing the final product, which aims to provide an objective basis for determining whether the final work product is acceptable or not. This framework starts to be defined more as a Solution Design takes shape. Lets now explore briefly how Solution Design contributes to good testing and its relationship to the Requirements.

Solution Design and Test Scenarios

The best way to think of the Solution Design is that it provides the specifics of how the Solution will meet the Requirements (and achieve the outcome). Once you have identified what the Design will be you can write a Test Scenario. A Test Scenario is a series of steps that can be taken in order to achieve the outcome outlined in the Requirement.

A well-written Test Scenario will therefore achieve two things:

1. It will utilise the components of the Solution Design; and
2. It will confirm that those components work to achieve (or further the achievement of) the outcome

You can think of a Test Scenario as a more detailed version of the outcome component of a Requirement that specifically explains how the Solution Design component can be tested to show how it contributes to meeting the Requirement.

Why Test Scenarios matter

How we use them in Quality Assurance

An Agreed Procedure

Test Scenarios are an agreed procedure to follow when Acceptance Testing of the Solution occurs. If there is no agreement on the Test Scenarios before the Solution is produced, then users testing the Solution may end up testing for functionality that was not supposed to be produced or configured under the Solution Design.

A way to avoid disputes

This is where most vast majority of disputes occur in technology projects. It's usually enough of a change for a stakeholder to adapt to a new way of doing things. If they aren't provided some guidance as to the way the functionality is supposed to work, they might feel like the Solution isn't meeting their need simply because it's not following a familiar process.

This is less of a problem in less complicated solutions, but provides tangible benefits as soon as complexity starts to emerge in the Design.

Getting users involved early

This underlines the importance of getting stakeholders involved early in the definition of Requirements, and then again in the definition of Test Scenarios when the Solution Design is produced. A lot of time can be saved by being disciplined about producing good and agreeable Requirements and Test Scenarios.

When Test Scenarios are Defined

Waterfall and Agile differ in their approaches

Unfortunately not all project management approaches call Test Scenarios the same thing, and they also differ on when the Test Scenarios are produced.

In Waterfall

In a waterfall approach, we take the view that Test Scenarios are best produced alongside the Solution Design during the Design Stage. However, we have seen some service providers wait to produce them during the Build stage to avoid incurring detailed prototyping during the Design stage. It ultimately depends on the nature of your project as to when Test Scenarios are best defined.

In Agile

Agile tends to group together all the planning (other than high-level Requirements) at the start of each sprint in a dedicated meeting. So definition of Test Scenarios for the sprint should occur no later than at the planning/sprint meeting. Some Agile projects don't define Test Scenarios at all, and instead just discretely 'Unit Test' the outputs of each sprint. That's all part of the manifesto of Agile; doing what works for your project rather than strict adherence to a defined procedure.

What approach we take

We tend to favour more discipline when it comes to producing discrete Test Scenarios than other providers we have seen. That being said, common sense should prevail when working with a set of really well defined Requirements. If the Requirements are accompanied with straightforward outcomes and the Solution Design is uncomplicated, then time can be saved by using the Requirements themselves as Test Scenarios.

This is party why User Stories have been so successful as a format for Requirements. Because well drafted User Stories, taken together with the Solution Design Documentation give you all the components you would have in a Test Scenario.

We therefore make a judgment call, taking into account the complexity of the Solution and the level of detail provided by the Requirements, as to whether it is appropriate to create discrete Test Scenarios. If we consider them appropriate, we will include them as a Deliverable in a Statement of Work.