Requirements Repositories (1) - Modern...

0 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.

Requirements Repositories and

Reusability

How repositories and reusability can help achieve a

competitive advantage

Keith Ellis President & CEO

Enfocus Solutions

In partnership with:


What are we going to talk about?

• What creates value?

• Requirements are valuable when Connected and in Context

• Can repositories deliver standardization?


Enfocus Solutions: Achieving Business Analysis Outcomes


Requirements Excellence Framework™ Business Analysis Perspec0ve


Learning Objectives

• Best practices in knowledge management

• Building the business case for BA/Requirements Repository

• Challenges in building a repository

• Linking the repository to business architecture

• Promoting standardization and reusability


Repository could be anything…


PMBOK Requirement Types •  Business requirements, which describe the higher-level needs of the organization

as a whole, such as the business issues or opportunities, and reasons why a project has been undertaken.

•  Stakeholder requirements, which describe needs of a stakeholder or stakeholder group.

•  Solution requirements, which describe features, functions, and characteristics of the product, service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements:

o  Functional requirements describe the behaviors of the product. Examples include processes, data, and interactions with the product.

o  Nonfunctional requirements supplement functional requirements and describe the environmental conditions or qualities required for the product to be effective. Examples include: reliability, security, performance, safety, level of service, supportability, retention/purge, etc.

•  Transition requirements describe temporary capabilities, such as data conversion and training requirements, needed to transition from the current “as-is” state to the future “to-be” state.

•  Project requirements, which describe the actions, processes, or other conditions the project needs to meet.

•  Quality requirements, which capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements.

BABOK includes Business, Stakeholder , Func7onal, Nonfunc7onal and Transi7on requirements


Repositories: Behind the Scenes What is really being asked of employees?

Tacit Knowledge (“I understand something”

“It’s in my head”)

Codify (Write down, or model the knowledge)

Store (Select how

and where I put it)

Repository

Tacit Knowledge (“I understand something”)

Search (Find what

I need)

Utility (Understand why to use this knowledge)

De-Codify/ “Interpret” (Read, view,

interact)

Motivation Assumptions Have the

desire to help others

Have training & discipline

Have desire to

learn

Faster to go to the repository

than to just ask someone


How do repositories start…

Requirements Analysis

Requirements Management

Solu9on Assessment

Planning Monitoring Requirements Elicita9on

Risk Management

Process Improvement

Technology SME

Test Management

Technical Wri9ng

Quality Assurance Benchmarking

Project Management

Financial Analysis

Acceptance Criteria

Interviewing

Agile / Scrum

Waterfall

Dodd-‐Frank

COBIT

TOGAF

ISO/IEC 9126

Basel II/III

Data Management

UML

Six Sigma

SQL

HTML5

JavaScript CSS3

Business Rules

Data Dic9onary

Data Flow Diagrams

SOX Compliance

Balanced Scorecard

Change Management JAD Sessions

Focus Groups Func9onal Decomposi9on

Scheduling / Es9ma9on

Lessons Learned

Metrics / KPIs

Non-‐Func9onal

Analy9cal Thinking

Business Knowledge

Supply Chain Mgmt

Structured Analysis

XML

XBRL

FpML

ASP

PHP

.NET

VBScript

C/C++

Visual Basic

Observa9on

Organiza9on Modeling

Problem Tracking

Enterprise Architecture

Prototyping

Organiza9onal Change

Root Cause Analysis

Scenarios / Use Cases

Scope Modeling

Sequence Diagrams

State Diagrams

Data Migra9on

Survey/Ques9onnaire

Interface Analysis

User Stories

Vendor Assessment

Business Case

Dependencies

Valida9on

UI Design

BPMN

OCEB

OCUP CISA

CISSP

PRINCE2

IIBA XQuery

ISO 22301

NASCIO

ISO 31000

ISO 27001

BABOK

DMBOK

Patriot Act

CBAP

ITIL

PMP

Cloud Migra9on

Release Management

FERC

Balanced Scorecard

Programming Skills

FIX

Staff Development

COSO

ISACA


Differentiating Repository Variations

Requirements Repository

Requirements Hoarding

Requirements Modelling

Factual and Contextual Knowledge with Organization and Codification

All Knowledge, No Organization Extremely High Level of Codification


Golden Rules to Consider

•  People are more willing to search for knowledge than share

•  Every repository needs subject context to get contribution

• Codification is a balance: o  Too little and it’s hoarding o  Too much and it’s a single purpose system

•  Two types of integration need to occur to make repositories useful:

1.  Make the repository part of the daily work environment 2.  Insure the repository interacts with other information

systems within the organization


REPOSITORIES: WHAT CREATES VALUE?


Context is THE most important issue

Impact Who or What does it impact?

(Service, Persona, Process, Data, Rule)

History (Log of change,

approval and Implementation)

Work Flow (Who did the work, what’s next to do, issues, defects,

resolutions)

Intent (Expected

benefits for a sponsor)

PROJECT

Requirement Attribute Requirement Feature

WORK PRODUCTS (Attachments, models, etc.)

COLLABORATIVE

(Comments, shared actions,

etc)

STATE (Draft, Approved,

etc)

VERIFICATIONS

(Conditions of value)


Connected Requirements E

nter

pris

e A

rchi

tect

ure

Laye

r P

roje

ct

Laye

r

Requirements Repository (Project-focus, Transactional, Stakeholder oriented)

Architecture Repository (Planning-focus, Point-in-time snapshot, IT-oriented)

TOGAF

“CONNECTED REQUIREMENTS”

1)  Maintain the

synchronization between PLAN and ACTION layers

2)  Facilitate interaction between the Owners and Analysts

3)  Make it a closed, self-updating, loop


Manage Requirements Data not Documents

Requirements

Elicit

Analyze

Elaborate

Validate

Requirements consist a set of relationships: •  User Story or Shall

Statement •  Requirement acributes •  Rela9onships to other

objects like impacted data, services, personas, etc.

•  Priori9za9on •  Es9mates •  Business Rules •  Traceability •  Visualiza9ons •  Dependencies •  Review Comments •  Test Cases and Acceptance

Criteria •  Ac9on Items and Work

Tasks •  Requirement Change

History

•  Crea9ng Large Requirement Documents is an archaic prac9ce brought forward from the 70s

•  Requirement data is dynamic and no longer fits word processing or spreadsheet sofware

•  Crea9ng large paper requirements documents is slow, inefficient, and costly


Conclusions about VALUE and Best Practice What is “Reusable”

•  First and foremost - the CONTEXT of the requirements is necessary: o  An effective project archive is a showcase of context – who, did what, why,

using which workflow (how), to what outcome. o  Context is surprisingly repeatable - the same business conditions tend to

trigger a project

•  Repositories are the only way to synchronize architecture and IT service planning to the execution layer (project layer) of the business

•  Repositories allow you to change the way requirements are done… o  Manage data, not documents o  Do requirements in layers

•  Finally… what is likely the #1 requirements repository today?


BUILDING THE BUSINESS CASE FOR REPOSITORIES AND STANDARDIZATION


Building your business case

•  The 2% rule: 1.5% to 2% of requirements change per month… in an implementation over 24 months: o  ~40% of requirements change at least once and ~ 10% of requirements

change two or more times o  Cost of defect and change management vastly outweighs the cost to create

•  The 2X rule: If stakeholders routinely tell the analyst they are taking 2X the time expected, OR, analysts are taking 2X the time budgeted… o  It’s a signal of structural problems and you need the efficiency gain o  The payback is in the discipline

•  The 3X rule: Can you use a stored asset 3 times? o  The reuse of the asset vastly outweighs the effort to create and

store.

•  Quality, Agility, Stakeholder Satisfaction…

Why do you need a repository?


Our Value Proposition is Ultimately About Doubling Project On-Time, On-Budget and Success Rates Turning Business Ideas into Action

Source: Ellis, Business Analysis Benchmark 2009


MAKE THE REPOSITORY PART OF THE BUSINESS PROCESS


Large Documents or a Wall of Post-It Notes

Large Requirement Documents A Wall of Post-‐It Notes

Requirement data is too dynamic to use either of these methods.

How can this support changing requirements?

Can you imagine what the chief compliance officer might say when told these are

requirements for one of our strategic systems?

Waterfall Development Agile Development


Iterative and Incremental Itera0ve Incremental

When you work itera0vely you build what you can in one itera9on, then review it and improve it in next itera9on and so on un9l its finished. Requirements are built going through a con9nuous set of reviews by stakeholders and the business analyst. Business Analysts receive comments from stakeholders, make improvements to the requirements, and ask for comments

When you work incrementally you add components piece by piece un9l you are finished. Requirements are built in layers, star9ng with high level business objec9ves, decomposed into features, func9onal requirements, and various layers of detail for each requirement.


Requirements V-Model


Who owns Primary Responsibility for Requirements

Budget % of Target

Time % of Target

Func0onality % of Target

Stakeholder Time % of Target

IT 162.9 172 91.4 172.9

Business 196.5 245.3 110.1 201.3

Jointly Owned 143.4 159.3 103.7 163.4

Source IAG Business Analysis Benchmark, 2008

Joint Responsibility for Requirements Makes a Big Difference


REQUIREMENTS SKILL REPOSITORIES

Access to [a knowledge repository] explained 76% of the variability in the analyst’s domain knowledge”

Vitharana, Jain, Zahedi, 2010


RequirementCoach™ Analyst Community Knowledge Content

Analyst Briefs Methodology BA Techniques Prac9ce Aids

Prac9ce Guide Visualiza9on Methods

Reference Guides Third Party Materials


RequirementCoach™ Community of Practice for Business Analysis

A requirements tool is not enough to build mature

business analysis capabili9es.


Learning Objectives

• Best practices in knowledge management

• Building the business case for BA/Requirements Repository

• Challenges in building a repository

• Linking the repository to business architecture

• Promoting standardization and reusability


REMINDER: Enfocus Solutions - Achieving Business Analysis Outcomes

(psst… It’s the secret to successful projects)


QUESTIONS AND DISCUSSION

Getting the Slides: Email to: [email protected] Give us a little feedback, and Andrea will be happy to send you the slide deck

Requirements Repositories (1) - Modern...

Documents

Transcript of Requirements Repositories (1) - Modern...