Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  For Requirement Experts
Previous Previous
 
Next Next
New Post 12/20/2019 7:14 AM
User is offline MadiMo
19 posts
9th Level Poster


For Requirement Experts 

Hello,

As a new person in the Business Analysis field, I got used to write the requirements accompanied with User Stories. My understanding and experience is that Users Stories are applicable and more conventional with Systems or IT field, but can they also work for Business Requirements? If someone requires a report to be have a legal agreement to receive some confidential documents by a particular team within 2 hours of an event for example, can I add the user story to the requirement or it might sound weird? 

Another question is how to Transform a Technical format Requirement into a Business Requirement? For example: I have a requirement that needs to be more System Agnostic, the requirement says: The System will allow the user to transmit the file using FTTP to the buyer.

If I am to re-write this requirement to a Business reader, the business requirement will simply read:

The purchased book will be electronically sent to the buyer.

Thank you and Merry Christmas!

 

 
New Post 12/23/2019 12:06 AM
User is offline Stewart F
96 posts
7th Level Poster


Re: For Requirement Experts 

Hi MadiMo, 

Using User Stories is more about what methodology your company uses, rather than whether a requirement fits in with being the 'right sort'. 

So, lets assume that your company does use User Stories. How do we as a Business Analyst use them for non-functional and Business Process requirements?

The answer is quite easy - exactly the same way as you would a technical requirement. 

The difference between the two is merely that one goes to a developer to do some code, and the other is that you or the process owner, puts in place a process.

Lets go through your examples and see how we would deal with them:

"Someone requires a report to have a legal agreement...etc" Lets break this down into components. What makes this whole process actually happen?

1. A report is required

2. A team needs some legal documents within a certain time frame

That seems to be the two main asks of your process. If there are other then add them in yourself. Now, with the two that we have ask yourself who is responsible for each? The first, the report, may be a technical requirement to build an automated report. If it is, then create a User Story to build this report and who should have access to it. 

The second, is that some documents need to be sent. OK, well how are they going to be sent - electronically? In which case this is probably another technical requirement. Think to yourself how are those documents to be sent, how are they to be picked up by the End User? This is likely to be another User Story. 

Your last example is also similar. You say that ultimately, your User Story will just read  "The purchased book will be electronically sent to the buyer." but, as the BA you have to define HOW it will be sent. What rules will there be, what happens if the Buyer cancels the purchase? What happens if it is out of stock? Again, this can all be included in a User Story, but there should be no gaps for a developer to 'guess' the answer and build something you don't want. 

Lastly, lets answer a question you raise about what to do with a User Story that has no technical build requirements. I.e. it is just a Business process request?

Well, these should be treated exactly the same. The difference here is that the BA (You) needs to find out who the process owner is and who will be responsible for ensuring that this process happens. Typically this will be the stakeholder that you spoke to, to get that requirement, although it doesn't have to be.

Ask them what steps they want to put in place to ensure the process is not forgotten or missed, This forms the basis  of your User Story. Make sure the steps are put in place. Your Acceptance Criteria is the gateways for the process. Get the process owner to run the test a couple of times to make sure it isn't missed. When you and they are happy that everything is in place, the User Story can be signed off. 

The thing to note here is that whether a User Story is technical in nature, a Business Process or a non-functional requirement, they still follow the same path in the User Story - they just happen to be assigned to different teams/people. 

I hope that helps, and I am sure you are on the right lines. You and your Product Owner (Or whoever 'owns' the backlog) are responsible for making sure your User Stories get done. 

Good luck and a Merry Christmas to you to.  

 
New Post 12/23/2019 1:48 PM
User is offline MadiMo
19 posts
9th Level Poster


Re: For Requirement Experts 

Hi Stewart

Thank you for the reply. What you said was very useful and inclusive in terms of the explanation, you cleared much of my confusion regarding the usage of the user story.

For the second section, what I meant is that the top management business stakeholders want the requirements to be written in a way that is more of business format despite that fact that all the requirements are Technical

So how would you change the format of a Technical Requirement and make it Business Requirement so that if you are sending this to a Business Person who does not want to deal with System or Technical format?

I provided an example and can re-instate the point as follows:

Say the requirement states the following:

The system will enable transferring of individual customers lists from one company to another if the user requests this transfer through the online portal

If I am to re-write it in a Business Requirement format I shall say

The solution will enable sharing a customer data from one company to another if the customer opted for this.

Is this correct?

Thank you very much and I appreciate your help

 

 

 

 
New Post 1/1/2020 11:39 PM
User is offline Stewart F
96 posts
7th Level Poster


Re: For Requirement Experts 

Hi MadiMo, 

I see your quandary! To be honest, what you wrote originally "The system will enable transferring of individual customers lists from one company to another if the user requests this transfer through the online portal" would probably do it. What they don't want to know is how exactly that will happen. i.e." An SQL code driven portal will transfer the data via an FTP server to a similar encoded sub system...." 

What they want to know is just the basics "a system will transfer some data to a portal where the customers can access the data..." 

So, my advice is keep to the basic facts of what will happen, not how it will happen. I would also suggest that you allow the 'Business' access to the more technical written requirements if they want to (there's always one who thinks he's up on the latest technology). 

What you need to be careful is that you don't end up with two sets of requirements. If they make changes to the business set, you need to make sure you align the technical ones with it. One way of doing this is to merge the two together. To do this, write your User Story in sections. The first is the basic ask "As a User I want...", the second is the Business Requirement - "The business want the system to transfer data to a customer Portal..." and the third is the more technical version "An SQL Code driven system needs to transfer the file ABC123 to the FTP drive Portal...."

This way everyone is viewing the same User Story/Requirements but they can pick and choose which version (Business or Technical) they wish to view.

  

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  For Requirement Experts

Community Blog - Latest Posts

Gen1us2k
Gen1us2k
Most of the IT projects imply constant cooperation between the team members and customers. Although it might be often overlooked, the role and the importance of the client within the project is very crucial. Thus, it is in your interest to build a strong relationship based on trust. However, gaining trust on a single occasion is not a dealmaker &md...
0 Responses
emorphistechno
emorphistechno
Introduction In today's world, most enterprises work aggressively to achieve a higher level of business growth, which is made possible by leveraging one of the best automation technologies. One such technology is Robotic Process Automation (RPA) that plays a vital role in streamlining the customer experience in the most profitable manner.&nb...
0 Responses
Nick Stowers
Nick Stowers
Introduction   When I was introduced to scrum, the burndown chart was a tool that was highly emphasised however I feel the purpose has changed from it being a tool to predict (to a certain level) timescales for delivery to a tool that measures a team’s productivity…..in other words, the focus is on the number of points clear...
0 Responses






Latest Articles

Copyright 2006-2020 by Modern Analyst Media LLC