Course Duration: 3 Days

Course Category: Business Analysis & Requirements Engineering

 

21 PDUs (Professional Development Units)
21 PD Hours / CDUs (Professional Development Hours / Capability Development Units)

Requirements Analysis

   
Course Overview

 

This three-day course describes an approach to requirements analysis that can be applied by requirements analysts with different levels of experience.  Underpinning the approach is the concept of use cases that describe requirements from the perspective of the users of a software application.
 
The course first shows participants how to undertake an activity analysis based on the concepts of activity theory. This is followed by a discussion of how to identify and analyse the information requirements associated with activities.
 
Participants are then shown how to create a conceptual modelling of the problem area using class diagrams. The conceptual model provides a context for the identification of requirements and the development of a use case model. A number of techniques for identifying and describing requirements are discussed. The discussion includes the role of business rules and the benefits of an application vision and scope statement.
 
The course then moves on to a detailed discussion of the theory of use cases and their practical application.  The course shows participants how to develop use case diagrams and document use case scenarios.
 
The course concludes with a brief discussion of the various approaches to packaging a requirements specification.
   
Course Features
  • Establish the need for software requirements.
  • Learn the techniques activity analysis, information analysis, conceptual modelling and use case modelling.
  • Learn how to develop and application vision and scope statement.
  • Learn how to identify and describe various types of software requirements.
  • Ability to effectively apply the techniques learnt during the course to a case study.
   
Participant Benefits
  • Clear understanding of the role of requirements in a software development or acquisition project.
  • Ability to effectively apply the techniques discussed during the course to a variety of projects.
  • Practical experience of applying the techniques and workflows to a case study.
   
Who Should Attend
  • Process Engineers, Software Engineering Process Group (SEPG) Staff, Methodologists, Process Improvement Staff
  • Business Analysts, Business Systems Analysts, Systems Analysts, Functional Analysts
  • Software Development Managers, Software Engineers, Developers, Requirements Engineers, Requirements Analysts
   
Course Agenda

Introduction

  • What Are Requirements?
    • Business Needs
    • Application Features
    • Software Requirements
  • Why Bother With Requirements?
    • Requirements and Project Failures
    • The High Cost of Requirements Errors
  • Requirements and the Product Life Cycle
  • Managing Changes to Requirements
    • Freezing Requirements vs. Baselining Requirements
    • Baselining Requirements
    • Change Control
  • A Systems Engineering Perspective of Requirements
  • Requirements Analysis Workflow
Activity Analysis
  • Characteristics of Human Activity
    • Object-Oriented
    • Supported By Tools
    • Achieves Goals
    • Performed by Actors
    • Involves stakeholders
    • Conforms to Rules
    • Allocated Responsibilities
  • Naming activities
    • Verb-noun template
    • Activity Verbs
    • Goals vs. tasks
  • Developing an Activity Map
  • Identifying Activities
    • Object Life Cycles
    • Resource Life Cycle
    • Hierarchical      
  • Business Activity Model
  • The Hierarchical Nature of Human Activity
    • Mission
    • Functions
    • Tasks
  • Decomposing Activities
  • When to Stop Decomposing
  • Publishing the Business Activity Model
Information Analysis
  • Concepts
    • Managing by Observing
    • Managing With Information
    • The Activity Life Cycle
    • Categories of Information
    • Information Requirements
  • Identifying Information Requirements
    • Identifying information requirements from Activity Breakdowns
    • Identifying information requirements from Activity Diagrams
    • The Information Requirements Catalogue
  • Information Samples
  • Data Elements
  • Derivation Rules
    • Describing with Natural Language
    • Describing with Activity Diagram
  • Subject Areas
  • Publishing the Information Requirements Catalogue
Conceptual Modelling
  • Why Conceptual Modelling?
  • Conceptual Modelling Concepts
    • Classification
    • Abstraction
    • Reification
  • Classes
    • Attributes
    • States
    • Operations
    • Events
    • Classes
    • Responsibilities
    • Constraints
  • Associations (facts)
    • Multiplicity
    • Composition (Part of)
    • Aggregation (Collection of)
  • Generalisation (Type of)
  • Class Diagrams
  • Objects
    • Objects
    • Object Diagrams
  • Identifying Classes
    • Class Archetypes
    • Event or Period of Time
    • Party, Place or Thing
    • Role
    • Type
    • Where to Look?
    • What to Challenge?
  • Subject Areas
  • Publishing the Conceptual Model
Requirements Definition
  • Why Requirements Definition?
  • Requirements Concepts
    • Types of Requirement
    • Requirements Deliverables
  • Business Rules and System Constraints
    • What are Business Rules?
    • Classification of Business Rules
    • Where to Document Business Rules?
    • How to Document Business Rules?
    • Business Rules vs. Software Requirements
    • Publishing the Business Rules Catalogue
  • Vision and Scope
    • Vision
    • Features
      • Features and diagrams
      • Features and Natural Language
    • Functional Areas
    • Scope
    • Publishing the Application Vision and Scope
  • Software Requirements Specification
  • Formal Requirements
  • Requirements Characteristics
  • Interface Requirements
    • Software interfaces
    • Network interfaces
    • Hardware interfaces
  • Functional Requirements
    • Functional Requirements and diagrams
    • Functional Requirements Natural Language
    • Functional Areas
  • Storage Requirements
    • Logical Data Model
    • Data Dictionary
  • Non-Functional Requirements
    • Quality attributes (ISO9126)
    • Constraints
    • Non-Functional Requirements and diagrams
  • Publishing the Software Requirements Catalogue
Use Case Modelling
  • Why Use Case Modelling?
  • Use Case Concepts
    • Use Case and Activity Theory
    • Naming Use Cases
    • The Importance of a Glossary
  • Use Case Diagrams
    • Including Use Cases
    • Specialising Use Cases
    • Why Not to Use Extend!
      • What is "Extend"?
      • The Correct Approach to Specialisation
      • A Better Approach to External Scenarios
  • Use Case Steps
    • The subject…verb…object template
    • Actor as the Subject
    • System as the Subject
    • Time as a Trigger
    • How to Handle "Actorless" Use Cases
    • Repetition
      • Repeating Steps
      • Concurrent Steps
  • Use Case Scenarios
    • Main Scenario
    • Alternate Scenarios
  • Handling Business Rules
  • Handing Functional and Non-Functional Requirements
  • Dealing With System Wide Functional Requirements
  • Interface Requirements
    • Handling Interface Requirements
    • Data Dictionary
    • Prototype
  • Organising Use Cases Into Functional Areas
  • Use Cases and Business Processes
    • Activity Diagrams
    • Sequence Diagrams
  • Use Case Templates
    • Use Case Templates
    • Levels of Use Case Description
    • Use Case Narrative
  • Publishing the Use Case Model
Review and Conclusion

 


Available Funding Support
Malaysia Only

HRDF Logo_02This course is HRDF SBL & HRDF SBL Khas Approved

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.