I've seen so much in the way of poor requirements work done on projects that I thought I'd write this lens.

It's all about an approach and the best practice techniques that work. That is, they deliver a set of business requirements, written in business speak, that will underpin the design and delivery of a successful solution.

If you can't wait, the main techniques I use during analysis are:

• requirements capture
• dataflow modelling
• logical data modelling

and, during logical design:

• business events
• business scenarios
• business function definition.

During both I maintain requirements compliance / traceability matrices.

By a successful solution, I mean one that comes within time and budget, that the users want, that meets the business need and that the user community feels they own.

Of course, all this must fit within a formally defined and run project (something akin to PRINCE2)

...And a successful project has a much lower carbon footprint than a failed one!

Find out more about the diagramming techniques I recommend.
Find out more about the three cross-validating, data-focused views.
Read a glossary of terms used.

In my many assignments, working alongside both client and consultancy business analysts, I have seen the flaws of what I call non-structured, 'sleeves-rolled-up' approaches to business requirements analysis, albeit by well-meaning folks.

But it has also been my pleasure to work alongside and learn from some real professionals in my career - they have shaped my development and to them I owe many thanks.

I personally have delivered requirements and logical solution architectures for many successful projects in energy companies, financial organisations and for major government initiatives. I have never delivered requirements for a project that failed.

I have worked with and alongside many major and minor consultancies, including Capita, Accenture, Logica, Fujitsu, Aspire and others.

I have had suppliers say that they have never had such good requirements from which to design solutions. Solutions that they say means they will have an easy life, knowing that what they build will meet the users' needs.

Sorry, no magic ;) just common sense...

1) Understand and document what, not how, using a structured, self-validating method.
It must be understandable by, and developed in conjunction with, the business.

2) Then help the business define a logical solution architecture (a conceptual design) that meets all the mandatory requirements.

Do these things and you'll have nailed it :) - it's now time to pass it on to the solution designers for some initial work.

3) The technical team will provide IT solutions, the business will provide manual process designs and the financial team will provide support in creating a cost model for both. Project management will assist in developing an outline plan all the way to business as usual.

2) and 3) together provide the first Business System Option (BSO). Others are prepared based on major variations of the requirements to be met, perhaps dropping some mandatory ones and including some value-add / nice-to-have ones.

One BSO is recommended to the project board, with reasons why and reasons for rejecting others.

The project board approves one and then detailed design and requirements specification can go ahead, leading to build, test and deliver.

(more detail below..)

1) When you first join the project, as lead BA you must understand and document the scope of the business analysis workstream by writing a Terms of Reference (ToR). If you are not the lead BA then familiarise yourself with the ToR.
This will also help kick start you on the analysis work, setting the scene, outlining the approach to gathering requirements, defining the deliverables, documenting the project aims and objectives, identifying the stakeholders and setting major milestones for the project plan.

2) Get the top ten or 20 conceptual level requirements documented - a spreadsheet will do just fine - gaining senior management / stakeholder buy-in on the way.
You can get an initial list from the Project Initiation Document (unless your work is to be used as input to it, as happens when you're there right from the beginning) or you can put together a straw man list for a workshop of senior management / stakeholders to take it apart and build up again.

3) If need be, conduct an analysis of the current business systems - for example if the project is for a change to an existing set of systems and processes. On the way you'll be bumping into requirements to use in the next step.

4) Cascade the conceptual level requirements into high level business requirements. Maintain a cross reference to the conceptual requirements and vice versa.
(done in parallel with the preceding step, step 3 and with the modelling, see topic below)
Make sure the requirements are phrased in a solution independent way (this is absolutely vital) so they're only about "what" and not "how".

5) Divide the requirements into functional and non functional. For the non functional requirements make sure you cover off areas including access and security (resilience, integrity, privacy), audit, disaster recovery, business continuity, legislative and industry compliance.

If you are analysing the requirements for change to an existing system then here's the guidance. If not, and you're looking at a new business system, see next topic, below.

Here are some specific examples about getting the level right:

• In getting to know a business requirement, if you start to bump too much into how it's currently done - you're going into too much detail


• If you are told 'we photocopy the order and pass one copy to accounts and one to the back office', then from a requirements point of view, the fact it's photocopied and how the copies get passed just isn't relevant.


• If the accounts department batches up cheques prior to doing a bank run then all the aspects about managing, controlling and auditing the batches and actually getting the cheques to the bank is just too much detail. The right level is that cheques get paid into the bank at the earliest opportunity.

..and some general points:

• The reason for analysing the current business system is that the requirements of the new will be stated by the various business representatives as relative to the existing.
  
  So you need to model the existing business system to allow everyone to be specific when phrasing the requirements and to be sure they're talking about the same thing


• In the current business system (just as for the required, later) you need to identify the sources and recipients of the data to be taken in, stored, transformed and output.
  
  Remember, you're interested in 'what' and not 'how', so if you start bumping into things being done purely to support the current way of doing things (such as holding orders in a temporary file until payment clears) then you know to back off.
  
  Btw, the requirement there, reading between the lines (Danger! Danger, Will Robinson!), is that received orders should wait until payment clears before being processed further.
  (Which leads to questions with the business such as: are long-standing customers treated the same? Under what circumstances are there exceptions? Is the system to enforce this in an automated way? Is stock to be allocated to the order while waiting for payment clearing?)


• A top level dataflow diagram as shown here, can be suitable for discussions / workshops / confirmation with senior management but is not at a detailed enough level to identify the full set of operational requirements / reports.
  
  By the looks of it, and reading through the process descriptions, going to the next level would probably suffice.


• The logical data model goes only to the level of business entities and their major business data items. A good example comes from the Acme Fashion Supplies feasibility study, here
  
  As long as the key business entities are present and shown mostly in 3rd normal form, you'll be fine. By 'mostly' some aspects may concealed, as to show them properly would clutter the diagram for little additional business benefit.
  
  A good example is where a history needs to be kept. To show this properly many entities would end up being replaced with a one to many relationship between the current and the past versions, with other entities now having complex relationships with either the master or the detail. Usually it is sufficient to state against an entity that a history needs to be kept.
  
  NB The full-blown requirements specification, which comes at the end of the analysis phase and once a business systems option has been chosen, will deal with the exact interplay of all entities with the present and / or historic versions.

I've outlined the next couple of topics below that I'll address. I hope to be active every couple of days until finished with this lens, so keep coming back for more :)

[tbd]

[tbd]