IBAC Analyst Standard

Function Driven Business Analysis Standard

Increase project delivery success rates within a new function driven digital era 

The Standards

A Function User Story

For every function, structured analysis and requirement gathering is performed prior to any coding and documented in a comprehensive “User Story”.

A User story is the detailed translation of an initial requirement (either by the customer or by the business) into very specific requirements for a certain function to be put in place by the project team taking into account overarching standard company architecture and design principles.

The starting point is the various industry models followed by a target operating model (TOM) with As-Is & To-Be Processes. The Business Landscape defines the Products, Distribution Channels, and Customer Journeys the solution needs to address.  Once the Customer Journeys have been defined by a Business Analyst who will translate this to a more technical description of capabilities and functions.

All applications have typically four common capabilities being Register, Logon, Profile, Logoff.  However, each application might have additional capabilities. For example, banks have a “Transfer and Payments” Capability.  Each capability has one or more functions that the user can use to navigate in the application.  Each Customer Journey identified in the Business Landscape will be covered to a function.

For each function the Business Analyst provides a detailed framework to develop a User Story and Use Case Specification.

6 Key User Story Templates

A User Story is built using six key templates to detail out the project requirements for a function.  A User Story is built for every single function.

01

High Level Processes

A High Level Process identifies the outputs, customers, suppliers, inputs, and high-level process steps for this function.

02

Customer Journeys

A Customer Journey documents the sequence of individual tasks and decisions with a focus on those that customers go through interacting with the company for this function.

03

Use Case Specification

A Use Case Specification (or Use Case) is a detailed technical document of this function. It identifies what needs to be built and implemented to deliver on the agreed Customer Journey.  It ensures consistency across all customer journeys, products and channels where required and ensures consent prior to building/ coding.

04

Wireframes

A Wireframe is a detailed out visual guide that represents the skeletal framework of an application describing the validation and behavior rules for all screen attributes for this function.

05

Sequence Flows

A Sequence Flow Diagram displays the sequence of messages exchanged between the objects needed to carry out the functionality of a scenario for this function.

06

Test Cases

A Test scenario is made up of multiple test cases which are made up of multiple test scripts. A Test case identifies all the test scripts that must be tested.

Six Use Case Attributes

A Use Case is at the heart of the User Story.  A Use Case is detailed out along six attributes which each make up a section in the Use Case document.  The Use Case can be used as a stand-alone document by the developer to start coding

01

Capability Model

The Capability Model is part of the IT Architecture. On this Model the user will identify on which Topology layer or layers the capability/function is located.

02

Pre and Post Conditions

Conditions that must be met prior or after to ensure this function can be executed as required.

03

Flow of Events

Details the pre, basic, sub, alternate, exception and/or post flows from the Customer Journey(s) identified previously as part of the User Story.

04

Screens/ Interface

Details all the screens and interfaces the user will go through. These are further detailed out in the Wireframes later on as part of the User Story.

05

Data Definition

Details out the input and output fields across all screens for this function. These are further detailed out in the Wireframes later on as part of the User Story.

06

Document Acceptance & Sign Off

Formal sign off by all decision makers allowing the project team to start the build and implementation.

Six Flows

Each function follows one or more of six Flows.  All the flows will be detailed out for a specific function in the Use Case.

FLOWWHEN USED
Pre FlowWhen the system is still on screens not belonging to this activity but is already (potentially) preparing for or collecting data that can be used in this activity
Basic FlowWhen the system has verified that the data provided is correct or as expected
Sub FlowWhen the system proposes an action and the user confirms that the system can execute the proposed action
Alternate FlowWhen the user moves away from the current screen and does not return to this exact screen
Exception FlowWhen the system detects something went wrong
Post FlowWhen the basic flow or exception flow has ended, triggering the next screen to be rendered

Four Patterns

Each flow follows one of the four Patterns.  Each Pattern consists of a number of Stages.  For each flow in the Use Case we will identify the pattern and define the technical requirements (activities) for each of its Stages. 

PATTERN

STAGES

Pattern 1

Data Entry

Execute

Pattern 2

Data Entry

Propose & Confirm

Execute

Pattern 3

Eligibility

Data Entry

Propose & Confirm

Execute

Pattern 4

Eligibility

Data Entry

Propose & Confirm

Digital Signature

Execute

FBAR

Funtional Business Analyst Repositry

FBAR is a repository hosted on the product WESTER that contains MVP’s (Minimum Viable Product) for any industry, with Capabilities and Functions that can be deployed on a MVP. All the training courses create a MVP, while Product Courses create Capabilities with Functions that can be deployed on the MVP framework.
 
Companies can use WESTER to reverse engineer an existing application (AS-IS) and create a repository of Capabilities with Functions. Functions have Use Cases (Pre, Basic, Sub, Alternate, Exception and Post Flows) for every function/customer journey. Use Cases have Wireframes with tagged fields and specifications which are stored in a dictionary. Use Cases have Test Cases and Test Scripts for each function.
 
Companies can then use the repository with the dictionary that was created during the AS-IS reverse engineering process to create a new TO-BE application within minutes. New Capabilities and Functions with all the Use Case, Wireframe, Test Case detail can be added to the AS-IS and TO-BE generated application in the repository.
This will reduce the five (5) year transformation plans to months and save millions.