Recognizing and Controlling Requirement Risk Outline

COURSE 2685 | 2-DAY PUBLIC SESSION | 3-DAY VIRTUAL SESSION
Recognizing and Controlling Requirement Risk

Course Outline

Section I. Why is Requirements Development So Hard?
Of all project activities, requirements development has changed the least in approach and results. Its importance is recognized, so why aren't we doing better? This section describes the nature of the challenge.

Challenge of communication
Why review and analysis don’t fit find most defects
Role of human factors
Why requirements are dangerous

Section II. Types of Requirements Risk
There are many things that impact the quality of requirements and many things that requirements can affect. We factor requirements risk into seven groups and describe the contents of each.

Application risk
Stakeholder risk
Process risk
Resource risk
Change risk
Implementation risk
Defect risk

EXERCISE: Participants identify their requirements risks. Then, teams share their risks with the entire group.

Section III. Requirements Risk Management
After admitting the danger, a project team must control its requirements risk. This section describes the challenges of a risk management process.

Recognizing requirements risk
Forecasting project-specific dangers
Developing a strategy
Monitoring reality

Section IV. Safety Tactics 1: Avoiding Requirements-based Failures
Projects become famous failures by promising a lot, consuming resources, and delivering little or nothing. Tactics in this section focus on avoiding this type of fame.

Reconfirm reality and satisfiability of stated needs
Triage and prioritize requirements
Manage customer expectations
Reconfirm project feasibility or reduce scope
Identify and resolve conflicts early
Commit incrementally

EXERCISE: The entire group identifies challenges of incremental commitment — why might it be hard?

Section V. Safety Tactics 2: Mitigating Impact of Requirements-based Problems
Requirements will conflict and be defective, despite your best efforts. This section describes tactics that reduce the impact of these problems.

Require frequent demos of understanding
Decouple vision from build
Prototype unfamiliar functions and interfaces
Subdivide project scope
Build in multilane cycles

Section VI. Safety Tactics 3a: Minimizing Communication Problems
Clear project communication is one of the core challenges of system development. Natural language is a major problem, because it is so natural. This section describes alternatives and supplements to text blocks.

Maintain a climate of safety and respect
Document assumptions
Mark intentional imprecision
Use rich definitions
Use derived values rather than "magic numbers"
Identify user types and create user personas
Clarify with examples and measures
Structure information with spec patterns
Picture requirements information
Capture context

EXERCISE: Teams create rich definitions including a derived value, quality profile, and action contract. Team definitions are shared with the entire group.

EXERCISE: Teams replace a "magic number" with a derived value.

EXERCISE: Teams create a state transition table and then share with the entire group.

Section VII. Safety Tactics 3b: Minimizing Other Problems
Beyond communication, there are other problems that can be reduced with specific minimization tactics. This section describes these added tactics.

Improve results of current requirements development process
Identify minimal sets of marketable features
Focus on quality and environmental requirements early
Identify impacts and mitigation strategies
Analyze benefits, risks, priority, and cost of proposed requirements and changes

Section VIII. Safety Tactics 4: Monitoring Requirements Status
Requirements and their related information (e.g. defects) must be monitored to detect expected and unexpected risk. This section describes tactics that provide this monitoring.

Monitor requirements instability and growth
Monitor accuracy of assumptions, expectations, and priorities
Monitor stakeholder participation
Use workshops to find issues early
Incrementally review long specifications
Identify unclear, imprecise, and missing information
Estimate defect risk
Verify satisfaction arguments of derived requirements
Track requirements defects
Analyze and classify requirements defects and root causes

EXERCISE: The entire group interprets requirements change measures.

Section IX. Safety Tactics 5: Staffing for Requirements Development
People, their involvement, knowledge, and behavior make all the difference. This section focuses on getting the right people, with the right perspective and skills to do the job right.

Build cross-functional team
Supplement with outside knowledge, skill, and experience
Replace underperformers and disruptors
Train stakeholders in technical communication
Immerse stakeholders

Section X. Safety Tactics 6: Planning for Requirements Risk Management
To get risk management off to a solid start, you need to understand what information people need and what bad things might happen as you try to get it. This section deals with creating effective strategies for requirements development and risk management.

Elicit meta-requirements
Brainstorm risks and tactics
Identify risk indicators and root causes
Customize requirements development and specification strategy
Customize, carry out, and monitor requirements risk management strategy

EXERCISE: Teams brainstorm risks and tactics for a case study and then share results with the entire group.

Section XI. Safety Tactics 7: Preparing for Requirements Risk Management
Some tactics (e.g. acquiring tools) involve the creation, outside a production project, of a foundation that enables other safety tactics (e.g. identify imprecise information) to be more effective during development. This section describes these foundational tactics.

Formulate baseline requirements process(es)
Systematize change management and requirements defect and failure tracking
Provide tools supporting safer requirements
Develop requirements defect and root cause profiles
Conduct requirements retrospectives

Section XII. Safety Tactics 8: Compensating for Requirements-based Problems
Because misunderstanding will occur and mistakes will be made, some design, implementation, and test work will need to be redone. Sometimes your worst fears will not be realized and your strategy will need adjusting.

Estimate and track requirements-based rework
Adjust for surprises, both good and bad

EXERCISE: Teams walk through the tactics usage process