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.
By the end of the course, participants will be able to:
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®).
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
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.
Introduction and Overview
Elicitation and Documentation
Analysis and Communication
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.
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:
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.