Sailing in Requirements Management Cross Currents - www.manageware.co.il Seminar

Clickin cross currents:title text format
Sailing
to edit the
setting your course amidst the many current
approaches to requirements

Click to edit the outline text format
Second Outline Level
Third Outline Level
– Fourth Outline Level
Daniel Moul & Keith Collyer
– Fifth Outline Level
Requirements Outline Level
– Sixth Product Delivery Team
dmoul@us.ibm.com & keith.collyer@uk.ibm.com
– Seventh Outline Level
RDM 2023B
– Eighth Outline Level
– Ninth Outline Level

The premiere software and product delivery event.
June 6–10 Orlando, Florida
‹#›

1

Abstract
Click to edit the title text format

Click development? Manufactured products? Packaged applications? SOA? Agile?
Web to edit the outline text format
System requirements specifications? Use cases? User stories? Faced with the
many competingLevel of projects and approaches to creating and managing
Third Outline types
requirements, how can you determine which are right for your organization?
This session will survey major approaches, provide a framework to help you
– Sixth Outline Level
assess–them, and offer some keys to successful implementation based on years of
Seventh Outline Level
IBM Rational and Telelogic experience.

‹#›
2

2

In your edit the title text which
Click to current project …format ship are you sailing?

Third Outline Level

‹#›
3

There are many kinds of ships because they are optimized for different goals, environments,
people and cargo.
Same with software and systems delivery projects.
You shouldn’t attempt to create the One Right Requirements Process for your organization.
The important thing is to understand each project’s goals, environment and constraints, and
optimize your requirements process for that project with them in mind. In this session we will
offer a framework for doing that.

3

On terminology

Clicktoday let’s outline textall of these “RM”
For to edit the consider format
Requirements Management
Requirements Level
Third Outline Engineering
Requirements Definition
Sometime we’ll use
“practices” to mean
“process”

‹#›
4

4

Not every requirement is called
Click to edit the title text format a requirement

Gaps in Outline Level
Second
Packaged
Third Outline Level Capability
Applications Gap
(military)

Regulations
Business
Policies
Rules
Standards

‹#›
5

And not everyone doing requirements management realizes that’s what they are doing

5

Why to you need a text format
Click do edit the title requirements process?
Isn’t a requirements tool enough?

Click to edit the about people and process
Effective RM is outline text format
Third Outline Level
Process is whole-team behavior
Tools enable and accelerate process

‹#›
6

Process is whole-team behavior – much better if it’s premeditated rather than ad hoc
Promotes (and requires) discipline: “We agree we aspire to …”
Promotes situational awareness and reflection
“Are we doing / did we do what we said we would?”
Promotes predictability
Promotes quality

Requirements tools enable and accelerate your requirements process

Requirements Management is more about people, skills, and process than tools.

Tools are not a magic silver bullet.
Requirements is

6

The to edit the title text format
ClickBusiness Environment Determines Project Parameters

Click to edit customer or contractor?
Are you the the outline text format
What are Outline Level terms?
Second the financial
Third Outline Level
Who is responsible for what?

‹#›
7

The business environment also has a major impact on the optimal requirements process.

7

Projects are commissioned to meet business goals
Program & Portfolio
Management
Second Business strategy
Outline Level
Objectives & priorities
Third Outline Level
Business cases
Project proposals
Project selection
Project charters

Vision documents
Requirements identified
Project execution

Project Management
‹#›
8

Start with portfolio prioritization: Which projects will we undertake?
Outcomes, Benefits & Risks
Costs: Time, Effort, Money
Timing: Short term, quick return OR Strategic, capital investment

8

Different projects need different governance
Uncertainty and risk are the key discriminators

Click to edit the outline text formatConstruction
Inception Elaboration Transition/Maintenance
Variance in Cost, Schedule, …

Third Outline Level
New New Capability Maintenance and
Platform on existing small change
– Fifth Outline Level platform requests

High Variance Medium Variance Low Variance

Time

‹#›
9

Uncertainty in understanding of the problem and the solution
Leads to risk that the project will not deliver what’s needed (or that adjusting to
new knowledge will cost unanticipated money, schedule, etc)
Also early on there is a lot of execution risk: how effective/productive will the
team be?

Source of chart: Murray Cantor & Walker Royce

9

Project delivery is an exercise in removing uncertainty

Initial Plan
Initial State
Third Outline Level Initial Planned Path Uncertainty in
Stakeholder
– Fourth Outline Level Satisfaction
Space
Actual Path
Acceptable
– Seventh Outline Level solution set
Points of feedback,
– Eighth Outline Level learning, and adjustment Delighted
customers

Feedback course corrections better outcomes

10

‹#›
As often as possible (especially early in the project), get feedback and reset path. This
provides feedback for a steering mechanism.
Rational consultants consistently report that “becoming more iterative” is the most
valuable change that the teams can make, precisely for the reasons shown here.


10

Managing Uncertainty = Managing Variance

A completion date is not a point in time, it is a probability distribution
0 Third Outline Level 6 12
Scope is not a requirements document, it is a continuous negotiation
Scope Sixth Outline Level
–
Product features / quality
Plans / resource estimates Level
– Seventh Outline
A plan– NinthaOutline Level it is an evolving,
is not prescription,
moving target Uncertainty in
Stakeholder
Satisfaction Space

Initial State Initial Plan
Actual path and precision of Scope/Plan

‹#›
11

On large systems projects the key variables tend to be cost and schedule,
particularly later in the project. After all, your ships need to float and your planes
need to fly regardless.
On IT projects often there is more opportunity to reduce scope and hold cost or
schedule constant.


11

Click to Requirements Hierarchy – two views
Typical edit the title text format

Typical Systems View
Typical IT View
Third Outline Level Problem
Problem
Stakeholder
Problem
– Fifth Outline Requirements
Level

hy
Definition
Problem Space

rarc
– Sixth Outline Level Needs

Hie

Tra
Ta
Abstract System Solution

ent

cea

e b
Solution Requirements Features

rem
Space

billii

ty
qui
Re
Software
Design Requirements
Mech Elec S/W Human

Interfaces

‹#›
12

Should be possible to change the design without changing the system
requirements
You need to be cognizant of when you are working on problem vs solution
domain
Am I trying to understand the problem or trying to create a solution
to that problem?
Present in sw world but not as big an issue
Need to be aware when the gap is so small that we go straight to solution
more common in IT projects, maintenance projects
Need to update docs afterward a la Parnas

Managing requirements involves the translation of stakeholder requests
into a set of system features. These in turn are detailed into specifications
for functional and nonfunctional requirements. Detailed specifications are
translated into test procedures, design, and user documentation.

The above diagram doesn’t show the use of requirements to guide the
work of the project team or for showing that what you are delivering
actually meets the requirements. This of course is hugely valuable.

12

Progressive removal of format
Click to edit the title textuncertainty
Requirements
Definition
Stakeholders identified Highly diverse,
Requirements collected unstructured
Third Outline Level
Domain knowledge & information
terminology
System scope determined
– Sixth Outline Level Problem statement
Requirements selected
Requirements flow-down
Structured information

Solution design
Requirements
Engineering
Like sand in an hourglass, this can be a continuous process ‹#›
13

This does not suggest a waterfall process
The grains of sand are your requirements becoming clear during the
various iterations / stages of your project.
This metaphor doesn’t capture the feedback loops either

13

Models: Low-cost ways format
Click to edit the title text to learn early
Optimize for learning / adjusting

Visual
Click to edit the outline text format Simulations
Models
Third Outline Level
– Fourth Outline Level Performance
System
– Fifth Outlinecontext diagrams
Level Load testing
Business Process
Sequence diagrams
Diagrams Monte Carlo Financial Return
– Seventh Outlineflow
Functional Level BPMN
– Eighthblock diagrams
Outline Level
Cost & Duration
Venn
– Ninth Outline Level Project Planning
UI simulations
diagrams IDEF
Stresses, heat
Use Cases CAD/CAM flow, air flow
Pictures
Screen shots
Manufacturability
Story boards Prototyping
Behavior

‹#›
14

Modelling helps you to …
•Understand a problem
•Reason about a solution
Analyze & Optimize
•Communicate with stakeholders

14

Economics the title text format
Click to editdetermine many of the possible optimizations
Optimize for learning and adjusting as much as possible within your constraints

What can you optimize?
What are Outline Level economics?
Second the underlying
Third Outline Level
Value of being fast-to-market
Cost of failure
Cost Fifth Outline Level
– of change
Cost Sixth Outline Level
– of communication
Cost Seventh Outline Level
– of non-compliance
Cost Eighth Outline manufacture
– of design and Level

‹#›
15

We often don’t recognize that we are evaluating economic dynamics when intuitively choosing
the processes we use.

15

Industry patterns reveal format
Click to edit the title text optimized groupings

Click to industry outline text format
Unique edit the characteristics
Government / private
Manufactured systems / IT
Third Outline Level
Patterns Fifthreflected in culture
– are Outline Level

‹#›
16

Systems - Key Drivers
Increasing complexity
SW is a growing % of product value
Complex sub-contractor scenarios
Faster time to market
More predictable outcomes

IT - Key drivers
Lower cost
Faster time to market
More predictable outcomes

16

Project have various cultures
Group Requirements Focus
Engineering & Compliance culture RM in an engineering process
Good outcomes the the result of good,
Click to edit are outline text format • Formal process
controlled processes.Level we missed
Second Outline “Have • Manufactured systems
anything?” • Mission-critical systems
Third Outline Level • Regulated, compliance, and contract-driven
– Fourth Outline Level industries
Market-driven culture Level
– Sixth Outline Effective teams, efficient tools
Balance process and expedience. “How can • Business-oriented software applications
we get this out faster with good quality?” • Fast-to-market manufacturers
ALM minimalist culture Level
– Ninth Outline Use development and test tools
“We use our main tools for requirements too” • Requirements by and for dev and test
• Typically business analysts are not involved

Ad-hoc culture Using general-purpose tools at hand
“What is RM?” • May employ some RM, “pure agile”
“We don’t do RM” methodologies or no defined methodology at all
“We get by with office docs”

‹#›
17

We see these differences … we get “psychic whiplash” when we talk to engineering
team then to IT team in the same organization

17
17

Management Techniques in Organization Culture (extract)
Base Technique Engineering - Market- ALM Ad hoc
Lifecycle Compliance driven minimalist
Waterfall BDUF Y
Complete stages
Click to edit the outline text format Y
Single release Y
Complete plan Y Plan, what plan?
Incremental Outline Level
Third BDUF Y
Parallel implementation Y Y Y
Early release Y Y
Iterative / Large-scale iteration Y Y
Evolutionary Plan complete at high level Y Y
Cost-benefit driven Y Y Y
– Eighth at every release
Value Outline Level Y Y
Each release "complete" Y Y
Small releases ? Y Y
Just enough planning Y Y
Agile User stories Y Y Y
Time-boxing Y Y
Test-driven Y Y
Work-item list Y Y Y
Common Evaluate against plan Y Y Y
Compliance-checking Y ?
Feedback Y Y Y Y
Consistency check Y Y Y ‹#›
18

Definitions of different lifecycle types:
•Waterfall: Each stage (typically Requirements, Design, Implementation, Test) is separate.
The output of each stage is the input to the next. In principle, the stages are carried out
consecutively, though in practice there will be significant feedback. All lifecycle models use
waterfalls in practice, though some of the disadvantages are often mitigated by making the
“size” of the waterfall small
•Incremental: The incremental model is similar to the waterfall model, except that after the
design is completed, the implementation and subsequent stages are divided into delivery
increments. Each increment is delivered separately, typically sequentially though occasionally
in parallel.
•Iterative / Evolutionary: Like the incremental lifecycle, the iterative or evolutionary lifecycle
delivers in parts. The significant difference is that each iteration is complete in itself, though
small compared to the envisaged scope of the entire project. Decisions are taken on what
should be delivered in each iteration on the basis of cost-benefit analysis.
•Agile: The agile approach is essentially a development of the evolutionary approach. The
most significant differences are not in the planning approach but in the ways in which the
system is defined. However, time-boxing (restricting development stages to a few weeks) is
specific to agile development, and the use of a work-item list (based mainly on change
requests) is common.

18

Click to edit theconstraints – Example: IBM agility@scaleTM
Consider other title text format

Team size Compliance requirement
Click to edit the10
Under
outline text format
1000’s of
Low risk Critical,
developers developers
Second Outline Level Audited

Third Outline Level
Geographical distribution Domain Complexity
Straight Intricate/
– Sixth
Co-located OutlineGlobal
Level -forward Emerging
Enterprise discipline Organization distribution
– Ninth Outline Level (outsourcing, partnerships)
Project Enterprise
focus focus Collaborative Contractual

Organizational complexity Technical complexity
Flexible Rigid Heterogeneous,
Homogenous Legacy

‹#›
19

In the early days of agile, the applications where agile development was applied were smaller in scope and
relatively straightforward. Today, the picture has changed significantly and organizations want to apply agile
development to a broader set of projects. Agile hence needs to adapt to deal with the many business,
organization, and technical complexities today’s software development organizations are facing. This is what
Agility@Scale(TM) is all about – explicitly addressing the complexities which disciplined agile delivery teams
face in the real world.
The agile scaling factors are:
Geographical distribution. What happens when the team is distributed, perhaps on floors within the same
building, different locations within the same city, or even in different countries? Suddenly effective
collaboration becomes more challenging and disconnects are more likely to occur.
Team size. Mainstream agile processes work very well for smaller teams of ten to fifteen people, but what if the
team is much larger? What if it’s fifty people? One hundred people? One thousand people? Paper-based,
face-to-face strategies start to fall apart as the team size grows.
Compliance requirement. What if regulatory issues – such as Sarbanes Oxley, ISO 9000, or FDA CFR 21 –
are applicable? These issues bring requirements of their own that may be imposed from outside your
organization in addition to the customer-driven product requirements.
Domain complexity. Some project teams find themselves addressing a very straightforward problem, such as
developing a data entry application or an informational web site. Sometimes the problem domain is more
intricate, such as a bio-chemical process monitoring or air traffic control or perhaps it is changing quickly,
such as financial derivatives trading or electronic security assurance. More complex domains will require
greater emphasis on exploration and experimentation, including but not limited to prototyping, modeling, and
simulation.
Organization distribution. Sometimes a project team includes members from different divisions, different
partner companies, or from external services firms. This lack of organizational cohesion can greatly increase
the risk to your project.
Technical complexity. Some applications are more complex than others. It’s fairly straightforward to achieve
high-levels of quality if you’re building a new system from scratch, but not so easy if you’re working with
existing legacy systems and legacy data sources which are less than perfect. It’s straightforward to build a
system using a single platform, not so easy if you’re building a system running on several platforms or built
using several disparate technologies. Sometimes the nature of the problem that your team is trying to
address is very complex in its own right.
Organizational complexity. Your existing organization structure and culture may reflect traditional values,
increasing the complexity of adopting and scaling agile strategies within your organization. To make matters
worse different subgroups within your organization may have different visions as to how they should work.
Individually the strategies can be quite effective, but as a whole they simply don’t work together effectively.
Enterprise discipline. Most organizations want to leverage common infrastructure platforms to lower cost,
reduce time to market, and to improve consistency. To accomplish this they need effective enterprise
architecture, enterprise business modeling, strategic reuse, and portfolio management disciplines. These
disciplines must work in concert with, and better yet enhance, your disciplined agile delivery processes.
Each factor has a range of complexities, and each team will have a different combination and therefore will need 19
a process, team structure, and tooling environment tailored to meet their unique situation.

Value to stakeholders should determine RM priorities

Practitioners Team Leaders Executives
Many common aspirations: Regulatory &
Improvement in Requirements Quality

Second Outline Level Contractual
• Improve productivity
Third Outline Level
• Reduce rework Compliance
–• Fourth Outline Level right
Get the requirements
• Make customers happy Manage
– Fifth Outline Level Scope &
• Meet business goals
– Sixth Outline Level Change

– Seventh Outline Level Re-use Deliver to
Cost &
– Eighth Outline Level Audit Schedule
Trail Traceability Constraints
Visible
Context between
Scalable
Common Role-Based Reqts
Repository Access
Tailorable
RM
Handle Process
Complexity

Increased use of Requirements Management Good Practices
‹#›
20

Each stakeholder looks through the lens of his/her personal ROI: What’s it going to cost me? What’s in it for me?
Executives won’t get the benefits they seek if the middle managers and practitioners don’t get what they seek.

Some examples
•Scalable Common Repository: a common database for requirements. Everyone knows where they are and
which ones are current. Less confusion and error.
•Handle Complexity: master arbitrary levels of complexity. Reduce errors of thought and execution.
•Visible Context: relevant views of information, in-line with attributes and related information
•Tailorable RM Process: process “right-sized” to team / solution; tools support and enable the process
•Audit Trail: Development process is under control (this is one of many factors contributing)
•Re-use: re-use of information through linking and copying. Save time & money; increase consistency and quality
•Role-Based Access: access control based on groups and users
•Traceability between Requirements (and to other things): Solution quality & completeness; dev process
coherence
•Manage Scope Change: impact assessments of potential changes and notification of changes
•Deliver to Cost & Schedule Constraints: The ability to control scope and changes enables greater certainty in
what should be delivered, hence greater control over costs and schedule
•Demonstrate Regulatory / Contractual Compliance: The ability to trace to internal and external information gives
confidence that regulations and contractual conditions are being met
•Conform with Standards (CMMI. SPICE, ISO): The transparency of information together with the ability to define
necessary information, allows conformity with standards to be assessed and managed

20


Third Outline Level

‹#›
21

Like all icebergs, 90% is below the surface. The buying decision is often most
visible and has most attention, but that is just the start of the work of ensuring a
successful roll-out.
What management should do – vision:
•paint the vision – why? what value? what will success look like? what if not successful? how to
measure success?
•ensure seen as important, with full backing of Senior Management
•provide support
•commit personnel – people that are well respected in the organization
•tie performance evaluations to the work done on initiative
Initiative must NOT be seen as a secondary duty

Set realistic, achievable goals: Incremental, value-based adoption
Address team and personal ROI: Make sure teams (and individuals) see themselves being more
productive & successful when they follow them
Create a set of coordinated, customizable, adoptable, RM processes for your teams: Allow
appropriate degree of self-organization among the teams
Pilot, learn, replicate your success
Educate, mentor, measure, share success stories
Continuously improve

21

People edit the title text format
Click to impose significant constraints
And in one company there are many project team cultures

Click to edit the outline text format Systems
Second Outline Level Engineering
Research
IT Applications Group
Third Outline Level
– Fourth Outline Level Manufacturing
– Ninth Outline Level Software
Development

Software
Development

‹#›
22

There are a couple of things to say here.

First, the pictures of people remind us that the people involved impose significant constraints on the requirements
process
For example, which notations can be used to communicate effectively? Depends on their technical background:
you can communicate with developers using UML diagrams, but don’t try that with marketing!
Trust, competence, commitment, team work

People touch requirements in various ways: author, validate, approve, use requirements

•Know your audience. What do they need / expect? What can you expect from them? How best to communicate?

Includes many job roles …
•Marketing, Product Managers, Business Analysts, Requirements Engineers
•Licensed Engineers, Developers, Testers, Architects, Operations / Production team
•Project Managers, Executives, Customers, Other Stakeholders
•And many more

Second, in any reasonably large organization there will be projects that have differing optimizations and thus
differing project cultures.

22

Rational RM portfolio today
Addressing different cultures and different needs

Group
Second Outline& Compliance cultures
Engineering Level
DOORS and
Good outcomes are the result of good,
Third Outline Level DOORS Web
controlled processes. “Have we Access
missed anything?”
Market-driven culture RequisitePro
Balance process and expedience.
“How can we get this out faster with Requirements
good quality?” Composer
ALM minimalist culture
Team Concert and
“We use our main tools for Quality Manager
requirements too”
Ad-hoc culture
50% of project failure
“We don’t do RM” can be tracked to poor
requirements practices
“What is RM?”

‹#›
23

Engineering & Compliance cultures
•Reliance on formal process
•Manufactured Systems
•Mission-critical systems
•Regulated, compliance, and contract-driven industries
•Customized tools to support process and analysis of complex requirements

Market-driven culture
•Business-oriented software applications
•Fast-to-market manufacturers

ALM minimalist culture
•Requirements by and for dev and test
•Typically business analysts not involved

Ad-hoc culture
Using general-purpose tools: office, collaboration tools, defect database.
•May employ RM, “pure agile” methodologies or no defined methodology at all
•We think ad-hoc culture teams should move up to one of the other groups (as shown by the arrows)

RRC’s bar has hash markings, since it can be used as a requirements definition accelerator with these other tools

23
23

Summary
Systems
Engineering
Research
IT Applications
Group
Manufacturing

An effective requirementstext format …
Click to edit the outline process will
FitSecond Outline environment and project methodology
the business Level
Software
Development

Third Outline Level Software

Recognize where there is scope for optimization Development

(and–where there isn’t)
Fourth Outline Level
Recognize (and reduce) the degree of uncertainty in the
solution throughout the project lifecycle
Be adaptable … not “one size fits all teams”
Be well communicated, understood, and followed
Be relevant to the entire project lifecycle
Include measurement, reflection and continuous improvement
Be supported by (embodied in) tools

‹#›
24

24


Third Outline Level

‹#›
25

25


Third Outline Level
www.ibm/software/rational

© Copyright IBM Corporation 2010. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind,
express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have
the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM
software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities
referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future
product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services
are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product,
or service names may be trademarks or service marks of others.

‹#›
26

Additional URLs:
IBM Rational software: www.ibm.com/software/rational
Rational launch announcements: www.ibm.com/software/rational/announce/
Rational Software Delivery Platform: www.ibm.com/software/info/developer
Accelerate change and delivery: www.ibm.com/software/rational/offerings/scm.html
Deliver enduring quality: www.ibm.com/software/rational/offerings/testing.html
Enable enterprise modernization: www.ibm.com/software/info/developer/solutions/em/index.jsp
Ensure Web site security and compliance: www.ibm.com/software/rational/offerings/websecurity/
Improve project success: www.ibm.com/software/rational/offerings/lifecycle.html
Manage architecture: www.ibm.com/software/rational/offerings/design.html
Manage evolving requirements: www.ibm.com/software/rational/offerings/irm/
Small and midsized business: www.ibm.com/software/rational/smb/
Targeted solutions: www.ibm.com/software/info/developer/solutions/index.jsp
Rational trial downloads: www.ibm.com/developerworks/rational/downloads
Leading Innovation Web site: www.ibm.com/software/rational/leadership
developerWorks Rational: www.ibm.com/developerworks/rational
IBM Rational TV:
www.ibm.com/software/info/television/index.jsp?cat=rational&media=video&item=en_us/rational/xml/M259765N40519Z80.x
ml
IBM Rational Business Partners: www.ibm.com/partnerworld/pwhome.nsf/weblook/index.html
IBM Rational Case Studies: www.ibm.com/software/success/cssdb.nsf/topstoriesFM?OpenForm&Site=rational

26

Sailing in Requirements Management Cross Currents - www.manageware.co.il Seminar

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (9)

Ähnlich wie Sailing in Requirements Management Cross Currents - www.manageware.co.il Seminar

Ähnlich wie Sailing in Requirements Management Cross Currents - www.manageware.co.il Seminar (20)

Mehr von Manageware

Mehr von Manageware (19)

Sailing in Requirements Management Cross Currents - www.manageware.co.il Seminar