Basically, the objective is to create a visual representation of the software specification document. This visual representation would capture various scenarios involved in the software.


  • Picture speaks louder than words
  • Catch scenarios so that they need to be handled by the developer
  • Becomes a knowledge map for others
  • Can be used as a reference
  • Can be used for knowledge transfer as well.


  • If possible, we can dynamically modify the visual representation to add scenarios when site issues are found and they were not identified initially.

I do not know how to do this. But I would like to invest time to find out how to do this. But is it worth the effort?

closed as primarily opinion-based by gnat, user40980, Bart van Ingen Schenau, Dan Pichelman, Kilian Foth Jul 14 '14 at 10:18

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Can you point me to an example of such a map? I think, if the program get's even a little complex - the complexity of such a map would be overwhelming. – mhr May 29 '13 at 6:33
  • 3
    First thing that comes to my mind is UML (en.wikipedia.org/wiki/…) - which is a standardized way of visualizing different aspects of software. Have you checked if UML can solve your needs? – Rafael Emshoff May 29 '13 at 6:56
  • Then again - check out this Q&A: programmers.stackexchange.com/questions/1095/… , might be this answers your question. – Rafael Emshoff May 29 '13 at 7:00
  • @mri: I agree that it gets a little complex. I googled now and found some mind mapping utilities which might help me. – a3.14_Infinity May 29 '13 at 7:24
  • @RafaelCichocki: I found mind mapping softwares which fits into my requirement here. UML diagrams would help, but some mind mapping utility helps with more options. – a3.14_Infinity May 29 '13 at 7:25

Well, I'm going to talk a little about my experience with AndroidRipper, perhaps it can help you.

When I was designing the general architecture for my thesis project, I had the idea while sitting on a bench. I only had paper and pen, so I sketched up a Class/Package Diagram (I'm not very strict about UML) the captured the barebones of the idea. Here's the very first draft BTW:


The constraints of the medium helped me to focus on the pure functionality rather than how to implement it, so that in the end all the classes listed in that high level diagram ended up being abstract ones or interfaces.

The diagram could also be read data-flow schematic since (at the third or fourth attempt...) I drew the components so that you can follow how they interact with each other, in ordinary situations, going clock-wise. Each component is then moduled in its own class diagram (but these were made much later, on my PC) where extra ordinary situations and submodules are described in detail.

In my case, the software was supposed to be used by the software engineering department, therefore using UML made complete sense. If you map needs to be used by non-techies, then maybe a generic diagram is better suited.


We ordinary use Google drawings or alike to chart rather complex structures -

like this one can collaborate in-sync ... and things get way more obvious.

This is pretty much the same like so called "paper tests" were once.

Sometimes it might be even required to revision the chart while the implementation,

just because things not always work out as imagined - this is like a visual documentation.

Also, when added new developers to a project, it's more easy for them to understand.

Sometimes I chart things with "Connected Mind", especially when I'm on the train.

Sorry, I'm not allowed to show off anything :)

Not the answer you're looking for? Browse other questions tagged or ask your own question.