The formal name for KAOS is Knowledge Acquisition in Automated Specification of Software Systems. A simpler name for it is Keep All Objects Satisfied. There are a few types of models that make up KAOS, mainly, a goal model, an object model, and an operation model. In this blog post, we will focus on the goal model, mainly how to read it as well as pros and cons. From there, you, the reader, can dive into our listed sources to determine if integrating KAOS into your methodology would good for your organization.
The goal model displays a strategic goal which needs to be satisfied by sub-goals through AND or OR gates. At an OR gate, either of the sub-goals needs to be satisfied in order to progress in the goal-flow. At an AND gate, both of the sub-goals need to be satisfied in order to progress in the goal-flow. An agent, in the diagram below is the human and the software, is an active system component. These have tasks to perform. An operation is an action that an agent takes to achieve a goal. The action will most likely be on an object. In the diagram below, the object is the application and the human needs to complete it and submit it before the system knows who he is. So, if he starts an application and then abandons it, the system wouldn’t know who he is. Likewise, if he starts and completes an application but never submits it, the system again doesn’t know who he is. Requirements in this type of model can be found where a software agent needs to complete a task. We see in the model below that we’re expecting the system to correct an application. You can derive requirements from that idea. For example, “the system shall correct every submitted application”.
