Whitefield CALL GIRL IN 98274*61493 ❤CALL GIRLS IN ESCORT SERVICE❤CALL GIRL
Traceability: Why Connecting the Dots is Important
1. Traceability:Traceability:
Why Connecting the Dots isWhy Connecting the Dots is
ImportantImportant
International Project Management DayInternational Project Management Day
Friday, November 5, 2010Friday, November 5, 2010
2. Jennifer C. Colburn, CBAP, PMPJennifer C. Colburn, CBAP, PMP
Senior Business Analyst at Kindred HealthcareSenior Business Analyst at Kindred Healthcare
CBAP (Certified Business Analysis Professional) by theCBAP (Certified Business Analysis Professional) by the
IIBA (International Institute of Business Analysis)IIBA (International Institute of Business Analysis)
PMP (Project Management Professional) by PMIPMP (Project Management Professional) by PMI
(Project Management Institute)(Project Management Institute)
VP of Education for Louisville Chapter of the IIBAVP of Education for Louisville Chapter of the IIBA
2009-20102009-2010
Member of the IIBA’s Business Analysis CompetencyMember of the IIBA’s Business Analysis Competency
Model CommitteeModel Committee
Enjoys traveling to other countries.Enjoys traveling to other countries.
3. What is Traceability?What is Traceability?
Traceable –adjectiveTraceable –adjective
1. capable of being traced.1. capable of being traced.
2. attributable or ascribable (usually fol.2. attributable or ascribable (usually fol.
by to): a victory traceable to goodby to): a victory traceable to good
coaching.coaching.
http://dictionary.reference.com/browse/traceabilityhttp://dictionary.reference.com/browse/traceability
4. Connecting the DotsConnecting the Dots
http://appraisalnewsonline.typepad.com/photos/uncategorized/2007/12/19/connect_the_dots.jpghttp://appraisalnewsonline.typepad.com/photos/uncategorized/2007/12/19/connect_the_dots.jpg
5. Traceability for IT ProjectsTraceability for IT Projects
Enterprise TraceabilityEnterprise Traceability
Understanding how the project traces back toUnderstanding how the project traces back to
organizational goals.organizational goals.
Requirements TraceabilityRequirements Traceability
Tracing Business, Functional, and TechnicalTracing Business, Functional, and Technical
Requirements and Use Cases/Test ScriptsRequirements and Use Cases/Test Scripts
6. Enterprise AnalysisEnterprise Analysis
Understanding the “big picture”Understanding the “big picture”
DefineDefine businessbusiness goals the solution must meetgoals the solution must meet
Integrate requirements into largerIntegrate requirements into larger businessbusiness
architecturearchitecture
Support initiatives and long term planningSupport initiatives and long term planning
Strategic planning, business case development,Strategic planning, business case development,
CBA, feasibility studiesCBA, feasibility studies
““Why are we doing this?”Why are we doing this?”
From the Business Analysis Body of Knowledge v 2.0From the Business Analysis Body of Knowledge v 2.0
9. Where is the “Big Picture”?Where is the “Big Picture”?
Mission StatementMission Statement
Portfolio StrategyPortfolio Strategy
Business StrategyBusiness Strategy
Strategic InitiativesStrategic Initiatives
Success FactorsSuccess Factors
Balanced ScorecardsBalanced Scorecards
Business goals of your sponsorBusiness goals of your sponsor
10. Documenting EnterpriseDocumenting Enterprise
TraceabilityTraceability
SponsorSponsor
Project CharterProject Charter
Clearly stated Business ObjectivesClearly stated Business Objectives
SMART (Specific, Measurable, Achievable, Relevant, Time-SMART (Specific, Measurable, Achievable, Relevant, Time-
Bound)Bound)
Cost Benefit AnalysisCost Benefit Analysis
ROIROI
Change ControlChange Control
Relationship between project components and businessRelationship between project components and business
goals/objectivesgoals/objectives
12. Requirements TraceabilityRequirements Traceability
"In the requirements engineering field,"In the requirements engineering field,
traceability is about understanding how high-traceability is about understanding how high-
level requirements -- objectives, goals, aims,level requirements -- objectives, goals, aims,
aspirations, expectations, needs -- areaspirations, expectations, needs -- are
transformed into low-level requirements. It istransformed into low-level requirements. It is
therefore primarily concerned with thetherefore primarily concerned with the
relationships between layers of information."relationships between layers of information."
Requirements Engineering (Second Edition) Hull, Jackson & Dick.Requirements Engineering (Second Edition) Hull, Jackson & Dick.
13. Requirements TraceabilityRequirements Traceability
Prevent scope creep and/or gold platingPrevent scope creep and/or gold plating
Ensure a quality productEnsure a quality product
““Does the solution do what it is suppose to do?”Does the solution do what it is suppose to do?”
Facilitates Change ControlFacilitates Change Control
Assists in prioritization and future planningAssists in prioritization and future planning
““The ability to describe and follow the life of a requirement, in bothThe ability to describe and follow the life of a requirement, in both
a forward and backward direction (i.e. from its origins, througha forward and backward direction (i.e. from its origins, through
its development and specification, to its subsequent deploymentits development and specification, to its subsequent deployment
and use, and through periods of ongoing refinement andand use, and through periods of ongoing refinement and
iteration in any of these phases).”iteration in any of these phases).”
http://www.projectperfect.com.au/info_requirements_traceability.phphttp://www.projectperfect.com.au/info_requirements_traceability.php
14. Traceability MatrixTraceability Matrix
Associates the business and functional requirementsAssociates the business and functional requirements
with the use cases and test scripts that will be usedwith the use cases and test scripts that will be used
to validate them.to validate them.
Ensures completeness of testing and provides theEnsures completeness of testing and provides the
basis for test planning.basis for test planning.
Can be a stand-alone document or part of theCan be a stand-alone document or part of the
requirements document or test plan.requirements document or test plan.
Change Control- when a business requirementChange Control- when a business requirement
changes (or changes priority)- it can be identifiedchanges (or changes priority)- it can be identified
and updated easily throughout all documentation.and updated easily throughout all documentation.
http://www.slideshare.net/jennifercolburnhttp://www.slideshare.net/jennifercolburn
15. Traceability Matrix Example 1Traceability Matrix Example 1
Each Business Requirement decomposed to smallest package andEach Business Requirement decomposed to smallest package and
assigned a unique identifier. BR 001assigned a unique identifier. BR 001
Each Business Requirement will have one or more functionalEach Business Requirement will have one or more functional
requirements. FR 001.01, FR 001.02requirements. FR 001.01, FR 001.02
The relationship of driver (i.e. requirement) to satisfier
(i.e. use case or test script) can be one-to-one, one-to-
many, or many-to-one. Traceability requires unique
identifiers for each requirement and use case/test script.
16. Traceability Matrix Example 2Traceability Matrix Example 2
http://lh5.ggpht.com/_vdqOsYKAf0Y/Sjw5tKW4EyI/AAAAAAAAAXM/YoRVMRxsOgUhttp://lh5.ggpht.com/_vdqOsYKAf0Y/Sjw5tKW4EyI/AAAAAAAAAXM/YoRVMRxsOgU
/Sample%20Traceability%20Matrix2_thumb%5B2%5D.jpg/Sample%20Traceability%20Matrix2_thumb%5B2%5D.jpg
18. SummarySummary
Projects that are aligned with business goalsProjects that are aligned with business goals
provide value.provide value.
Enterprise Traceability proves alignment toEnterprise Traceability proves alignment to
business goals.business goals.
Requirements Traceability assists inRequirements Traceability assists in qualityquality
solutions that meet the business needs.solutions that meet the business needs.
Traceability allows for greater control ofTraceability allows for greater control of
inevitable changes during a project.inevitable changes during a project.
Notas do Editor
Traceability allows you to connect the dots from one point to another, both forwards and backwards. Why is connecting the dots important?
Sometimes traceability is REALLY important- last year the Christmas Day underwear bomber incident was attributed to a failure to connect the dots. Traceability can be really important on our projects as well. Fortunately, for most of us, our projects don’t involve life or death situations.
This presentation will cover 2 traceability concepts that are important to IT projects- these are relevant to Project Managers, Business Analysts, and any members of the project team including technical resources.
Some companies use software that traces organizational objectives all the way down to lines of code to capture the value of IT and ROI. For companies that don’t, it can still can be done in less automated ways through documentation.
To understand Enterprise Traceability you first need to understand Enterprise Analysis and Enterprise Architecture
What does success look like to the business? If you can answer this question, you can prove project value.
Formal enterprise traceability through documentation benefits the project- artifacts prove project value to organization.
Informal traceability- understanding how the project fits into the big picture- benefits the project team and can improve team moral and motivation. If they understand the relationship between stakeholder needs and what they are doing, then they understand the value they add.
How many are familiar with the Zachman Framework? Schema or Taxonomy used in enterprise architecture that asks What, How, When, Who, Where and Why across various stakeholders including Business, Systems, and Technology. Understanding the Business Model is key to IT.
Each row represents a distinct perspective, but the deliverables from each perspective must give enough detail to translate into the level beneath them in order to define the solution. Each level must understand the constraints of the other levels.
Planner = C-level view
Each perspective focuses on the same questions (the top row) and answers them from their viewpoint, creating models for each.
The Why column provides the business drivers for all other columns.
How do we know if our project addresses a critical need? How do we trace it to organizational goals & objectives?
Most organizations don’t have a “big picture” hanging on the wall somewhere. Some are too complex, some are not that mature,
Familiarize yourself with the organization’s mission, strategic initiatives, goals and more granular objectives.
Find out what your sponsor is managing, what goals are they being held to? What metrics are they responsible for? Your sponsor should provide insight into the business goals and objectives.
Even infrastructure projects can tie back to business objectives, as the infrastructure project is likely a dependency for other projects that are tied directly to business goals and objectives.
Documentation of the relationship between specific project components and business goals/objectives is important so that when a business goal/objective changes, or its priority changes, it is easier to determine and control changes
For Project Managers, this is similar to a WBS, where the large chunks of work are broken down into their smallest components, or tasks. Requirements are broken down from the high level objectives in the project charter to specific business requirements that are decomposed into their smallest package and given a unique identifier. The same process is then followed for functional and technical requirements. With this traceability, if a stakeholder priority changes, it is easier to reallocate resources. This information should be shared with the entire project team, so they have visibility into the “why” as well as what needs to be done if priorities change.
Traceability assists in preventing scope creep as a functional requirement must have a business requirement driver.
Traceability assists in delivering a complete solution, as every business requirement must be satisfied by a functional requirement, a technical requirement and a use case or test script.
It also assists program managers if a business rule that affects multiple projects is changed, it is much easier to determine impact across all effected projects as it relates to resources and budget.
Understanding the origin- who requested the requirement, the priority of the requirement, etc is important for the entire project team, including the BA, the PM and the developer. Requirement Management software is the best way to accomplish this. If your organization does not have these tools, it still can be accomplished using a spreadsheet
Following best practices, business requirements should be decomposed to the smallest package and numbered with the following numbering convention: BR001, BR002, etc. For each business requirement there will be one or more functional requirements that should match the numbering convention for the associated business requirement: FR001.01, FR001.02, FR001.03, FR002, etc. Functional requirements should be decomposed to the smallest package.
For each functional requirement, there will be one or more associated technical specs that should match the numbering convention of the associated functional requirement: TS001.01.01, TS001.01.02, TS001.02, etc. Technical specs should be decomposed to the smallest package.
For simplicity, Tech Specs can be kept in a separate spreadsheet (see Tech Spec Traceability Matrix).
Easiest to use an Excel Spreadsheet.
Line items in test scripts can be traced back to functional requirements, to allow for ease in updating test scripts when functional requirements change.