Briefing Study: Requirements Analysis and Specification (slide 5)
Position of Full Study
Although the slide shows the full study starting after project initiation, in reality there is an overlap. Often in ones I've helped initiate, a quick scoping and sizing exercise is carried out as part of building the business case.
(The business case is used to approach the board for project funds. Not quite a feasibility study, these exercises tend, by their very nature, to only need a high-level DFM, together with a quick and dirty impact analysis covering some or all of: customer, products, processes, organisation, location, data, applications and architecture. The impact analysis also includes volumetrics and degree of impact.)
Ideally a feasibility study will have been completed prior to the full study. This will give the assigned business analyst(s) a head start. The key products of dataflow model (DFM), logical data model (LDM) and Requirements Catalogue will be present - albeit to a high level. And importantly the User Catalogue, list of stakeholders and authorisers of the original study report will be documented, too.
Depending on how long ago the feasibility study was completed, these products will need to be re-assessed at the project's inception. You'd need to factor in the rate of business change prevalent in the environment in which the need exists, to guide how deep that assessment should be.
The result of the Full Study is some form of business requirement specification document. This has to be fit for purpose to hand over to a supplier. Remember, in this briefing, the arrangement with the supplier is (as stated on the first slide) that they are responsible for the part of the lifecycle from conceptual, functional and physical design, through code, build and test, to delivery for UAT by the business.
If being used as part of an Invitation To Tender document set, the business requirement specification should pretty much be fit for purpose as long as all the products of the Full Study are included. Of course, during assembly make sure that any particularly commercially sensitive material is kept out, even if there is a non-disclosure agreement in place with the suppliers. Confirm with senior business representatives.
Where exactly does the supplier get involved in the lifecycle?
Well, a high level Impact Assessment will come back after feasibility and before full study, as a response to an ITT. Where there is an existing contract with a particular suppler in place the high level IA will have been used to help inform Business System Options, prior to selection and publication of the Feasibility Report.
Where the ITT route is being followed, once a tender has been selected and the supplier chosen, the Full Study is entered with the IA. Following this route, it is possible that another round of BSOs or TSOs is needed with the business as a result of the IA.
Once the full study is properly entered and the detailed requirements are being elicited, the supplier is best involved as the requirements are being firmed up. This gives them early exposure which is always a good idea.
The supplier really starts to lead as you get properly into logical system design. They would be responsible, for example, for the rest of Dialogue Design, after the business has identified the critical dialogues (see later slide) and for things such as leading RAD or JAD workshops. In these last two, a business analyst should always facilitate / chair, to help keep things restrained and within scope. But remember, always to stress at such sessions that until something is in the signed-off requirements spec, agreement about requirements reached at such workshops have no contractual significance.
The reason for a supplier to take the lead during logical design is that so much of this stage is seen by suppliers as being constrained by their in-house approach, methods and by the platforms on which they are prepared to build / support systems. Another crucial reason is that the detailed requirements specification is best done by their "systems analysts". Why crucial? Because it gives them the direct contact with the key business users and the time to build good relationships with them that will carry them all the way through their design, code, build, test and interaction with UAT. It also gives the opportunity for knowledge transfer into the supplier at an early opportunity, helping de-risk the project. Finally, the supplier side can achieve a much deeper and more accurate understanding of the requirements.
Where does that leave the organisation's business analyst base? Where it belongs, focused on the business and helping get solutions delivered that meet the need, and not becoming immersed and embroiled in detail that detracts from this. It takes a bear of tremendous brain to be able to perform well at both ends of the spectrum and, as Winnie-the-Pooh knows, there aren't that many such bears around!
Requirements Management and Tracking
As you elicit requirements, you need to start managing them so you don't lose track. In the early stages they are likely to be high-level and difficult to objectively quantify. They're much more akin to business objectives at this level. Even so, they still need to be recorded properly and managed.
Initially you'll do this in your business analysis workstream's Terms of Reference and, later, in the Feasibility Study / Full Study documents .
The high level ones will each be given a unique reference (with a prefix do indicate they're high level) and will be cross-referenced in the detailed requirements as you drive out any directly related ones.
The initial formal record will be in whatever version of Business Requirements document you're writing (i.e. either during the feasibiility study or the full study stages). It'll likely be a table in the relevent section of the doucment. The reason it's considered a formal record is because it's that doument which will be signed off - making the requirements in it those that the business wants met.
What do you mean, track requirements - and why bother?
The whole point of this sort of project is to deliver business benefit. How much it cost to deliver each of the high-level requirements (the ones that initially justified the project) has to be offset against the benefits actually achieved once the project's gone live.
This can only be done if the requirements are tracked through their solution provision and into real-world operation:
- You start this off
- It then gets handed off to other teams as the project progresses through its lifecycle
- Ideally you'll still be around whenever clarity is needed or requirements change (remember, a business doesn't stand still!)
- If they do, you'll likely do any required impact analysis.
Once the project has been delivered, has gone live and settled past any initial teething problems, it's then that the value of benefits can be properly measured. They are compared to costs in delivering that benefit therefore allowing the true value to the business to be assessed.
Ok, so how do I track requirements?
There are tools you can get covering all or parts of a project's lifecycle. These will include a module for formally recording the requirements. Other modules within these tools, such as solution architecture, will cross reference the requirements they help meet. A test module will do the same. This chain allows completion monitoring - for example, how many requirements are left that still have to be successfully tested?
In smaller, cosier teams, it may be sufficient to work from spreadsheets, with columns recording status and completion of the various stages and ones that allow cross-referencing of related deliverables.