Analyze Requirements Through the Lens of Features
Before we dive into this new chapter, it’s worth taking a moment to clarify what a “feature” actually is.
I’ve probably used the word a dozen times since the start of this Course without really defining it.
A feature is a specific capability a system provides to meet an identified need. You can think of it as an action or behavior that delivers value or benefit to the user.
This capability can also be expressed through actions the user can perform (e.g., adding products to a wish list, deleting them, and so on). The example here is simple; in practice, features are typically more detailed, but this gives you the idea.
Identify Each Requirement
Make Sure the Requirement Is Properly Expressed.
Your first step is to identify each requirement and ensure it is clearly stated. Requirements should describe the concrete functionality the system must deliver not a technical solution.
Ask yourself: is this requirement functional or non-functional?
Determine the Relevance of Each Requirement
Also make sure each requirement is truly relevant to the project.
If a requirement has no direct connection to the end product or does not contribute to meeting user needs, it may be unnecessary—and therefore removed, with Product Owner validation, of course.
Distinguish Between Updates and New Features
As you work through the requirements, identify whether each one is an update to an existing feature or a completely new need being introduced.
Most of the time, the specifications will tell you which case it is.
If not, you can either:
ask the Product Owner; or
compare with specifications from previous versions of the application.
These observations will be important later when identifying the impacts of these requirements on the Product and on Test assets.
Hold on what exactly is a test inheritance?
Think of it as a library, but instead of books you have test cases and scenarios already written for previous test campaigns. This includes both manual and automated tests.
You’ll also find data sets and environments.
Reminder: Question everything challenge every assumption!
Taking what you read at face value is surely MISTAKE number one. Don’t worry—you’ll do it, I’ve done it, and it’s completely normal! Even though we strive for near-perfection, software testers can make mistakes—but those mistakes can still bring us closer to our Goal.
This exercise may seem easy, but it must be approached with great care. Here’s what happened to me recently:
We had a new team member join the project. Highly competent in his field, he was responsible for writing the specifications.
He was tasked with updating the website images, including the homepage image.
In his analysis, he did not notice that the image he requested from the Developers was far too large for its intended placement.
Sensing trouble, I raised my hand: “Are you sure the image is the right size?” — “Yes, no worries.”
Well… during execution, right on target, the image was only partially visible, the entire site’s ergonomics were affected, and we had to go back to development.
This shows why taking everything you read or are told at face value—even after multiple people have reviewed it—will not protect you from analysis errors.
To Do This: Think 5W1H!
Here are some examples of questions corresponding to each letter:
Who: Who is involved in the subject? Who needs to trigger the feature?
What: What is it about? What are the facts, events, or processes related to the subject?
Where: Where does the subject take place? Where is it located in the system?
When: When does the subject take place? When is the feature triggered?
How: How should the evolution brought about by this requirement behave in the system?
Why: Why is this evolution necessary? What does it add to the system?
By applying this method, you ensure that you have identified the ins and outs of the requirements.
Now that all requirements have been identified and clarified, let’s move on to the next step of requirements analysis.
Define Impacts
We’ve identified the project’s requirements from several angles. Now let’s look at the impacts they will have on the system.
So what is an impact?
An impact is any change or consequence a requirement will have on one or more software features. It may involve code changes, workflow adjustments, performance improvements, or new security or implementation constraints.
This is where the requirements analysis from the Identification part of the chapter becomes very useful.
Once you have both the technical and functional consequences in mind, take a step back again—gain perspective.
Next, determine the scope of the requirement: does it only apply to what is written?
At first, this work may feel tedious, but it’s what distinguishes high-quality analysis from superficial work.
I remember a case involving an underwriting form where we were asked to increase the maximum length of the “Name” field bankers had to fill in.
You might think, “Nothing too wild.” That’s what I thought too: “Five minutes to test and I’m done…”
Except… this value was then reused by the system to generate letters sent to the customer.
Innocently, I ran the processes and—big mistake—the letter templates weren’t ready. The environment had to be restored, leaving 4 projects (including mine) impacted...
You may think, “It’s just one day,” but it was one day across four different projects—about ten people affected. Nearly ten days of lost productivity because I overlooked the impact of increasing a field by just a few characters.
So take the time to analyze the impact of each change—it will save you a great deal of time during execution.
Competition Between Requirements
Be an organized conductor don’t mix violins with tubas!
What’s the connection? Here’s the explanation!
Competition is a technique for analyzing specifications. It involves:
identifying requirements that may conflict with each other;
identifying requirements that may produce negative side-effects when implemented together.
This analysis helps determine which requirement should take priority and how to resolve conflicts.
Here’s another story I was still working on my bank mail submission tests (yes… still that):
For a new product version, customers needed to receive and submit a new letter under certain conditions. One of those conditions required them to hold a specific type of savings account, available only in French overseas territories.
But shortly before my testing phase, the project owner (project owner french wikipedia page) added a new requirement: ALL letters had to concern customers residing in mainland France (you can already see the inconsistency).
Of course, the specific savings account was only held by people living in overseas territories meaning we would never send that letter.
It was a simple case that could easily have been anticipated, but because the requirement arrived late, I rushed my analysis—and we only caught the issue during execution.
To avoid these pitfalls, here are a few tips:
Identify competing requirements: look for requirements that affect the same feature or that pursue contradictory objectives.
Analyze requirements: consider their objectives, product impact, and potential risks.
Prioritize requirements: use criteria such as user value, quality impact, or urgency.
Collaborate with the development team: understand implementation implications and determine the best resolution approach.
Document your results: update test plans, test cases, and test scenarios accordingly.
By following these steps, you’ll be able to effectively analyze competing requirements and ensure product goals are met while avoiding negative impacts on features or overall quality.
Over to You!
Context
Your first reading of the specifications is complete. You now understand the project’s stakes and objectives.
You and Andy discuss how to analyze the requirements in greater detail.
You agree to list and classify them using different criteria to make them easier to identify.
Specifications
As you review the specifications, analyze all the requirements described.
Your task is to group the requirements by Features:
by type (UI, back-office, microservice, etc.);
identify the criticality of each requirement;
link requirements to features (a requirement may relate to several features).
Summary
Identify each requirement by determining whether it is functional or non-functional, and whether it is clearly expressed.
Use the 5W1H method for your requirements analyses.
An impact is a change or influence a requirement will have on one or more software features.
Put product requirements into competition with each other—conflicts may arise, and the earlier you catch them, the more time you save.
Collaborate with your teams: if you’re wondering about a requirement, chances are someone else already has too.
You likely have many questions at this stage—don’t worry. Next, we’ll move on to writing the requirements review document.
