These analysis example documents, briefing studies and case study all complement each other and are aimed at systems analysts, junior business analysts and degree or diploma students.
Their primary focus is on business systems, their analysis and the specification of a set of business requirements, all done using a pragmatic approach to the use of the Structured Systems Analysis and Design Method (SSADM) and others such as DSDM.
They hardly touch on technologies, apart from covering off Technical Systems Options, which will be generic in nature. The requirement specifications produced stop just prior to anything that would be solution specific.
So, if you're into business analysis, systems analysis, requirements gathering and capture or an IT project lifecycle, you'll learn something here.
The author, Mark Ridley, has been using heavily pragmatised versions of SSADM / DSDM since 1990, and has been a freelance business analyst since then.
In that time he has seen and has been retained to correct many instances of a flawed approach to analysis and specification within in-house IT departments.
What you will find here is a distilled set of experiences and best practice techniques, applicable to most data processing environments, within the context of briefing study guides and case studies.
Analysis Example Documents
Real-life example documents These documents are taken from actual projects undertaken by us and demonstrate how the approach used on a project is dictated by its profile. Business analysis is not a prescriptive recipe, rather it's an approach that has to be tailored each time, as befits the characteristics of the project being undertaken - as these documents show.
Briefing Study (Tutorial)
Requirements Analysis Specification The purpose of this Briefing Study guide is to define an optimal set of techniques that deliver a Business Requirement Specification to an external supplier. From the specification and with access to the business users for design decisions, the supplier will be able to prepare a fixed price quote for the system covering logical design, physical design, code, build and test.
Get the e-book instead...
Our briefing study web pages covering Requirements Analysis and Specification are so popular, we've now made the whole study guide available as an ebook. A handy reference you can carry with you on your phone, tablet or kindle!
Acme Fashion Supplies Feasibility Study The case study presently covers the Terms of Reference, and partial Dataflow and Logical Data Models. This is a work in progress and mimics those products' developments in a real project.
Acme Fashion Supplies provide fashion goods, aimed at European and traditional UK tastes, on a sale-or-return basis. Their customers are high street shops and other retail outlets.
It uses mainly manual processes with some ad-hoc computer support. Acme has embarked on a strategy to provide automated and integrated support to these processes and to embrace the opportunities presented by the world wide web and the internet.
Get the e-book instead...
The case study is now also available as an ebook. Now you can carry it with you on your phone, tablet or e-reader and learn when it's convenient to you!
The best bits of SSADM - made pragmatic
Diagramming notation explained Pretty much all of the studies and guides use standard diagrams of various sorts, all drawn from the Structed Systems Analysis and Design Method and applied in a modifiable, unrestrictive way. This slide sequence explains the notation used for each.
Agile: the be-all and end-all?
No! Read this refreshing article Agile Myths and Truths by Laurence Nicholson. Here's a short quote:
There are many ‘Agile’ evangelists who claim that going ‘Agile’ is the answer to all your problems. It isn’t.
Now, I confess I am a big fan of incremental software development techniques, and ‘Agile’ is as good as any, but it can throw up as many problems as it professes to solve.
The claim from the governing body is that ‘Agile’ frameworks help companies accelerate time to market, increase productivity, and respond to changes in priorities.
Let’s take a look at these along with the beliefs that it is easy to implement and is widely accepted...
It has been my own experience that application of the Agile software development approach to the Business Analysis phase of business change projects is fundamentally flawed.
Another quote from Laurence:
When considering expanding ‘Agile’ outside of the technical environment, you have to bear in mind this is a technique created in the engineering world, including software engineering or development as we now call it.
Extending it to corporate disciplines is difficult to say the least and, as mentioned, project managers by definition have to know how to react as quickly as possible to changes in the project requirements, and are already using techniques to do just that, albeit in a more structured and formal way.