In writing a business requirements document (BRD), the business analyst needs to document who can access the solution (assuming software) and what data can be created, updated, read, and deleted (CRUD). In other words, a security model that a security analyst can build access profiles with the appropriate privileges. This article provides the business analyst a method for documenting a security model in the BRD based on information extracted from Use Case and Class models. This security model consists of three matrices with traceability from stakeholders to the data entities that they need to create and/or manipulate:
-
Stakeholder / Use Case Actor Matrix
-
Use Case Actor / Use Case Matrix
-
Use Case / Data Entity Matrix
Note: this article assumes that the reader understands use case and class models.
A necessary component of the business requirements document (BRD) is the security model (nonfunctional requirement). The business analyst can utilize two models, Use Case (functional requirements) and Class (data requirements), for this purpose. To illustrate this, this article utilizes a use case and a class model for a Student Record System as an example. Note the models in this article are high-level in order to focus on the information needed to build the security model (i.e., only the use case diagram, not its description, is depicted here).
Student Record System Analysis
During the analysis of a student record keeping area for a university, the business analyst discovers the following stakeholder goals through interviews and facilitated meetings:
-
professors create, read, update, and delete student course grades
-
department heads create, read and update student transcripts (not delete), and read student course grades
-
students read their course grades and transcripts
-
students also create, read, update, and delete campus interests
The business analyst also notes the following business rules:
-
only professors maintain student grades*
-
only department heads maintain student transcripts
-
and transcripts are never deleted**
The business analyst documents the goals in a use case diagram under the constraints of the business rules. In Figure 1, a context bias use case diagram is shown. The diagram exhibits the boundary of a proposed Student Record System with several use cases (goals) and the associated actor roles. Besides the use case and actor associations, the business analyst also documents generation-specialization associations between the respective roles:
-
Grade Reader and Campus Interest Creator
-
Grade Reader and Grade Creator
-
Grade Reader and Transcript Reader; Grade Reader and Transcript Creator (through inheritance)
-
Transcript Reader and Transcript Creator
Figure 1. Student Record System – Use Case Diagram
Security Model – Three Matrices
Together with the use case diagram, the business analyst builds a Stakeholder / Use Case Actor Matrix associating stakeholders with the needed actor role to accomplish their goals (“x” in the intersecting cell); see Figure 2. Note a stakeholder can have multiple roles.
Figure 2. Student Record System – Stakeholder / Actor Role Matrix
Along with the above matrix, the business analyst also builds an Actor Role / Use Case Matrix which can be read off the use case diagram. The “x” in the intersection cell associates actor roles with use cases.
Figure 3. Actor Role / Use Case Matrix
(Note if there is an additional business rule that limits professors to maintaining grades only for students in their classes, the business analyst needs to reference this rule within the Create Grade use case description.)*
The third and final matrix for our security model is the Use Case / Class matrix. For this matrix, the business analyst documents the use case data needs in a Class model. The business analyst draws information for the Class model from the use case descriptions (not shown) via a noun analysis of the use case scenarios.
Figure 4. Student Record System – Class Model
From the data defined in the Class model and how the data are manipulated in the use case scenarios under the constraints of the business rules, the business analyst builds a Use Case / Class Matrix associating Use Cases with the Classes that they create, read, update, delete (CRUD); see “C,R,U,D” in the intersecting cells on Figure 5.
Figure 5. Use Case / Class Matrix
(Note absence of “D”, for StudentTranscript Class per business rule)**
Traceability
From these three matrices (Figures 2, 3, 5), a security analyst can build the required security access profiles. The matrices provide a security model with forward and backward traceability (Figure 6) that a security analyst can use to link each stakeholder who needs access (use case actor) through each functional requirement (use case) to the data (class) that the stakeholder needs to create and/or manipulate.
Figure 6. Forward and Backward Traceability – Security Model
Summary and Special Note
This article provides a business analyst a method for documenting a security model in the BRD. The model consists of three matrices based on information extracted from Use Case and Class models. A security analyst uses the security model to build access profiles with the appropriate privileges. Note: This article does not address the security approach of securing all data or only securing sensitive data. Regardless of the approach, the matrices still apply. In addition, it is a best practice that access profiles have expiration dates. This ensures that the security analyst reviews the profiles for validity on a scheduled basis. Typically, the security organization determines the security approach and recommends expiration dates.
Author: Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance, and certified in BPMN by BPMessentials. He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business. Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – [email protected].