Foundation Level - CPRE FL

The source and so the justifications of the requirements for a system lie in the system context of the planned system. The source consists of the set of all context aspects that initiated or influenced the definition of the requirements. Among the potential aspects in the system context are:

• People (stakeholder or groups of stakeholders)
• Systems in operation (technical systems, software and hardware)
• Processes (technical or physical processes, business processes)
• Events (technical or physical)
• Documents (e.g. laws, standards, system documentation)

It is the function of the system boundary to define which aspects will be covered by the planned system and which aspects are part of this system’s environment. The context boundary identifies the part of the environment that has a connection to the system to be developed.

Often the system boundary is only precisely defined towards the end of the requirements process. Before that, the desired functions and qualities of the planned system are only incompletely known or not known at all. Therefore there will be a grey zone in which the possible system boundary lies. Besides a shifting of the system boundary within the grey zone, the grey zone itself can also shift during the RE process, e.g. when, through a shifting of the system boundary, further aspects of the environment become important.

Also the context boundary can change over time, e.g. when it turns out, contrary to expectations, that a legal requirement, previously classified as relevant, has absolutely no impact on the planned system, then the system context is reduced in this area.

The context boundary also has a grey zone. It comprises the identified aspects of the environment for which, at a particular time, it is unclear whether these aspects have a relation to the planned system or not.

Use case diagrams or data flow diagrams are often used for the documentation of the system contexts (especially the system and context boundaries). In context modeling, based on data flow diagrams, the sources and sinks in the system environment are modeled, showing respectively the source or destination of data flows between the system in consideration and the environment. The actors (i.e. for example people or other systems) in the system environment and their use relations with the system to be developed are modeled in use case diagrams.

According to the IREB Syllabus a context diagram must include:

• A clear name for the system under analysis.
• All neighbor systems and interfaces have names.

Context diagrams can be drawn in many different ways:

• Data flow diagram of the structured analysis
• Mind Maps
• Use case diagrams (with only one Use Case in the middle)
• Block diagrams (e.g. in Visio)
• Deployment diagrams (from the UML)
• etc.

The most important rules for developing context diagrams:

• There is only one process/system in the middle of the diagram
• There are no storage units (e.g. databases)
• There exists one or more interfaces with:
  • Data input - deliver what the system needs.
  • Data output - results of the system processes.
• Ther emust be no depdendencies between the interfaces.
• Printers, terminals etc. are typically part of the systems.
• Find all actors

Possible requirements sources are, for example, stakeholders, documents or existing systems.

An important activity in RE activity is the elicitation of requirements for the system to be developed. The foundations for the requirements elicitation comprise on the one hand the system context and on the other hand the requirements sources. Various types of requirements sources are differentiated. Possible requirements sources are, for example, stakeholders, documents or existing systems.

It is the task of RE to collect the goals and requirements from the various requirements sources. If sources are disregarded, this can have significant negative consequences on the entire course of the project. The documentation of the requirements sources should, with respect to the stakeholders, contain at least the following information:

• name
• function (role)
• additional personal and contact data
• temporal and spatial availability during the project progress
• relevance of the stakeholder
• their area and extent of expertise
• their goals and interests regarding the project

Depending on the company culture it is appropriate, in agreement with the stakeholders, to define verbally or by means of written documentation the tasks, responsibilities, authority, etc. From the stakeholder agreements arise rights and duties for each stakeholder. Dealing with stakeholders effectively guards against lack of motivation and conflicts. Stakeholders should be involved in the project and not only affected by the project.

For the elicitation of requirements, it is crucial to know what importance the requirements have for the satisfaction of the stakeholders. According to the model of Dr. Kano, this satisfaction can be classified into three categories:

• Basic factors (synonym: Dissatisfiers) - must have features
  • Assumption that these features are part of the product
  • They do not lead to an increasing enthusiasm of the customer just because they exist in the produt
  • If these features are missing, they lead to very strong discontent of the customer with the product.
• Performance factors (synonym: Satisfiers) - linear features
  • The more of this features / qualities are fulfilled, the higher is the satisfaction of the customer
• Excitement factors (synonym: Delighters)
  • They are not expected by the customer upfront.
  • Are not absolutely missing, if they are not part of the product.
  • If existing, the product becomes more attractive for the customer.
  • Are suprises for the customer and generate a positive feeling of th eproduct for the customer.

Negative features load to a shrinking customer satisfaction if these features are fulfilled.

Elicitation techniques fulfill the purpose of finding out the conscious, unconscious and subconscious requirements of stakeholders. Important factors influencing the choice of elicitation technique are:

• Risk factors
• Human influences
• Organizational influences
• Function-content and technical influences
• Intended level of detail of the requirements

The elicitation techniques are considerably different depending on the availability of documentation and the abilities of the stakeholders.

Various techniques are needed for the various RE products:

• Survey techniques (e.g. interviews, questionnaires)
  • We can assume that there are stakeholders, that have a sufficient knowledge about the system.
• Creativity techniques (e.g. brainstorming, brainstorming paradox, change of perspective, analogy technique)
  • The goal is either not clearly defined or unknown.
  • We can assume thtat there are different possible solutions.
• Document-centric techniques (e.g. system archaeology, perspective-based reading, requirements reuse)
  • There already is an existing solution.
• Observation techniques (e.g. field observation, apprenticing)
  • There is no adequate documentation that would allow us to deepen our knowledge about the system.
  • The stakeholders are either not willing or capable to sufficiently specfiy the requriements.
• Support techniques (e.g. mind mapping, workshops, CRC cards, audio and video recordings, use case modeling, prototypes)
  • The usage scenarios of th efuture system are well known.

The application of appropriate elicitation techniques is a project-critical key competence. The best results are achieved with a combination of various elicitation techniques.

In RE it is necessary to document all important information. All forms of more or less formal representation of requirements, from the description in prose up to diagrams with formal semantics, are called documentation techniques. Many people are involved in the documentation in the lifecycle of a requirements document. Documentation plays a goal-orientated supporting function in communication. The following factors make this support necessary. Requirements are long-lasting, legally relevant and should be accessible to all. Requirements documents are complex.

Requirements documents include, amongst other things, functional requirements that normally represent the following three different perspectives of a system.

• Data perspective
• Behavioral perspective
• Functional perspective

All three perspectives can be documented by means of natural language requirements, whilst conceptual model types are specialized for one of these perspectives. Effectively applicable forms of the documentation are:

• Natural language requirements documentation
• Conceptual requirements models such as, for example use case diagrams, class diagrams, activity diagrams or state diagrams (see also EU 6)
• Combined forms of requirements documentation

Central components of a requirements document are the requirements for the system being considered. Besides the requirements, depending on the purpose of the document, the requirements documents also contain information about the system context, acceptance conditions or, for instance, characteristics of the technical implementation. In order to ensure the manageability of requirements documents, such documents must be structured most appropriately.

Reference structures for requirements documents propose a more or less complete and a more or less flexible field-tested content structure. Common reference structures for requirements documents are described amongst others in the Standard ISO/IEC/IEEE 29148:2011.

In practice it turns out that there are a lot of positive effects from using reference structures for requirements documents. For instance, the use of reference structures simplifies the usage of the requirements documents in subsequent development activities (e.g. in the definition of test cases). Generally reference structures cannot be adopted one-to-one for a requirements document, as the content structure frequently has to be adapted in detail for domain-, company- or project-specific circumstances.

Requirements documents serve as the basis for many activities during the project lifespan, such as, for example

• Planning
• Architectural design
• Implementation
• Test
• Change management
• System usage and system maintenance
• Contract management

xxx

xxx

xxx

xxx

xxx

In order to serve as a basis the subsequent development processes, the requirements document must meet certain quality criteria. In particular this includes:

• Unambiguity and consistency
• Clear structure
• Modifiability and extensibility
• Completeness
• Traceability

In addition, the individual requirement must satisfy certain quality criteria, in particular:

• agreed
• unambiguous
• necessary
• consistent
• verifiable
• feasible
• traceable
• complete
• understandable

Besides the quality criteria for requirements there are two basic style rules for requirements in natural language, which promote readability:

• short sentences and paragraphs
• formulate only one requirement per sentence

A frequent cause of conflicts, arising in RE, lies in the different understanding of terminology among the involved people. To prevent this problem, it is necessary that all relevant terms are defined in a glossary. A glossary is a collection of term definitions for:

• context-specific technical terms
• abbreviations and acronyms
• everyday concepts that have a special meaning in the given context
• synonyms
• homonyms

The following rules should be observed when working with a glossary:

• The glossary must be managed centrally
• The responsibilities for maintaining the glossary must be defined
• The glossary must be maintained over the course of the project
• The glossary must be commonly accessible
• Use of the glossary must be obligatory
• The glossary should contain the sources of the terms
• The stakeholders should agree upon the glossary
• The entries in the glossary should have a consistent structure

It is beneficial to begin the development of the glossary as early as possible, in order to reduce the alignment work later on.

As natural language is often ambiguous and interpretable, it is necessary to pay special attention to precisely this aspect when using language. During the processes of perception and writing, so-called “transformational processes” occur. The fact that these transformational processes follow certain rules can be used by the requirements engineer to elicit exactly what the author of the requirement really did mean. The five most relevant transformational processes for RE are:

• Nominalization
• Nouns without reference index
• Universal quantifiers
• Incompletely specified conditions
• Incompletely specified process words

Requirements templates are an easily learnable and applicable approach to reducing language effects in the formulation of requirements. The requirements template effectively supports the author of a requirement in creating high quality requirements.
The five steps to formulating requirements through a requirements template are:

• Determine legal obligation
• Determine the core of the requirement
• Characterizes the activity of the system
• Insert objects
• Determine logical and temporal conditions

The fixing of liability by using the verbs "shall", "should", "will", “may” can be made in the text of the requirement. If the liabilities change, then the requirements change too. The use of attributes is another possibility for documenting the liabilities of requirements.
The best results cannot be achieved by making the use of requirements templates compulsory, but rather by offering training on the method and by treating requirements templates as a supplemental tool.

Using models makes it easier to understand information selectively about the facts and their connections, to record them more quickly and document them unambiguously. A model is an abstraction of an existing reality or a reality to be created (note that this definition covers the most frequent case in requirements engineering, but is a bit narrow. More generally speaking, a model is an abstract representation of an existing entity or an entity to be created, where entity denotes any part of reality or any other conceivable set of elements or phenomena, including other models. With respect to a model, the entity is called the original.). Models have three important properties:

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

In RE conceptual models are used frequently. They typically model reality through a set of graphical elements. Conceptual modeling languages are used for the modeling of conceptual models, which are defined by their syntax (modeling elements and their valid combinations) and semantics (meaning of the modeling elements).

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

The documentation of requirements in the form of conceptual models offers, in contrast to natural language requirements documentation, among other things the following advantages:

• 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

The combination of natural language and requirements models provides the advantages of both documentation types.

A goal describes an intention of a stakeholder. Such intentions typically concern characteristic features of the system to be developed or of the associated development project. Goals can be documented both in natural language and in the form of models. 

An integral part of the documentation of goals is the description of refinement relationships (decomposition relationships) between higher and subordinate goals. In this regard two types of decomposition are distinguished:

• "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. The use case approach is based on two complementary documentation techniques:

• Use case diagrams
• Use case specifications

Syllabus IREB Certified Professional for Requirements Engineering
‑ Foundation Level ‑ Version 2.2.2, August 23, 2017 Page 22 / 35
Use case diagrams are simple models to document the functions of a system from a user’s perspective and to document the interrelations of the functions of a system and the relations between these functions and the systems context. Typical modeling elements for use case diagrams are:

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

Use case specifications complement the overview-like use case diagrams through a more precise specification of the essential characteristic of individual use cases. For this purpose, a predefined template is generally filled in for each relevant use case separately. Typical sections of such a template include:

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