Building the Security Model with Use Case and Class Models

Featured
18342 Views
2 Comments
11 Likes

Building the Security Model with Use Case and Class ModelsIn 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 – mark.a.monteleone@sbcglobal.net.

Like this article:
  11 members liked this article
Featured
18342 Views
2 Comments
11 Likes

COMMENTS

Lexaux posted on Wednesday, June 13, 2012 8:28 PM
Thanks for posting.
baldrick posted on Thursday, June 14, 2012 4:01 PM
Nice and straightforward, except that there is appears to be a bit of magic happening between the use case mapped to classes step.

Another thing one might consider adding to the class model, are the business constraints between the classes. How many of each class participate in each relationship, for example? Are there certain instances that do not apply to the relationship?
Only registered users may post comments.




Latest Articles

The Core Question about Building Better Software
Apr 14, 2019
1 Comments
In recent years, agile software development has been the classic example of this pursuit of magic solutions, so I’ll use that as an example here...

Copyright 2006-2019 by Modern Analyst Media LLC