Ever been in a situation where you are not given much, but need to deliver is a lot? – Not to worry, this article is here to help you!
So welcome to the world of business analysis! Sometimes you are assigned a task to write a user story or a requirements document and the information you have is very meager. I mean scant – like non-existent even! But its OK, this is where our skills as business analysts shine the most. Check out the case study below where we get into the minute fine details of how to do this!
How to write requirements given incomplete information
This case study examines a real world situation of resolving complaints funnelled in through a support ticket. It shows the steps taken to resolve highly technical problems without being given much information upfront.
Disclaimer: Though the scenario is real, all data, names, systems, products and services are fictitious.
Case Study: Tech Support Driven Feature Enhancement Requirements
You are a business analyst with River Corp. One of their flagship products is StockPro, a purchase order management system. You are given a list of support tickets that came through the StockPro’s customer support portal. These tickets were assessed and prioritized and then given to you to write technical requirements for. The list you received is shown below (Don’t worry if you don’t understand any of it because this is exactly the reaction you would have in the real world!).
That’s it. That’s all you have. Now write requirements!
Uh? – like really? That’s what you are thinking right?
You have no idea what these issues are, what steps were taken, no idea of the discussions that were held before the list got to your desk and no idea who the clients are that complained, no idea about so many things but you now have the responsibility to resolve all of it. Great – right? !
In many companies it may not be as extreme as this, there might be a more systematic handing off process and knowledge transfer to help you better understand the problem. But in face paced environments, this is fairly common. If there isn’t a formal process then you have to work in the boundaries that you are given. At a later date, if given the chance you can address the problem of fixing the process. That is a topic for another case study!
So what would you do? Where would you start?
At this point a number of questions should be racing in your mind:
- Which part of the system are they referring to?
- How to access these forms, pages and screens?
- What were the original functionality?
- Are these bugs or feature enhancements?
- Are there any dependencies within the system for the changes being proposed?
- Can these changes impact other clients using the software?
You have no answers to these questions yet, so the first thing you have to do when you have a situation where you have more questions than answers is to:
1. Fill Your Knowledge Gap
Firstly observe that even though you don’t have all the information -you at least now have SOME information. The list has a priority, comments, and the tech support name. These are all useful information that you do have. Focus on the positives.
Next: Confirm where in the system these fields are, once you find that out, then you should have a general idea what the original functionality might be. Get the technical documentation for that section of the software and read about the functionality.
2. Determine which item to tackle first
Since the list is prioritized, then that is your first indicator of what is most important. If you are not given a priority it’s a good idea to ask your boss if anything on the list is a higher priority than the others.
You might think that tackling the highest priority is the first thing to do. This can be a good idea -or not. It depends on what you can actually get done first without feeling frustrated. Tackling the highest priority is great if it’s simple, but if it is super complicated then it will just frustrate you and make you feel discouraged. If possible start with the easiest in order to get your feet wet.
In the list above, which task would you start with?
For me, it’s task 2 simply because the tech on it only has that task so I can call them up and get some background information about it.
Mark you, if you are told that the highest priority item is urgent then you have to scrap everything I just said and tackle that one first. Repeat after me: Must keep boss happy!
3. Dive into the details
I don’t want to get into too much details here but the next thing you have to do is -get into the details.
First of all you need access to the system so you can familiarize yourself with the screens and go through a request form.
Make sure you understand the real problem. Lst’s look at the ticket again, it says:
“Please make the Delivery Cost field default to “Not Applicable” for purchases made within departments”
Find the screen with the delivery cost field. Take note of the field type. Find out what “ within departments” mean. Yes I know it sounds obvious, but never take it for granted that you know what they mean.
Call up the tech support agent and ask a few questions including what is meant by “within departments”. He tells you that within departments means any internal purchase where the requester is a department within the company and the receiver is another department within the company regardless if they are in different geographical locations or not. Ooh you didn’t assume that last bit did you? Don’t assume – clarify.
Often as a BA, you think a thing is clear as day and then when you ask the subject matter expert, they throw in a few details you didn’t consider.
4. Find the real problem: Watch out for the proposed solutions!
Now that you have the details, lets look at the description again:
“ Please make the Delivery Cost field default to “Not Applicable” for purchases made at within departments”
Hmmm… doesn’t it seem a bit prescriptive? It’s telling you the solution, but did you get a handle on the problem? This is common in the BA’s world. Everyone has the solution and its natural to propose it but you need to uncover the underlying problem to make sure your solution addresses the real issue and not the symptoms. Be careful to evaluate the task you are assigned to not assume the solution in the task is the right fix.
Hopefully you got a good understanding of the problem from the tech support you spoke with. Let’s say he told you that when a value is entered in the Delivery Field for purchase orders for other departments, it overstates the expense reports for the department because of a new business rule that they do not charge for internal transfers within departments. So even though it is a cost to deliver this is to be recorded elsewhere based on the new company policy.
Ok then.
So now that you know the real purpose of this change. The screen with the relevant fields are shown below
So this case study is supposed to help train you on the business analyst’s though process to solve problems. It’s a guide so though, this is detailed try to take away from this the approach and the observations and strategies used here to solve similar problems.
So the first thing to notice on the screen shot above is that the delivery cost field that you are asked to change is not a drop down. It’s a text. Also there are two other fields that stand out and these are the “From” field and the “To” field which determine where the item is coming from and where it is going to. The tech support guy Larry, told you that if the From field selection is an internal department and the To field selection is an internal department, then the delivery cost should not be applicable. That’s what you have to implement.
4. Design the solution
Based on Larry the tech support guy’s information (which you verified) that the business policy was recently enacted to no longer report delivery cost for internal deliveries, then this changes is not a bug fix but a feature enhancement to the current functionality. Meaning its a new functionality that didn’t exist before.
Now how do you implement this? You can achieve this enhancement in several ways:
1. Update the requirements to make the Delivery Cost field default to the words” Not Applicable” whenever the From field and To field have values for internal departments
2. Create a new checkbox with the caption: ” Internal Delivery?” If checked then the Delivery Cost field will be disabled. If not checked it would function as it does today and is editable.
I personally choose option 2 because it seems cleaner to me. However it requires changes to the existing screens. You will need to create screen mockups to accompany your requirements.
5. Create Screen Mockups
Making a screen mockup of an existing screen does not have to be complicated. You can use a number of fancy tools but you can also use free tools like Paint. For this I will use Paint and Colorcop (to match the exact colors). Check this article for business analysis tools.
Here’s what my mockup looks like:
You can possible create two mockups of the two options and then when showing your requirements to you boss you can let them pick the one they like best – Instead of only showing the option you picked unilaterally, after all it’s not your software!
For me, mostly I usually prepare two mockups but first show the one I prefer to do. If they complain then I show the other one – slick right?
6. Write the Requirements
If all is well and this change does not affect any other functionality in the system and doesn’t affect any other clients then you are good! Go right ahead and write the requirements or user stories.
The requirements for this could look something this:
Business Requirement:
The StockPro user must be able to indicate if the delivery is internal on the StockPro Cost Summary screen and if so then the Delivery Cost Field must be disabled
System Requirement:
The system must disable the Delivery Cost Field if the user checks the Internal Delivery checkbox on the StockPro Cost Summary Screen. If unchecked then the system must require a value.
User story:
As a StockPro user, I want to be able to indicate if the delivery is internal so that I can determine if a delivery cost is to be entered Acceptance Criteria:
-
Verify that the StockPro Cost Summary Screen ha a new checkbox captioned " Internal Delivery?". This should be placed below the Delivery Cost field.
-
Verify that if the user selects the checkbox for Internal Delivery then the Delivery Cost field must be made inactive and prevent the user from entering a value in that field
-
Verify that if the Internal Delivery checkbox is not selected then the system must continue to require a value in the Delivery Cost field as it does today.
And there you have it!
You know what you just did? You just wrote requirements given incomplete information – congrats!
Bonus:
There is a debate about the level of granularity that should be included in user stories/ requirements. How specific should you get. Because this example is so minute, the user story got very specific down to the field type level, however there are cases when you need to use a greater level of abstraction and write the user story/requirements at a higher lever. How detailed should our requirements be is a topic for another blog post – stay tuned for that!
For the rest of the tasks in this list, look out for the downloadable complete case study coming soon.