Foundation Level - CPRE FL

Good RE is important since many errors arise already in this phase and can only be rectified later at high cost. Typical symptoms of inadequate RE are missing and unclear requirements.

The worst consequences of inadequate requirements engineering are:

• Missing of the project targets because of unavailable requirements.
• Diversion of the real project target, because the requirements have low quality (they do not satisfy the requirements standard criteria's)
• Implicit requirements which unexpectedly and late influence the project.
• Contradictiory requirements lead to expensive additional work in the project.
• Requirements creeping are almost unrecognizable changes of requirements. They result in unexpected changes of the original project target, as well as changes of the original project estimate.

Typical reasons for inadequate RE are

• the wrong assumption of the stakeholders that much is self-evident and does not need to be stated explicitly
• communication problems due to differences in experience and knowledge
• the project pressure from the client to build a productive system rapidly.

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.