What I want to get from the Business Analysts

These are the things I would like to get from the Business Analyst specifications.  I wrote this up for a friend of mine who was a BA and asking me about it.  So from the point of view of a dev guy who has done app maintenance, DBA work, testing and performance analysis here are my view points.

The goals are to make sure there is enough detail for:

• the developers to build the application
• the DBA to understand the data model
• the operations guy/gal what kind of information they would get at run time
• the testers to write their test scripts
• the performance tester to determine what are their targets
• the trainers to write a course on the application
• the stakeholders to know what they are paying for
• the BAs (both client side and your side) to understand what need to be going on.

One thing you should know is business analyst specifications unlike requirements are living documents like source code.  Although they should not change too much.  The items here are not necessarily Curam specific, but it links to some of the Curam specific requirement gathering documents.

Starting point document

A starting point document would document what someone would need if they want to know what is going on with the project.

It should have the following:

Specific Objectives or goals for the user.  The key things are that they are specific and for the user (or the user's client) such as "get a job for the person" or "gather all the information needed for the mainframe rules processing."

A Glossary of Terms so everyone speaks the same language.  Every industry has their own lingo, so having that there reduces the confusion.

A References section which lists business documents such as the ones described here or requirements and where to find them.

The Business Analyst Document Template specifications.  This would guide people how to read your documents.  It would list your document types, their purpose and audience. (Fortunately I kind of written what the types are for you in this blog entry).

Ideally a BA document has the following:

• Title page which shows the document type, the subject and version number.
• Version history.
• The meat.

The starting point document already says what the document types are and their purpose, so don't repeat yourself.

End-to-end scenarios

End-to-end scenarios should be the basis of any BA specifications.  They should be written up as graphical work flow representations with little detail (the little detail is important because if you put in too much detail on this level it will take too much time make make things harder to change).

They are taken from the goals in the Starting point document.

It should talk about how a person would manually do things.  Knowing how things are done manually makes it easier to communicate with the stakeholders (users or client) as they must know how things normally work in case the system breaks down.

It should have the following sections

• Objective or Goal
• Enactment events or How the scenario starts
• Workflow diagram

For the stakeholders a visual representation makes it easier for them to understand what is going on.

For the testers the flow gives them an idea how to do their functional testing.

For the developers if they have a workflow engine, they can utilize the workflow engine to do their work or they can implement but have their unit test planned out as well.

For the business analysts they help define the screen flow and the domain specifications.

Domain specifications

The domain specifications is where it gets really interesting.  I put it before screen flows because this is usually what is missing in most of my Curam projects.  However, it is not really much of a problem outside of Curam projects I find though.  However, this can be done in parallel with the screen specifications.

When dealing with domain specifications it is best to think what you as a BA are more used to communicating in.  I prefer a more object oriented fashion rather than a database oriented fashion because it lets me avoid getting into lower level details which should be done by the developers or the DBA.

For example, I would talk about a Case as a single object that can contain other objects such as Case Members which has a reference to a Person.  A Person is a Participant which has a name.  And I could go on.

The advantage of dealing with it in an OO fashion allows me to deal with a collection of objects as one object graph.

Although when I write these, I don't expect the BA version to be the final copy.  I would expect the developers to give me a cleaned up version of their UML diagram when they finish from their tool (though it should look relatively the same).

The way this is written would be one document per object graph and a high level object graph diagram.

The high level object graph diagram shows how each object graph would link to each other.

Each object graph document would show:

• a UML static class diagram of the object graph
• each class operation should be sufficiently named so what needs to happen is unambiguous (otherwise the BAs would have to write out what the operation is supposed to do).

The BAs specifications do not show the following because they are too low level

• CRUD operations
• Find methods.
• Sequence Diagrams
• private, protected operations

For the stakeholders the UML representation allows them to see how things are aggregated together.  You can explain to them that each box is like a folder which can contain other folders or papers.

For the testers, knowing the domain model allows them to perform data checks directly on the database without the UI.

For the developers it allows them to write a UML class diagram that can be shared with the BAs for review.

For the DBA it allows them to write a logical and physical data model more easily.

For the business analysts they help define what the data you are dealing with and what operations can be performed.

Screen flow specifications

The end-to-end scenarios would provide the detail on what screens should be available.  These documents generally come up to look like a site map.  It is best to work with a UI person on this one.  These would define the following:

• Global page links (e.g. inbox, change password, logout page, preferences)
• Page hierarchy (which allows us to make breadcrumb navigation, a very simple yet effective page navigation metaphor)
• Page link map (only show links that are neither defined by the page hierarchy or the global page links implicitly.

For the testers the flow gives them an idea how to do their functional testing in terms of screen flow.

For the developers the screen flow helps them figure out how to link pages together.

For the business analysts they help define what screens they would need.

Template Screen specifications

The template screen specifications talk about the global look and feel of a screen for the application.  You may end up with more than one template depending on the complexity of your application, but you should have at least the following:

• Global navigation
• Page hierarchy navigation
• Global page component list (e.g. date picker component, numeric input component, etc).
• Accessibility (if it is in scope) requirements.
• Internationalization (if it is in scope) requirements.
• Common fields (e.g. start date, etc).

These should be done with a UI person who would create the layout in HTML for you.

Individual Screen specifications

There are two components to the individual screen specifications.  The actual business data and how it looks like.  How it looks like should be kept as a separate document written by the UI person.  The business data which the BA should do specifies the following:

• Template used (if there is more than one or it is not the common one)
• Screen (purpose,overall validation on submission if any)
• Fields (purpose, validation rules, default values, selection list)
• Links (where do they go to)
• Submit button (what do you want it to do when you submit the data)

Treat each screen as an individual document, this allows you to update one screen without having the developers read through the entire document to find what has changed.

The template screen specifications already specify some common field information so DO NOT REPEAT YOURSELF.  If you are repeating something often then put it in the template specifications.

Validation rules

From the screen specifications and the domain specifications, you should be able to determine what validation rules you would need aside from the obvious mandatory validation, format validation.  What you need to describe are business validation such as SIN validation etc. (although I would recommend you just put in links to some web site that describes the algorithm for you... Google is your friend).

The validation rules document should only describe the ones that are global rather than domain or screen specific.  Screen specific or domain specific should be put in as part of their respective documents.

Business rules

Business rules are best written out as decision tables.  You can use the same technique I used for Curam rules.

Non-Functional Requirements

These are not necessarily part of the business flow but is much needed and usually forgotten.

• Logon/Authentication process
• Authorization management
• Change password process
• Logging/auditing requirements
• Off-line access (if any)
• Data archiving requirements
• Privacy requirements
• End user messages
• Performance targets