Course Duration: 2 Days

Course Category: Business Analysis & Requirements Engineering

 

14 Contact Hours

Discovering Software Requirements: A practical approach to Discovering and Documenting Software Requirements

 

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 Agenda

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

 

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
  • 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

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 requirements

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. bredth
    • Hierarchical numbering schemes and unique identifiers
  • The importance of taceability
    • 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 requirmements

  • 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'

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <font color="" face="" size=""> <span style="">

PMI, PMP, PMBOK, CAPM, PMI-ACP and the Registered Education Provider logo are registered marks of the Project Management Institute, Inc.
CMMI®, Capability Maturity Model®, Capability Maturity Modeling®, CMM®, PCMM® and Carnegie Mellon® are registered in the US Patent and Trademark Office by Carnegie Mellon University.
ISTQB® is a Registered Trade Mark of the International Software Testing Qualifications Board.
IIBA®, BABOK® and Business Analysis Body of Knowledge® are registered trademarks owned by International Institute of Business Analysis. CBAP® and CCBA® are registered certification marks owned by International Institute of Business Analysis. Certified Business Analysis Professional, Certification of Competency in Business Analysis, Endorsed Education Provider, EEP and the EEP logo are trademarks owned by International Institute of Business Analysis.
The APMG-International Agile Project Management, AgilePM and Swirl Device logos are trademarks of The APM Group Limited.
PRINCE2®, ITIL®, IT Infrastructure Library®, and MSP® are registered trademarks of AXELOS Limited. The Swirl logo™ is a trade mark of AXELOS Limited.
The ITIL Licensed Affiliate logo is a trademark of AXELOS Limited.
SCRUM Alliance REP SM is a service mark of Scrum Alliance, Inc.