Basic tools – Checklists
We will start with a simple checklist to demonstrate the basics of goal-based approach. Checklists are simple lists of items to be checked to satisfy a given goal. A pilot has to go through a before-takeoff checklist before taking off. Many more checklists are used in aviation and they are also used in other industries. What is nice with checklists is that they explicitly define items to be verified.
We will consider a simple checklist for computer data backup. Similar checklist may be used to control if the backup process ensures data recovery in an event of IT system infrastructure failure.
We will develop the checklist in a systematic way using the goal-based approach. The first step is to define the main goal. This is a critical step as the scope of the goal has impact on the requirements and needed evidence. In our case we should decide if our goal is just to have a backup or to have guarantee the data can be restored or maybe to resume system operation after a failure. Usually standards define goals for us but we may also define our own goals. Our need is to have guaranties the data will be recovered in case of a serious failure.
Having the goal defined we should look for the method how the goal can be achieved. You may want to check some standards like ISO 27002 for guidelines or you may decide on your own. In our case we assume that we will achieve the goal by implementing a backup policy and procedure to make the backups and verify them.
In accordance with this implementation strategy, we define three sub goals. If you say that this decomposition is not complete you can add some other sub-goals. You can manage this with the implementation strategy which specifies what sub-goals are adequate to satisfy the main goal.
In the next step each sub-goal can be further decomposed in the similar way into sub-sub-goals and so on down to the level of individual requirements. We will keep our checklist simple and the sub-goals will be decomposed directly into requirements.
The important feature of the goal-based approach is that each step of the goal decomposition is explicit and exposed for analysis and verification. You can examine it and adjust if it is not complete, appropriate or convincing. For example in decomposition of sub-goal 2 you can ask a question how we know the location for storing the backup is secure? We should probably extend the set of requirements or split sub-claim 2 into two sub-claims, one related to the backup process and the second one to the backup storage confidentiality and availability. The advantage of the approach is that even for complex conformance projects when you have hundreds of requirements you can always directly point to a specific place in the conformance model and say that this is wrong and should be corrected.
When we decompose goals to requirements, we can treat these requirements as the checklist items. The requirements should be specified in a way that it is possible to directly evaluate if it is satisfied or not. When you have all the requirements specified you can hand the checklist over to assigned persons to use it to check the system and confirm if all the requirements are satisfied.
The screenshot below presents section of the checklist for sub-goal 2 during the evaluation in NOR-STA. For each requirement a user can give one of three assessment results:
- “it’s satisfied” and select the green item,
- “it’s not satisfied” and select the red one or
- “I don’t know” and select the yellow one.
For each requirement you can add a comment to describe your evaluation of the requirement or give guidelines for improvement.
Free user account
for one project
Assurance Case Online Training
5.06.2024
View Demo projects
for selected standards