Requirements People Need Your Help!

The simple thing is this – write your requirement as a test. With defined inputs and outputs. Expected results and expected (and unexpected) data.

If you do this, your life will become bright, shiny, and you will live happily ever after. Or at least your software will become much much, much more reliable. And you’ll probably find out a lot of things about your ideas before you’ve invested in building unnecessary features and details.

You can do this with high level requirements, such as business goals and overall objectives, as well as with low level isolated features, and everything in between.

I think that the “everything in between” part is where we (software industry people) lacks the most care and insight about the importance of concrete, testable requirements.

When it comes to high level requirements, we may have business people who do follow up business cases & objectives, i.e. test the results of the investment, at least I have seen it done once or twice.

When it comes to very low level requirements, or micro-requirement as my friend @spindelmanne call them, TDD  do take care of it to some extent.  Such as “When renaming item x the list will keep the same sort order”. It’s hard to separate micro-requirements from real business requirements sometimes. “What is really a valid input string here?” “How should we present the date format” etc but good developers generally can make some good micro-requirements decisions.

For the “everything in between” requirements, we have a lot of work to do to make them testable. From what I know it seems as there are mainly 3 ways of communicating requirements today.

Either you’re “agile” and have a loosely defined product backlog, filled with short user stories and then not so much more information.

Or you have a heavy regulated requirements process, with hundreds of pages of use cases or “shall”-requirements. Often with abstract statements such as (from real example):  “Purchase has generated a receipt”

Or the ad-hoc requirements: “Let’s send an email to the developer telling what I need to have”.  Example:  “We need to update the purchasing order receipt page. Right now it doesn’t show the total. The total need to be there. When can this be done?”.

As a requirements analysts / project manager I have seen and practiced a way out of these three abstract, ambiguous, non-informative ways of communicating requirements. Much thanks to developers who seriously cared about taking TDD to the next level, and by having the chance to work with testers close by who taught me how to express what I want as test scenarios.

I’ll share some examples from a previous project.

A testable business requirement
I was asked by the business owner to implement a feature: “Cardholders should be able to edit the rights for a whole household to use the money on their bonus card” Since money and banking was involved, it was a bit complicated to implement.

My first question to the business owner was: “why?” and how will you know it works?”

After quite a lengthy conversation, he said that what he really cared about was that the money on the bonus account was spent. He didn’t want the money to stay on their bonus cards.

“How can we verify that this target is achieved?” I asked.
“Well.. he said. If the money is spent, then the feature works.”
“So.. when in time is realistic that we can check this..?”
“Well..  within 6 months we should have a better rate of spending the bonus money than now” he said.
“Ok. So what do you mean by ‘better’?”
“Hm…” he said. “I’d be content for now if 50% of the total money paid out to customers bonus accounts would be spent”.
“Thanks for clarifying! Our feature could help out with achieving that goal. But to achieve this, other things are involved. Customers need to know about how to share bonus money between people in their family. How will they know?  Marketing, customer service.. a lot of factors might affect if this feature is used by the customer.”

“Yes, of course. But this is what I really care about. And when you have a feature households can use, we should do an effort to inform customers”.

Good. Now we had a high level business goal, a testable business requirement.  Even though our feature wouldn’t be the sole solution to make the business achieve this goal, knowing the target for sure helped us a lot in developing the feature.

What to do when you don’t have access to the business owner? When maybe you just get a bunch of use cases from somewhere to implement?

Well, in these cases I try to define my own hypothesis about the main goal and result. “This is how I / we have interpreted the target since we don’t know” and then show for those stakeholders I do have access to. Often I do get some feedback on my hypothetical business goal statement. Even “You’re totally wrong in your assumption!!” is good to know before developing anything. And you have a reason to ask for answers.

Before testing or developing any feature, we have to know or make a clear defined assumption about  the expected result for business.

A testable middle level, user requirement
So now we knew the business goal of the feature. The feature could be implemented in many ways, with options from everything from printing and scanning paper forms to digital authorization functionality.

As a requirements analysts, turning into a  tests-before-development tester, I defined some user stories. (We did a lot of other things too to understand what solution might fit, but that’s another story).

The main “middle level” user story:
As main cardholder I want to authorize other card-holders in my family in order for anyone to use the money on the bonus account.

Before communicating this to the development team, I start to think about.. how to test this? What would I test?
I brought in a tester for a chat. The tester was busy with other assignments, but he did have a few minutes to help me out. And I asked him “How would you test this story?”
“Identify scenarios” he told me. And with some coaching I made up some scenarios. (here is just a snapshot to keep the article short)

Scenario 1: Give authorization to other cardholder in a household with only 2 cardholders.
Scenario 2:  Give authorization to other cardholder in a household with several cardholders.
Scenario 3:  Authorization process is actively canceled by cardholder
Scenario 4:  Authorization process is canceled by unplanned interruption

Then, exemplify these scenarios with Gherkin inspired syntax:
Scenario 1: Give authorization to other cardholder in a household with only 2 cardholders.
Given that:
Household has 2 and only 2 cardholders
The 2nd cardholder doesn’t currently have the right to use bonus money
Main cardholder has actively selected the 2nd cardholder
The 2nd cardholder is >= 12 years old
Expected result:
Information is shown: “You have now given authorization to <2nd cardholders full name> with SSN: <2nd cardholders SSN>.
The 2nd cardholder now has authority to use bonus.

Scenario 3: Authorization process is actively canceled by cardholder
Given that:
Household has 2 and only 2 cardholders
The 2nd cardholder doesn’t currently have the right to use bonus money
Main cardholder has actively selected the 2nd cardholder
has entered external digital identification application to authorize
shuts down the digital identification application
Expected results:
The 2nd cardholder doesn’t have authority to use bonus
Message to main cardholder: The change has been canceled.

These were just two examples. Doing this I had now:
1. A specification that can be used for testing
2. Got forced to find out the exact business rules regarding who actually could be authorized. The age limit, for instance, was discovered by defining the tests. By defining test scenarios, I got a foundation to ask the right questions to domain experts. “Can anyone be authorized?”
3. A way to at any time go back and show for who it might concern (developers, stakeholders, customer service) what exact requirements and rules we built for.

These are just small examples from a big domain, so I expect you have a lot of critique “Where are scenario x?? And those examples could for sure cover much more! And aren’t that statement a bit vague?  What does ‘actively’ mean really..?”

The point here is not to give the full picture. For that I’d need to write a book 🙂  The point is to show that by defining tests while working with the requirement, the requirement got much more explicit. We saved time for our tester, who could focus on exploratory testing when time came. We saved a lot of time for developers who actually got the information ahead development on what would be tested, and what rules should be applied, so they saved a lot of rework.

Also when having conversation with developers about the examples we modified them a bit, and removed unnecessary ones, or added missing. Some of the scenarios could even be quite easily automated while developing, which also saved us a lot of time.

So, what to do as a tester then? If you’re just not involved in creating the requirement definitions? Maybe the requirements are just handed off to you in one way or another, and when you get them they’re not testable at all?

One thing you can do as a tester, is to make an effort to be included when other people are working with requirements. Offer your help!
Only once I have been approached by a tester with this offer!

It’s always me who’ve approached testers to help me with making testable requirements.

Have you ever as a tester tried to offer your help – and seriously tried? To the guys working with requirements?  And there are much more efficient ways than to say “If you need me you know where I am”.

A tester could say something like this:  “I know I’m going to work on testing for this project a couple of months from now. Is it possible for me to see some of the requirements already now? It will help me get ramped up quicker when I’m in the project. I’m in another project right now, but still I should be able to take one or two hours to look at what you have. And yeah, incomplete use cases or draft user stories will work fine too!”

When you do get hold of some kind of requirements early in the process, take a quick look. Try to define some simple test cases or scenarios, and maybe you will get an opportunity to discuss these with the requirement analysts (or whatever role who works with the requirements).. Then why not inviting her for a lunch or a virtual coffee break (or other social excuse) over Skype in case of distributed teams?

Requirements people need your help! They just don’t know it yet. Who, if not you, will seriously invite to make their work testable? ParkArticlesTestable RequirementRequirements People Need Your Help! The simple thing is this - write your requirement as a test. With defined inputs and outputs. Expected results and expected (and unexpected) data. If you do this, your life will become bright, shiny, and you will live happily ever after. Or at least your software...
The following two tabs change content below.

Ulrika Park

Ulrika Park is a requirements geek with a passion for testing, methods, learning & the development of products & services within organizations and teams. With 15 years of experience in software development, management & business she now works at SmartBear. She believes in the synergy of people, software and quality thinking to change the world.

Latest posts by Ulrika Park (see all)