Knowing when what you’ve asked for is exactly what you’ve asked for can be just as tricky as knowing what it is you want in the first place. And in truth, I think they might actually be the same thing. If you can describe how you might test your requirements, your test should end up being a great description of what it is you actually want; your test would then be your requirement.
A test can be thought of as three steps:
And that’s it. That’s the basic structure of a simple test. State what needs to be true and what you might need to perform the test. Describe what action needs to happen involving what you listed. And then say what you expect to be true when the action takes place.
Often, when it comes to requirements, we have the habit of just describing only a couple of those details. As a business analyst, you might only describe what it is you want, your assert. But if your developers don’t know the context of your want, they might design a solution that doesn’t apply to your client. Or, you might only end up describing what is true for your client. This isn’t ideal, as then you are leaving the analysis of what should be designed to your developers. Though they might be amazingly brilliant people, it’s your responsibility to ensure the client gets what they need or want.
It forces me to document a greater coverage of the necessary details required to explain to my development team (and often, the clients themselves) what needs to be developed.
Now, if you have some development experience, you might have recognized the structure of arrange, act, assert. This is the basic formation of a unit test you might create when writing your code. For analysts, there is a similar pattern we can use: Given, When, Then.
Given, when, then follows the same pattern as assert, act, arrange. And we can use this structure to document our requirements as tests.
That being said, our client certainly doesn’t view their wants or needs as tests. They have specific use cases in which they need a solution. So, instead of referring to our test as a test, we can call them Scenarios. Scenarios are the use cases in which our client will interact with the solution we will build for them. In these scenarios, our clients will have certain expectations and desires. As such, it’s important to capture real-world specifications and examples for our scenarios. We will speak to this idea in a future post. But for now, if I were an analyst, tasked with designing a bird that could swim, I might give my developers something like the following:
But for now, if I were an analyst, tasked with designing a bird that could swim, I might give my developers something like the following:
Scenario: Bird swims when put in a lake Given I have a bird and a lake When I put the bird in the lake Then the bird should be swimming pleasantly in the water
Of course, this is a simple example (I’m missing details like the bird should preferably be alive and the lake should not be frozen). However, I’m hoping this shows you how and where you might document those sorts of details in your own requirements. Also, you might notice, I described my requirements in terms of “a bird” instead of “a duck”. This speaks to a bigger point that we want to describe our wants, but not necessarily the solution. Our developers might indeed give us a duck to satisfy our requirements. But if you think a duck doesn’t satisfy your needs, you probably need to provide more detail
Also, you might notice, I described my requirements in terms of “a bird” instead of “a duck”. This speaks to a bigger point that we want to describe our wants, but not necessarily the solution. Our developers might indeed give us a duck to satisfy our requirements. But if you think a duck doesn’t satisfy your needs, you probably need to provide more detail on what it is you want. Don’t blame the duck! (or the developers, they are good people).
At the end of the day, it’s all about communication. As an analyst, you are the translator between your client and your development team. It’s important to capture your client’s wants, as well as the context in which they want those things. And myself, thinking of the requirements I’m going to document as tests help me do that.
PS. Structuring your requirements as tests also mean you can actually perform the test itself to verify you got what you wanted! But we’ll discuss that in a future post.
People hear and interpret things differently. You need to adjust to your audience, share the message through different avenues and repeat your message until it has been understood.Continue ...
In a traditional systems development life cycle (SDLC) project, sometimes the end result does not successfully meet the needs of the user, even though it does meet the requirements set out by the business requirements document.Continue ...
Plain and simple, software and services are used by people. And the user’s experience with those services will decide the success or failure of the enterprise that creates and owns them.Continue ...
Customers become frustrated with an online service that goes as far as filling out a form, then they click on submit and end up waiting for days, weeks or longer for their transaction to complete.Continue ...