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
31 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
119 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
31 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
119 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

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC