Briefing Study: Requirements Analysis and Specification (slide 6)
Three data-centric, overlapping views
These views get produced in parallel, each focussing on a different aspect of the areas of the business in scope:
FunctionThe procesess that take data, transform it and make it available to the recipient (the Dataflow Model - DFM)
On the dataflow diagrams you'll be referencing data all the time. The datastores hold the entities that appear in the logical data model. You'll expect to see processes that cover off at the minimum all the creates, reads, updates and deletes on the CRUD matrix for each entity.
StructureThe interelationships between data groupings (the Logical Data Model - LDM)
All entities in the LDM must appear in a datastore in the DFM with processes to create them, update them and delete them
SequenceThe business rules around the lifecycle of a data entity
These get recorded in a CRUD Matrix in their simplest form (create / read / update / delete), or in Entity Life History diagrams when more precision is needed or where complex business rules apply.
Of course, every entity on the CRUD matrix must appear in the LDM and in the DFM (and vice versa). You might only do entity life histories for one or two business-critical entities, or none at all - circumstances will dictate.
A really great side-benefit of preparing each of these views is that they are cross-validating, helping to identify gaps / inconsistencies early. And spotting those things early is key to a successful project. This is because the later they are found, the more costly, the more delays and the more hassle it will be to sort out.
How does the cross-validation happen?
For example, while doing some LDM'ing with the users, someone mentions off-handedly that the best customers get a seasonal gift pack, value depending on volume of orders placed... Whoa! You check and see that there's a whole bunch of processes not yet on the dataflow diagrams in the DFM. For instance, setting the volume(s) that defines a 'best' customer, processes to ensure marketing have what they need for such folk and so on. Wait! Is there an issue here around corporate bribery?
While CRUD'ing you might find an entity never has a creation or, more likely, a deletion event. Is there a missing process on the DFDs? Was an event not spotted on the DFDs / during function definition, when preparing the CRUD Matrix? There may be a whole end-of-life process that gets intiated that has been missed (such as transfer of account / rights on a personal customer's decease).
Attention to detail
This is one of the characteristics needed by a business analyst in many aspects of the role. A great example is in cross-checking deliverables. Are they complete and is each item in them consistent with the items in the other deliverables?
Attention to detail means, for example, going through each and every entity that appears on the CRUD matrix and making sure that it also appears in the LDM (and vice versa). Highlighters and printed copies come in handy for this sort of thing!
In the dataflow model, do all external entities (aka actors) on the lower level processes appear on the higher level diagram that subsumes it? On the Context diagram? Again, attention to detail means going through and double checking every one. Is there at least one process for for handling the creation, amendment and deletion of each entity and its attributes, as recorded on the LDM? Is the data on all flows which cross the boundary of the in-scope area represented somewhere in the LDM?
Are all the requirements phrased in solution-independent language? Do they say what the business means them to mean? Are they written in plain English and are they jargon free? Are they independent of each other - as far as makes sense? Is each one testable? If not, how will you know if they've been met by the solution? Is each one's priority correctly assessed? How 'hard' is that assessment by the business?
Attention to detail means cross-checking each requirement with every other requirement, looking for conflicts or unintended constraints or consequences. Attention to detail is following that up with the business and recording their decisions.
When you're reviewing a supplier's response to the requirements, attention to detail means checking that every requirement is addressed. If it can't be met, why not? What are the alternatives? What is the impact on the business? Is it a deal breaker? Have you followed up each concern?