A strong model supports a range of perspectives. If the Assertion Model is to inform business decisions it must be consistent and complete. Here is a checklist for reviewing a View (a subset of Assertions managed together for information gathering and reporting)
Delineating the View
An Assertion View will usually address the attainment of an organizational goal ( such as registering a member, or managing an incident). In preparing a modeling initiative the identification of the Views are part of the scoping activities. Scoping Assertion Models will be elaborated elsewhere. Usually a View will be constrained by the information needed to reach a goal. A governance Assertion will delineate the goal. The governance assertion will provide a set of criteria for determining is the goal is reached and to what level of success. Usually there will be a set of milestones or information states (produced by an Assertion) that demonstrate a sequence of Assertions and the flow of information.
In Assertum
With management participants identify a set of governance assertions that guide and measure the View.
Refinement Checklist
Here are a set of items to review to ensure the Assertion Model you are building is fit for purpose.
Authorities have full descriptive names and clear definitions. For the modeling initiative an SME should be identified as the spokesperson for that role. They will sign off that the Assertions identified for that role are accurate and feasible. The Authority must be role and not a job description. If a person with a specific job description typically fills the role that should be identified. Often roles are categorized by other business factors; so there might be a registrar for a particular region, for example.
□ Authorities are identified for all Assertions in the View.
Both the Accountable and Responsible Authority(Role) are named and defined for all Assertions. For signoff the business person identified as the SME for the Role should sign off on the Responsibilities section.
In Assertum
Inspect the HTML Full Model for the Responsibilities section. The Assertions assigned to each Role are shown. Any Assertions assigned to the tbd Roles should be resolved. Use the RACI report in Firmstate3 to inspect how responsibilities are assigned.
□ Orphan Authorities are Identified
An ‘orphan’ is an Assertion that does not have an information flow into it. Or an Assertion that does not have a flow out. In practice some Assertions legitimately have no formal information flowing into them (All assertions may have informal information sources such as email, verbal, or observations). But these should be checked to ensure that there is not actually information that the responsible role receives. Similarly, Assertions that have no connected downstream assertions have trouble justifying their existence. In many cases these Assertions feed outside the scope of the View itself. If well-specified the ‘ending’ Assertion will be the one that indicates the level of success of failure.
In Assertum
Orphans show up well in the Sparx diagrams ‘Rendered’ for the View. Also scrolling in the detailed assertions section of the HTML Report will show if there is no output or input visible for the Assertion.
Add notes in the Input Targets or Output Targets field to explain.
□ External Authorities are identified
Some Assertions produce information that is passed out of the View (to other departments, or outside the organization). These flows are an important part of the business description and must be resolved by adding external Assertions that accept the flows. It may not be possible to even partially specify what the external authority will do with this information. However, the information passed should be specified.
In Assertum
Add an new Assertion into the Assertions List. The naming rule for Assertions is a challenge in this case (Normally Assertions should be named the information they produce). Probably the best name is ‘Organization X Business Decisions’ . For information flows in, the name of the Assertion is clearer. It is the information received.
Both these Assertions should have the Model level set to EXTERNAL.
□ The determination method (Automatic, Augmented, or Manual) is identified for all Assertions in the View
The default is Manual ( with neither the Automatic or Augmented combo box checked) . Manual Assertions are determined entirely by the Authority (usually using email etc) . If some of the information is provided from an existing app the method should be set to Augmented. This means that the Authority must access the app which assists or augments how the Assertion is determined.
In Assertum
Select Automatic if the Assertion can be calculated automatically with no assistance from the Authority (As the Authority they are responsible for the information produced and therefore the correctness of the algorithm or business rule used. With Automatic unchecked the Augmented checkbox can be chosen if there should be assistance in delivering the information for the determination. Also some determinations are ‘configurations’ where the output is a complex arrangement. If support in arranging and inspecting the result is to be supplied then the Assertion is ‘augmented’. Some modelers refer to this as automated.
□ Preliminary Sizing is Identified
The sizing values ( Manual Effort Hours, and Yearly Repeat) adds significant information to the decisions arising form using the Assertion Model. Particularly in apportioning modeling and implementation effort where it will have the most effect. They are considered very approximate orders of magnitude values. use the Repetition Note and Effort Note to annotate these to show assumptions. When this is identified for the goal Assertion it may be possible to decide further modeling effort should be applied elsewhere.
□ Discrepancies and Anomalies are identified in the Model Note
As modeling progresses there may be additional information necessary or a modeling approach that requires addressing. Use the model note to explain these situations.
□ Information Flows Are Identified
In addition to the source and target of the flows, the information passed is of paramount importance. In early modeling this may be a single name for the collection of information passed. As refinement progresses the data definitions become clearer, more concise, and more complete until they can be used to perform data design activities.
The information is passed in Frames from one Assertion to another. This Frame is a schema that provides the meaning to the values passed. Rarely, it could be a single value such as ‘Is Approved’. Or it may be a table of rows with columns defined. It is the structure of this Frame that dictates what populated screens may shown the Authority, and what fields they are expected go complete.
When modeling, some Assertions are difficult to pin down and starting more structured questions about the information itself (including example values) can help clarify the Assertion itself.
In Assertum
When an Assertion is created a prompt asks for a name for the Assertion. This is not a verb defining the effort occurring ( as it is in a process model). It is a qualified noun that describes the statement made by the Authority. As a rough first approximation this name can be the same as the name of the Frame. It is the Frame name that is shown on diagrams to indicate what information is passed. This name is used to populate the data type for the frame and any attributes for the datatype.
The Frames Tab is used to specify the details of the information. Further information on the frame itself can be added in the Frame Note field. By default one text Attribute is included with the Frame. Some Frames such as those that deliver a report do not have a detailed information structure (it is implied by the template of the report itself). A ‘primitive’ type of DOCUMENT can be indicated. When it is important to identify if the information supplied meets a certain standard a boolean value(true or false) can be added. For a report this may be ‘Approved’ and will be used by receiving Assertions to begin downstream determinations.
□ Determination Process is Described
The way the Assertion is determined is described. This description elaborates on how the Authority will determine the outputs. For example a responsible role may confirm information using phone calls, online research or emails before providing an assessment. When the determination must be carefully controlled the Specification field is used to give explicit guidance to the responsible Authority. This value is necessary to ensure clarity of the model.
□ Assertion Identifiers are Unique
The SpecID field is an identifier at the discretion of the modeler. A numbering system should be established for the modeling initiative and the values provided should align with the agreed system. For example certain views will be given a 2 letter prefix and then me numbered consecutively. In Firmstate3 a view can be renumbered automatically starting from a selected upstream Assertion.