Summary

The website content provides an introduction to the fundamental role of business analysts in understanding, capturing, and managing requirements, emphasizing the importance of clear communication with clients who may not have a full grasp of what requirements entail.

Abstract

Understanding requirements is crucial for business analysts (BAs) as they navigate various industries and projects. The article, "Understanding Requirements — Part 1," emphasizes the challenge of explaining requirements to those unfamiliar with the concept, a task BAs must perform regularly. It outlines the basics of requirements as described in the Business Analysis Book of Knowledge (BABOK), noting that requirements are statements of needs or conditions necessary for clients to achieve their objectives. The article categorizes requirements into Business, Stakeholder, Solution, Functional, and Non-Functional types, and underscores the necessity for requirements to be platform-agnostic to ensure objective solution evaluation. The author advocates for a structured approach to requirements elicitation, hinting at a detailed exploration of the DADA model in subsequent parts of the article.

Opinions

The author suggests that even experienced BAs may struggle to articulate what requirements are, highlighting a gap in foundational knowledge that this article aims to address.
There is an emphasis on the importance of BAs being able to communicate requirements clearly to clients who may not understand them, which is a daily expectation in the field.
The author asserts that requirements should be platform-agnostic, criticizing the practice of tailoring requirements to fit a specific product or application as this may compromise the objectivity of the solution selection process.
The article takes a stance against the unethical practice of writing requirements based on pre-selected applications or products, advocating for an unbiased approach to solution evaluation.
The author indicates that the process of identifying and capturing requirements, known as the Requirements Elicitation phase, follows a set of established steps that may vary depending on the project's delivery methodology.

Understanding Requirements — Part 1

“Do question, even the basics!

You will be a fool for once!

If you don’t, you will be, for a lifetime.” – Himmilicious

Okay, here’s a little challenge for all of you BAs out there. Find someone who would have no idea what requirements are and explain the subject to them in as simple terms as possible. It’s not that easy, is it? And yet, this is something that we’d be expected to communicate on a daily basis to customers who potentially may not know or fully understand what a requirement is, or be especially clear how to express them unambiguously or accurately. Moreover, there are plenty of business analysts who are starting out (and a surprising number of more experienced BAs) who can’t confidently answer the question “What are requirements, and what have they got to do with me?” If you’re in that boat, fear not – this post is for you! Call it ‘Requirements 101’, if you will.

As business analysts, we will be expected to carry out many tasks and objectives during an assignment, but the one task that is common across any industry, organisation or business function is the identification, capture and management of requirements. This is a fundamental part of the role, and is a key deliverable for any BA. As this is a vast and complex subject, I can’t cover everything, so I’ll be aiming to give an overview of the basics in this article, and will hopefully drill down on the more detailed aspects of requirements in later posts.

At its most simple, a requirement is a tool used to clearly, accurately and unambiguously describe something that the client or customer – which may be an organisation, a function, an individual or even a system – wants or needs in order to evaluate and / or effect a desired change. Referring to the Business Analysis Book of Knowledge (BABOK), requirements can be defined as:

A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
A documented representation of a condition or capability as in (1) or (2).

This ‘10,000ft view’ forms the basis for how a business analyst needs to approach defining the “ask” from the client, and the mechanics of capturing the requirements rely on well-defined and established methods that we’ll look at shortly. However, it’s important to note that there are several different types of requirement that could possibly be captured, depending on the scenario and the business or client needs. These are broadly broken into the following types:

People, Process & Procedural (PPP) Requirements: Understanding the changes or improvements that a client – be it a function, area, organisation or individual – wishes to implement as part of their ongoing operational development, and defining the steps needed to accomplish their aims. These may be driven by market forces (for example, a competitor develops a new market leading product which the client wants to develop their own version of), mandatory changes driven by governments or regulatory bodies, or changes in the ways of working the client is looking to employ, such as outsourcing existing processes to deliver cost savings. Of course, this is a non-exhaustive list, and the reasons for change may vary significantly.
System or Product Requirements: Defining and modelling the properties of a platform, system or application, or identifying criteria required to implement a new system, or make changes to an existing system. These may incorporate technical, Functional requirements which outline the what and why of the ask and sit within a clearly defined scope, as well as Non-Functional Requirements (NFRs), which focus on the when, where and how of delivering the solution – which we’ll look at in further detail later.

Speaking of solutions, you would do well to remember this (and I’ll write it in all caps AND in bold, so you know that I’m actually making a point here);

REQUIREMENTS ARE SUPPOSED TO BE PLATFORM AGNOSTIC.

Got it? Good. I’ll explain why a little further on.

Getting back to the basics, requirements generally can be assessed as falling into one of the following categories, as defined in the classification scheme by the IIBA (www.iiba.org) in the BABOK:

Business

These are statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.

Stakeholder

These describe the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business and solution requirements.

Solution

These describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution.

Functional

These describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage.

Non-Functional

Also referred to as Quality of Service requirements, these do not relate directly to the behaviour of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have.

Speaking of solutions, I mentioned earlier the need for requirements to remain platform/solution agnostic, so let’s make something very clear; your requirements should drive the evaluation and selection of an application, product or solution, not the other way round. Too often, BAs are often pressurised into writing requirements based on delivery of a very specific product or application, which reduces or removes altogether the organisation’s ability to objectively review a set of options independent of influence. Of course, this may be case of ‘JFDI’ and you will have little choice but to produce requirements in such a way, but we should be clear that this is absolutely NOT best practice, or even, in some cases, ethical — particularly where a known/unknown conflict of interest exists.

Requirements can be gathered using a variety of different techniques, such as workshops, interviews or reviewing documentation, and can be captured in variety of ways, such as cataloguing individual requirement instances, use cases or user stories – you may even use several different techniques in combination in order to refine the way requirements are captured. Regardless of the tools used, requirements identification and capture – referred to from here on in as the Requirements Elicitation phase – will generally follow an established set of steps, which may vary slightly dependent on the delivery methodology used in your project, be it Agile, Waterfall or a combination thereof.

There’s more detail to cover but as it will make the read-time for this article quite long, I feel it best if I split this into a couple of parts. In the final part of this feature, we’ll take a look at the DADA model (Discovery — Analysis — Definition — Agreement) and how it can be used to guide the requirements journey from start to end.