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.  

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.