Requirement prioritization criteria

Commonly used prioritization criteria:

• Importance: Urgency of implementing, importance for acceptance of the system, importance for
architectural design, strategic importance to market position.

• Cost: Financial resources needed for implementation.

• Damage: Disadvantage from neglecting the requirement.

• Duration: Time needed to realize the requirement.

• Risk: Risk that the requirement cannot be realized in the system appropriately (e.g., because of
technological problems).

• Volatility: Probability that the requirement changes during a certain period of time.

• Business value: The value the asset creates for the business (e.g. scrum uses business value/cost
benefit to prioritize use cases to be implemented first).

Prioritization criteria relevant for different goals:

• Resolving conflicts:

• Damage – Resolve conflicts for high-damage requirements first.

• Volatility – Volatile requirements are likely to cause more conflicts.

• Intensity and order of validation activities:

• Cost – Early validation may avoid costly modifications later.

• Duration – Early validation may avoid additional development time.

• Order for documentation:

Importance – Acceptance criteria should be documented in detail.

Quality criteria of a good requirement

Consistency of Single Requirements

A single documented requirement is consistent if the statements therein do not contradict each
other.

“R15-2: The system shall compute the report in less

than a second in 90% of all potential situations and

prohibit response times >= 1 second.

• Agreed: The relevant stakeholders established a sufficient agreement about the requirement.

• Complete: The requirement adheres to the defined documentation and specification guidelines,
does not omit any information relevant for some stakeholder, and does not need any further
explanations.
• Comprehensible: The content of the requirement is easy to understand for all stakeholders.

• Consistent: A requirement is consistent if the statements within the requirement do not contradict
each other. In addition, the consistency of an entire set of requirements (document) as to be taken
into account.

quality criteria for requirements specifications. based on [ISO/IEC/IEEE 29148; Pohl and Rupp 2011]

• Correct: The relevant stakeholders confirm that the specified or documented requirement is
correct, and that the system shall realise the requirement.

• Feasible: The requirement can be technically realised within the system constraints and does not
require major technological advancements.

• Identifiable: The requirement can be uniquely distinguished from other requirements (e.g. by using
a unique identifier).

• Implementation free: The requirement does not contain any unnecessary constraints regarding the
architecture and its realization.

• Traceable: The source, evolution and use in later development phases of the requirement are
identified and documented.

• Unambiguous: The requirement only permits one valid interpretation. All readers arrive at the
same understanding of the requirement.

• Verifiable: The requirement allows proving whether the implemented system satisfies the
requirement or not.

Quality criteria requirement specification

• Affordable: There exists a feasible solution that satisfies the complete set of requirements within
the lifecycle constraints (e.g. cost, time, legal).

• Bounded: The set of requirements is defined within the system scope, i.e. the requirements
specification contains no “gold plating”.

• Clearly structured (comprehensible): The requirements specification supports selective reading

and should thus be clearly structured and comprehensible.

• Complete: The requirements specification contains all relevant requirements, and each
requirement is completely specified. No TBDs etc. are included.

• Consistent: All single requirements are internally consistently defined. There are no contradictions
between the requirements.

• Modifiable and extendable: The requirements specification is easy to modify and extend. The
document structure and style should support simple, complete and consistent modification.

• Traceable: The relationships between different versions of requirements specifications and other
documents (e.g. business process models, architecture, test cases, user manuals, standards) should
be traceable.
• Unambiguous: Each single requirement on its own, as well as the entire requirements specification
allow only one valid interpretation.

A requirements specification is a specific kind of requirements document which supports later

development activities and/or is used for contracts. It contains specified requirements as well as
relevant additional information.

Use Case specification templates

• Use case templates provide detailed descriptions for the use cases defined in a use case diagram.

• Use case templates shall be specifically designed for each companies specific purposes.

Essential items that should be documented

Requirement Traceability
“Requirements traceability refers to the ability to describe and follow the life of a requirement, in
both a forwards and backwards direction (i.e. from its origins, through its development and
specification, to its subsequent deployment and use, and through all periods of on-going refinement
and iteration in any of these phases).”

• Pre-traceability denotes the traceability of requirements artefacts to its predecessor artefacts, i.e.
to its source or origin.

• Post-traceability denotes the traceability from a requirements artefacts to its successor artefacts,
i.e. architectural components, implementation in the source code, test cases.

Traceability has positive effects on various aspects of the development process, e.g.:

• Accountability: allows assigning development effort to individual requirements.

• Process improvement: allows tracing problems in the development process back to their causes.

• Change management: allows analysing the affected artefacts in case of a change.

• Risk management: allows identification of artefacts potentially affected by a risk.

• Gold plating: allows identification of functions or qualities not specified in the requirements.

• Additional benefits: verifiability and acceptance, quality assurance, maintenance, re-engineering,

reuse, etc.

Traceability Relationship Types

Condition

• Constraint: A source artefact constraints a target artefact.

• Precondition: A source artefact defines a condition to be fulfilled before a target can be realized.

Content

• Similar: Associated artefacts are similar in content.

• Compares: An artefact is the result of a comparison between a set of artefacts.

• Contradicts: Associated artefacts cannot be realized together.

• Conflicts: The realization of an artefact hinders the realization of another. In contrast to

“contradicts” this type does not necessarily document an inconsistency.

Abstraction

• Classifies: A source artefact classifies a set of target artefacts.

• Aggregates: An artefact aggregates a set of other artefacts.

• Generalizes: An artefact is a generalization of (one or) several other artefacts.

Evolution

• Replaces: A target artefact replaces a source artefact.

• Satisfies: The realization of a source artefact satisfies the realization of a target artefact.

• Based on: A target artefact has influenced the definition of a source artefact.

• Formalizes: A source artefact is a formal documentation of a target artefact.

• Refines: A source artefact defines a target Artefact in more detail.

• Derived: A source artefact is derived from a (set of) target artefacts.

Miscellaneous

• Example of: A source artefact contains exemplary aspects of a set of artefacts.

• Verifies: A source artefact verifies or validates a target requirements artefacts.

• Rationale: A source artefact documents the justification of a target artefact.

• Background: Background information assigned to a requirements artefact.

Conflicts resolving strategies

Conflict detection requires involvement of stakeholders from

• the relevant parts of the requirements engineering context (usage facet, subject facet and IT
system facet of the system context as well as development context)

• in all requirements engineering activities, especially elicitation, validation and negotiation!

There are five conflict types:

• Data conflict

• Interest conflict
• Value conflict

• Relationship conflict

• Structural conflict

Three basic strategies for resolving data, value and interest conflicts!

• Negotiation

The conflicting parties agree on a solution by means of negotiation.

Resolve a conflict by exchanging information, arguments, and opinions.

• Conflict is resolved if either

• one viewpoint is accepted or

• a solution which ranges between the different viewpoints is found and accepted.

⊕ All conflicting parties are considered

⊕ Win-win situation is created

⊖ Negotiation can be very time-consuming

⊖ Compromise may not be the best solution from an objective viewpoint

• Creative solution

The original viewpoints of the conflicting parties are discarded and a new, creative solution is
developed that harmonize the viewpoints of all conflicting parties.

Resolve a conflict by discarding the old viewpoints.

• Develop a new viewpoint acceptable to all conflicting parties. The new solution is independent of
the previous viewpoints!

⊕ All conflicting parties are winners

⊖ Negotiation can be very time-consuming

⊖ New solutions may influence other requirements

• Decision

A higher authority makes a decision in favour of one conflicting party.

Conflict is resolved by a decision-maker (generally a higher authority), based on the present

circumstances.

• Decision which viewpoint should be adopted for the system.

• Decision-maker may even be involved in the conflicting parties himself.

• Alternative: Voting by all stakeholders.

⊕ Quick resolution (no long discussions)

⊕ Avoid consuming too many resources

⊖ Need for a decision-maker

⊖ Other viewpoints might be ignored

⊖ Negatively influence the motivation of ignored

Stakeholders

Functional requirement, quality requirement, constraints

A requirement is

(1) a condition or capability needed by a user to solve a problem or achieve an objective.

(2) a condition or capability that shall be met or possessed by a system, system component, product
or service to satisfy a contract, an agreement, standard, specification or other formally imposed
documents.

“These [functional requirements] are statements of services the system should provide, how the
system should react to particular inputs and how the system should behave in particular situations.
However, functional system requirements describe the system function in detail, its inputs and
outputs, exceptions and so on.”

A quality requirement defines a quality property for the entire system, for a system component, for
a service or for a function.

Maintainability - Degree of effectiveness and efficiency with which a product or system can be
modified by the intended maintainers.

Reliability - Degree to which a system, product or component performs specified functions under
specified conditions for a specified period of time.

Performance - efficiency Performance relative to the amount of resources (e.g., other software
products, hardware configuration, etc.) used under stated conditions.

A constraint is an organizational or technological requirement which restricts the way the system
shall be developed.

Requirements specification model / diagram

Goals of scenarios
A goal describes a high level objective of one or more stakeholders about a property of the system
to be developed or the development project.

A scenario describes a concrete example of satisfying or failing to satisfy a goal (or set of goals).
Use of goal and scenarios can significantly improve the elicitation of existing as well as the
development of new/innovative requirements.

Change Management
The requirements engineering context changes over time, e.g.,

• evolution of stakeholder needs due to new insights,

• changes to (inter-)national laws,

• new technologies are invented,

• new products of competitors are introduced.

• During system operation problems can occur, e.g.,

• data inconsistencies,

• system errors,

• insufficient system quality.

• Requirements artefacts must be adapted to cope with context changes and problems in system
operation originated in requirements artefacts.

• Change management process is a explicitly defined process to systematically manage changes in

requirements artefacts.
Step 1. Classification of the Change Request

Each incoming change request is classified, based on an

analysis, to a change category.

• Change categories typically used are corrective, adaptive change and exceptional change.

• The classification of the change request is suggested by the change manager and approved by the
change control board.

• If the change request in a corrective or an adaptive change, the impact analysis is executed next.

• If the change request is an exceptional change the request is directly integrated outside the change
management process overseen by the change control board.

Step 2. Impact Analysis

Goal: Estimate the effort (i.e. resource consumption) required to integrate a proposed change using
a change impact analysis.

• Affected artefacts need to be identified. The use of traceability information reduces identification
effort.

• Typically, the impact analysis is not performed by the change control board but assigned to the
Change Control Manager or other experts.

• Change impact can even imply a restructuring of the whole system architecture. (Significant high
effort)

Step 3. Evaluation of the Change Request

• Change control board evaluates the change request regarding the effort required to integrate the
change request and the benefits of realizing a change request.

• Benefits can be, e.g.:

• Improvement in market position.

• Avoidance of loss of prestige.

• Contract fulfilment and avoidance of contractual penalties.

• Based on the evaluation the change control board decides about the acceptance or the rejection of
a the change request.

Step 4. Prioritization of Change Requests

• In case of acceptance, the change control board prioritizes the change request.

• Based on the prioritization the change request is assigned to a system release or a change project
in which the changes are realized.

Step 5. Monitoring of Change Integration

The change control board

• monitors the change integration during the realization,

• tracks the status of each change request and

• keeps the originator of the request informed about the current realisation status.

Validation technique
A requirements review is a process or meeting during which the requirements for a system,
hardware item, or software item are presented to project personnel, managers, users, customers, or
other interested parties for comment or approval.

Commenting Artefacts

Simple technique for the validation of requirements artefacts by one or multiple stakeholders
(inspectors).

• Author sends the material to be validated to the inspector

• Either to one inspector, who reviews the material, comments on it and passes the material and the
review results to the next inspector.

• Or, material is send in parallel to several inspectors.

• Individual defect detection and documentation.

• Consolidation of results performed by the author.

• Options:

• Instructions for reviewing the material and documenting the results.

• Execution in a group meeting.

Validation and verification

Validation criteria when assessing the content of the requirements specification
Complete

• Requirements artefacts: Does the requirements artefact adhere to the defined documentation and
specification guidelines? Does each requirement artefact contain all the information required?

• Requirements specification: Does the document contain all relevant requirements? Are all
requirements completely defined?

Consistent

• Requirements artefacts: Are there any contradictory statements within the artefact?

• Requirements specification: Are all the contained requirements artefacts consistent? Do any
requirements artefacts contradict each other?

Correct

• Do all relevant stakeholders confirm that the requirement is correct, and that the system shall
meet the requirement?

Traceable

• Requirements artefacts: Can each requirement artefact be traced to its source? Is the use of each
requirement artefact in later phases documented appropriately?

• Requirements specification: Are the relations between the requirements specification and other
documents identified and documented?

Unambiguous

• Requirements artefacts: Can the requirements artefact be understood in many ways? Does each
artefact allow only one correct interpretation, independent of the reader?

• Requirements specification: Can the specification as a whole be interpreted in different ways?

Risk of insufficient requirement validation

• Error propagation

- If an error in a requirements artefact is not detected until the release stage of the system, all
artefacts (requirements artefacts, design artefacts, source code test artefacts, and manuals) need to
be revised.

Very high costs for corrective activities!

• Legal issues
- Requirements are often part of the contract between client and contractor.

- Overlooked defects in requirements may lead to disputes and conflicts concerning the actual
contractual liabilities.