Develop from Use Cases or Business Requirements

Question

I'm involved in a project where the business team created a large business requirements document that were using to create product backlog items and acceptance criteria.

However, they have also created use cases that look to contain more interaction between how they see their users interact with the software.

The business team seems to feel the use cases contain more detail with more behaviors around how their users would interact with the software.

My question is: Should we be putting more weight and time into turning the use cases into backlog items/acceptance criteria or stick more to the business requirements, or treat them equally? Is there any rule of thumb that others use?

Answer 1

Business Requirements (BR) and Use Cases (UC) are two different poles of the software development cycle (SDLC).
You have to consider both, but apply them at different times of the SDLC.

Take a look on this diagram (taken from here):

Both documents come from the customer's perspective, but apply differently:

BR essentially define primary objectives (hence the name), e.g. what the software should do. They are usually having top-down, feature-wise nature.
UC define individual cases (hence the name) how the users will interact with the system, or how the components interact with each other.

As soon as both are defined, the development team starts elaborating both by essentially moving towards each other:

• Analysts drill down to SRS and DS;
• QA team elaborate Use Cases into Test Cases;

(skipping the resource planning phase as it is not relevant to your question)

Then, at the very middle of the SDLC, the Developers bring both ends together.

Summarizing:
You can't ignore BR as they define what the software will do;
You can't ignore UC as they define how it will be tested (or, if you wish, they define success criteria for telling working software from non-working one)

Caveats:
I've seen quite a few cases when teams failed to keep both documents synchronized, assuming BR are for project start, and UC are for project end. As result, one of these docs becomes too detailed, while another is treated as "it's for the customer, not for the developers". IMHO, having these two synced at all phases lets the team detecting logical gaps early. Too valuable asset to ignore.

Answer 2

A more detailed answer, I think the business requirements document should be considered like the document that the customer (directly or through your business team) delivers so that you understand what they need. Any of the requirements will be for sure complex and hence, prone to be interpreted in a variety of ways not all of them probably suitable for what your customer needs.

In your case, lucky you, your biz team has created also the UC. I think your development team (or you) should validate both documents with an emphasis on detailing and completing the UC and mix them in a unique document (easy since both documents come from your biz team) and once this is done use both documents to involve the customer and give approval.

I don't think the UC document should be used for the development, I think it's aligned with Agile best practices to have a clear understanding of the requirements and how they will be implemented before starting to code and even when Agile focus on reducing documentation, if you have been awarded with a good BR and UC documents use them at least to start moving and plan the first releases(sprints) or prototype the User Interface. What option you choose depends on how technically savvy is your customer and how much effort do you want to invest.

Even if your customer is familiar with your development because you are going to customize and existing product of your company of has been shown other projects your company has developed the privilege of early feedback either based on a customer review of your merged document or a prototype of the UI is priceless.

Usually all this work is done internally, so why not wrapping it a little with a red ribbon and handle it to your biz team so that they help you to get the customer feedback.