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 10:55, 21 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. In KAOS, the requirements can be represented in the form of goals, which can be functional or non-functional.[2] 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.[3]

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.

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.

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)

Sub-models[4]

Goal

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

Soft goal

The purpose of soft-goals is to document choices among possible system behaviors.

Agent

KAOS' agents are mainly software-intensive systems' users and components. A system agent is an active component that serves a specific purpose in achieving a goal. An agent can be a human agent, a device or a software component.

AND/OR-decomposition

An AND-OR decomposition link indicates that a goal has been met if all of its subgoals have been met, or at least one of them has been met.

Potential conflict

This link documents that meeting one goal may interfere with the achievement of another goal in certain circumstances.

Responsibility model

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

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.

Operation process Model

Operational process model

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

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.

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

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

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

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. ^ Evaluating the Effectiveness of a Goal-Oriented Requirements Engineering Method
  3. ^ Formal Representation of SysML/KAOS Domain Model
  4. ^ 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. ^ "A KAOS Tutorial" (PDF). KaosTutorial.
  6. ^ Objectiver A power tool to engineer your technical and business requirements
  7. ^ 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=1134904906"