Course Category: Business Analysis
Course Duration: 2 Days
Hours: 14 Contact Hours
Course Overview
Software development projects frequently charge ahead without a clear set of requirements. The all too often result is a product is delivered late, over budget that doesn’t meet the needs of its users. Effort is then wasted on patches and expensive rework, often impacting the technical integrity of the product.
However, while writing good requirements is not easy, it is certainly a skill that can be practiced and learnt if requirements authors understand and adhere to few basic principles.
By carefully balancing theory and practice, this course teaches participants the practical skills required to write good requirements, providing an excellent foundation for them to refine and develop their skills.
Course Features
- Writing exercises that critiqued by the course instructor.
- Ample time to practice the discovery and documenting of requirements.
- Cross referenced to IREB, BABOK and IEEE 29148.
- Combines best practice from a number of different sources.
- Provides a wealth of practical checklists and templates.
Participant Benefits
- Taught by a requirements practitioner with years of industry experience writing requirements.
- Develop the ability to write clear, unambiguous well structured requirements.
- Gain the skills required to organise requirements into documents that are easy to understand.
- Investing in well written requirements saves time, money and effort in the long term.
- Participants are better able to contribute to requirements reviews by understanding what good requirements look like.
- Develop the ability to restructure and improve existing requirements documents.
Who should Attend
- Business Analysts, Business Systems Analysts, Systems Analysts, Functional Analysts
- Software Development Managers, Software Engineers, Developers, Requirements Engineers, Requirements Analysts
- Engineering Managers, Systems Engineers, Electrical Engineers, Control Engineers, Mechanical Engineers, Human Factors Specialists
- Users, User Representatives, Stakeholders, Project Sponsors, Project Managers, Program Managers
- Process Engineers, Software Engineering Process Group (SEPG) Staff, Methodologists, Process Improvement Staff
Course Outline
The context for requirements
- Activity theory
- Activity and objects
- The role of tools
- Activities and goals
- The activity triangle
- The hierarchical nature of activity
- Collaborative activity nodelling
▪ Clarifying scope
▪ Consolidating stakeholder perspectives
- The four critical requirements questions
- Who are the stakeholders?
- What are the stakeholder’s goals?
- What do the stakeholders need?
- How can software be used as a tool to support the stakeholders goals and satisfy their needs?
- Requirements at different levels
- Need
- Feature
- Requirement
- The IEEE 29148 view of requirements levels
- The BABOK view of requirements levels
- The Requirements Discovery Canvas – a tool for summarising product requirements
- What is a Canvas?
▪ The Business Model Canvas
▪ Other canvases - How Are Canvases Used
▪ Canvas vs. process
▪ As a discovery template - As a collaborative tool
- What is a Canvas?
Identifying Stakeholders
- Summarising stakeholders with ‘MACROSCOPE’
- The ‘onion’ model of stakeholders
- Empathy maps and personas
- Analysing stakeholders
- Subject matter knowledge
- stakeholder committment
- Stakeholder attitude
Identifying stakeholder goals and needs
- How to get started
- Concept Mapping
- People, Places and Things
- Roles
- Time
- Classification
- Goals vs. activities
- Identifying stakeholder goals
- Types of goal
- Decomposing goals
- Identifying stakeholder needs
- Strategic needs
- Improve or preserve a strength
- Remedy a weakness
- Exploit an opportunity
- Avoid a threat
- Strategic needs
- Store and retrieve information
- Enforce rules and constraints
Identifying and describing product features
- Populating the Requirements Discovery Canvas
- What are product features?
- Features support goals and satisfy needs
- Types of feature
▪ Capability
▪ Quality attribute
▪ Technology
▪ Constraint
- Identifying features from goals and needs
- Identifying product components and interfaces
- The recursive nature of requirements
- The need for a high-level architecture
▪ Coupling vs. cohesion
▪ Layered architetcures
▪ Service oriented architectures
- Identifying product components
- Low coupling
- High cohesion
- Identifying product interfaces
▪ User interface
▪ Devices and systems - Allocating features to components
- Describing features
- Natural language
- Use case diagrams
- User Stories
Course Outline
Writing requirements
- Defining software requirements
- Functional requirements
- Interface requirements
- Storage requirements
- Non-functional requirements
▪ Quality attributes
▪ Product constraints
▪ Global vs. local non-functional requirements
▪ Non-funcitonal requirements and checklists
- Writing requirements statements
- The correct structure and wording of a requirements statement
- Words that should be avoided in requirements statements and why they should be avoided
- Ability to spot ambiguity in all its forms in requirements statements
- Ability to spot requirements that have not been properly qualified or are subjective in nature
- Quality criteria for good requirements
- How to apply the requirements quality criteria
- Uniquely identifying a requirement
- Requirements statement templates
- Product-centric requirements templates
- User-centric requirements templates
- Scenario style requirements templates
- Requirements attributes
- Use of requirements attributes to sort and filter requirements
- Prioritising requirements
- Handling exceptions
- Conducting a systematic search for exceptions
- Structuring requirements to accommodate exceptions
- Requirements acceptance criteria
- Getting ‘real’ about requirements
- The importance of objective criteria
- Abstract stements vs. concrete examples
- Behaviour-driven development and test-driven requirement
Structuring requirements
- Grouping requirements
- Logical vs. physical groupings
- Allocating requirements to components
- Grouping requirements into functional areas
- Combining component s and functional areas
- Requirements hierarchies
- Depth vs. breadth
- Hierarchical numbering schemes and unique identifiers
- The importance of traceability
- Traceability to features
- Tracing features to goals and needs
- Tracing requirements to features
- Traceability between requirements
Documenting requirements
- Requirements Documents
- Typical structure and expected contents of a requirements specification
- Quality criteria for a requirements specification
- How to apply the requirements specification quality criteria
- The role of pictures and diagrams in requirements specifications
- Requirements Tools
- Requirements management tools
- Diagramming tools
- Repository based diagramming tools
Working with requirements
- Gathering requirements
- From groups of stakeholders
- From individual stakeholders
- From experience and observation
- From doucments and things
- From measurements
- Iterative refinement of requirements
- Validating requirements
- Workshops
- Prototypes
- Modelling
- Requirements reviews
- Behaviour driven development and test driven requirements
- Wizard of OZ testing
- Managing changes to stakeholder needs and requirements
- Baselining requirements
- Version control of requirements documents
- Capturing and managing change requests
- Managing requirements ‘churn’ and scope ‘creep
Course Category: Business Analysis
Course Duration: 2 Days
Hours: 14 Contact Hours
