This tutorial covers area 5 of the Certified Software Test Professional requirements. This tutorial also counts as an elective towards the requirements of the Certified Test Manager (CTM) certification.
For cost and cities where this course might be offered, check our Public Training Schedule.To bring this course to your test team at your location, contact our Education and Professionals Services Group.
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.
- 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.
- 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"
|
