Use Screen Prototypes to Clean Software Requirements
I have been in software development for 15 years and I can tell you one thing: expensive misunderstandings in software development. If you are not careful, you can aim at moving targets or even build applications that are not needed or wanted by anyone. I will show you how to properly apply a screen prototype and avoid this trap, while having fun in the process.
There are many tools commonly used for prototype and GUI prototype software. Over time I have used most of them and what I have found is that they all lack in two ways: the speed and ease of use of paper sketches (which you cannot maintain, so they are also not a solution). Now with Mockup Screenshot I am satisfied with both, and I can focus on the real problem: quickly engineer the requirements for software applications.
Note that the Mockup Screen is very capable of completing all categories of tasks quickly and efficiently. You can use it (and many do it) very differently from what I will explain here, just experiment with screen prototypes and find what works for you.
1. Recognize Scenarios for Building Frameworks for Requirements
Think about what users want from your application. Choose and create the scenarios that people use most often. Don’t aim for perfection, prototyping is now a more important thing to do. Try working with your customers. If this works, continue to work together in this way: this is very effective. However, more likely, you will experience difficulties so do not force it further – involving the customer that counts the most, with a screen prototype that will be submitted later.
2. Screen Prototype Sketches for Important Scenarios
Determine which scenario is most important and sketch a screen for it. Imagine this is a paper sketch and focus on speed, not on design or perfection. Populate the screen with data that will provoke a reaction. Remember what Wikipedia says on prototyping software: “[Prototyping] is not a tool to prove that we are right. This is a tool to show us where we are wrong.”
Repeat this for the next most important scenario and the next one. Copy screens from existing templates or finished scenarios wherever you can. Choose two or three scenarios that you want to discuss with customers. Don’t decide too much or you get bad feedback.
Before the workshop, see for yourself the scenario, it is your prototype. Put signs and comments where you have questions or want to emphasize something. If you want to make changes interactively and experiment with customers, provide a prototype with the “slideshow” option on your notebook (remember to save a file with a different name first). If not, just export the scenario and discuss it in your web browser or via print.
Of course, the same process applies to web pages and web application prototypes. Free the use of predetermined puppet images really speeds things up here.
3. Discuss the Requirements Implied by the Screen Prototype
In a workshop with customers, present your ideas for each screen: what certain elements mean and why they are there, what happens when users click a button, etc. Determine for each piece of data where it came from. For example if the table has a “Date” column, that date is: creation date, last update date or something completely different. These are real software requirements, they nail. Pay special attention to data that must be calculated or derived from other systems.
Be prepared to listen, and have the customer talk. Your goal is to get feedback, quite a bit to stay on topic and always return to the prototype screen.
4. Improve Screen Prototype with New Requirements
When you get feedback, correct your prototype and screen requirements accordingly, and always send to customers to confirm. If you contact the customer, his mind can still process the screen prototype and can produce some surprises.
5. Determine Requirements for Completing the GUI Prototype
When the scenario is over, invest another five minutes and “empty your head”, open the screen prototype and document the screen one by one. Focus on getting everything on paper when it comes to mind. Don’t analyze or compile anything, let the association flow and take notes quickly. Then apply some minimal structure, but don’t do anything that doesn’t improve information. With these two stages, you will be able to do this very quickly. One specific way is to export a scenario, print it (web pages will open automatically) and write notes on paper copies. Then copy the screenshot to Microsoft Word and arrange these notes as you type.
When you are done, you will have most of the software requirements and user interface specifications. For smaller applications that may even be needed.
This article does not cover everything about GUI prototypes, and I must avoid many important aspects of the discipline of software requirements. But it is effective and I will find this particular approach very useful: I certainly enjoy my work better this way.
In short, experiment, find the right one for you and have fun!