In the previous post “Requirement Classification Schema – How to create a SRS template”, we already know components of a SRS Template. In this post, we’ll cater for details of the first 2 classifications of requirement: Business Requirement and Stakeholder Requirement.
With Business Requirement, as it’s just overview of the system, and the main audience is end user, I would recommend writing with normal style. However, it should specify why the system is build, and what it can do. For example: Deriving from the fact that many officers who have to work outside of the office can’t access the current Intranet File Shared system to get their CAD design, a need of having a new system arises. The new system is Internet-based which allows officers outside to upload, search and download CAD design files using their laptop, Ipad or mobile.
For Stakeholder Requirement (or High Level Requirement), everything is modelled for better depicting overview of the system. Hence, let’s get used to with model-related definitions first.
According to BABOK ver 3 (IIBA, 2015), under 220.127.116.11. Model Requirements, there are 2 modelling formats (Matrices for uniform structured but complex requirement and Diagram for hard-to-express-using-word-requirement) and 5 modelling categories (People and Roles, Rationale, Activity Flow, Capability and Data and Information). Normally, we will see both 2 formats but not all of categories under Stakeholder Requirement.
There are some common components under the Stakeholder Requirement:
- Entity Relationship Diagram: to show relationships between all entities (including actors and objects) within the system. Actor is normally a group of users (person/ people), but it can be system as well (in case of integration or scheduled job). For object, we will take into account both main objects and not-main objects (or so-call master data). In short, we take note Relationship between Actor and Object.
- Permission Matrix: to show which actor can perform which action in which condition. In short, we take note Relationship between Actor and Action.
- Workflow Diagram: to show the workflow within the system such as approval/review process.
- State Transition Diagram: to show the change in state of an entity during its workflow.
- Use Case Diagram: to depict which actor can perform which actions (or so-call use cases) and the relationships between those actions. In short, we take note Relationship between Actor and Action, Actor and Actor, and Action and Action.
- Sitemap: to navigate user from Homepage of a system/ solution to each functional area/ module.
(Note: There are many systems which don’t have workflow (thus do not have State Transition Diagram as consequence). However, Entity Relationship, Permission and Use Case Diagram exists in every system.)
The above components’ name implies their own modelling formats: Matrices (for Permission Matrix) and Diagram (for the others). But how about the categories?
Definition of each category is stated in BABOK ver 3 can be used as a clue:
- People and Roles: models represent organizations, groups of people, roles, and their relationships within an enterprise and to a solution.
- Rationale: models represent the ‘why’ of a change.
- Activity Flow: models represent a sequence of actions, events, or a course that may be taken.
- Capability: models focus on features or functions of an enterprise or a solution.
- Data and Information: models represent the characteristics and the exchange of information within an enterprise or a solution.
Now, let’s map each component to its modelling category:
1 – Entity Relationship Diagram belongs to Data and Information category.
2 – Permission Matrix belongs to People and Roles category.
3 – Workflow Diagram belongs to Activity Flow category.
4 – State Transition Diagram belongs to Data and Information category. Quite simple, State is data, not action or event.
5 – Use Case Diagram belongs to Activity Flow category. For me, this relationship is quite ambiguous. While Activity Flow represents a sequence of actions, events, or a course that may be taken, Use Case Diagram seems to show all functionalities that the system provides along with actor who can perform them. Should it be Capability category instead? I used to question myself until I see the very important point under Use Case Diagram: it also shows relationships between use cases. On the other hand, you might know how to achieve a goal: it might need many sub-use-cases to complete a use case, and the Use Case Diagram shows us that. This point also differentiates the Use Case Diagram from Permission Matrix (as they are quite similar in purpose, when both show the relationship between actors and actions).
6 – Sitemap belongs to Capability category.
After knowing the purpose also modelling concept of each component, we’ll soon find out the way to create them. There are many tools BA can use to draw these diagrams such as Microsoft Visio, Lucidchart, etc. (for matrices, we can just use table feature of Word or Excel). BA can also draw online, I sometimes do it on draw.io website. But to really draw them, we have to use some techniques:
- To draw Entity Relationship Diagram, we use Data Modelling Technique.
- To draw Permission Matrix, we use Roles and Permission Matrix Technique.
- To draw Workflow Diagram, we use Process Modelling Technique.
- To draw State Transition Diagram, we use State Modelling Technique.
- To draw Use Case Diagram, we use Use Cases and Scenarios Technique.
- To draw Sitemap, we use Functional Decomposition Technique.
As each technique is not easy and I can’t just explain them in some simple sentence, I’ll entail each technique along with the related components in the next posts.
- IIBA. 2015. BABOK. Version 3.0.