Foundation Level - CPRE FL

To manage the system’s requirements over the whole lifecycle of the system, it is necessary to collect requirements’ information as attributes in as structured a way as possible. The definition of the attribute structure for requirements is done through an attribute scheme, which can be defined either in tabular form or in the form of an information model.

Attribute schemes are frequently defined and adapted for a specific project on the basis of specific conditions. This includes:

• Specific properties of the project
• Constraints of the organization
• Domain rules
• Constraints of the development process

Typical attributes are:

• Identifier
• Name
• Description
• Source
• Stability
• Risk
• Priority

The "legal obligation" can also be saved as additional requirement’s information in the form of an attribute.

In practice, the amounts of requirements in a project and the number of dependencies among these requirements are evermore increasing. In order to keep the complexity of the requirements manageable for the project staff, it is necessary to selectively access and thereby filter the requirements depending on the current task. Two kinds of view formation are distinguished:

• Selective views: showing a subset of the attribute values from requirements selected by defined selection criteria
• Condensed views: showing condensed information about requirements selected by defined selection criteria

Requirements are prioritized, at various times and during various activities, according to various criteria. Preparing prioritization of requirements is based on a simple system:

• Determining the goals and constraints for the prioritization
• Determining the prioritization criteria
• Determining the relevant stakeholders
• Selection of the artifacts to be prioritized

Based on the results of these activities, one or more techniques for prioritization are selected and the prioritization itself carried out. Among the prioritization techniques are:

• Ranking and top-ten technique
• Single-criterion classification
• Kano classification
• Prioritization Matrix According to Wiegers

Within the management of requirements, the requirements’ traceability information is recorded, organized and maintained.
The benefits of requirements traceability involves:

• Simplification of verifiability
• Identification of unneeded properties in the system
• Identification of unneeded requirements
• Support of impact analysis
• Support of reusability
• Support of determination of accountability
• Support for maintenance and administration

With respect to the requirements’ traceability relationships, three classes of traceability relationships are distinguished:

• Pre-requirements-specification traceability
• Post-requirements-specification traceability
• Traceability between requirements

Only such information should be recorded for which there exists a clear use. The traceability of requirements can be represented in various ways. Typical representation forms are:

• Text-based references and hyperlinks
• Trace matrices
• Trace graphs

Requirements’ versioning and configuration makes it possible, over the lifecycle of a system or product, to have specific development states of requirements and requirements documents available. The version number of a requirement has at least two components:

• Version
• Increment

A requirements configuration comprises a defined set of logically related requirements, whereby at most one version of each requirement is contained in the requirements configuration. The formation of requirements configurations are defined in two dimensions:

• Product dimension: the individual requirements of the requirements foundation
• Version dimension: the various change states of a requirement

Requirements configurations have several typical properties:

• Logical connection of the requirements in a configuration
• Consistency of the requirements within a requirements configuration
• Unique identifier of the requirements configuration
• Immutability of the requirements within the requirements configuration
• Basis for rollbacks to earlier versions of the requirements base

Requirements baselines are specific requirements configurations, which comprise stable versions of requirements and often define the delivery increments of the system (system releases) as well.

Requirements change over the entire lifecycle of a system. The changes to the requirements are managed and processed in a systematic change management process. In this change management process, the Change Control Board is responsible for processing the incoming change requests.

The tasks of the Change Control Board are:

• Classification of incoming change requests
• Determination of the effort for performing the change
• Assessment of the change requests in respect to effort-benefit
• Definition of new requirements based on incoming change requests
• Deciding whether to accept or reject a change request
• Prioritization of the accepted change requests
• Assign accepted change requests to change projects

Typical member of the Change Control Board are the change manager, contractor, architect, user representative, quality manager and requirements engineer.

If changes to requirements are deemed necessary, these are documented in the form of change requests and submitted to the Change Control Board. A change request contains at least the following information:

• Identifier of the change request
• Title of the change request
• Description of the necessary change
• Justification of the need for the change
• Date filed
• Applicant
• Priority of the change as seen by the applicant.

There are three types of change requests:

• Corrective changes
• Adaptive changes
• Exceptional changes

The process of change management provides the following steps:

• Impact analysis and assessment of the change
• Prioritization of the change request
• Assignment of the change to a change project
• Communication of the acceptance/rejection of the change request

Based on the requirements validation and management information such as errors, attributes, traces or changes, the quality of the requirements documents and processes can be analyzed. This enables the identification of improvement possibilities. Typical measurements include

• Requirements change rates
• Requirements errors

Many system development tools can also support RE, e.g. test management or configuration management tools, Wikis, office software or visualization software. Also modeling tools are important for RE in order to create and analyze information as models. Requirements management tools are intended only for RE. They should feature the following characteristics:

• manage various information
• manage logical relationships between information
• identify artifacts uniquely
• make information accessible flexibly and securely, e.g. through access control
• support views over the data
• organize the information, e.g. through assignment of attributes and formation of hierarchies
• generate reports over the information
• generate documents out of the information

Standard office tools support these features only to a limited extent, specialized tools refine these, e.g. through traceability management.

Only after the introduction of RE procedures and techniques can an appropriate tool be sought. The tool introduction requires clear RE responsibilities and procedures. In the process, the following aspects are to be considered:

• Consider necessary resources
• Avoid risks by means of pilot projects
• Evaluation according to defined criteria
• Take into account costs beyond license costs
• Instruct employees

The variety of aspects to be considered when evaluating RE-tools can be structured using the following seven views:

• Project view (e.g. support for project planning)
• User view (especially usability)
• Product view (functionality)
• Process view (methodological support)
• Provider view (e.g. vendor services)
• Technical view (e.g. interoperability, scalability)
• Economic view (costs)

Clear criteria are to be defined for each view.

The four main activities of Requirements Engineering are elicitation, documentation, validation/negotiation plus the management of requirements:

• Eliciation - The first step concerns the collection of requirements: | To get correct requirements as complete as possible
• Documentation - Specification of the requirements.  | specify the requirements with techniques and tools like use cases, feature lists, domain data model, etc.
• Validation (and Negotiation) - The focus here is the review and reconciliation of requirements with stakeholders. | quality assurance in RE
• Management - Requirements must be maintained over the duration of the project, but also especially beyond. | working out the requirements

The activities can be scheduled in specific processes such as recommended in the Standard ISO/IEC/IEEE 29148:2011. They often concern different levels of requirements such as stakeholder requirements and system or software requirements.

• Natural language is the most important means to communicate requirements.
• At the same time it is particularly important to agree on a common terminology.
• Furthermore the communication medium (written or spoken) plays a big role. When communicating, all participants must deal consciously with focusing and simplification.

The following linguistic effects are important for the IREB exam:

• Nominalization - by nominalization a long and complex process is transformed into a single event. Example: "The booking and printing of the ticket is done after the payment". Solution: Questions about what the process of booking does exactly look like? Questions about what exactly happens when we "print the ticket"?
• Nouns without reference index
• Universal quantifiers - Keywords like: never, always, none, everybody, everyone, nothing, etc.
• Incomplete specified conditions - keywords: if, then, in case of, dependent of. Questions what happens if something does not occur or happen?
• Incomplete specified process words (especially verbs) - Use an active language style: "The printer prints the documents..."

Besides communication skills he or she must especially have the following skills:

• communication skills
• analytical thinking and reasoning capabilities
• empathy
• conflict resolution skills
• moderation skills
• self-confidence 
• ability to convince

WORK STYLE

• exact - loves to work precisely in order to get a clear result
• lovers bureaucracy - is willing to document the results of the analysis in detail

WORK SKILLS

• analytical thinking - can analyze problems without losing himself in details
• reasoning capabilities - can include different aspects and views in the analysis of a problem
• RE methods and tools knowledge - Know the most important methods and tools. 

SOCIAL SKILL

• has a high social competence and is empathic
• self confidence / ability to convince -  can make agreements with both the specialized experts (domain expert) and with the technicians in the project team
• conflict resolution skills - can negotiate in difficult situations to solve simple conflicts

COMMUNICATION SKILLS

• precise language - uses an exact language
• moderation skills - The RE understands and speaks the language (the concepts) of the stakeholders. This means he has some domain knowledge.
• RE knows how to convert the wishes and needs of the stakeholders into clear requirements for the project.

Typically we differentiate between three kinds of requirements:

• functional requirements
• quality requirements OR non-functional requirements
• constraints

The umbrella term “non-functional requirement” is often used for quality requirements and constraints. Quality requirements must be documented explicitly. In particular the following aspects need to be considered

• Performance
• Security
• Reliability
• Usability
• Maintainability
• Portability

Even though quality requirements are mostly documented using natural language, their relation to other statements have to be traceable and their validation has to be ensured by quantitative assertions or made operational by transformation into additional functionality.

ISO/IEC/IEEE 24765:2010:

1. The process of studying user needs to arrive at a definition of system, hardware, or software requirements.
2. The process of studying and refining system, hardware, or software requirements.

Spirit in Projects:

The process of the elicitation, elaboration, specification and QA of requirements.

Similar terms for requirement analysis are system analysis, technical analysis, and goal analysis.

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