Company logo of Crocus Information LtdCrocus Information Ltd

Business Requirements Analysis consultancy to blue chip companies

Briefing Study: Requirements Analysis and Specification (slide 11)

rass, supplier designs, builds s11 - techniques listed

this briefing study's slide map | previous | next

Techniques and tools listed

The following are the core techniques you need to have in your toolkit. A good understanding and some experience in putting them to use (together with "soft" business analysis techniques such as relationship building and influencing) will make you an excellent contributer to projects as a business analyst:

  • Requirements Definition (RD)

    Understanding quantifying and recording the users' needs of the system and the associated non-functional requirements.

  • Dataflow Modelling (DFM)

    Expressing the totality of the users' in-scope business processes as a set of diagrams with their detail documented in prose and list form.

  • Logical Data Modelling (LDM)

    Expressing the users' data needs of the system as a diagram with supporting prose and lists describing their detail.

  • Function Definition (FD)

    Defining from the users' perspectives the discrete functions that together cover all processing of the required system, taking into account the practicalities of the day-to-day running of each business area.

    As a business analyst, you'll be doing this at a high level without much regard as to what might or might not be automated. The solution provider's systems analysts will take it to the next level of detail where the boundary gets defined between the (computer) systems and the business process and its users.

  • Event / Entity Analysis

    Identifying the triggers that cause a process to do its thing and recording the way that this changes each affected entity's attributes. It is also where you identify the business rules.

    An Entity Life History (ELH) diagram is a structured way of expressing what you find but you might only use this on really key entities, leaving the CRUD matrix as a higher level view. (CRUD stands for Create/Read/Update/Delete.)

  • Business System Options (BSO)

    Together with the key business stakeholders' you produce a range of options for taking the fulfilment of the requirements forward. Each has an associated cost / benefit analysis and (often) its own supporting dataflow model and logical data model. The project board or governance group then chooses which way to go.

  • Dialogue Identification

    Ususally done by a systems analyst: Identifying at a practical level the critical dialogues (two way interaction) with the system. What logically has to be on screen, what is keyed in, what comes back, what then gets done using the screen before that dialogue is complete.

    A business analyst might do one or two to give to potential suppliers something they can get their teeth into in their proposals / bids for the work.

A rose by any other name

No matter the organization you work for, in the projects you find yourself in as a business analyst, there will always be an equivalent to the above in the methods they use. So, if you already are or can get familiar with the above tools and techniques, you'll have great transferable skills that open doors for your career progression.

Go to Top
exercises on modelling process and data


The difference between a business and a systems analyst

Although you'll often hear people using the terms interchangeably, they really are two different roles.

I like to think of the difference as being defined by where in a project's lifecycle the two roles come into play. A clue also lies in the names used.

A business analyst is concerned with the operation of units of the business carrying out their full range of activities. No matter what solution supports those activities, the activities are needed by themselves or as part of a greater whole in order to meet a business need. That's their only reason for existence.

A systems analyst is concerned with those activities within a business sytem that are carried out by an IT system (computers, automation, telephony etc) and not so much the operation of the business unit as a whole. Their concern is exactly where the boundary between the two lies.

Logical sytem design is the point in the project lifecycle where this becomes important and is therefore the transition point from business to systems analysis and that's the definition used for this briefing study.

Another way of looking at it is to realize that it costs money and time to gather, document and confirm information.

Going beyond the level of detail needed for a particular analysis phase in the project not only takes longer but is likely wasted effort. For example, let's say the business option the project board chooses to take forward excludes some of the requirements from its scope. If the detail had been driven out for those requirements, that would be wasted effort.

It makes sense that you only go to detailed requirements after you have agreement from the business stakeholders that their higher level business requirements are complete and accurate.

In the lifecycle in this briefing study, the next phase after this signoff is logical system design. This is the point where the supplier, whether internal or external steps in. So everything points to this change in focus being the place where the role changes from a buisness anlyst to a systems analyst.

Responsibilty of the Business as a solution designer

If you've done your job as a BA correctly, you'll have documented the 'to-be' in terms of business processes and requirements, without regard to where the system boundary lies.

This means that some of the requirements may not be met by the system but manually, by the business. So, when the time comes during logical systems design, it's incumbent on the business to provide the solution design for a set of process and procedures to cover off the manual acticity.

This achieves two things:

  • Involvement with the logical system design will encourage the business representatives to think in a focussed way and improve the quality of the final outcome.
  • When the time comes to do full end-to-end business testing, things will be easy for the test teams with the business steps being already defined.

All the above means...

Everyone wins because this approach will have uncovered issues at the earliest opportunity, before doing detail work that can subsequently be invalidated by arising circumstances. This reduces wasted effort and rework, helps with hitting deadlines and helps keep the project in good shape.