Test Deck

Representation property: models map reality Reduction property: models reduce the represented reality Pragmatic property: models are constructed for a special purpose

They typically model reality through a set of graphical elements

Modeling elements and their valid combinations

Meaning of the modeling elements

Requirements models are conceptual models that define the requirements for the system to be developed.

Information presented in pictures is quicker to understand and memorize Requirements models allow the targeted modeling of one perspective on the requirements By defining the modeling language for the particular purpose, an appropriate abstraction of reality can already be specified

A goal describes an intention of a stakeholder.

The goals typically concern characteristic features of the system to be developed or of the associated development project.

"AND decomposition” (all sub-goals must be fulfilled in order to fulfill the higher goal (super-goal) "OR decomposition” (at least one sub- goal must be fulfilled in order to fulfill the higher goal (super-goal)

Such decomposition relationships between goals are frequently documented in the form of and/or trees.

Use cases help to examine and document a planned or existing system, from users perspective.

Use case diagrams Use case specifications

Actors (people or other systems) in the system context The system boundary Use cases Various types of relationships between these modeling elements.

Unique designation of the use case Name of the use case Description of the use case Triggering event Actors Result Pre- and post-conditions Various kinds of scenarios. Scenarios describe typical event sequences which lead to the successful execution of the use case (main scenarios, alternative scenarios) or explicitly describe how, during the execution of the use case, exceptional situations should be handled (exception scenarios)

Data perspective Functional perspective Behavioral perspective

Entity relationship models and UML class diagrams

data flow diagrams or UML activity diagrams (with object flows between actions)

Finite state automata or statecharts.

The structure of data is documented as well as usage and dependency relationships in the system context

Entity types Relationship types Attributes

The frequency by which an instance (entity) of an entity type participates in a relationship of a specific relationship type can be documented using cardinalities.

Classes Associations (with multiplicities and roles) Aggregation and composition relationships Generalization relationships

The functional perspective of requirements deals with the transformation of input data received from the environment into output data released into the environment of the system.

Processes Data flows Data stores Sources/sinks (In data flow diagrams there is no control flow)

Actions Start and end nodes Control flow Object flow Decision nodes Merge of alternative control flows Fork (concurrency) Join (concurrency) Hierarchization elements

In this perspective the focus lies on the various states in which a system can be found and on the events that are responsible for a change of state.

State Start and end states State transition Concurrency

The objective of requirements validation is to validate whether requirements satisfy the defined quality criteria Also to detect and correct any errors in the requirements as early as possible in RE.

Unresolved conflicts in a system’s requirements mean, for example, that one group of stakeholders’ requirements cannot be implemented or that the operational system is either not accepted or not sufficiently used.

The goal of negotiating requirements is to develop, among the relevant stakeholders, a common and agreed understanding with respect to the requirements for the system to be developed.

content documentation agreement

Completeness of the requirements document Completeness of the individual requirements Traceability Correctness and adequacy Consistency No premature design decisions Verifiability Necessity

Conformity to document format and document structures Understandability Unambiguity Conformity to documentation rules

Agreed Agreed after changes Conflicts resolved