About the Course

Many of the problems encountered in business information system implementations are the direct result of shortcomings in the processes and practices used to gather, understand, and document requirements for the system. Requirements are often not reflective of the real business need(s), they are all too often incomplete, vague and disconnected and consequently provide little value to the development and testing teams and ultimately to the business.

This course is intended for those who want to add to their current business analysis knowledge and confidently take ownership of the requirements from elicitation, analysis and documentation. It highlights the many different viewpoints of requirements and their interrelationships but also places emphasis on achieving testable requirements – which means that relevant team members can, from the description of the requirements, ascertain the testing necessary to demonstrate that a particular requirement has been met.

Learning Outcomes

By the end of the course, participants will be able to:

• Understand the objectives, processes and activities involved in defining testable requirements of different types in the context of Agile as well as more linear approaches to systems development
• Learn about techniques to elicit quality or non-functional requirements
• Understand how to negotiate and prioritise conflicting requirements
• Understand how to define and use requirements quality metrics in the process of defining requirements
• Understand the importance of consistent use of approved requirements templates

IIBA Endorsed Training

This course is endorsed by the International Institute
of Business Analysis (IIBA^®) and is aligned with the
Business Analysis Body of Knowledge^® (BABOK^®).

Credits

This course will contribute 14 CDUs (Continuing Development Units)
towards your Certificate of Competency in Business Analysis™ (CCBA^®) or Certified Business Analysis Professional™ (CBAP^®) certification
requirements.

Intended for:

• Business analysts
• Analyst/Designers
• Systems analysts
• Requirement engineers
• Project leaders
• Project managers
• Anyone else involved in defining and representing requirements for business systems

Prerequisites:

Participants are expected to have an end-to-end understanding of business analysis activities. A suggested lead-in course is Software Education’s Business Systems Analysis course.

Duration

2 days

Course Content

Introduction and Overview

• Obtain an overview of a requirements engineering roadmap
• Requirements engineering in context of the software development lifecycle
• Recognise the relationships between business analysis and requirements engineering
• Accreditation and certification bodies

Requirements Fundamentals

• Common requirements problems explored
• The various types of requirements which define a business system
• Business rules in context
• Requirements properties to manage requirements
• Characteristics of “good” requirements statements looking at various approaches to writing requirements (from user stories to more formal approaches to requirements specification)
• Various approaches to structuring and writing requirements

Requirements Activities

Elicitation and Documentation

• Eliciting requirements (various approaches with focus on eliciting quality or non-functional requirements)
• Producing the documentation
• Vision and scope document
• System requirements specification
• Software requirements specification
• Supplementary specification

Analysis and Communication

• Analysis techniques to consider requirements from different viewpoints
• Requirements trade-offs
• Requirements negotiation
• Requirements prioritisation

Methods Used

The course is based on participation, group work, and collaborative discussion. There are lecture sessions to formalise and confirm the findings from the collaborative activities. The participants undertake a case study through the course, building up to a final complete set of documentation and knowledge of the topic.

Why Attend?

Industry studies around the world suggest that five out of every six software projects fail or are “challenged” – over time and/or over budget. Looking through a requirements lens, we see that some of the main contributors are:

• A poor understanding of the VISION or expected business outcome affecting top-down requirements practices
• Poorly defined requirements, especially the lack of emphasis on Quality or Non-Functional requirements
• Incomplete, inconsistent, vague and disconnected requirements affecting requirements communication, implementation and testing.

Whatever the system development lifecycle (Agile, V-model, waterfall etc.), when requirement’s are poor and the required business outcomes are unsatisfactorily documented then requirements tend to be ‘invented’  – usually by the programmer. But the decisions that software developers make are often different from the decisions a subject matter expert would make under the same circumstances. When a project fails it is often seen as a direct result of poor requirements practices.

Registration Information

Telephone: +966.1.4661406
Fax: +966.1.4661398
Email: training@jodayn.com