Test Deck

Over the whole lifecycle of the system, it is necessary to collect requirements’ information as attributes in as structured a way as possible

in tabular form or in the form of an information model

Identifier Name Description Source Stability Risk Priority "legal obligation"

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

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

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

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

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

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

Text-based references and hyperlinks Trace matrices Trace graphs

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.

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

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)