Business Analysis

We provide skilled Business Analysts to the market who has an ability to clearly and crisply identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement, organisational change or strategic planning and policy development (our Business analysts by default also include IT business analysts, technical business analysts, online business analysts, business systems analysts, and systems analysts).


MetaPerformance specialises in developing Business Requirements Specifications (BRS) relating to Information Technology (IT) based systems. The Business Requirements Specification formally documents the business needs, both existing needs and also the changes that are required in the status quo. It documents WHAT is required, and its primary audience is the designers, who will determine HOW these needs are to be met.

The What and the How cascade down through to the lowest level. Thus the sub-system designers will then use the system design as a statement of WHAT is required, to generate a sub-system design, which specifies HOW the sub-systems needs will be met (e.g. a functional specification for a sub-system). In turn, the component designers will use the sub-system design to generate component (module) designs, which specify HOW the component needs will be met (e.g. the physical database structure, the use cases, and other aspects of the technical design).

The BRS focuses on the business need (WHAT), rather than physical implementation (HOW). Talking with stakeholders about HOW the process may be implemented inevitably leads the discussion down into the physical details of operational procedure or technology. This closes off options, and can lead to an incomplete specification. By contrast, using the diagrams listed will avoid implementation detail, as they are technology-independent. A second option for refocusing on WHAT rather than HOW is to ask stakeholders: “WHY do they do that”. This can elicit policy, legislative, cultural and procedural reasons or requirements to be met. However, it can backfire: stakeholders can hear the question as: “Why do YOU do that”, and become defensive particularly if the only reason is that: “we have always done it like that”!

These requirements are structured as follows in our BRS:

  1. Context Level Diagrams
  2. Data Flow Diagrams
  3. Work Flow Diagrams
  4. Data Dictionary & Entity-Relationship Diagram
  5. State Transition Diagrams


  1. Level 0 – Context diagram/ Business Model – describes the particular environment at its highest level, showing interaction with other IT Systems and organisational functional areas/ processes.
  2.  Level 1 – expanded detail on Level 0. Each of the processes described at L0 is expanded on in more detail.
  3. Level 2 – Detailed Business Process Maps and Descriptions – the Level 1 processes are decomposed into detailed process steps, triggers, inputs, outputs, roles and required technology. The process flows specifies the origin and destination of data; the flow of data; the processing of data – derivation of new data, changes in the value of existing data, and changes in the status of existing data. This Level also includes the development/specification of:

Business Rules

Rules that govern the process and related decisions.

Functional Requirements

Contains the functional user requirements and statements.

Data Flows and Data Requirements – depicts the flow of data through the certification and accreditation processes and how it must interface with the ICT System (i.e. stored data), and external system interfaces

Contains the related data input and process output fields. The above principles are explained in more detail with the two diagrams below


Who We Work With

  • AlexanderForbes
  • Rhodes
  • Bestmed
  • Anglo American
  • DataCentrix
  • Enviroserv
  • FirstRand
  • Sasol
  • FTP
  • MTN
  • Omnia
  • PEP
  • SABS
  • Sasol
  • StandardBank
  • SunCityResort