W EEK 13 Requirements traceability and interdependencies.

WEEK 13Requirements traceability and interdependencies

INTRODUCTION

Most individual requirements cannot be treated in isolation They are related to and affect each other in

complex manner

Example Constrains how other requirements can be

designed or implemented Affects the cost of implementation of other

requirements Increases or decreases the customer satisfaction

of other requirements

Requirements interdependencies are not problematic per-se, but they influence a number of development activities and decisions made during the SE process including Change management

Neglecting these dependencies when assessing the impacts of change may result in neglecting some of the actual impact of a change.

Understanding and knowing these relationship avoid selecting a set of requirements that must be changed later (costly modification)

A critical part of the requirements change management process is the assessment of the impact of a change on the rest of the system Change while requirements are being developed,

how that change affects other requirements Change while implementation is underway,

impact assessment involves assessing how the change affects the requirements, the system design and its implementation

Change after the system has gone into operation, check how all stakeholders in the system might be affected by the change

REQUIREMENTS TRACEABILITY Definition

The ability to describe and follow the life of a requirements, in both forward and backward direction, ideally through the whole system life cycle.

It is achieved through associating related information objects such as Requirements and related system components satisfying

those requirements System objectives and requirements derived from those

requirements Change proposals and requirements which they intend to

change A decision and the rationales and assumptions on which

they are based Test cases and the requirements which fulfillment they

intend to ensure and System components and the resources needed to

implement those requirements

TRACEABILITY

Traceability information is information which helps you assess the impact of requirements change. It links related requirements and the requirements and other system representations

TRACEABILITY (DAVIS)

S- stakeholderBR- business ruleDoc- previous documentation

C-component

TRACEABILITY (DAVIS) Types of traceability information by Davis

Backward-from traceability Links requirements to their sources in other documents or people

Forward-from traceability Links requirements to the design and implementation components

Backward-to traceability Links design and implementation components backs to requirements

Forward-to traceability Links other documents (which may have preceded the requirements document) to relevant requirements.

TYPES OF TRACEABILITY

Requirements-sources traceabilityLinks the requirement and the people or

documents which specified the requirement Requirements-rationale traceability

Links the requirement with a description of why that requirement has been specified.

Requirements-requirements traceabilityLinks requirements with other requirements

which are, in some way, dependent on them. This should be a two-way link (dependants and is-dependent on).

TYPES OF TRACEABILITY

Requirements-architecture traceability Links requirements with the sub-systems where

these requirements are implemented. This is particularly important where sub-systems are being developed by different sub-contractors

Requirements-design traceability Links requirements with specific hardware or

software components in the system which are used to implement the requirement

Requirements-interface traceability Links requirements with the interfaces of external

systems which are used in the provision of the requirements

TRACEABILITY TABLES

Traceability tables show the relationships between requirements or between requirements and design components

Requirements are listed along the horizontal and vertical axes and relationships between requirements are marked in the table cells

Traceability tables for showing requirements dependencies should be defined with requirement numbers used to label the rows and columns of the table

A TRACEABILITY TABLE

Depends-onR1 R2 R3 R4 R5 R6

R1 * *R2 * *R3 * *R4 *R5 *R6

TRACEABILITY LISTS

If a relatively small number of requirements have to be managed (up to 250, say), traceability tables can be implemented using a spreadsheet

Traceability tables become more of a problem when there are hundreds or thousands of requirements as the tables become large and sparsely populated

A simplified form of traceability table may be used where, along with each requirement description, one or more lists of the identifiers of related requirements are maintained.

Traceability lists are simple lists of relationships which can be implemented as text or as simple tables

A TRACEABILITY LIST

Requirement Depends-onR1 R3, R4R2 R5, R6R3 R4, R5R4 R2R5 R6

TRACEABILITY POLICIES Maintaining traceability information is expensive. All too often, traceability information is not updated. Traceability policies helps to define what and how

traceability information should be maintained. Traceability policies may include

The traceability information which should be maintained.

Techniques, such as traceability matrices, which should be used for maintaining traceability.

A description of when the traceability information should be collected during the requirements engineering and system development processes.

The roles of the people, such as the traceability manager, who are responsible for maintaining the traceability information should also be defined.

A description of how to handle and document policy exceptions

The process of managing traceability information

FACTORS INFLUENCING TRACEABILITY POLICIES

Number of requirements The greater the number of requirements, the

more the need for formal traceability policies. Estimated system lifetime

More comprehensive traceability policies should be defined for systems which have a long lifetime.

Level of organisational maturityDetailed traceability policies are most likely to

be cost-effective in organisations which have a higher level of process maturity

FACTORS INFLUENCING TRACEABILITY POLICIES

Project team size and composition With a small team, it may be possible to assess the

impact of proposed informally without structured traceability information. With larger teams, however, you need more formal traceability policies.

Type of system Critical systems such as hard real-time control

systems or safety-critical systems need more comprehensive traceability policies than non-critical systems.

Specific customer requirements Some customers may specify that specific

traceability information should be delivered as part of the system documentation.

REQUIREMENTS INTERDEPENDENCIES INFLUENCE DIFFERENT ACTIVITIES IN SE

Requirements management Change management and impact analysis Release planning Reuse of component Reuse of requirements Design and implementation Testing

Requirements management Managing large amount if requirements Maintaining decomposition of requirements The source of the requirements and the detailed

of it RM issue here is to provide traceability

between the source and the more detailed requirements explaining them

Managing the decomposition is also a way of managing the fast increasing number of requirements, since the requirements are often grouped into hierarchies

Change management and impact analysis Concerned with managing changes and

assessing the effect of change requests Since requirements interdependencies show if

requirements influence others, it will help the accuracy of impact analysis since other requirements that need to be changed can be defined.

Release planning Concerned with selecting an optimal collection of

requirements for implementation in the next version of a software system

The selection is usually based on requirements priority and the estimated cost of implementing the requirements.

Due to the fact that requirements are related to and affect each other, the priority and cost are not enough.

Reuse of components If similarities between requirements are

documented, this information can be used to identify reusable components by comparing the stated requirements with the requirements of the existing system

The traceability information can be used to recognize the adjustment needed to change the components to the new application

Reuse of requirements Recycling requirements are carried in ad-hoc

manner which is both time-consuming and error-prone Difficult in term of identifying requirements that are

potentially be reused Difficult to ensure that all requirements related to the

once recycled ones are included Too many requirements are included

Knowledge of requirements interdependencies is useful when reusing requirements

Design and implementation Software design – decision making Many trade-offs are made – scope and

functionality Common trade-off between conflicting or

inconsistent requirements Challenge: to what extent multiple requirements

can be satisfied simultaneously Requirements interaction management –

discover, manage and disposition of critical relationships among sets of requirements

Testing Ensuring that all the requirements of the system

have been met and includes tasks such as test planning, selecting and designing test cases, executing test cases and reporting on the result of the execution

Requirements interdependencies – the order in which test cases are executed. Some function can not be tested before other

functionality is in place and verified due to some reasons Efficiency Reduce un-necessary re-execution of test cases.

IMPACT ANALYSIS

Software changes are necessary and inevitable in software development, but may lead to software deterioration if not properly controlled.

For example, when Mozilla’s 2,000,000 Source Lines of Code (SLOC) were analyzed, there were strong indications that the software had deteriorated significantly due to uncontrolled change, making the software very hard to maintain

Software deterioration occurs in many cases because changes to software seldom have the small impact they are believed to have.

Example In 1983, some of the world’s most expensive

programming errors each involved the change of a single digit in a previously correct program, indicating that a seemingly trivial change may have immense impact.

A study in the late 90s showed that software practitioners conducting impact analysis and estimating change in an industrial project underestimated the amount of change by a factor of three.

IMPACT ANALYSIS FROM A REQUIREMENTS ENGINEERING PERSPECTIVE

Software life-cycle objects (SLOs) affected (right) due to requirements changes in different phases (left)

impact analysis is an integral part of every phase in software development.

•During requirements development, design and code do not yet exist, so new and changing requirements affect only the existing requirements.•During design, code does not yet exist, so new and changing requirements affect only existing requirements and design. •Finally, during implementation, new and changing requirements affect existing requirements as well as design and code.

IMPACT ANALYSIS Impact analysis is a tool for controlling

change, and thus for avoiding deterioration. Bohner and Arnold define impact analysis as

“the activity of identifying the potential consequences, including side effects and ripple effects, of a change, or estimating what needs to be modified to accomplish a change before it has been made”

Consequently, the output from impact analysis can be used as a basis for estimating the cost associated with a change. The cost of the change can be used to decide

whether or not to implement it depending on its cost/benefit ratio.

Impact analysis is an important part of requirements engineering since changes to software often are initiated by changes to the requirements

Wiegers provides checklists to be used by a knowledgeable developer to assess the impact of a change proposal

Checklist for Requirements Changes Forms available at: http://

www.processimpact.com/process_assets/impact_analysis.doc

MEASURING CHANGE ACTIVITIES The measurements should be motivated by the

questions you are trying to answer and the goals you are trying to achieve

Measuring change activity is a way to assess the stability of the requirements and to identify opportunities for process improvement

The requirements change activities can be measured from the following aspects– The number of change requests received, open, and

closed– The cumulative number of changes made– The number of change requests that originated from

each source– The number of changes proposed and made in each

requirement since it was baselined– The total effort devoted to handling changes

SOFTWARE CHANGE AND IMPACT ANALYSIS Software change occurs for several reasons, for

example, in order to fix faults, to add new features or to restructure the software to accommodate future changes . Changing requirements is one of the most

significant motivations for software change. Changes to requirements reflect how the

system must change in order to stay useful for its users and remain competitive on the market. At the same time, such changes pose a great risk as they may cause software deterioration. Thus, changes to requirements must be captured,

managed and controlled carefully to ensure the survival of the system from a technical point of view.

FACTORS THAT CAN INFLICT CHANGES TO REQUIREMENTS The problem that the system is supposed to solve

changes, for example for economic, political or technological reasons.

The users change their minds about what they want the system to do, as they understand their needs better. This can happen because the users initially were uncertain about what they wanted, or because new users enter the picture.

The environment in which the system resides changes. For example, increases in speed and capacity of computers can affect the expectations of the system.

The new system is developed and released leading users to discover new requirements.

FRAMEWORK FOR A CHANGE MANAGEMENT PROCESS

Plan for change involves recognizing the fact that changes occur, and that they are a necessary part of the system’s development. Baseline requirements means to create a snapshot of the current set of requirements. The point of this step is to allow subsequent changes in the requirements to be compared with a stable, known set of requirements.A single channel is necessary to ensure that no change is implemented in the system before it has been scrutinized by a person, or several persons, who keep the system, the project and the budget in mind. In larger organizations, the singlechannel is often a change control board (CCB).

A change control system allows the CCB (or equivalent) to gather, track and assess the impact of changes. According to Leffingwell and Widrig, a change must be

assessed in terms of impact on cost and functionality, impact on external stakeholders (for example, customers) and potential to destabilize the system. If the latter is overlooked, the system (as pointed out earlier) is likely to deteriorate.

To manage hierarchically defeats perhaps too common line of action: a change is introduced in the code by an ambitious

programmer, who forgets, or overlooks, the potential effect the change has on test cases, design, architecture, requirements and so on. Changes should be introduced top-down, starting with the requirements. If the requirements are decomposed and linked to other SLOs, it is possible to propagate the change in a controlled way.

KOTONYA AND SOMMERVILLE

1. Problem analysis and change specification2. Change analysis and costing, which in turn

consists of:1. Check change request validity2. Find directly affected requirements3. Find dependent requirements4. Propose requirements changes5. Assess costs of change6. Assess cost acceptability

3. Change implementation

Most individual requirements cannot be treated in isolation

Requirements interdependencies as being part of requirements traceability

Dependencies between requirements is not a problem per se, but interdependencies affect many decisions and activities in the software development process

KEY POINTS Requirements change is inevitable as customers develop a

better understanding of their real needs and as the political, organisational and technical environment in which a system is to be installed changes.

Requirements which are concerned with the essence of a system are more likely to be stable than requirements which are more concerned with how the system is implemented in a particular environment.

Types of volatile requirement include mutable requirements, emergent requirements, consequential requirements and compatibility requirements.

Requirements management requires that each requirement should be uniquely identified.

If a large number of requirements have to be managed, the requirements should be stored in a database and links between related requirements should be maintained.

KEY POINTS Change management policies should define the processes used

for change management and the information which should be associated with each change request including who is responsible for doing what in the change management process.

Some automated support for change management should be provided.

Traceability information records the dependencies between requirements and the sources of these requirements, dependencies between requirements and dependencies between the requirements and the system implementation.

Traceability matrices may be used to record traceability information.

Collecting and maintaining traceability information is expensive.