Test Deck

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.

Change Control Board (CCB)

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

change manager contractor architect user representative quality manager requirements engineer.

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.

Corrective changes Adaptive changes Exceptional changes.

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 reques

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.

Requirements change rates Requirements errors

test management or configuration management tools, Wikis, office software or visualization software and modeling tools.

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

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

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)

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.

Complete requirements free from defects are the basis for successful system development. Potential risks have to be identified during requirements engineering and must be reduced as early as possible to allow for successful project progress. Faults and gaps in requirement documents must be discovered early on to avoid tedious change processes.

(1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2)

A stakeholder of a system is a person or an organization that has an (direct or indirect) influence on the requirements of the system.

Requirements engineering is a systematic and disciplined approach to the specification and management of requirements with the following goals: (1.1) Knowing the relevant requirements, achieving a consensus among the stakeholders about these requirements, documenting them according to given standards, and managing them systematically (1.2) Understanding and documenting the stakeholders’ desires and needs, they specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and needs

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