Great things are not done by impulse, but by a series of small things brought together.
Vincent Van Gogh (1853-1890)

Document solutions as a specification
So now you’ve bonded with your client, analysed their problems and designed a solution which they can understand and agree to fund. How do you build it? Well luckily you’ve got a number of choices depending on your organisation. You may have an in-house development team or a trusted external supplier. You may use an off-shore company or go out to tender. All you need for a quote is a specification which is accurate, unambiguous, comprehensive and doesn’t pre-suppose any particular software or hardware – after all you’ve already specified your technology constraints in the form of non-functional requirements.

The document is commonly called a Logical Model (or Functional Specification), and the documentation standards come in a variety of shapes and sizes. They can range form a highly prescriptive and highly detailed document – good for tenders, mainframe systems and outsourcing – through to minimalist documents which just aim to capture concepts. The later are good for exploratory projects where the final solution is not known and may require several iterations before it emerges.

In the end the project will dictate the level of documentation which works best but be sure you understand what you leave out as well as what you’re including.

As many of you know, the analyst’s job doesn’t end there. They can be called on to write business cases, manage the project, write and conduct acceptance testing…..etc. However lets stick to the basics for now.

As mentioned at the start of this article, there’s plenty of talk in the industry about business analyst’s skills. The following skills have been refined by IRM in over 20 years of business analyst training and have been packaged into three course covering the fundamentals of business analysis.

Requirements Gathering & Specification (RGS)	Engage with clients	scope project, set boundaries, agree system targets write a Terms of Reference (Project Charter) plan and conduct stakeholder interviews establish functional & non-functional requirements analyse and prioritise the client's requirements validate for completeness & accuracy document a Business Requirements specification present recommendations to stakeholders
Analysing & Solving Problems (ASP)	Analyse client problems and create solutions	use standardised methodology for identifying and defining problems apply techniques for analysing problems, their root cause and impact use creative & lateral thinking techniques to identify solutions assess solutions based on risk, impact and feasibility select and justify the recommended solution
Business Analysis (BA)	Document solutions as a specification	describe typical development lifecycles describe milestones and the checkpoint process model existing systems produce data and process models of proposed systems define supporting data in a data dictionary specify process logic (business rules) apply essential modelling to current/future systems document business requirements as a functional specification