REQUIREMENTS

MANAGEMENT
OBJECTIVES
▪ The importance of requirements identification and traceability
▪ Fundamentals of version management.
▪ The importance of change management.
▪ The purpose of views on requirements .
▪ The categories of tools used for managing requirements .
ASSIGNING ATTRIBUTES TO
MANAGE REQUIREMENTS
Identification and assigning of attributes are precondition for traceability and
management of requirements.
OBJECTIVES
▪ Attributes are properties of requirements that help represent the metadata of
the requirements engineering.
▪ The most important attributes of requirements and their typical
characteristics.
▪ The allocation of a unique identification value through an ID-attribute is an
important precondition of the requirements engineering.
▪ The different attribute schemes for requirements and requirements
documents.
ATTRIBUTES OF
REQUIREMENTS
Attributes of requirements serve the purpose of:
▪ structuring

▪ ensuring consistency (dependencies)

▪ identification

▪ progress and state control

An attribute scheme is the set of all defined attributes for a class of requirements.
ATTRIBUTE SCHEMES
Defined and adapted for a specific project based on the following conditions:
▪ Specific properties of the project
e.g. project size, local or distributed development or project risk
▪ Constraint
e.g. organizational standards and regulation
▪ Domain rules
e.g. reference models, modeling guidelines, standards
▪ Constraints of the development process
e.g. liability law, process standards
 TYPICAL ATTRIBUTES OF
REQUIREMENTS
▪ Identifier ▪ Stability
▪ Name ▪ Risk
▪ Description ▪ Priority
▪ Source
ID Name Description Source Stability Risk Priority
101 Add to Basket The system provides J. Smith , A. Low Low High
customers with the… Miller
102 Display The system provides J. Smith Medium Low High
Basket customers with the…
211 Encrypt Data All customer data is stored R. Lock High High Medium
encrypted…
312 Generate Sale At 0:00h GMT+8, the Sales Process High Low Low
Report system generates… Doc
ADDITIONAL ATTRIBUTES OF
REQUIREMENTS
▪ Version ▪ Benefit
▪ Author ▪ Loss
▪ Legal obligation ▪ Effort
▪ Kano model type ▪ Risk

▪ Status (regarding content, validation, agreement)

▪ Requirement Type (functionality, quality, constraint)
▪ Requirement kind (high level, detailed requriement)
▪ Acceptance criteria
▪ Release
▪ …
TEMPLATE-BASED ASSIGNMENT OF
ATTRIBUTES
▪ Defines relevant information that has to be captured.
▪ Can be different depending on requirement type (functionality/quality)
▪ Reader of requirements easily finds information.
IDENTIFICATION OF REQUIREMENTS
MOST IMPORTANT ATTRIBUTE OF A
REQUIREMENTS
An ID is An ID is not
▪ a key attribute of a requirement. ▪ a statement about the requirement’s content.
▪ a mean for referencing the requirement. ▪ an element of structuring or grouping
requirements
▪ a mandatory attribute .
▪ no chapter number
▪ explicitly assigned.
▪ no list number
▪ uniquely assigned and never modified.
▪ valid for the entire life cycle of the product.
LIFE-CYCLE OF REQUIREMENTS
AND MANAGEMENT OF
IDENTIFICATION
▪ The ID must be assigned at the requirement creation time.
▪ Even if a requirement is discarded its ID is preserved.
▪ Deletion is a state of the requirement.
▪ The information about the requirement is preserved.
VIEWS ON REQUIREMENTS
Selective and condensed views for different stakeholder and readers.
TYPES OF VIEWS ON
REQUIREMENTS
Selected view Condensed view
▪ Subset of attribute values ▪ Condensed/aggregated information.
▪ Selected by different criteria ▪ Selected by different criteria
STAKEHOLDER INTERESTS
Each stakeholder has his specific interest in requirements
Stakeholder Interest in requirements

Management Vision and goals, classification in the business context, progress

report
User Functionality, fulfillment of needs, specific interest of user groups

Quality department Define metrics, compliance with metrics, completeness of

artifacts
Legal department Compliance with contract, norms, standards

Project manager Coverage, progress report, time and effort, change wishes, effects

Client Progress report, acceptance criteria

Architect Non functional requirements, structure of the system architecture

Developer Scope, functional decomposition, architectural design, guidelines,

standards
… …
REQUIREMENTS ATTRIBUTES
BASICS FOR GENERATING
VIEWS
Generating views:
▪ Establishing the necessary views
▪ Definition of attributes, that are contained in every view.
▪ Definition of statistics of attribute sets.
▪ Definition of metrics for progress monitoring.

▪ Definition of Reports
▪ Selective and condensed views.
▪ Usage of Excel, Word, version management.
▪ Usage of requirements-management Tools.

▪Determine the requirements attributes

▪Create the reports
▪Publish the reports
PRIORITIZING
REQUIREMENTS
Methods and techniques for requirements prioritization
GOALS OF THE CHAPTER
▪ You can explain the importance of requirements prioritization.
▪ You know the most important target groups for thee prioritization results.
▪ You know how the prioritization results are used by the target groups.
▪ You know different methods and techniques of prioritization.
▪ You can explain the life cycle model for prioritizing the requirements.
PROJECT PLANNING WITH
REQUIREMENTS
PRIORITIZATION IN THE PROJECT
DEVELOPMENT
Prioritization of requirements as control instrument
▪ Classical prioritization with low, middle, high priority.
▪ Prioritization using Kano model.

Usage of prioritization in project planning

▪ waterfall approach
▪ change management process after the requirements approval.
▪ control of the scope against budget, a change can replace an approved
requirements.
▪ iterative approach
▪ allocation of requirements to releases according to vision.
▪ allocation of requirements to iterations according to priorities.
METHOD FOR REQUIREMENTS
PRIORITIZATION
Goal: Order of Realization
1. Determining prioritization criteria
▪ Cost of implementation
▪ Risk of the implementation
▪ Benefit
▪ Loss in case of incorrect or missing implementation
▪ Volatility/Stability of the requirement
▪ Importance
▪ Time to implement the requirement
2. Choosing the stakeholder for prioritizing
▪ Depending of criteria
▪ User, management, developer
▪ Support the checking of the content, the validation.
3. Determining the requirements to be prioritized
▪ Requirements to the same object (system, sub-system or component)
▪ Requirements with approximately the same detailing degree
4. Establish prioritization techniques
5. Prioritizing
TECHNIQUES FOR
PRIORITIZATION
Single-Criterion Classification, IEEE Std. 830-1998
(importance of realization)
▪ Mandatory
▪ Optional
▪ Nice-to-have
Primarily used in procurement projects, for evaluation.
Kano classification
▪ Dissatifiers / Basic Factors: Must have, or else useless
▪ Satisfiers / Performance Factors: Must have, or unsatisfied clients
▪ Delighters / Excellent Factors: Should have, lead to great satisfaction
Used in projects with great innovation, for release planning.
TECHNIQUES FOR
PRIORITIZATION
Ranking
▪ Everybody create the ranking order of the requirements
▪ The ranking points are added
▪ The sum of the ranking points determine the priority
Top-Ten Technique
▪ Everybody has a point (n ≈ half of the evaluated objects)
▪ Everybody can distribute the points at discretion
▪ The points are added
▪ The sum of the point determine the priority
TECHNIQUES FOR
PRIORITIZATION
WIEGERS PRIORITIZATION
Procedures

MATRIX (1/2)
1.
2.
Determine the relative weights for benefit, penalty, cost and risk.
Determine the requirements to be prioritized.
3. Estimate the relative benefits.
4. Estimate the relative penalty.
5. Calculate the total values and percentage values for each requirement.
6. Estimate the relative cost for each requirement.
7. Calculate the cost percentage for each requirement.
8. Estimate the relative risks for each requirement.
9. Calculate the risk percentage for each requirement.
10. Calculate the individual requirement priorities.
11. Assert the rank of the individual requirements.
TECHNIQUES FOR
PRIORITIZATION
WIEGERS PRIORITIZATION
Calculation

MATRIX (2/2)
Value% (Ri) = Benefit (Ri) x WeightBenefit + Penalty (Ri) x WeightPenalty
Priority (Ri) = Value% (Ri) / Cost% (Ri) x WeightCost + Risk% (Ri) x WeightRisk
Rel. Benefit = Penalty = Cost Risk
Weight 2 1 =1 = 0.5
Requirem Rel. Rel. Value Cost Rel. Risk
Total Rel. Cost Priority Rank
ent Benefit Penalty % % Risk %
R1 5 3 13 16.8 2 13.3 1 9.1 .941 1

R2 9 7 25 32.5 5 33.3 3 27.2 .692 3

R3 5 7 17 22.1 3 20.0 2 18.2 .759 2

R4 2 1 5 6.5 1 6.7 1 9.1 .577 4

R5 4 9 17 22.1 4 26.7 4 36.4 .489 5

Total 25 27 77 100 15 100 11 100

AGILE REQUIREMENT
PRIORITIZATION (AN AGILE
STORY PRIORITIZATION GAME)
Pre: An unordered stack of story cards / requirements
1. Take the first card, place it on a table.
2. Take next card, if priority is higher, place above otherwise below first card.
3. Take next card, place it above both cards if it is the most important, in between or below,
depending on your judgement.
4. And so on until stake is gone.

With many people involved, one by one can pick a card from the stack or move one card from
the table up or down.
TRACEABILITY OF
REQUIREMENTS
Traceability, Trace analysis
OBJECTIVES
▪ You can explain the importance of traceability in requirements management.
▪ You know the different techniques for achieving traceability.
▪ You can explain why traceability is essential for
▪ Cost estimation
▪ Impact analysis of changes
TRACEABILITY
CLASSIFICATION OF RELATIONS
Classification of traceability relations
▪ Traceability of requirements towards origin is necessary, to
demonstrate the reaching of goals and needs.
Pre-RS-Traceability
▪ Traceability of requirements towards solutions is necessary, to
evaluate the results of changes.
Post-RS-Traceability
▪ Traceability between requirements towards origin is necessary, to
manage dependencies between requirements (refinement,
generalization, replacement).
Traceability between requirements
TRACEABILITY
ADVANTAGES (1/2)
Advantages of traceability
▪ Simplification of Verification (coverage analysis)
▪ all requirements are implemented.

▪ the fulfilment of all requirements has been checked.

▪ Identification of system gold plating (coverage analysis)

▪ no system parts without contribution to requirements fulfilment.

▪ Identification of requirements gold plating (coverage analysis)

▪ no requirements without contribution to reaching a system goal.

▪ no requirements without relation to a need.

▪ Progress monitoring (coverage analysis)

▪ requirements without solution parts.

▪ requirements without test cases.

TRACEABILITY
ADVANTAGES (2/2)
Advantages of traceability
▪ Change management (impact analysis)
▪ identifying the affected artifacts/system parts by the requested change, in order to estimate the time and costs of the
change implementation.
▪ Maintenance (impact analysis)
▪ identify causes and effect of an error.

▪ determine the system parts affected by the error.

▪ estimate time and cost of the error removal.

▪ Reuse
▪ identify reusable artifacts by comparing requirements.

▪ Accountability
▪ allocation of the realizing efforts to the requirements.
REPRESENTATION OF
REQUIREMENTS TRACEABILITY
Text based references
▪ Unambiguous identification of the elements, of which relations must be traced.
▪ Recognizable syntax of the identification.
▪ Automated generating of traceability relations.

Hyperlinks
▪ Linking of the artifacts.

Trace matrices
Trace graph
TRACEABILITY MATRIX
▪ Record relationships between two items types, e.g.
▪ requirements and sources
▪ use cases and features
▪ test cases and requirements
▪ design parts and requirements
▪ requirements and requirements

▪ Get unmanageable with an increasing number of items

TRACEABILITY GRAPH
VERSIONING OF REQUIREMENTS
Version management and management of requirements changes
OBJECTIVES
▪ You can explain the terms version, configuration, baseline, change
requestand change management.
▪ You can explain the difference between the version of a requirement and the
version of requirements document.
▪ You can explain the basic procedure in change management.
▪ You know the tasks of a change control board.
 REQUIREMENTS VERSIONS
All requirements
can have versions (with a status
signed)
▪ Manually in the document.
▪ Manually in a separate list.
▪ Automatically in a repository.

At least the whole document needs to be

version controlled
(and have a defined status)
▪ Manually in the document.
▪ Automatically with version control tools.
REQUIREMENT VERSION
DESIGNATION
CONFIGURATION OF
REQUIREMENTS
CONFIGURATION OF
REQUIREMENTS DOCUMENTS
REQUIREMENTS BASELINES
▪ Distinct configurations of requirements, that define the release steps
▪ of the requirements = requirements release
▪ of the system = system release
and related to which the requirement changes can be traced.
▪ Basis for release planning
▪ Basis for communication with the contractor
▪ “Stable” requirements
▪ Estimation of the release effort
▪ Comparison to the competing products
A configuration defines a state (subset) of the basis requirement, every change leads to a new
version of the requirement and, as needed, to a new configuration.
CHANGE MANAGEMENT
Changes compared to a baseline are triggered by change requests
▪ The change request documents the desired change and contains information for the management of the
change request.

Reasons for change request

▪ Inadequate requirement
▪ Evolution of the context e.g.
▪ Change of the user wishes
▪ Legal changes
▪ New technology
Change frequency
▪ Low
▪ Are the stakeholders still interested?
▪ High
▪ Indicator for inadequately performed requirements engineering / overloads project
CHANGE CONTROL BOARD
(CCB)
Tasks of the change control board
▪ Classify incoming change request.
▪ Estimate effort for performing the change.
▪ Evaluate change request, with respect to the effort/benefit ratio.
▪ Define new or changed requirements.
▪ Accept or reject change request.
▪ Prioritize accepted change request.
▪ Assign accepted change requests to change projects/releases.
CHANGE CONTROL BOARD
(CCB)
Composition of the CCB
▪ Change manager
▪ Contractor
▪ Architect
▪ User representative
▪ Quality manager
▪ Requirements engineer
ELEMENTS OF A CHANGE
REQUEST
▪ Needed information from the applicant
▪ Identifier
▪ Title as summary of the requested change
▪ Description
▪ Justification (benefit of the change)
▪ Data filed
▪ Applicant
▪ Priority in the applicant’s opinion

▪ Management information
▪ Change validation
▪ Change the request status
▪ Estimate costs of the change
▪ CCB decision status
▪ CCB priority
▪ Responsible for implementation
▪ Planned system release
CLASSIFICATION OF INCOMING
CHANGE REQUESTS
▪ Corrective requirement change
▪ Failure during operation because of an error in the requirements.
▪ Timely analysis, evaluation and eventually implemented.

▪ Adaptive requirement change

▪ Change in the context.
▪ Grouped and analyzed, evaluated together later, an implemented in a (later) release.

▪ Exceptional change (hot fix)

▪ Can be corrective or adaptive.
▪ Must be absolutely immediately be done at all cost.
MEASUREMENT FOR HANDLING
CHANGE REQUESTS
MEASUREMENTS FOR
REQUIREMENTS
Quality of requirements documents and processes can be analyzed based on the
following requirements validation and management information:
▪ Error founds
▪ Attributes
▪ Traces
▪ Changes
This enables the identification of improvement possibilities.
Typical measurements include:
▪ Requirements change rates
▪ Requirements errors
END OF CHAPTER