Six Exercises Strengthen Trace Ability

8/2/2019 Six Exercises Strengthen Trace Ability

1/12

Six Exercises toStrengthen Traceability

Seapine Traceability Toolkit|Part 2

Task2

Task3

Task

1


2/12

1

White Paper

In Part One of Seapines Traceability Toolkit, Recognizing

the Danger Signs of Weak Traceability, we looked at the

strength of your traceability and shared some symptoms

that might indicate weaknesses in your traceability

processes. In this part, we provide six exercises to help you

strengthen traceability in your product development

lifecycle.

Achieving traceability within a product development

lifecycle helps ensure that changes are shared across teams,

in order to maintain quality and compliance. Traceability

is especially critical for achieving compliance with

ever-stricter government agencies and other qualitystandards, such as the DOD, FAA, FDA, GxP, IEC, and

ISO. Good traceability strategies and best practices help

eliminate unforeseen issues and provide a greater

assurance of quality and communication.

Developing a Traceability Strategy

The purpose of a traceability strategy is to put in place the

processes, tools, and best practices that will help your business

maintain a high level of quality and ensure compliance with

industry regulations. To that end, key stakeholders should

answer the following questions when developing a strong

traceability strategy.

What are our current product development problems?

What compliance requirements must we meet now

and in the near future?

What best practices should we adopt?

Which technology best supports these new best practices?

When you begin to discuss traceability with the key

stakeholders in your organization, youll likely nd dieringideas about what traceability is and how it aects their

jobs. Some groups might even resist improvements to your

companys traceability, because they dont understand the

benets of doing so.

Stakeholders may believe that strengthening traceability

will mean more hours or days lost to building traceability

matrices in Excel. However, once stakeholders understand the

importance and the benets of traceability, it should become

clear that traceability will not impede the current workload,

and stakeholders may be more amenable to adopting the new

strategy, best practices, and software tools.

Often, companies neglect steps and dont include the right

people when formulating a traceability strategy, which can

create animosity between groups and may cause territory

wars. Make sure you survey all groups and include everyone

who will be impacted by the new traceability strategy.

Topics to Consider

The following framework of topics may help you begin to

develop a traceability strategy:

Describe why traceability is important to the business.

Cite examples of how the lack of traceability has

negatively aected the business.

Communicate the benets of traceability to each

department. The benets may include:

Improved communication

Collaboration across departments

Specialization between departments

Continuous improvement

Reduced individual work

Describe specic regulatory and compliance requirements.

Assess current traceability.

Develop and enforce traceability best practices.

Best Practices for Exploring Traceability

and Communication in Product Development


3/12

2

White Paper

Once you determine that traceability is important to the

organization, where do you begin the improvements? The

rst step is to meet with stakeholders to begin identifying,

exploring, and capturing traceability best practices.

Six Exercises to Help Develop Traceability Best PracticesThe basics of strong traceability involve knowin g

what information needs to be traced, capturing that

information at dierent points in the process, and sharing

it across teams, departments, and ultimately the entire

organizationall in a timely manner.

To complete these six exercises, youll need to make the

time, invite the right people, create the right environment,

and take steps in advance to prepare for success.

Make the Time

The time it takes to cover the six areas will vary by organization,

but it could take as little as two hours if properly managed and

structured. Another approach is to break the exercises into

mini-sessions. We have outlined an estimated time for each

key exercise below for better time management.

Many may balk at spending two hours on these exercises. The

problem, however, is that you cant aord to not make time for

a critical issue like traceability.

Another way of looking at it is this: Would you rather waste

hours or even days creating a traceability matrix manually,only to have it fail to prove to auditors you are compliant?

Or would you rather spend two hours to create a strong

traceability strategy that will result in more accurate matrices

and less painful audits?

Invite the Right People

Too many times, management believes they know what

is best for their teams, but a lack of knowledge about

day-to-day activities and processes can impede developing

a best practice.

Consider inviting the following core people:

Product experts from Marketing, R &D ,

and Product Management

Business analysts and project managers from Design

Developers and engineers from Development

Testers and QA managers from Quality Assurance

Product documentation personnel

Key regulatory and compliance personnel

Your business may have dierent titles for the people

you invite, but this list should give you a good idea of the

roles to consider. All participants should be familiar with

product development artifacts and how theyre managed.

Get a Fresh Perspective

Often, people have a bias toward doing things the way theyve

always been done, and this can hinder your attempts to

achieve stronger traceability. It may not even be a visible or

conscious bias; you and your team may think your practices

are best because theyre the only practices to which youve

been exposed.

A neutral third party, such as an outside consultant, can oer

a fresh perspective. Try enlisting the aid of someone who has

engaged in this type of discussion before and knows the best

practices of similar businesses. An outside professional can

help direct the conversation, ensuring that everyones needs

and concerns are addressed in a way that attains the best

results for the business.

Prepare for Success

Once the meeting is scheduled, share this toolkit withparticipants one week prior, so the wheels are already turning

and they know what to expect. Some participants may also

suggest you invite other participants who are more aware of

the process or daily activities.

Before you get started, make sure you have access to the

following resources:

Meeting room with a whiteboard (the larger, the better)

Markers for whiteboard (black, blue, green, red, and yellow)

Sticky notes (the larger, the better)

Pens and paper for each participant

Youre now ready to tackle the traceability best

practices exercises.


4/12

3

1. Identify Key Artifacts

Within any product development lifecycle, there are key

artifacts that should be tracked and managed. A key artifact is

any type of product development item that should be managed

independently for better tracking and accountability, suchas specic requirements, test cases, development tasks, and

issues. Dont pigeonhole yourself into the old ways, such as

using at-le documents. Instead break the artifacts down to

core elements that are more manageable. A good example of

this is focusing on specic requirements, and not treating the

entire requirements document as a single artifact. You can also

have specic product artifacts that are managed collectively,

such as a traceability matrix or other reports.

There are no wrong answers when identifying key artifacts.

Exercise (15 minutes)

Have each participant write down the key artifacts they

manage, and the other artifacts that are aected by changing

each managed artifact. Collect the lists of artifacts and write

them on a white board with a black marker, organizing these

key product artifacts into groups that make sense to your

company, such as:

Design/Requirements

Testing

Issues/Tasks/Feature Requests

Source Control/Other Product Assets

Reports

Again, there are no wrong answers.

Questions to Ask:

What are you going to deliver? (Explicit product

requirements, electrical requirements, functional

requirements, compliance requirements, user stories, etc.)

How are you going to consistently verify the product?

(Functional test, materials test, regression test, load

test, verication test, test cases, etc.)

What types of issues are you going to track? (Change

requests, product defects, program bugs, spelling

mistakes, quality problems, etc.)

What types of customer requests are you going to

track? (Feature, cosmetic, functional, training, etc.)

What types of intellectual product capital require

versioning? (Software source code, rmware code,

technical documentation, standard operating

procedures, etc.)

What types of reports are essential for you and your

team? (Traceability matrices, detailed reports, trend

reports, etc.)

Exploring and identifying these core development artifacts

gives the group a better understanding of all the related

artifacts that are managed in a product development lifecycle.After you have collected and organized your key artifacts on a

whiteboard, you can move on to the next exercise.

Test ing

Test Cases

Requ irements

Bus iness Requ i rements


5/12

4

2. Explore Terminology and Meaning

After completing the previous exercise, you will likely see

dierences in terminology. Before getting started on this

exercise, remind participants that this is a traceability exercise.

Participants should think beyond just the artifact naming,because you may want to separate key artifacts for specic

reporting or tracking needs later.


Get all participants to agree on one naming convention per

artifact, especially if there are legal or compliance reasons for

consistent artifact names.

There may be situations where an agreement is not possible,

in which case these artifact names should be documented

or mapped to each other, even if they are essentially the

same. For example, customers may call something a bug, QA

may call it a defect, Development may call it an issue, and

Engineering may call it an anomaly, but ultimately each group

may be referring the same thing. Map these terms to each

other and move on.

If your artifacts cannot be grouped into one name or have a

dierent process, then assign a name for each artifact.

Establish a simple meaning for each artifact, and write the

meaning on a sticky note. You can even use some of the original

words used by others, so everybody is on the same page.

Write a general denition of the dierent types of artifacts.

Dont worry about dening every type of artifact, unless

there is a specic reason for tracking and relating them

dierently. (Requirements will likely be the exception to this

rule, because each requirement type or artifact will likely

have a dierent meaning.)

Once youve agreed to each artifacts name and written all

denitions on sticky notes, put the sticky notes at the head

of the table or on another board to the side. Youll use these

denitions later as remindersor to combine artifacts or addother meaningsin upcoming exercises.

Questions to Ask:

Does each artifact name have a dierent process? If not,

try to get the team to agree on names for artifacts that

are essentially the same. For example, maybe all types

of tests (manual and automated) require a formal testcase to document or verify completion of the test.

Which artifacts require consistent naming for auditing

or compliance? Identify these artifacts and agree on

a name for each. If a government agency explicitly

defines a specific artifact with a certain name, it is

usually a best practice to call it by the same name

to minimize auditing confusion.

Getting everyone on the same page with artifact

terminology and meaning helps reduce confusion and

eliminates possible negative implications from a legal orcompliance perspective.

Tasks & IssuesFeature Requests

are anoma li es , change

r equests , or bugs found

withi n theproduct.

They canbe cosmetic ,

functional, o r pe rformance

in nature .

I ssues=

are sugg estions orfeatures

recommendedby customers,

busines s analy sts, or others .

They can becosmetic,

functional, or performance in

nature. Th ey are routed to

produ ct development for formal

review and canbe approved for

specific pr oje cts as a us er

story or formal requirement.

Requ ests=Fe

ature

are tasks orwork i tems forsoftware developmentto c ode into thesoftware produc t.Th eycan be cosmetic , functiona l, or performance innature a nd maybe routed fromrequire ments or user storie s.

De ve lopme ntTasks=


6/12

5

3. Analyze the Impact of Change

You now need to determine how change aects other

related artifacts. For example, what is the impact on a test

case when a requirement changes?

Because this is one of the tougher, more sensitive areas to

explore, this exercise is simple.


On the whiteboard, draw blue arrows from each artifact

to the dependent artifacts that would also change if the

original artifact changes.

Do not perform this exercise for reports, because the

whiteboard could become unmanageable.

Note: To complete all six exercises in two hours, youmust stop this exercise when you reach 15 minutes. If the

exercise cannot be completed in 15 minutes, you may want

to nish it in a separate meeting. For now, map out a few

key impacts of change per category.

Questions to Ask:

Which artifacts are directly impacted by change?

Changing one artifact can have a ripple eect, resulting

in other indirect changes, which is quite common in

most product development lifecycles.

Managing change in an organization is not easy and can

have many risk factors. Mapping these potential risks

will give your team a bigger picture of how each change

ripples outward, aecting both upstream and downstream

artifacts. This visual impact analysis can also be used to

help determine if an artifact is worth changing, because it

may cause delays in your product development lifecycle.

Test ing

Test Cases

Tasks & IssuesFeature RequestsThe steps o fmanu al, automated , functi onal , r egre ssion , and

performance tests.

These testcase s can

have test variants .

TestCases=

The results of a te st caseexecution wit h associatedtest va r iants, typical ly

saved to a particu larbuild/test run set. Alsocal l ed test runs or testexecutions.

Te st Recor ds =

Work i tem s for develope rstocode into th esoftware /fi rm ware

DevelopmentTasks=

Anomal ies, change

requests , o r b ugs found

by e ither QA testing orcustomers

Is sues =

Cr t/u

t tt

c t r f

l ct

n /cn in

functi n lr

uirnt

Cr t/fl

ci t

t t c

Ii t ly

u n

r lfn

/u t

functin lr

uirnt

Re commended

su ggestions /improvem ents

Re quest s = Fe ature


7/12

6

4. Establish Trace Relationships and Handos

You can now start to dene the types of relationships and

handos that need to occur if change happens. It is a best

practice to ask the participants to not worry about current

technologies or processes, but to concern themselves onlywith what is ideal for the company. In other words, dont

focus on how you do it today. Instead, consider what is the

most eective or ideal way to communicate changes and

handos.

Exercise: (30 minutes)

On a sticky note, dene the type of relationships that exist

for each blue arrow on the whiteboard. The facilitator

should write the who, what, how, and when on the left

side of each sticky note, then place it on the blue arrow.

Do not perform this exercise for reports.

Questions to Ask:

Who needs to be notied of the change? (A specic

group, manager, assigned person, customer, etc.)

What needs to be checked, approved, changed, orcreated if the related artifact changes or enters a nal

state? (A simple ag, quick review, formal review,

creation of another artifact, etc.)

What other systems need to be updated? (PLM, QMS,

CRM, ERP, SCM, Help Desk, etc.)

How should the changes be communicated? (Flagged,

email, formal notication, etc.)

When should the changes be communicated?

(Immediately, time-based, escalate if no action takenwithin x days, etc.)

This exercise can take more time than youve allocated

for this meeting, so try to dene one key relationship

per group at a minimum. Ideally, tracing two to three

relationships per group helps drive home the importance

of key handos.

Using trace relationships to connect artifacts helps

map out the interdependencies and impact before

change is considered. These relationships are critical

for achieving effective traceability and should be

automated as much as possible.

est ing

Cases

Task Feat

Who:

What:

How:

When:

Issueshouldbe

createduponfaile

d

testrecordforrev

iew

Email notification

of

newissuefromfa

iled

testrecord

Immediately upon

failed

testrecord

QA

Work i temsford eve loperstocode i ntothe software/ firmware

Deve lopmentTa sks=

Anomal i e s, change

requests, o r bugs fou ndby ei ther QA test i ng o r

custome rs

I ssues =

Rec ommend ed

su ggestions /impr ovements

Re qu est s =Feat ure


8/12

7

5. Making Sense of Data

Establishing performance guidelines and tracking metrics

are critical to measuring the success of an organization

and helping to reduce the risk of future issues. However,

getting your team to adhere to these guidelines can bechallenging. Many times, team members dont understand

why a report is needed or dont have the time each day to

record the necessary data.

Exercises: (15 minutes)

Step 1: Review each report you dened earlier as an artifact

and verify that nothing was overlooked. Re-read the

denitions from the second exercise, and assess how easy

it is to get the information required of each report. Mark

each of the sticky notes with one of the following symbols:

A red X, to indicate there are problems getting data.

A green check, to indicate there are no problems

getting data in a timely fashion.

A yellow X, to indicate there is not a unanimous

decision.

Step 2: Remind the team to be honest with this exercise

because you need an accurate representation of the

current state of data. For each artifact, ask the teams who

are most responsible for the daily management of data to

rate how easy it is to pull data together for daily tasks and

how easy it is to analyze data without generating reports.

Mark each sticky note with one of the following:

A red X, to indicate they cannot easily get the data for

daily tasks or they have to generate reports to analyze

data.

A green check, to indicate they can easily get the data

to do their job.

A yellow X, to indicate there is not a unanimous decision.

Questions to Ask:

What type of reports do you need to create? Do you

have all reports listed from an operational,

management, and governmental compliance

perspective? Can you easily determine status andvelocity of your projects? Can we easily pull the

appropriate data to report against?

Can you easily get the data you need to do your job?

From a daily operational perspective, can you easily

view the data you need to make well-informed

decisions? Can you take action with this data?

Can you analyze key data quickly? Are you able to

organize data the way you work or do you have to

create reports to analyze data?

These metrics drive an organizations performance and

establish targets and goals for each department. Using a

system that gathers and presents metrics in a seamless

operational task helps to ensure that good performance

metrics are documented and eliminates the scramble to

document, roll-up, and report metrics. It also provides

good quality metrics to management.

Shows the trace

relation shi ps of core

artif acts fromrequir ements to tes

t

record s to issues .

Traceability

Report=

Showsa llopenissuesand developmenttasksfortheproject, typica llysharedwithupper management

Open IssuesReport=

Sh o ws o ve ra l l status of

a pro j ec t/re le ase

Pro jectStatus =

Pro vi de s a g ra phi ca l

r epr e se nt ati on of wor k

le f t t o do ve r su s t i m e in

the current iteration/re lease.

Bu rn D own /Bu rn

Up Cha rts =

Reports

Traceab i l i ty Report

Test ing

Test CasesThe steps o f m

anual ,

autom at ed, functional ,

regre ssion, and

per formancetest s.

The se t est cas es can

have test variants.

TestCases =

The results of a test caseexecuti on wi th assoc i atedtest vari ants, ty pical ly

saved to a part icular

bui ld/ test run set. Alsocal led test runs or t estex ecuti ons.

Test Reco rds =

Who:

What:

How:

When:

Create/updatetest

casesto reflect

new/changing

functional requirement

Create/flagassociated

testcases

Immediatelyupon

approval ofnew/updated

functional requirement

QA


9/12

8

6. Inventory Current Processes and Tools

Are your methods and practices outdated? Do they

impede daily activities? There are always new tactics

and development methodologies that can give you a

competitive advantage for each product or project, but arethey compliant?

How do you ensure that traceability between artifacts

happens on a daily basis? Thats the question this exercise

aims to resolve.

Exercises: (30 minutes)

Read the sticky notes with the who, what, how, and when

for each trace relationship aloud. Then ask the participants

to decide if they can do everything listed on these sticky

notes with the current process, and if the systems and

software support these ideal processes. Mark each sticky

note with one of the following:

A red X, to indicate the process is broken or the tools

dont support the process.

A green check, to indicate everything on the sticky note

can be accomplished with the current process and tools.

A yellow X, to indicate there is not a unanimous

decision.

Once you identify processes that are successful and ones

that fail, ask the following questions.

Questions to Ask:

For each green check, ask:

Why are these processes successful?

Do they give proactive backward and forwardtraceability?

Are key activities and notications automated?

For each red or yellow X, ask:

Why arent they successful?

Do people not understand the process?

Is there a lack of communication?

Do the tools support your preferred trace relationships?

Is the process still valid or have there been changes in

the organization that make the process obsolete?

Other questions to consider about current systems and

processes:

Will they continue to support current and future

development and project methodologies?

Will they continue to handle our current and future

compliance needs?

Do they help us or get in our way?

Establishing ideal processes will remove some of the burden

of having emergency knee-jerk reactions, audit failures,

and the need to improve eciency and productivity. A

good process will also reduce risk, and identify areas that

should be controlled to ensure success.

Who:

What:

How:

When:

Issueshouldbe

createduponfa

iled

testrecordforrev

iew

Emailnotification

of

newissuefromf

ailed

testrecord

Immediatelyupon

failed

testrecord

QA


10/12


11/12

10

Integrated Software Solution

Providing strong traceability strategies and best practices

involves adoption of a comprehensive, integrated, and

congurable product development lifecycle solution

that matches your business needs, quality standards, andcompliance initiatives.

Adaptable and Congurable

Just like businesses, no two processes are ever the

same. Most businesses need solutions that can be easily

congured to t with internal terminology, project

requirements, business rules, compliance regulations, and

user needs. As your business grows, so will your business

processes. You will need a system that can adapt. When

searching for such a system, keep in mind these key

attributes:

Congurable Security

Strong, congurable security measures are required of

most government and compliance agencies. Even if you

arent required to have security measures for

compliance reasons, some level of security allows you

to be certain that your intellectual property is protected

when working with clients or contractors.

Congurable Workow

Congurable workows ensure that your business and

compliance rules are enforced and tracked, even if yourequire electronic signatures or approval processes.

Again, the solution should be adaptable enough to

meet your business needs/requirements.

Congurable Naming and Labeling

Congurable naming and labeling helps encourage

user adoption of a new solution by allowing users to

change the names of development artifacts,

requirement types, specic elds, events, and reports

that match your business and compliance initiatives.

Trying to t in to canned naming conventions only

makes users more resistant to a new solution.

Congurable Automation Rules

Ensuring the right communication is happening in

your organization sometimes requires proactive

notifications, like emails or reminders based on

escalation rules. Congurable automation rules ensure

tasks or specic events are completed on time, based

on your business rules.

Eective Content Reuse

Item eld mapping allows for eective content

reuse in an organization, as artifacts transition from

requirements to test cases to test executions to issues.

Instituting content reuse between artifacts helpsprevent mistakes and establish a common language

across the organization.

Relationship Linking

Based on your business needs, creating and managing

links between artifacts can be accomplished manually,

suggestively, or automatically. Advanced parent-child

linking, many-to-many linking, and relationship

descriptions help identify the type of relationship that

exists with a link. These linking capabilities ultimately

enable the workings of good traceability practices:

validation matrices, suspect notifications, process

coverage, and forward and backward impact analysis.

Suspect Relationships Change Impact Analysis

When an artifact changes, it can impact other artifacts.

For example, a test case is impacted when a

requirement changes. Flagging or marking artifacts as

suspect can be automated by the system, or the user

can be prompted to ag linked artifacts as suspect.

Actionable Traceability Matrix

A traceability matrix is a tool that can assist in coverageanalysis, which can be represented in many ways, such as:

Requirement to Sub-requirements

Requirements to Test Cases

Test Cases to Test Runs

Test Runs to Issues

Traceability matrices also help in identif ying gaps

in artifact relationships. A traceability matrix may alsobe printed or exported for management or auditing

purposes. One advantage of an integrated product

development lifecycle solution is that the data is never

stale. As changes are made on a daily basis, the matrix

is automatically updated.


12/12

Cincinnati, Ohio I London, England I Melbourne, Australia I Munich, Germany

www.seapine.com

2011 Seapine Software, Inc. All rights reserved.

11

Some life sciences companies have a dedicated

resource who continually updates a spreadsheet that

generates their trace matrix. This spreadsheet is always

being updated, but never in real time. As a result, it

often includes human errors. This type of practice wasrequired before product development lifecycle

solutions arrived on the market.

Impact Analysis

Understanding the impact of a change is essential.

Knowing dependencies before a change is considered

or made provides a logical control over the process

workow. Complete product development lifecycle

solutions can show both forward and backward impact

analyses. These solutions can also generate reports

that provide this same data within a hierarchical view.

Traceability Reporting

All businesses have unique reporting needs to track both

internal and external goals and help ensure that they

are met. By providing strong traceability and objective

evidence reporting, the fear of failing internal or external

audits will be a thing of the past.

Transparency

If all of the above features are congured to match your

processes and language, then the system should provide

transparent traceability to the users. With an automatedproduct development lifecycle solution, you no longer

have to worry about duplications or trying to remember

to email team members about changes. An automated

solution will allow your users to do their daily jobs, analyze

key data, and feel condent that specic business and

compliance rules are being met by the system.

Need Help?

Many organizations nd it dicult to dedicate the time

or resources necessary to develop traceability strategies

and best practices. Some are afraid that one group or

department may take control without the consideration ofother groups and ideas.

Seapine Software can assist in these eorts by exploring

and creating a solution that works for everybody in your

organization. We have an experienced professional services

team that can help with discovery sessions, installation,

data migration, conguration, validation, and trainingservices. Contact your Seapine sales representative to

discuss how we can help improve your traceability strategy.

About Seapine

Seapine Software is a leading provider of

quality-centric Application Lifecycle Management

(ALM) solutions. Seapines software development

tools help organizations of all sizes streamline

communication, improve traceability, achieve

compliance, and deliver quality products. Over

8,500 companies use Seapines award-winning

tools for requirements management, software

change and conguration management, test case

management, issue and defect tracking, load

testing, and automated functional testing.

Seapines TestTrack product suite provides a

complete product development lifecycle solution

that has helped businesses achieve high levels of

compliance in some of the most strictly regulated

industries. TestTrack delivers actionable, real-time

traceability matrices that can be tailored to meet

your specic needs. Youll no longer be burdened

with stale, duplicate, or erroneous data. TestTrack

ensures your data is updated on a daily basis,

keeping your traceability matrix current.

TestTrack allows your team to do its job with the

condence that critical business and compliance

rules are being met.

Documents

Six Exercises Strengthen Trace Ability