Detailed BRS

The Detailed Business Requirements Specification document outlines the requirements as they are identified in the subject area (this is described as part of the BPM document) in detail.

Step by step processes for the requirements are found in this document using Use Case full dress descriptions.

 

We collect two sets of requirements:

• Functional requirements, relating to the functioning of the system, and are documented as Use Cases. They are things the system must do.
• Non Functional requirements, specific the characteristics of a system as a solution such as, reliability, scalability, performance, mean time between failures etc.

Why doing it?

Without requirements how do you know:

• what needs to be build, designed, coded.
• when you are finished building it.
• how you build it is correct

Audience

The audience of this document is typically the “Business” being the stakeholders and the reference groups. They provide input on what the existing business processes are and agree with the document content.

UML Elements

Use Case Models, the most common used models within the UML and is uses to provide context to how the business works it outlines the scope boundaries in outside (actors) and inside (use cases). Its intention is to diagram the functions, roles and deliverables.

Use the WAVE concept:
W – Does the use case describe WHAT to do, not how to do it?
A – Is the use case describe from the ACTOR point of view?
V – Does the use case include VALUE for the actor?
E – Is the flow of events an ENTIRE scenario?

 

Although the model is used for requirements gathering the actual use case description is where the detail sits. What the requirement is and how it has to work is described in the Main Success Scenario (MSS) also known as basic path. It is a good way of doing it but it has limitations that if it gets big it can become complicated and that is where we can use Sequence Diagrams, the Sequence Diagrams are compiled by the Solution Architects.