Defining and Managing User Requirements

Course available to schedule for your team

Learn More

Applicable Certifications:

CSTP-P #5

CSQM #8

Concepts

Understanding and articulating business requirements for automated systems always has been the weakest link in systems development. Up to 67 percent of maintenance and 40 percent of development is wasted rework attributable to inadequately defined business requirements. Too often developers proceed based on something other than what the business people really need; and development methodologies commonly focus mainly on the format for representing requirements. This interactive workshop also emphasizes how to discover content, why to build it and what it must do to produce value for the customer/user. Using a real case, participants practice discovering, understanding, and documenting clear and complete business requirements that can speed development, reduce maintenance, and delight customers.

Participants will learn:

Role and importance of defining business requirements accurately and completely.
Distinctions between the user's (business) requirements and the system's (design) requirements.
How to gather data, spot the important things, and interpret them meaningfully.
Using the Problem Pyramid™ tool to define clearly problems, causes, and real requirements.
Formats for analyzing, documenting, and communicating business requirements.
Techniques and automated tools to manage requirements changes and traceability.

Who should attend: This course has been designed for systems and business managers, project leaders, analysts, programmer analysts, quality/testing professionals, and auditors responsible for assuring business requirements are defined adequately.

Outline

Requirements Role and Importance
- Sources and economics of system errors
- How requirements produce value
- Business vs. system requirements
- Survey on improving requirements quality
- Software packages and outsourcing
- How we do it now vs. what we should do
Discovering "Real" Requirements
- Do users really not know what they want?
- How the "real" requirements may differ
- Aligning strategy, management, operations
- Technology requirements vs. design
- Problem Pyramid™ tool to get on track
- Understanding the business needs/purposes
- Horizontal processes and vertical silos
- Customer-focused business processes
- Who should do it: business or systems?
- Joint Application Development (JAD) limits
- Management/supervisor vs. worker views
Data Gathering and Analysis
- Surveys and questionnaires
- Research and existing documentation
- Observing/participating in operations
- Prototyping and proofs of concept
- Planning an effective interview
- Controlling with suitable questions
Documentation Formats
- Formats to aid understanding of the data
- Business rules, structured English
- E-R, data flow, flow, organization diagrams
- Data models, process maps
- Performance, volume, frequency statistics
- Sample forms, reports, screens, menus
- Formats for communicating requirements
- IEEE standard for software requirements
- Use cases, strengths and warnings
- 7 guidelines for documenting requirements
- Top-level requirements and project scope
- Iterating to avoid analysis paralysis
- Conceptual system design solutions
- Expanding to detailed deliverables
Getting more clear and complete
- Stakeholders and Quality Dimensions
- Addressing relevant quality factor levels
- Standards, guidelines, and conventions
- Detailing Engineered Deliverable Quality*
- Simulation and prototyping
- Defining acceptance criteria
Managing the Requirements
- Supporting, controlling, tracing changes
- Automated requirements management tools
- Measuring the "proof of the pudding"