I'm currently developing a small Database Management System for a local company. How would you go about explaining how the system you have designed to a client? If they are non-technical and have no understanding of programming, how would you go about showing what the system will do and how it will do it? I guess some sort of visual representation of the system but this seems very patronising to me.
+6
A:
Slowly and with pictures :-)
Seriously though, I would avoid explaining how it works and focus on what it can do for them - the benefits it brings.
You may need to explain how it operates but do this in the context of solving a particular problem or implementing part of some business process.
Chris McCauley
2010-05-25 06:49:59
+1 Sadly the picture thing is no joke, every time you think you will need to say more than 1 sentence about a feature you should accompany that with a grafic visualization of what you say. it sounds over the top but this is how it works.
ntziolis
2010-05-25 06:53:23
I know! I almost dropped the smiley because it's too often true.
Chris McCauley
2010-05-25 06:54:34
Absolutely - the key here is that they know - or should know - what they do, you are providing a tool that will help them do that "better", they don't particularly care how *providing* that it does what it does right. So yes, Slowly and with pictures!
Murph
2010-05-25 06:58:28
+1
A:
Try to explain what the decisions you made mean for the client. What value does it have for them. Don't try to go over the technical aspects, because they most likely wont understand it.
Ikke
2010-05-25 06:50:21
A:
I'd go with @pranay's solution.
As of designing an application, you have probably created some artifacts to help you do so.
When I do that, I usually follow Rational Unified Process. Doing so, I use Use Case Diagrams for the functional requirements and a Software Architecture Document for non-functional requirements. Simplifying that: non-functional mean more technical stuff. The functional documentation (use cases, system sequence diagrams, etc) can be used to document your application design and can be read by any client.
The use case model can simplify the overview of the system by functionality. Each use case description (fully dressed version) can be checked by the client to verify if it complies with his requirements.
/X
mjsr
2010-05-25 09:04:08
These design artefacts helped you to write the application. They will be meaningless to the client who just wants to use it.
Joe
2010-05-25 09:11:17