Jump to content

User:Ipoxylari/KAOS (software development)

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Ipoxylari (talk | contribs) at 21:07, 23 January 2023. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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. 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

Basic constructs of KAOS framework for modeling goals and assigning responsibilities for goals to agents

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.[2]

Goals and Agents

Behavioural goal

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.[2]

Example

"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)[2]

Soft-goal

In KAOS, soft-goals are used to document preferences among alternative system behaviours. [3] 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. [2]

Example

"The system shall minimise the travelling time."

Agent

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.[3]. An agent can be a human agent, a device or a software component. [2]

Goal relationships in KAOS

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.[2]

AND/OR-decomposition

An AND-OR decomposition link relates a super goal to a set of sub-goals[2]. 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.[4]

Alternative decomposition

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

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.[2][4]

Responsibility Assignment

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 implement- ing the system, at least one of the alternative assignments needs to be chosen. [2]

Sub-models

In KAOS, the requirements can be represented in the form of goals, which can be functional or non-functional.[5] 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.[6]

Goal

Goals describe acceptable behaviors for a system. In order to verify whether a system meets a goal, it should be defined clearly.[4]

Responsibility model

The responsibility model describes the requirements or expectations of each agent and the tasks assigned to him.[4]

Object Model

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.[7]

Operational process model

The operational process model of KAOS describes the requirements that the agent needs to fulfill.[7]

Obstacle Model

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.[7]

Components[1]

Conceptual model

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.

Acquisition strategies

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.

The acquisition assistant

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.

Process of writing a requirement document using KAOS [7]

  1. Give a description of the problem.
  2. Give a target model for the system, including which target model you have used
  3. Give one of the responsibility models for the system.
  4. Give one of the object models of the system.
  5. Give the operational process model for the main objects in the system.
  6. Give potential obstacles to the achievement of the system's objectives
  7. Write a requirements document for the system based on the IEEE standard template.

KAOS Tool[8]

Objectiver

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

GRAIL[9]

Other goal-oriented modeling methods

References

  1. ^ a b 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.
  2. ^ 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)
  3. ^ 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.
  4. ^ 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.
  5. ^ 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.
  6. ^ 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.
  7. ^ a b c d "A KAOS Tutorial" (PDF). KaosTutorial.
  8. ^ Objectiver A power tool to engineer your technical and business requirements
  9. ^ 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.
Retrieved from "https://en.wikipedia.org/w/index.php?title=User:Ipoxylari/KAOS_(software_development)&oldid=1135302012"