Briefing Study: Requirements Analysis and Specification (slide 9)
All about the 'sequence' view
The one vital thing that is missing so far is what happens to data over time? What must happen before something else can happen? In what order do things have to happen? What are the common and not-so-common exceptions? Again, you'll likely want some examples.
Back to my small business, PhotoReady, selling stock photos over the web. I keep a record of my customers, what they've bought, when they bought it, the accompanying emails I get that tell me what has been sold and any VAT receipts issued on request.
Ok, so what about the time / sequence view?
How is a Customer entity created? (i.e. how do I first get to know about this customer?) Simple, I get an order from someone who isn't already a customer. Or perhaps I get an initial email enquiry from someone before they become a customer proper. (NB I'd still record them as a "customer" but, having no orders recorded from them would tell me they are not yet a customer proper.)
What causes me to change the details I hold about a customer? Well, in a subsequent order they might include a note to the effect that that they want me to use a different email address for them in any email correspondence. They might send me an email directly asking me to change, say, a misspelling in their name.
What causes me to remove a customer from my system? Well, they might ask me to (but I won't if I'm in the middle of processing an order from them, obviously I'd wait 'til after, unless I was planning an emailshot, in which case I wouldn't want them to be included). Even after I remove them, I still keep a record of their orders.
Every year or two - or at a whim - I archive off the info I hold on inactive customers. I also go through my mailing list from time to time, taking off customers whose email address no longer works or where they never read their mail (if the mailbox is always full, I'll keep getting bouncebacks).
If I receive an "unofficial" email order, and not one where they've gone through my shopping basket system, I won't email out the ordered items until I get confirmation from PayPal (my order processor) of payment receipt, unless they're a well-established and trusted customer.
Apart from where I decide it is time to archive off inactive customers or to deal with bouncebacks, in each case it is the receipt of something that triggers me to do something that causes a change to the data I hold in my business system.
And there are some business rules in the above, as well. Did you spot them? Hints: removing a customer; trusted and well-established; bouncebacks.
You should see a lot of overlap here with both structure and function. The time / sequence view shows the sequence of processing, and the business rules that guide the processing, that happens to entities, from triggering event through to completion, for all types of events over the whole life of the data entities.
Softer skills of the Business Analyst cont'd
Golden Rules 1 and 2
First and foremost I recognise that my client is the business
I will be a bridge and interpreter between the business and solution providers
To best fulfil those rules, these are important considerations:
- Even though an IT/IS department may pay your wages / fees, your loyalty must be seen to be with the business - for the project duration think of yourself as seconded to the business.
- When you meet with stakeholders, explain that your BA loyalty lies with them, that you're there to help make sure that what gets delivered will actually meet their need.
- In project meetings that involve business representatives, always be seen to be supportive of them.
- Make an effort to establish a more informal relationship with them, as well as the formal one of being a BA.
- Always be a little early if you're meeting with them, make sure they realize you know how valuable their time is. And always finish promptly. If they're being quite generous with their time, you be quite generous with the coffee!
- If possible, get all the key business people included in, say, a bowling night out for the project - project budget pays for the first couple of drinks. Your job on the night is to make sure everyone mixes and to spend much of your time with the business peeps.
- In meetings where both business representatives and technical people are present, make sure jargon is avoided. If it comes up, translate and then use your skills in diplomacy to ask for it to be avoided. Remember that people often won't speak up when they don't understand or disagree, so watch for any body language signs and then facilitate the right outcome, again using any diplomacy needed.
- If you are told things in confidence, respect that confidence and go out of your way to protect the identity of the source.
As you do the above, you'll find the business gaining more confidence in you. They'll begin to recognise your commitment to ensuring their requirements are met. That's when they start to accept you and begin to see you as their champion.
When you achieve this, your job will become so much easier.
And what about the solution providers?
Remember, you are the bridge between them and the business and this means establishing great relationships with key people in the solution provider teams as well. As you meet with them
- You'll explain that your philosphy is to be almost embedded within the business, that for the duration, your loyalty lies with the business.
- You'll explain that doing this derisks the project, and keeps everyone's costs down.
- You'll emphasize that you get better, more solid requirements sooner that way. Let them know that this is because the business sees it's worth while investing their valuable time in getting the requirements right (meaning for example, that reviews get done thoughtfully and on time, amongst others things).
- You'll outline the sorts of deliverables you'll be producing and make sure that their need will be satisfied by them. For example, a Solutions Architect is going to be very interested in the process model because it's one of the things s/he'll need to map to the logical solution architecture design they'll be creating. If they're not familiar with a dataflow model, take the time to explain its key features, describing where the info is that they say they want and how it relates to and is cross referenced to requirements.
- Ask them if there's anything you can do to make their life easier. Check if there's anything that they want to be notified about if you come across it during your investigation. If so, add them to your communication plan and make sure you follow through. When you do, it will help you build your relatonship with them.
- Lastly, you'll make sure they want to attend the bowling night!