Requirements Gathering

Two-thirds of all application system defects can be traced to incomplete, inaccurate, or missing requirements. This seminar, based on a research project  including over 50 companies, offers practical techniques to get requirements right. The study showed a potential hundred-fold economic return on the effort expended to improve requirements definition. 

Is this how your people are gathering requirements? 

• Scope has careened wildly out of control because of their inability to uncover true needs and to hear when requirements are not clear or plain, are ambiguous, are vague, or are uncertain. 
• They are wasting time because of an inability to distinguish true needs from wants.
• They are wasting effort because of an inability to manage scope creep and an inability to see wasted processes? 
• Chaos is reigning because your people don't have a toolkit of processes to find, resolve, and refine requirements. (Resolve conflicting needs and wants.)

Signs that your Requirements Gathering Process May Be "Broken" 

• Huge cost overruns 
• Spending more money correcting than finding defects. 
• Spending mass sums on defect detection and correction. (If you’re not doing the right thing, it really doesn’t matter how well you’re doing it.) 
• Iterative or ad hoc  processes, guidelines, and training
• Your staff is fighting over opinions. Nobody knows the facts. 
• Your people are never done gathering reqts. 
• Your staff is constantly rehashing the best solution because they have no method to resolve conflicting trade-offs; your people don’t know how to determine the “best” solution. 
• Your people are finding true reqts closer to end of project at the worst possible time. 
• Your people are "technology-crazed." If they have a "hammer" they see only "nails." Your people are taking what they are already doing and superimposing it on the problem.
• Your people's solutions are technology-based not problem-based.  
• The users' needs are tainted by the technology available to use. You may need to decode your users' needs. (True needs are those that are phrased in such a way as they cannot be addressed with technology.)  
• Your people are not testing requirements, therefore, requirements are unclear or broken. 
• Your staff is asking too detailed questions and have completely misunderstood the problem. 
• Management is not committed to the requirements gathering process. 

What are your people actually going to do in this course? 

1. Deconstruct why requirements are often invalid.
2. Identify sources of poor requirements.
3. Distinguish needs from wants.
4. Help customers verbalize unknown needs. 
5. Identify, diagnose, parse and reform errors in requirements.
6. Calculate true needs tied to the mission and eliminate wasted processes.
7. Develop standards for good requirements. 
8. Minimize information loss, misunderstanding, and ambiguity.
9. Use a six-phased procedure for developing requirements.
10. Practice models to interactively improve rapport, interview techniques, and question elicitation strategies via NLP metamodeling strategies.

Sample this course: select any of the WEBinars listed under "in this section" top-left above. 

Projects related to this course: 

For an electronic design automation company in Oregon, Steve showed members of a team a way of computing undiscovered requirements from existing missions and processes, by utilizing a special matrix. One of those individuals applied these techniques for 30 minutes and saved the customer over $11,800,000.

For a Federal Branch chief, Steve "installed" the capability for that person to think and interact generally when before they were only able to interact in detailed specifics, via coaching and NLP (Neuro Linguistic Programming), thus improving communication with more senior managers.

For a Federal Government Agency, Theresa and Steve took their requirements gathering process in a completely new direction, from solution orientation to assuring the meeting of true customer needs, by implementing a 6-step requirements gathering process.  Major tools included  a needs derivation based on mission and information elicitation strategies.

Course Outline:

This course is typically held in a 4-day session. The first 2 of the 4 days is an interactive tutorial with exercises sharing a new process model for requirements gathering and implementation. 

• Tutorial and training
• Live demonstrations
• Directed practice and coaching using real company requirements  

The remaining 2-day session is broken into 4 equal 1/2 day sessions, having the following structure: 

1. The Requirements Mission - Process - Requirements (MPR) model to calculate true needs  
2. The Rapport - Process - Interview - Process - Rapport (RPIPR) interviewing model to minimize defects during information gathering  
3. Elicitation strategies to minimize ambiguity and increase focus, especially for users who don't know what they need.  The answer to "I'll know it when I see it" (reduce requirements ambiguity)
4. Active listening, demonstrated understanding, and integration of all previously learned models

Also included:  

• Detailed surveying and optional interviewing of participants for course tailoring
• 4 day intensive seminar
• Substantial morning, daytime, noon, and evening individual "Navigating The Obstacle Course Coaching"
• Detailed seminar workbook
• Follow-on WEBinars to integrate performance on the job 
• Free digital CD: All PowerPoint slides plus full audio transcript