User:Ipoxylari/KAOS (software development)
KAOS, is an acronym for Knowledge Acquisition in autOmated Specification. KAOS, has been designed by Axel van Lamsweerde, Anne Dardenn, and Stephen Fickas from the University of Oregon and the University of Louvain.(Belgium)[1]
It is considered a goal-Oriented requirements engineering approach that is used in the requirements acquisition phase of the software lifecycle. KAOS is used in a variety of fields, including mechanics, telecommunications, and healthcare[2]. This method is based on the idea of building requirements models and is thought to be an efficient method for eliciting goal-oriented requirements.
As a result of KAOS, requirements can be structured methodically and logically, and problems can be solved by using graphical methods.
Constructs of KAOS
[edit]
This section describes the basic constructs for documenting goals and assigning goal responsibilities to agents provided by the KAOS framework. In KAOS a goals is either a behavioural goal or a soft-goal and is defined as a prescriptive statement of intent that the system should satisfy through the cooperation of its agents.[3]
Goals and Agents
[edit]Behavioural goal
[edit]A behavioural goal describes a set of admissible system behaviours. Behavioural goals can be defined in a clear-cut manner. For example one can verify whether the system satisfies a behavioural goal or not.[3]
Example
[edit]"The train doors shall remain closed while the train is moving."
KAOS differentiates between two types of behavioural goals
- Achieve goal: An achieve goal demands that the defined property must eventually hold
- Maintain goal: A maintain goal requires that the defined property always holds (possibly under some condition).[3]
Soft-goal
[edit]In KAOS, soft-goals are used to document preferences among alternative system behaviours. [4] There is no clear-cut criterion for verifying the satisfaction of a soft-goal. Therefore, soft-goals are expected to be satisfied within acceptable limits rather that absolutely.[3]
Example
[edit]"The system shall minimise the travelling time."
Agent
[edit]In KAOS agents are primarly related to users and components of software intensive systems. An agent is thus defined as an active system component which has a specific role for satisfying a goal.[4] An agent can be a human agent, a device or a software component.[3]
Goal relationships in KAOS
[edit]Dependencies between gaols are represented in KAOS goal model using AND-decomposition links and conflict links. Alternative decompositions of a goal are expressed by attaching multiple AND-decomposition links to the same goal. In the agent sub-model, goals can be assigned to agents by means of responsibility assignment links.[3]
AND/OR-decomposition
[edit]An AND-OR decomposition link relates a super goal to a set of sub-goals.[3] It indicates that a goal has been met if all of its subgoals have been met, or at least one of them has been met.[5]
Alternative decomposition
[edit]OR-decomposition of a goal are documented in KAOS by assigning multiple AND-decompositions to the super-goal. Therefore, each alternative is represented as an AND-decomposition(which may also consist of just ne sub-goal). The set of assigned AND-decompositions refines the super-goal into the different sets of sub-goals. The super-goal is satisfied if one of the alternatives is satisfied.
Potential Conflict
[edit]Conflicts between goals are documented using potential conflict links. A potential conflict link documents that satisfying one goal may prevent the satisfaction of the other goal under certain conditions.[3][5]
Responsibility Assignment
[edit]Responsibility assignment links relate goal sub-model to elements of the goal sub-model to elements of the agent sub-model. A responsibility assignment link between a goal and an agent means that this agent is responsible for satisfying the goal. Only terminal goals can be assigned to an individual agent. If a goal is assigned to an individual agent it can thus not be further decomposed. In addition, alternative responsibility assignments can be defined, i.e. a goal can be related to multiple agents using a responsibility assignment relationship. When implementing the system, at least one of the alternative assignments needs to be chosen.[3]
Sub-models
[edit]In KAOS, the requirements can be represented in the form of goals, which can be functional or non-functional.[6] Six sub-models are used for the representation of the goals. In these six sub-models, the object model and the goal model are the two main sub-models. The object model uses the UML class diagram for the representation of domain vocabulary. The goal model is used for the determination of requirements to be satisfied by the system and of expectations with regard to the environment through a goals hierarchy.[7]
Goal
[edit]Goals describe acceptable behaviors for a system. In order to verify whether a system meets a goal, it should be defined clearly.[5]
Responsibility model
[edit]The responsibility model describes the requirements or expectations of each agent and the tasks assigned to him.[5]
Object Model
[edit]The object model is used to define and document relevant concepts in the application domain, presenting static constraints between concepts so as to satisfy design requirements. Entities, agents and associations are the three types of objects that consist in the object model.[8]
Operational process model
[edit]The operational process model of KAOS describes the requirements that the agent needs to fulfill.[8]
Obstacle Model
[edit]An obstacle is a situation that violates a goal, expectation or requirement. For a secure system, it is important to address potential barriers, which allows the analyst to address special situations that may occur during the requirements engineering phase, rather than coming to a solution when the system is running out of steam, thus ensuring the robustness of the system.[8]
Components
[edit]The approach taken in KAOS has three components including a conceptual model for capturing and structuring requirements models, with an associated acquisition language, a set of strategies for formulating requirements models in this framework, and an automated assistant to provide guidance in the acquisition process based on these strategies.[1]
Conceptual model
[edit]Conceptual models provide abstract representations of requirements models that need to be acquired. Therefore, it is considered a meta-model. Ideally, it should allow the precise and natural capture of both functional and non-functional requirements for any kind of composite system.[1]
Acquisition strategies
[edit]The acquisition strategy defines a coherent set of steps for acquiring components of the requirements model as instances of meta-model components. To put it another way, a strategy describes how the meta-model graph is traversed to acquire instances of its various nodes and links.[1]
The acquisition assistant
[edit]With the acquisition assistant, it is possible to follow one or more acquisition strategies using automated assistance. It is constructed around two repositories: a requirements database and a requirements knowledge base. They are both structured based on the meta-model components. It is the requirements database that maintains the requirements model that has been built gradually during the acquisition process.[1]
- Give a description of the problem.
- Give a target model for the system, including which target model you have used
- Give one of the responsibility models for the system.
- Give one of the object models of the system.
- Give the operational process model for the main objects in the system.
- Give potential obstacles to the achievement of the system's objectives
- Write a requirements document for the system based on the IEEE standard template.
KAOS Tool
[edit]
Objectiver is a powerful tool to engineer the technical and business requirements owned by Respect-IT, a spin-out of the University of Louvain.
Objectiver is a modeling and support tool for writing requirements documents. It follows the KAOS methodology and allows us to generate a completed and consistent requirements document in Word format.
Main features
[edit]- Automatic generation of Request for quotation (RFQ)/ Request for proposal (RFP)
- Goal driven requirements analysis
- Multiple views on documents with easy navigation
- Completeness and consistency checks
- Traceability inside models, source, output documents
- Queries
GRAIL
[edit]
GRAIL relies on KAOS and is a tool designed for requirement engineer practitioners to enable them to do real requirements engineering.[9] GRAIL helps with proceeding to produce requirements documents and doing efficiently standard checking.
The GRAIL kernel combines a graphical view, a textual view, an abstract syntax view, and an object base view of specifications. GRAIL has already been applied in the industry's cases, which plays an important role of a call for tender management tool, requirement management tool and requirements management tool connector. The textual editor supports template-driven requirements acquisition, and incremental checking of syntax and semantics both at declaration and assertion level. The graphical editor complements the detailed textual view with a high-level graphical view of the specification. The navigator allows specifiers to browse the entire specification in hypertext mode. The object base provides persistence, querying and concurrent access to the specification. The current version allows multiple specifiers to cooperate on the same specification in real-time.[10]
Other goal-oriented modeling methods
[edit]External links
[edit]- A KAOS Tutorial
- Goal-Oriented Requirements Engineering: An Overview of the Current Research
- Evaluating the Effectiveness of a Goal-Oriented Requirements Engineering Method
References
[edit]- ^ a b c d e Dardenne, Anne; van Lamsweerde, Axel; Fickas, Stephen. "Goal-directed requirements acquisition". Science of Computer Programming. 20 (1–2): 3–50. doi:10.1016/0167-6423(93)90021-g. ISSN 0167-6423.
- ^ Comparative evaluation in requirements engineering, 2006, CERE '06, fourth international workshop on. [Los Alamitos, Calif.]: IEEE Computer Society. 2006. ISBN 0-7695-2712-4. OCLC 85895398.
- ^ a b c d e f g h i Pohl, Klaus (2010). Requirements engineering : fundamentals, principles, and techniques. Heidelberg. ISBN 978-3-642-12577-5. OCLC 642291082.
{{cite book}}: CS1 maint: location missing publisher (link) - ^ a b Lamsweerde, A. van (2009). Requirements engineering : from system goals to UML models to software specifications. Chichester, England: John Wiley. ISBN 0-470-01270-6. OCLC 243941685.
- ^ a b c d Teruel, Miguel A.; Navarro, Elena; López-Jaquero, Víctor; Montero, Francisco; González, Pascual (2011). "A COMPARATIVE OF GOAL-ORIENTED APPROACHES TO MODELLING REQUIREMENTS FOR COLLABORATIVE SYSTEMS". Proceedings of the 6th International Conference on Evaluation of Novel Approaches to Software Engineering. SCITEPRESS - Science and Technology Publications. doi:10.5220/0003466301310142.
- ^ Comparative evaluation in requirements engineering, 2006, CERE '06, fourth international workshop on. [Los Alamitos, Calif.]: IEEE Computer Society. 2006. ISBN 0-7695-2712-4. OCLC 85895398.
- ^ Lamsweerde, A. van (2009). Requirements engineering : from system goals to UML models to software specifications. Chichester, England: John Wiley. ISBN 0-470-01270-6. OCLC 243941685.
- ^ a b c d e "A KAOS Tutorial" (PDF). KaosTutorial.
- ^ Darimont, R.; Delor, E.; Roussel, J.-L.; Rifaut, A. (2002). "Requirements engineering with GRAIL/KAOS: tell the requirements, all the requirements, and nothing else but the requirements". Proceedings IEEE Joint International Conference on Requirements Engineering. Essen, Germany: IEEE Comput. Soc: 299. doi:10.1109/ICRE.2002.1048541. ISBN 978-0-7695-1465-9.
- ^ Darimont, R.; Delor, E.; Massonet, P.; van Lamsweerde, A. (1997). "GRAIL/KAOS: an environment for goal-driven requirements analysis, integration and layout". Proceedings of ISRE '97: 3rd IEEE International Symposium on Requirements Engineering. Annapolis, MD, USA: IEEE Comput. Soc. Press: 140. doi:10.1109/ISRE.1997.566851. ISBN 978-0-8186-7740-3.