“How can I possibly tell you what the product is going to look like until I have developed some/most of it.” “I don’t know how to design it or what it is going to do before I code it.” “Doing a Requirements Specification is a waste of time because it will change anyway.” “I hate doing them so I am not going to do it.”
Do any of these statements sound familiar to you? Have you even found yourself saying them too?
Whatever you might think, there are two main truisms about software. One, software is just a language. It is not a mysterious magic wand that mere mortals are not worthy of waving. While it might be a fancy language, it is still exists because unfortunately (or maybe fortunately) machines still need to have a human tell them what to do. Humans speak in words. So it should not matter if you say the words, “if I press the button on Y screen the “X” screen shall open,” or you write: if y.button.press = true; myapp.xscreen.launch.”
Two, software is a really just a machine that solves a problem. Once you identify what the problems you need to solve are then you can start to define how to solve them.
So why is it so hard to tell me how the software is going to look like when you are done? If you think of it as telling me what the software will do it becomes easier to envision what you will have when you are done. Then you can assign buttons and text edit boxes and drop downs when you know what you need to make happen.
How do you decide what the software should do without making some screens. The best way to do this is to ask yourself what problems and how many of them do you need to solve. More importantly what are the major important problems you are spending your money on to develop this software that you want to get solved?
What I do is put a series of horizontal rectangular boxes up on a white board. In each box I put the major problems that need to be solved. Those tend to be the major TABs in the application if it has a GUI. And if it is lower level software, those are the major subsystems.
Once you have defined those major blocks you can now go on to divide them even further into lower layer dialogs or lower level subsystems. From there you will be able to define the screen widgets or other actions that will accomplish what yoiu are trying to do.
Now with your completed hierarchical picture you have a much better idea of what your software is going to do. What is more important, you will also be able to share that information with other important stake holders in your project.
