Requirements Specification and Modeling – BRD, Attributes
1. Specification and Modeling
Although this is a BA activity, we should acknowledge what it is and what it implies in order to work better with the deliverables – requirements documents, diagrams, models, etc.
The specification and modeling of requirements is related to analyze the expressed stakeholder desires and/or the current state of the organization using a combination of textual statements, matrices, diagrams and formal models. The views of the requirements for the new business solution should be comprehensive, complete, consistent, and understood from all stakeholder perspectives.
1.1 Tools and Techniques
The following are the top tools/techniques suited for performing this activity and they should be known by all the team roles in order to take full advantage when interacting with a requirement specification.
Diagrams and Models – UML, BPMN.
These text or graphics are a simplified representation of the reality. The use or disregard of them is determined by the audience for the information to be modeled as well as the level of detail in a particular model. UML and BPMN are part of the most used languages and notations for diagramming requirements.
Useful for identifying, describing and validating stakeholders interface needs. The prototyping tools are infinite and the possible approaches are:
- Deciding to use a Throw-away VS Evolutionary / functional prototype
- Deciding the functional scope of the prototype as Vertical (depth) VS Horizontal (navigation)
Scenarios and Use Cases - UML
Describe how an actor interacts with a solution to accomplish one or more of the actor’s goals, or to respond to an event:
-Scenario → One way in which an actor can accomplish a particular goal.
-Use case → All the possible outcomes of an attempt to accomplish a particular goal that the solution will support.
1.2 Business Requirements Document – aka “BRD” – and Requirements Attributes
Nowadays, the term “BRD” is related to the document where the requirements are listed and fully detailed. Other names we may find are “Functional Specification” and “System Requirements Specification/Document”– aka “SRS” or “SRD”. The difference is on the level of technical information described: theoretically, the BRD should only contain the requirements in terms of the business – what is required, instead of technical information – how to achieve it.
Regarding the attributes, the information documented on them helps the team efficiently and effectively make tradeoffs between requirements, identify stakeholders affected by potential changes, and understand the impact of a proposed change. Some of the most commonly used include:
1.3 Highlights for each team player: