How do system analyst use one on one interviews
Contents |
Tip you will find in this article:
- Focus on the deliverables and constraints.
- Remember that you are the bridge between the client and the developer.
- Simplify as much as possible your diagrams and system architecture
- Group deliverables into intelligible categories to make it ever so easy to understand what the system will do, leaving the detailed sub products for later development.
- Please try not to design everything the system should do, simple things shouldn't have three pages long documentations.
When interviewing clients prior to designing a system model you, the analyst, should pay a lot of attention on two things: +What they want in terms of product (deliverables) +How they want these products to work (constraints)
Building a list of products and sub products (the deliverables)
Imagine you are with a client and he/she asks, for example, a system that sends emails to a list of people (mailing list) from different countries, with a file attached to it. (It doesn't matter what file it is for now, imagine it is a PDF file that you won't have to do yourself, they will make it and provide it to you.) What are the deliverables in this example?
For me there are three main products (or deliverables): 1- the emailing system; 2- the translation system (I'm assuming different countries might mean they want the email in many languages, ask them that during the one-on-one interview), and; 3- the attachment system.
If you are an experienced developer these shouldn't be too much of a challenge: you will have a piece of code that will grab a list of emails from a database, separate them into countries based on the actual email address (xx@yahoo.com.br – Brazil, xx@yahoo.fr – France, xx@yahoo.co.uk – UK), get the text to send in the body of the email, connect to Google translation API (to translate the text), fetch the file to be attached, build the email message with the attachment and send it!
In other words:
- Fetch a list of addresses to send email to
- Separate email addresses by Country
- Fetch the text to send
- Connect to API and translate
- Fetch the file to be attached
- Build the email
- Send it!
You can see each of these bullet points as sub products that are part of the main deliverable: the emailing system. Now, this has to be clear in your mind as you talk to the client and the objects (sub products) must be written down for later reference. (Trust me, write it down as the meeting goes on, forgetting is a dangerous thing and basically you are being paid not to.)
Links between products (the constraints)
How these sub products (product, deliverable or object – all mean pretty much the same things. There are technical differences that I don't think it will fit in this article) will work internally and between them is often called "behaviour and constraints" or "assumptions and limitations". You need to design these relationships on your mind! Relationships are basically the conditions for the system to work.
If the client says: don't send the file attached if the email is from the US or don't send the email all together if the email address is from France... you should write that down and put it the technical specification so the developer know what to do. The list of relationships can be infinite and the more rules the more expensive the system will be. Don't be stuck in details though, just focus on the success scenario at first (success scenario here is: to deliver all emails to all acceptable addresses with one file attached to it) and take notes of the conditionals the client will give you "in between the lines".
The client won't say: If the email address is from France, don't send the email. No! They will say something like: Client: Our French clients should not receive these emails during the week days. Then you ask: will your system send emails on weekends? Client: No, not really.
Yes, sounds obvious that they don't want any of the French guys to receive that email, but that is not said as clearly as a developer needs to know. You will have to "translate" it! This type of conversation can take hours with many back and forth and you might end up only one paragraph of rules and relationships at the end of it.
To simplify a system analysis is the hardest thing an analyst can master
The emailing example I've given above is very simple. A system like that that does only one thing (sends email messages) will most likely be a simple part of a much more complex system will loads of different functionalities, products and relationships. A good tip is to group the product into groups and organise them graphically on diagrams that can be easily understood. No detailed diagram will be useful at the beginning of a development and you should aim for simplicity.
