The Buzzword Club – A simple example
Here is a simple example of an AM. It is a simple club of buzzword enthusiasts (our description will not knowingly use any) and the registrar decides who can join .o
Buzzword Club – How applications work
- An applicant submits an application stating why they should be accepted.
- A Registrar assesses the submission against the membership criteria and decides on acceptance or refusal.
- The Registrar responds by email to the Applicant with the result and also to the Webmaster to setup the new members access.
- Depending on the implementation a denial may automatically be sent to the webmaster, or only for acceptances.
- There are no membership fees and the registrar is the sole judge of acceptance based on the applicants reasons.
Example Information
Input from Applicant
Name: Astrid Ryder
Email: Astrid@ARyder.com
Reason For Membership: To meet other members and to use member privileges.
Assertion by Registrar
Specification: Decide if this person can join because they have a good reason.
Output from Registrar
Name: Astrid Ryder
Email: Astrid@ARyder.com
Application Decision: Denied
Denial Reason: The club will not benefit sufficiently from your membership
How this is shown in the model
There are two Assertions that respond to the membership decision
For one the Registrar responds to the applicant, and can be implemented automatically by assembling an email and sending it.
The other to the Webmaster will be acted upon (in this case) by no action, or for acceptances by createing an account.
There are 3 connections involved. One comes from the Applicant and this design assumes that this will be by email.
The second is by the Webmaster and this design assumes that this is automatic. A script checks the message, ensures it is from the Registrar and creates the account if it does not exist.
The third by the Registrar is manual. The registrar selects an acceptance or rejection template, plugs in the address and reasons and sends it.
Here is what the report looks like for the single Assertion:-
Here is the information provided in the report for an Assertion
Fields used in describing an Assertion
| Activity Type | eg REQUEST, FINDING, DETECTION, ASSESSMENT, DECISION, CONFERENCE, TBD |
| Attainment | Not properly defined at this point – because an attainment has not been firmly defined |
| Attainment Note | How this supports the attainment or why the Attainment is important |
| Authority Name | The Name of the Authority that makes this Assertion |
| Automatic | if false then manual |
| Currency Note | Note on if this is changed often or rarely |
| Description | Description of what the Statement is |
| Display Text | Text that shows in spec and implementation to describe the spec |
| Effort Hours | Indication of typical time necessary to perform a manual determination ( not elapsed, where wait is for a resource to do determination) |
| Financial | true if the output from this spec includes currency amount. Outputs from financial ‘statements’ are gathered in the accounting system. |
| Implementation Note | Factors on how this might be implements |
| Model Note | Notes on how this impacts the model |
| Model Level | Indication of organizational level of the spec. Typically STRATEGIC, TACTICAL, OPERATIONAL |
| Name | the name of the Spec/Statement |
| Output Note | Text to describe what the output structure and semantics is |
| Personal | true if output from this contains personal information -used for privacy |
| Record | true if output from this contains personal information -used for privacy |
| Script | scripting code that may perform automatic calculations |
| Size Note | TBD |
| SpecID | user identifier for the Assertion |
| Specification | Words to describe how a decision, assessment, finding is to be made |
| Status | A category of states that the spec goes through as it is modeled. eg INIT, or EDIT1,RAW, SKETCHED, VALIDATED, DRAFT, FINAL |
| Yearly Repeat | Indication of how often this event may occur in one year |