0% found this document useful (0 votes)
113 views47 pages

TDWI Requirements Gathering Preview - v1

This document preview provides an overview of requirements gathering for business intelligence (BI) systems. It discusses gathering requirements at three levels - business, functional, and technical - with the process starting with business needs and progressing to define how systems will meet those needs. The preview includes sample pages that cover defining requirements before design, with a focus on architectural requirements defined at the program level to describe needed BI capabilities and how those map to functional and technical requirements.

Uploaded by

temp rao
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
113 views47 pages

TDWI Requirements Gathering Preview - v1

This document preview provides an overview of requirements gathering for business intelligence (BI) systems. It discusses gathering requirements at three levels - business, functional, and technical - with the process starting with business needs and progressing to define how systems will meet those needs. The preview includes sample pages that cover defining requirements before design, with a focus on architectural requirements defined at the program level to describe needed BI capabilities and how those map to functional and technical requirements.

Uploaded by

temp rao
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 47

Previews of TDWI course books are provided as

an opportunity to see the quality of our material


and help you to select the courses that best fit
your needs. The previews can not be printed.

TDWI strives to provide course books that are


content-rich and that serve as useful reference
documents after a class has ended.

This preview shows selected pages that are


representative of the entire course book. The
pages shown are not consecutive. The page
numbers as they appear in the actual course
material are shown at the bottom of each page.
All table-of-contents pages are included to
illustrate all of the topics covered by a course.
TDWI Requirements Gathering
Getting Correct and Complete Requirements for BI Systems

© The Data Warehousing Institute i


TDWI Requirements Gathering

All rights reserved. No part of this document may be reproduced in any form, or
by any means, without written permission from The Data Warehousing Institute.

ii © The Data Warehousing Institute


TDWI Requirements Gathering

TABLE OF CONTENTS Module 1 Requirements and the BI Lifecycle ,,,,,,,,,,,,,,,,,,,, 1-1

Module 2 Kinds of BI Requirements …………….………….. 2-1

Module 3 Requirements Gathering Techniques ………….. 3-1

Module 4 Requirements Management Techniques ……… 4-1

Module 5 Summary and Conclusion ……………………….. 5-1

Appendix A Bibliography and References …………………… A-1

Exercises ................................................................................ B-1

© The Data Warehousing Institute iii


TDWI Requirements Gathering

iv © The Data Warehousing Institute


TDWI Requirements Gathering Requirements and the BI Lifecycle

Module 1
Requirements and the BI Lifecycle

Topic Page
Kinds of Requirements 1-2

The BI Lifecycle 1-10

Requirements Before Design 1-14

Requirements and Testing 1-20

© The Data Warehousing Institute 1-1


Requirements and the BI Lifecycle TDWI Requirements Gathering

Kinds of Requirements
A Multi-Level View of Requirements

1-2 © The Data Warehousing Institute


TDWI Requirements Gathering Requirements and the BI Lifecycle

Kinds of Requirements
A Multi-Level View of Requirements

THE CHALLENGE Gathering business requirements for BI systems is more difficult than for
OF GATHERING operational systems. Without the specifics of business transactions,
scheduled reports, and prescribed business rules it is difficult to know
REQUIREMENTS
where to start and how to proceed.

The skill set for the BI requirements analyst includes techniques to


identify requirements, tools to manage requirements, and checklists to
ensure completeness.

Simply knowing where to begin is one of the difficulties of BI


requirements. The scope of BI is broad, the possibilities almost endless,
and the differences from traditional information systems not always fully
understood. Starting in the right place, then following a logical
progression from business to technical requirements is an important part
of requirements gathering.

GETTING STARTED Defined scope for a program or project is the essential starting place to
gather, define, and document requirements. A good scope document
expresses very high level requirements in terms of business capabilities,
services, or products that are needed.

FROM BUSINESS Specifying requirements at three levels – business, functional, and


TO TECHNICAL technical – provides a logical progression from what the business needs to
what a system does. Every requirements gathering process should begin
with business requirements, then define functional requirements, and
finally technical requirements. Functional requirements are driven from
business requirements, and technical requirements from both business and
functional requirements.

© The Data Warehousing Institute 1-3


Requirements and the BI Lifecycle TDWI Requirements Gathering

Requirements Before Design


Architectural Requirements

1-14 © The Data Warehousing Institute


TDWI Requirements Gathering Requirements and the BI Lifecycle

Requirements Before Design


Architectural Requirements

REQUIREMENTS Requirements are the essential first step of every BI program and project.
FIRST They are, in fact, the beginning for successful programs and projects of
many kinds – both technical and non-technical. The importance of
requirements is expressed in many popular phrases: Look before you leap.
Measure twice, cut once. Fools rush in. Each of these sayings expresses
the importance of thought before action. The wisdom of this simple
principle – think first, then act – is obvious. Thoughtful action saves time,
money, waste, rework, effort, frustration, and embarrassment.
For BI programs and projects the principle becomes real as the concept of
requirements first, then design. The idea of understanding requirements
before designing solutions applies regardless of scope and lifecycle – for
architectural, linear, iterative, and agile analysis and design processes.

PROGRAM LEVEL Business requirements at the program level describe BI capabilities that
REQUIREMENTS & are needed by the business. A good definition of BI serves as a guide to
the kinds of business requirements that are beginning of BI architecture.
BI ARCHITECTURE
Dave Wells’ definition (www.b-eye-network.com/wells) works well for
this purpose:
“Business Intelligence is the ability of an organization or business to
reason, plan, predict, solve problems, think abstractly, comprehend,
innovate, and learn in ways that increase organizational knowledge,
inform decision processes, enable effective actions, and help to
establish and achieve business goals.”
Architectural requirements progress from requirements for business
capabilities (reason, plan, etc.) to functional requirements that express
how to deliver capabilities (report, monitor, etc.), and finally to technical
requirements describing the roles of technology in delivering business
capabilities.

FOR EXAMPLE Business requirements: Managers understand how their organizations


perform against business goals, reason to determine causes of favorable
and unfavorable performance, and have necessary information to predict
future performance.
Functional requirements: Monitor performance against goals using
performance scorecards. Provide a visual overview of performance and
trends with ability for drill-down analysis.
Technical Requirements: Publish performance scorecards for each
business manager. Integrate scorecards with multi-dimensional data and
OLAP analysis capabilities.

© The Data Warehousing Institute 1-15


Requirements and the BI Lifecycle TDWI Requirements Gathering

1-28 © The Data Warehousing Institute


TDWI Requirements Gathering Kinds of BI Requirements

Module 2
Kinds of BI Requirements

Topic Page
The Scope of BI Requirements 2-2

Classifying BI Requirements 2-6

A BI Requirements Checklist 2-20

© The Data Warehousing Institute 2-1


Kinds of BI Requirements TDWI Requirements Gathering

The Scope of BI Requirements


An Overview
business
functional
technical

2-2 © The Data Warehousing Institute


TDWI Requirements Gathering Kinds of BI Requirements

The Scope of BI Requirements


An Overview

BI SPECIFIC The requirements types business, functional, and technical are generic.
REQUIREMENTS They apply to requirements for information and software systems of
many kinds. When working specifically with business intelligence it is
practical to further classify requirements into a structure that helps to
assure completeness of both the requirements gathering process and the
resultant set of requirements.

This module presents one such structure that categorizes BI requirements


into seven major groups and itemizes forty distinct kinds of requirements.

© The Data Warehousing Institute 2-3


Kinds of BI Requirements TDWI Requirements Gathering

The Scope of BI Requirements


Business in BI

from Putting the Business Back in BI: A Framework for Requirements and Value Management
© David L. Wells, Reprinted with Permission

2-4 © The Data Warehousing Institute


TDWI Requirements Gathering Kinds of BI Requirements

The Scope of BI Requirements


Business in BI

BUSINESS The facing page illustrates a business perspective of BI requirements as


a framework of three dimensions. The business management dimension
PERSPECTIVE encompasses areas of management such as strategy, finance,
marketing, sales, and other typical domains of business requirements..
The corporate governance dimension includes policy, compliance, risk,
and audit – common motivations for business requirements. The
measurement dimension includes measures, metrics, indicators,
indexes, references, and trends which often emerge as functional
requirements of BI systems.

Systematic attention to business management and corporate governance


first, followed by consideration of business measures, and finally the
technology to deliver measures will build BI systems that are truly
business driven – putting the business back into business intelligence.

At any intersection of the three dimensions you may find business,


functional, and technical requirements. And those requirements may
align with any of the seven categories described on the previous pages.

© The Data Warehousing Institute 2-5


Kinds of BI Requirements TDWI Requirements Gathering

A BI Requirements Checklist
Summary

Business Capabilities
Reporting
Analysis
Measurement
Monitoring and Forecasting
Visualization
Search
Business Value
Cost-Value Comparison
Return on Investment (ROI) and Return on Assets (ROA)
Strategic Value
Tactical Value
Operational Value
Business Services
Metrics
Monitoring
Analysis and Analytics
Query and Reporting
Data and Information
Support and Training
Business Applications
Information Systems
Monitoring Systems
Management Systems
Data Integration
Source Data
Data Consolidation
Data Quality
Granularity
Detail
Service Levels
Performance
Timeliness
Capacity
Security
Privacy
Availability
Recoverability
Technology
Data Management
Metadata Management
Data Integration
Data Warehousing
Information Delivery
Business Analytics
Data Mining
Infrastructure

2-20 © The Data Warehousing Institute


TDWI Requirements Gathering Kinds of BI Requirements

A BI Requirements Checklist
Summary

PUTTING IT ALL The facing page summarizes the topics of this module as a checklist of
TOGETHER forty kinds of requirements in seven groups. Collectively these categories
span the levels of requirements – business, functional, and technical – and
represent most of the common kinds of BI requirements. They may occur
as program-level and architectural requirements and as project-level and
product specific requirements.

© The Data Warehousing Institute 2-21


Kinds of BI Requirements TDWI Requirements Gathering

2-22 © The Data Warehousing Institute


TDWI Requirements Gathering Requirements Gathering Techniques

Module 3
Requirements Gathering Techniques

Topic Page
Requirements as a Human Process 3-2

Ten Techniques 3-12

© The Data Warehousing Institute 3-1


Requirements Gathering Techniques TDWI Requirements Gathering

Requirements as a Human Process


Roles and Skills

ROLES
analyst
subject matter expert
interviewer
surveyor
facilitator
documenter
observer
prototype builder
modeler
reviewer

SKILLS
communication
brainstorming
group dynamics
conversation
clarification
abstraction
precision
visualization
synthesis
analysis

3-4 © The Data Warehousing Institute


TDWI Requirements Gathering Requirements Gathering Techniques

Requirements as a Human Process


Roles and Skills

THE ROLES Each person involved in a requirements gathering process typically fills
one or more of the following roles:

Analyst responsible to collect, evaluate, correlate, and test


requirements information from many sources and using many
techniques,
Subject Matter Expert responsible to provide expertise and depth of
knowledge in a particular subject area, often business related and non-
technical,
Interviewer who systematically asks questions to gather information
that leads to defined requirements,
Surveyor responsible to develop, distribute, collect, and analyze
surveys,
Facilitator who helps a group to understand common objectives,
assists them to achieve the objectives, guides consensus building, and
diffuses conflict,
Documenter who objectively records the results of requirements
gathering sessions,
Observer who gathers information by watching as business activities
are performed,
Prototype Builder who is fast and flexible developer of tangible
examples and working models of information systems,
Modeler responsible to represent requirements as data models, use-
case models, process models, etc.,
Reviewer who provides evaluation and perspective about proposed
requirements definitions.

THE SKILLS The roles described above work together with these kinds of skills:

Communication – written and verbal, formal and informal


Brainstorming - creative and open to new ideas
Group Dynamics – with attention to participation and interaction
Conversation – informal and comfortable exchange of ideas
Clarification – by paraphrasing, questioning, and probing
Abstraction – finding patterns, moving from specific to general
Precision – with attention to accuracy and details
Visualization – communication with pictures and diagrams
Synthesis – combining of ideas, moving from parts to whole
Analysis – investigation, decomposing into parts and relationships

© The Data Warehousing Institute 3-5


Requirements Gathering Techniques TDWI Requirements Gathering

Requirements as a Human Process


Identifying Stakeholders

3-6 © The Data Warehousing Institute


TDWI Requirements Gathering Requirements Gathering Techniques

Requirements as a Human Process


Identifying Stakeholders

THE PEOPLE Getting the right people involves more than roles and skills. Equally
important are the right interests, and these come from the stakeholders. A
stakeholder is anyone whose job may be affected by the program or
project that is the subject of requirements analysis. Stakeholder interests
occur in several forms including:

Strategic – affecting the stakeholders’ ability to develop or execute


business strategy. Business executives and senior managers are most
likely to have strategic interest.
Financial – consuming or contributing to stakeholder financial
resources. Anyone funding the effort has a financial stake, as well as
anyone who may realize financial gains.
Procedural – affecting how business is conducted across several
processes, functions, or organizations. Anyone with cross-functional
responsibilities may have a procedural interest. Common examples
include internal auditors, risk managers, and compliance officers.
Organizational – affecting the stakeholders’ organization with respect
to structure, size, or scope of responsibilities. Line-of-business and
functional managers are likely to see their organizations changed by
BI programs and projects.
Tactical – affecting the stakeholders’ ability to define and execute
business tactics. Tactical stakeholders typically range from line
managers to knowledge workers.
Technological – affecting strategy, planning, management, and
support of technology. IT executives, IT managers, and technical
architects are likely to be technological stakeholders.
Political – affecting the stakeholders’ power and influence whether
real or perceived. Almost anyone can become a political stakeholder if
they see the BI effort as either an opportunity or a threat. It is wise to
involve those whose political positions will influence success or
failure of the effort.
Process-Oriented – affecting planning, management, or execution of
business processes in which the stakeholder participates. Process
stakeholders range from managers responsible for effectiveness and
efficiency of processes to knowledge workers who perform the
activities of those processes.

© The Data Warehousing Institute 3-7


Requirements Gathering Techniques TDWI Requirements Gathering

Ten Techniques
Surveys and Questionnaires

Documents or instruments that are …

Planned
Structured
Group Focused
Individually Completed
Impersonal
Informative

3-20 © The Data Warehousing Institute


TDWI Requirements Gathering Requirements Gathering Techniques

Ten Techniques
Surveys and Questionnaires

WHAT Surveys and questionnaires are impersonal methods to collect information


from stakeholders. They are sometimes described as “the electronic
interview” but lack the conversational aspect that makes interviewing a
powerful technique.

WHY Surveys and questionnaires are most effectively used to get information
from a large number of participants, to gather consistent data from
members of a group, and as a means to collect data that can is easily
summarized and aggregated.

HOW Surveying is a process of multiple steps that are more complex than they
may appear to those who receive and complete surveys. A complete
survey process includes steps to:

Develop a survey or questionnaire that is purposeful, non-ambiguous,


self-explanatory, and quick to complete. Depending on the purpose
you may also want the survey to quantify by using a numeric scale for
responses.
Identify the group of participants considering population size,
knowledge areas represented, and the response rate that you desire
and expect.
Collect the data by distributing and collecting surveys. Distribution
medium is important here – email, web, etc. Also consider how you
will track responses and follow up with unresponsive people.
Analyze, aggregate, and summarize responses. How the analysis is
performed is directly related to the purpose of the survey.
Integrate and correlate survey results with other requirements
information. Surveys alone are never sufficient to elicit requirements
with confidence.

WHEN Surveys and questionnaires are particularly valuable to elicit requirements


from geographically dispersed stakeholders who can’t be brought together
for group sessions or easily interviewed in a face-to-face meeting. They
are frequently used when working with broad scope projects, and to
collect information from a large number of stakeholders. Surveys may
help to engage the disconnected stakeholder. Their impersonal nature is
useful when you need to understand sources and causes of conflict.

WHO A skilled surveyor and the stakeholder population to be surveyed.

© The Data Warehousing Institute 3-21


Requirements Gathering Techniques TDWI Requirements Gathering

Ten Techniques
Interface and Use Case Analysis

A requirements analysis activity that …

Examines scenarios (cases) of system use


Analyzes requirements from actor (user) perspective
Describes actor-system interactions
Models each case as a sequence of events
Uses events to determine functional requirements

3-32 © The Data Warehousing Institute


TDWI Requirements Gathering Requirements Gathering Techniques

Ten Techniques
Interface and Use Case Analysis

WHAT Interface analysis is the activity of understanding how a system interacts


with entities (people or other systems) that are external to the system. Use
case analysis is a formal analysis and modeling technique that extends
interface analysis to describe the behavior of a system as it responds to
external stimulus.

Bittner and Spence describe it this way: “Use cases, stated simply, allow
description of sequences of events that, taken together, lead to a system
doing something useful.” (Kurt Bittner, Ian Spence (2002). Use Case
Modeling. Addison Wesley Professional, 2-3. ISBN 0-201-70913-9)

The “something useful” is ideally the essence of business and functional


requirements.

WHY Understanding system requirements from the perspective of the people


who will interact with a system is a common sense approach to getting
the right requirements. Well written Use cases have proven to be easily
understandable by business people, and thus to bridge communication
between business and technical stakeholders. Use cases put requirements
in context, describing them in clear relationship to business tasks.

HOW Each use case focuses on describing how to achieve a goal or task. For
most software projects this means that multiple, perhaps dozens, of use
cases are needed to define a robust set of requirements. The degree of
formality in interface or use case analysis varies widely from simple text
descriptions of business scenarios to UML-based use-case models.
Regardless of formality and detail, analysis should minimally identify:

the scenario being described,


triggering actions and events
a normal course of actions from trigger to response
alternative and exception paths that deviate from the normal course
actors who perform each action in a course of events

WHEN Interface analysis effectively supplements other requirements methods by


making requirements personal: How will you interact with the system? It
is useful when either innovation or speed is needed, and may help to
overcome low stakeholder involvement.

WHO A skilled analyst working with business stakeholders.

© The Data Warehousing Institute 3-33


Requirements Gathering Techniques TDWI Requirements Gathering

Ten Techniques
Summary

geographic or logistics difficulty


poor stakeholder participation
large number of stakeholders

conflict, territorialism, politics


large project / broad scope

existing system influence


high level of uncertainty
high level of complexity

need for innovation

need for speed


Group Facilitation !
Interviewing

Brainstorming !
Surveys & Questionnaires !
Prototyping !
Observation

Current State Analysis !


Reverse Engineering !
Requirements Workshops ! !
Interface & Use Case Analysis

3-34 © The Data Warehousing Institute


TDWI Requirements Gathering Requirements Gathering Techniques

Ten Techniques
Summary

CHOOSING The matrix on the facing page summarizes the ten techniques just
REQUIREMENTS discussed and associates them with some of the common considerations
and challenges of requirements gathering. Use it as a guide to select the
TECHNIQUES
techniques that best fit your project profile.

Every requirements gathering effort is likely to use more than one


technique. Key stakeholders are typically interviewed as a core method of
gathering requirements. Other techniques are used to enrich the
requirements process. Consider these guidelines when choosing
requirements techniques:

Requirements workshops work will for large projects, broad scope,


and large numbers of stakeholders.
Brainstorming is a good fit when innovation is needed.
Prototyping works well to address uncertainty and rapid discovery
when speed is critical.
Current system analysis fits when existing systems have strong
influence.
Group facilitation helps in projects where conflict, territorialism, and
politics are barriers.
Surveys and questionnaires can help with geographic and logistics
challenges.
Highly complex projects need to use a combination of several
techniques including brainstorming, prototyping, and observation of
existing processes.
Poor stakeholder participation can be addressed using several methods
including group facilitation and requirements workshops.

© The Data Warehousing Institute 3-35


Requirements Gathering Techniques TDWI Requirements Gathering

3-36 © The Data Warehousing Institute


TDWI Requirements Gathering Requirements Management Techniques

Module 4
Requirements Management Techniques

Topic Page
Requirements as a Systems Process 4-2

Collecting Requirements 4-10

Documenting and Modeling Requirements 4-14

Testing Requirements 4-20

Managing Requirements 4-24

© The Data Warehousing Institute 4-1


Requirements Management Techniques TDWI Requirements Gathering

Requirements as a Systems Process


Systems and Requirements Gathering

4-2 © The Data Warehousing Institute


TDWI Requirements Gathering Requirements Management Techniques

Requirements as a Systems Process


Systems and Requirements Gathering

THREE STAGES Gathering requirements is more than a task. It is a process of multiple


steps that are commonly described as elicit, specify, and test (EST).
Alternative terms for the three-step process include elicit-model-test
(EMT) and elicit-define-test (EDT). Regardless of the terminology that
you choose the three steps are important to recognize and to apply.

ELICIT Requirements elicitation is the activity of obtaining the requirements for a


REQUIREMENTS developing system from the stakeholders. Steve McConnell says "The
most difficult part of requirements gathering is not documenting what the
users 'want'; it is the effort of helping users figure out what they 'need'
that can be successfully provided …” (Software Project Survival Guide,
McConnell, Microsoft Press, 1998). McConnell’s statement captures the
essence of eliciting requirements – finding what is needed.

SPECIFY Requirements specification (or documentation, or modeling) is the act of


REQUIREMENTS recording a description of each requirement. Every requirement describes
a necessary attribute of a system – a capability or characteristic that the
system must have to provide utility and value to its users. A well-
specified requirement includes:

What – A descriptive statement of the requirement that describes a


system capability, characteristic, function, feature, or quality.
Why – The rationale for the requirement describing the purpose or
value to be achieved.
Who – The source of the requirement and the stakeholders who will
receive benefit.

Whether recorded as text (specify, document) or as diagrams (model)


describing requirements is an important and separate step from eliciting
requirements.

TEST Requirements testing is the third and final step of the process. Each
REQUIREMENTS requirement must be evaluated with respect to ensure that it is clear, non-
ambiguous, complete, consistent, necessary, and feasible.

© The Data Warehousing Institute 4-3


Requirements Management Techniques TDWI Requirements Gathering

Collecting Requirements
Capturing Requirements
Identity What? Why? Who?

A declarative statement and a complete sentence.

4-10 © The Data Warehousing Institute


TDWI Requirements Gathering Requirements Management Techniques

Collecting Requirements
Capturing Requirements

SPECIFY, MODEL, There are many ways in which requirements can be captured and
OR DOCUMENT? recorded. It is that variety that causes the diffusion of language about
requirements gathering – EST, EMT, or EDT. Note that the differences
are entirely about the way in which requirements are recorded: specify,
model, or document. Debate about which is the right way is pointless.
There is no single “best” way to record requirements. The only correct
answer is to use a method and format that works for you and your
requirements team.

SOME GUIDELINES Regardless of the form in which you choose to record requirements, some
guidelines will help to achieve well written requirements statements.
Some of the guidelines found among widely accepted best practices for
requirements gathering:

Write in complete sentences, not with fragments.


Use simple sentences. Avoid compound and complex sentences that
are strung together with conjunctions.
Write, declarative statements using words such as “is” and “will.” For
example:
o The budget variance report will drill down to detail transactions.
o Budget to actual revenue data is available as summary with drill-
down to detail.
Write in business language, avoiding technical jargon.
Confirm that each statement is concise and free of excess or
unnecessary words.
Confirm that each statement is clear and free of language that is
ambiguous or subject to interpretation.
Reinforce text requirements statements with examples, diagrams,
sample data, etc. whenever practical..

© The Data Warehousing Institute 4-11


Requirements Management Techniques TDWI Requirements Gathering

Testing Requirements
Testing Completeness

All levels of requirements?


(business, functional, technical)

All categories of requirements?


(check against project scope and purpose)

All stakeholders represented?


(strategic & tactical, business & IT, executive & management …)

4-22 © The Data Warehousing Institute


TDWI Requirements Gathering Requirements Management Techniques

Testing Requirements
Testing Completeness

SCOPE OF Completeness needs to be verified in two ways. First check the


COMPLETENESS completeness of each individual requirements specification – is it fully
defined according to the conventions established by a requirements
TESTING
specification template: Have you collected all of the attributes? Then test
that the set of requirements collectively represents the full scope and
charter of the project.

COMPLETE FOR Check completeness by asking:


PROJECT SCOPE
Have we addressed all levels of requirements – business, functional
and technical?
Do we have all important categories of requirements? Check against
project scope and an outline or check list as described in mistake #8.
Are all of the stakeholders represented – strategic and tactical,
business and technical, executive and management?

© The Data Warehousing Institute 4-23


Requirements Management Techniques TDWI Requirements Gathering

Managing Requirements
Managing Scope

4-24 © The Data Warehousing Institute


TDWI Requirements Gathering Requirements Management Techniques

Managing Requirements
Managing Scope

EXPANSION It is common when gathering requirements to find that discussion of one


business need leads quite naturally to related topics and needs. Sometimes
the adjacent topics fall within the scope defined for the effort, and
sometimes they do not.

Be careful not to cry “OUT OF SCOPE!” each time a new subject arises.
That is the fast track to unhappy and disengaged stakeholders. And it is
often difficult to know whether a new topic is in scope until it has been
explored.

COMPRESSION Sometimes it is necessary to compress scope – to place out-of-scope some


less critical items as a project management measure to work within
schedule and budget constraints. This approach is common with rapid and
agile development methods. In these instances, don’t lose the
requirements. Simply tag them as out-of-scope for the current project.
They are likely to resurface within the scope of a future project.

SCOPE CREEP AND Expanding scope can easily become creeping scope – gradual and
CONTAINMENT unintended expansion of project size and complexity. Compressed scope
risks loss and rework unless out-of-scope requirements continue to be
tracked. Both of these circumstances can be managed by adding one or
more columns to your requirements management document. Depending
on your particular needs, consider columns for:

In-Scope-Indicator – where the values recorded are yes, no, or


undecided.
In-Scope-Project – where the values recorded are project names or
identifiers to track one set of requirements across a series of projects.
In-Scope-Date – where the values recorded are dates by which a
project needs to satisfy the requirement.

© The Data Warehousing Institute 4-25


Requirements Management Techniques TDWI Requirements Gathering

4-34 © The Data Warehousing Institute


TDWI Requirements Gathering Summary and Conclusion

Module 5
Summary and Conclusion

Topic Page
Best Practices for Requirements Management 5-2

Summary of Key Points 5-4

References and Resources 5-6

© The Data Warehousing Institute 5-1


Summary and Conclusion TDWI Requirements Gathering

Best Practices for Requirements Management


Dos and Don’ts

5-2 © The Data Warehousing Institute


TDWI Requirements Gathering Summary and Conclusion

Best Practices for Requirements Management


Dos and Don’ts

A GUIDE TO GOOD The facing page itemizes ten guideposts for successful and effective
REQUIREMENTS requirements management. Keeping this list in mind (and perhaps visibly
posted) whenever doing requirements work will increase both
MANAGEMENT
effectiveness and efficiency of your requirements processes.

© The Data Warehousing Institute 5-3


Summary and Conclusion TDWI Requirements Gathering

5-8 © The Data Warehousing Institute


TDWI Requirements Gathering Bibliography and References

Appendix A
Bibliography and References

© The Data Warehousing Institute A-1


TDWI Requirements Gathering Exercises

Exercises
for TDWI Requirements Gathering

Topic Page
Scenario B-2

Exercise One: Initial Thoughts B-4

Exercise Two: A Quick Self Assessment B-6

Exercise Three: Requirements Planning B-8

Exercise Four: A Requirements Survey B-10

Exercise Five: Interviewing B-12

Exercise Six: Specifying Requirements B-14

© The Data Warehousing Institute B-1

You might also like