# Presentation: 197223

## Introduction to Requirements Management

**Barry Schrimsher**
**U.S. Census Bureau SEPG Conference**
**November 8, 2005**

## Agenda

**Objectives**
**Keys to requirements management**
**Reaching agreement**
**Managing change**
**Maintaining consistency**
**Summary**

## Objectives

**After this session, you should understand:**
**The need for quality requirements**
**How to identify relevant requirements criteria?**
**Principles of effective change control**
**When to approve or disapprove proposed changes?**
**The role of traceability**
**How much is enough?**

## Keys to Requirements Management

**Good requirements!**
**A well-defined and consistently implemented change process**
**Visibility into the current state of**
**Requirements **
**Changes & their affects**
**               ****Requirements   =   Expectation**
**               ****Management          Management**

## What Are “Good” Requirements?

**Good requirements are:**
**Appropriate**
**Clear**
**Complete**
**Consistent**
**Discrete**
**Testable**

## How Do We Get “Good” Requirements?

**Reach agreement with**
**The customer**
**The team**
**The boss**
**Establish criteria for**
**Choosing from whom to accept requirements**
**Establishing priorities**
**Manage expectations**
**Cost, schedule, & functionality**
**Product & process quality**
**Risks & opportunities**

## Reaching Agreement

**The Customer**
**The responsiveness spectrum**
**Eliciting hidden requirements**
**Building confidence**
**The Boss**
**Aligning project & business objectives**
**Saying “No” with data & “Yes” with risks**
**Building confidence**

## Reaching Agreement

**The Team**
**Developing a common understanding of**
**The problem space**
**The solution space, including constraints**
**Documenting “good” requirements**
**Developing reasonable estimates**

## Establishing Criteria for Choosing

**Sources of requirements**
**End users**
**Customer representatives**
**Marketing**
**Management**
**Senior technical staff**
**Priorities for requirements**
**Alignment principle(s)**
**3 – 5 priority buckets**
**Quantified risk/impact/implementation value**

## Managing Expectations

**Cost, Schedule, & Functionality**
**Defensible estimates key!**
**Plan & *****budget***** for change**
**Prioritize!  Prioritize!!  Prioritize!!!**
**Product & Process Quality **
**Identify measurements & metrics**
**Define verification & validation activities**
**Publish the results**

## Managing Expectations

**Risks & Opportunities**
**Put a plan in place to manage these**
**Define periodic and event-driven update cycles**
**Prioritize!  Prioritize!!  Prioritize!!!**

## Managing Change

**Document your defined change control process**
**Implement your defined change control process**
**Inform stakeholders about the status of everything in your defined change control process**

## A Defined Change Control Process

**Documented!**
**Clear processes, procedures, & work instructions that specify**
**When to baseline requirements**
**Who may request a change**
**How to submit a change request**
**Who dispositions change requests**
**The criteria against which change requests are dispositioned**
**How stakeholders will be kept informed**
**This is sound configuration management**
**This is not rocket science**

## Implement the Defined Change Control Process

**Impact analysis**
**Cost, schedule, & functionality**
**Quality, risks, & issues**
**Upstream, downstream, & across to the other bank**
**Bi-directional traceability**
**Interfaces**
**Reprioritize**
**Be responsive!**

## Informing Stakeholders about the Status of Everything in the Defined Change Control Process

**Keep it transparent**
**Real-time updates on state changes?**
**Web-enabled access?**
**Automatic e-mails to affected parties?**
**Feedback to the initiator!**
**Publish**
**Configuration control board meeting minutes**
**Metrics**

## Informing Stakeholders about the Status of Everything in the Defined Change Control Process

**Candidate metrics for publication**
**Current state of each requirement or change request**
**TBD**
**Peer reviewed**
**Baselined**
**Mapped to a release**
**Tested**
**Released**
**Number of requirements by state**
**Volatility**
**Time & effort devoted to managing requirements**

## Maintaining Consistency

**What is traceability?**
**Bi-directional**
**Vertical & horizontal**
**How much is enough?**
**Flag inconsistencies**
**Effective corrective actions**
**How do you do it?**
**Use a tool**

## Summary

**Requirements Mgt = Expectation Mgt!**
**Get good requirements from all stakeholders**
**Prioritize**
**Alignment principle**
**Value, scope, & risk**
**Define & follow your process**
**Keep people informed**
**Keep related work products consistent**

## Objectives (Revisited)

**After this session, you should understand:**
**The need for quality requirements**
**How to identify relevant requirements criteria?**
**Principles of effective change control**
**When to approve or disapprove proposed changes?**
**The role of traceability**
**How much is enough?**

## References

**Karl Wiegers, *****Software Requirements***** (2****nd**** Edition), Microsoft Press, 2003**
**Steve McConnell, *****Rapid Development*****, Microsoft Press, 1996**
**Mary Beth Chrissis, Mike Konrad, & Sandy Shrum, *****CMMI:  Guidelines for Process Integration and Product Improvement*****, Addison – Wesley, 2003**

## Contact Information

**Barry Schrimsher**
**GlenTalon Consulting, Inc.**
**256.655.3381**
**barry@glentalon.com**