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.
| FLOW | WHEN USED |
| Pre Flow | When 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 Flow | When the system has verified that the data provided is correct or as expected |
| Sub Flow | When the system proposes an action and the user confirms that the system can execute the proposed action |
| Alternate Flow | When the user moves away from the current screen and does not return to this exact screen |
| Exception Flow | When the system detects something went wrong |
| Post Flow | When 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 |