sailing in requirements management cross currents - seminar

Click to edit the title text format

� Click to edit the outline text format

�Second Outline Level

� Third Outline Level

– Fourth Outline Level

– Fifth Outline Level

– Sixth Outline Level

– Seventh Outline Level

– Eighth Outline Level

– Ninth Outline Level

‹#›

1

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

Sailing in cross currents:setting your course amidst the many current approaches to requirements

Daniel Moul & Keith CollyerRequirements Product Delivery [email protected] & [email protected] 2023B











‹#›

2

2

Abstract

Web development? Manufactured products? Packaged applications? SOA? Agile? System requirements specifications? Use cases? User stories? Faced with the many competing types of projects and approaches to creating and managing requirements, how can you determine which are right for your organization?

This session will survey major approaches, provide a framework to help you assess them, and offer some keys to successful implementation based on years of IBM Rational and Telelogic experience.











‹#›

3

3

In your current project … which ship are you sailing?

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.











‹#›

4

4

On terminology

� For today let’s consider all of these “RM”�Requirements Management

�Requirements Engineering

�Requirements Definition

� Sometime we’ll use “practices” to mean “process”











‹#›

5

5

Not every requirement is called a requirement

Capability Gap(military)

Gaps in Packaged Applications

RegulationsPoliciesStandards

BusinessRules

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











‹#›

6

6

Why do you need a requirements process?Isn’t a requirements tool enough?

� Effective RM is about people and process

� Process is whole-team behavior

� Tools enable and accelerate process

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











‹#›

7

7

The Business Environment Determines Project Parameters

� Are you the customer or contractor?

� What are the financial terms?

� Who is responsible for what?

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











‹#›

8

8

Project selectionProject charters

Program & Portfolio Management

Project Management

Business strategyObjectives & priorities

Business casesProject proposals

Vision documentsRequirements identified

Project execution

Projects are commissioned to meet business goals

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











‹#›

99

9

Inception Elaboration Construction Transition/Maintenance

Different projects need different governanceUncertainty and risk are the key discriminators

Time

Var

ianc

e in

Cos

t, S

ched

ule,

…

New Capability on existing

platform

Maintenance and small change

requests

New Platform

Medium VarianceHigh Variance Low Variance

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











‹#›

10

10

Actual Path

Project delivery is an exercise in removing uncertainty

Feedback � course corrections � better outcomes

Initial Planned Path

Initial Plan

Initial State

Uncertainty inStakeholderSatisfaction

Space

Acceptable solution set

Points of feedback, learning, and adjustment Delighted

customers

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.












‹#›

11

11

Managing Uncertainty = Managing Variance

� A completion date is not a point in time, it is a probability distribution

Actual path and precision of Scope/Plan

0 6 12

Uncertainty inStakeholder

Satisfaction Space

ScopeProduct features / qualityPlans / resource estimates

Initial Plan

� Scope is not a requirements document, it is a continuous negotiation

� A plan is not a prescription, it is an evolving, moving target

Initial State

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.












‹#›

12

12

StakeholderRequirements

SystemRequirements

Design

ProblemDefinition

AbstractSolution

Mech Elec HumanS/W

Interfaces

Typical Requirements Hierarchy – two views

SolutionSpace

Problem Space

Traceability

Traceability

ProblemProblem

Needs

SoftwareRequirements

Features

Req

uire

men

t

Req

uire

men

t Hie

rarc

hy

Hie

rarc

hy

Typical Systems View Typical IT View

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.











‹#›

13

13

System scope determinedRequirements selected

Stakeholders identifiedRequirements collected

Domain knowledge & terminology

Requirements flow-down

Problem statement

Highly diverse, unstructured information

Structured information

Solution design

Progressive removal of uncertainty

Like sand in an hourglass, this can be a continuous process

Requirements Definition

Requirements Engineering

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











‹#›

14

14

Business Process

Financial Return

Models: Low-cost ways to learn earlyOptimize for learning / adjusting

SimulationsVisualModels

Performance

Cost & Duration

Manufacturability

Diagrams

Pictures

Behavior

Stresses, heat flow, air flow

Monte Carlo

Project Planning

Load testing

Sequence diagrams

BPMN

Systemcontext diagrams

Venn diagrams

Screen shots

UI simulations

Story boards Prototyping

Use Cases

Functional flow block diagrams

IDEF

CAD/CAM

Modelling helps you to …

•Understand a problem

•Reason about a solution

Analyze & Optimize

•Communicate with stakeholders











‹#›

15

15

Economics determine many of the possible optimizationsOptimize for learning and adjusting as much as possible within your constraints

� What can you optimize?

� What are the underlying economics?� Value of being fast-to-market

� Cost of failure

� Cost of change

� Cost of communication

� Cost of non-compliance

� Cost of design and manufacture

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











‹#›

16

16

Industry patterns reveal optimized groupings

� Unique industry characteristics

�Government / private

�Manufactured systems / IT

� Patterns are reflected in culture

Systems - Key DriversIncreasing complexitySW is a growing % of product valueComplex sub-contractor scenariosFaster time to marketMore predictable outcomes

IT - Key driversLower costFaster time to market More predictable outcomes











‹#›

1717

17

Use development and test tools• Requirements by and for dev and test• Typically business analysts are not involved

ALM minimalist culture“We use our main tools for requirements too”

Group Requirements Focus

Engineering & Compliance cultureGood outcomes are the result of good, controlled processes. “Have we missed anything?”

RM in an engineering process• Formal process• Manufactured systems• Mission-critical systems• Regulated, compliance, and contract-driven industries

Market-driven cultureBalance process and expedience. “How can we get this out faster with good quality?”

Effective teams, efficient tools• Business-oriented software applications• Fast-to-market manufacturers

Ad-hoc culture“What is RM?”“We don’t do RM”“We get by with office docs”

Using general-purpose tools at hand• May employ some RM, “pure agile”methodologies or no defined methodology at all

Project have various cultures

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











‹#›

18

18

Management Techniques in Organization Culture (extract)

YYYEvaluate against plan

YBDUFIncrementalYYYParallel implementationYYEarly release

YYLarge-scale iterationIterative / Evolutionary YYPlan complete at high level

YYYCost-benefit drivenYYValue at every releaseYYEach release "complete"

YY?Small releasesYYJust enough planning

YYYUser storiesAgileYYTime-boxingYYTest-driven

YYYWork-item list

?YCompliance-checkingCommon

YYYYFeedbackYYYConsistency check

YBDUFWaterfallYComplete stagesYSingle release

Plan, what plan?YComplete plan

Ad hocALM minimalist

Market-driven

Engineering -Compliance

TechniqueBase Lifecycle

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.











‹#›

1919

19

Domain Complexity

Straight-forward

Intricate/Emerging

Compliance requirement

Low risk Critical,Audited

Team size

Under 10developers

1000’s ofdevelopers

Co-located

Geographical distribution

Global

Enterprise discipline

Projectfocus

Enterprisefocus

Technical complexity

HomogenousHeterogeneous,

Legacy

Organization distribution(outsourcing, partnerships)

Collaborative Contractual

Flexible Rigid

Organizational complexity

Consider other constraints – Example: IBM agility@scaleTM

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 a process, team structure, and tooling environment tailored to meet their unique situation.











‹#›

20

20

ExecutivesPractitioners Team Leaders

Value to stakeholders should determine RM prioritiesIm

prov

emen

t in

Req

uire

men

ts Q

ualit

y

Increased use of Requirements Management Good Practices

Scalable Common

Repository

AuditTrail

Re-use

Traceability between

Reqts

Tailorable RM

Process

VisibleContext

Role-Based Access

Manage Scope & Change

Deliver to Cost &

Schedule Constraints

Regulatory & Contractual Compliance

Handle Complexity

Many common aspirations:• Improve productivity• Reduce rework• Get the requirements right• Make customers happy• Meet business goals

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











‹#›

21

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











‹#›

22

22

People impose significant constraintsAnd in one company there are many project team cultures

Research

Systems Engineering

Software Development

Manufacturing


IT Applications Group

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 processFor 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.











‹#›

2323

23

ALM minimalist culture

“We use our main tools for requirements too”

50% of project failurecan be tracked to poor requirements practices

Group

Engineering & Compliance cultures

Good outcomes are the result of good, controlled processes. “Have we missed anything?”

Market-driven culture

Balance process and expedience. “How can we get this out faster with good quality?”

Ad-hoc culture

“We don’t do RM”“What is RM?”

Rational RM portfolio todayAddressing different cultures and different needs

DOORS andDOORS Web Access

Team Concert andQuality Manager

RequisitePro

RequirementsComposer

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 cultureUsing 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











‹#›

24

24

Summary

An effective requirements process will …

� Fit the business environment and project methodology

� Recognize where there is scope for optimization(and where there isn’t)

� 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

Research

Systems Engineering


Manufacturing


IT Applications Group











‹#›

25

25











‹#›

26

26

© Copyright IBM Corporation 2010. All rights reserv ed. 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.

www.ibm/software/rational

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.xml

�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

sailing in requirements management cross currents - seminar

Documents

title text format

process process

right requirements process

optimal requirements

current project

business environment

projects goals

systems delivery projects