Test Deck

elicitation documentation validation/negotiation management of 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.

communication skills analytical thinking empathy conflict resolution skills moderation skills self-confidence (Persuasiveness) ability to convince

functional requirements quality requirements constraints

A functional requirement is a requirement concerning a result of behavior that shall be provided by a function of the system.

The umbrella term “non-functional requirement” is often used for quality requirements and constraints.

A quality requirement is a requirement that pertains to a quality concern that is not covered by functional requirements.

A constraint is a requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.

people, domain factors, or organizational constraints

Performance (time behavior and resource utilization) Security (accountability, authenticity, confidentiality, and integrity) Reliability (availability, fault tolerance, and recoverability) Usability (accessibility, learnability, and ease of use) Maintainability (reusability, analyzability, changeability, and testability) Portability (adaptability, installability, and replaceability)

The system context is the part of the system environment that is relevant for the definition as well as the understanding of the requirements of a system to be developed.

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 may result in incomplete or erroneous requirements. This leads to the system operating on the basis of incomplete or erroneous requirements, which is often the reason for system failure during operation.

The system boundary defines which aspects will be covered by the planned system and which aspects are part of this system’s environment. All aspects that are within the system boundary can thus be altered during system development.

The context boundary identifies the part of the environment that has a connection to the system to be developed.

Use case diagrams or data flow diagrams

stakeholders documents existing systems

It is the task of RE to collect the goals and requirements from the various requirements sources.

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.

Basic factors (synonym: Dissatisfiers) Performance factors (synonym: Satisfiers) Excitement factors (synonym: Delighters)

risk factors human influences organizational influences functioncontent influences intended level of detail of the requirements

Survey techniques (e.g. interviews, questionnaires) Creativity techniques (e.g. brainstorming, brainstorming paradox, change of perspective, analogy technique) Document-centric techniques (e.g. system archaeology, perspective-based reading, requirements reuse) Observation techniques (e.g. field observation, apprenticing) Support techniques (e.g. mind mapping, workshops, CRC cards, audio and video recordings, use case modeling, prototypes) The best results are achieved with a combination of various elicitation techniques

In RE it is necessary to document all important information. Many people are involved in the documentation in the lifecycle of a requirements document. Documentation plays a goal-orientated supportin function in communication. Requirements documents are complex.

Requirements are long-lasting, legally relevant and should be accessible to all.

Data perspective Behavioral perspective Functional perspective

use case diagrams class diagrams activity diagrams state diagrams

Simplifies the usage of the requirements documents in subsequent development activities (e.g. in the definition of test cases).

Standard ISO/IEC/IEEE 29148:2011

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.

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

Unambiguity and consistency Clear structure Modifiability and extensibility Completeness Traceability

agreed unambiguous necessary consistent verifiable feasible traceable complete understandable

short sentences and paragraphs formulate only one requirement per sentence