Click here to Skip to main content
Click here to Skip to main content

Create Screen Prototypes For Clear Software Requirements

, 26 May 2006 CPOL
Rate this:
Please Sign up or sign in to vote.
Misunderstandings are costly in software development. If you are not careful, you could find yourself aiming at the moving target or even end up building the application nobody needs or wants. Find out how to properly use screen prototypes to avoid this trap, while having fun in the process.

Introduction

I'm in software development for 15 years and I can tell you one thing for sure: misunderstandings are costly in software development. If you are not careful, you could find yourself aiming at the moving target or even end up building the application nobody needs or wants. I'll show you how to properly apply screen prototypes and avoid this trap, while having fun in the process.

There are many tools commonly used for software prototypes and GUI prototyping. Most of them lack in speed and ease of use of paper sketches. On the other hand, you can't maintain paper sketches, so there is no easy solution. Pick your tool, but focus on the real problem: to quickly engineer clear requirements for a software application. Start with these five steps as a basic "process", experiment and find what works for you.

1. Recognize Scenarios To Build A Wireframe for Requirements

Think what the users want from your application. Recognize scenarios that people will use most often and don't aim for perfection. Try to work together with your customer. If this works out fine, continue teamed up this way: it's very effective. More probable though, you'll have difficulties so don't push further - involve the customer where it counts the most, with screen prototypes you'll propose later.

2. Sketch Screen Prototypes For Important Scenarios

Decide which scenario is the most important and then sketch screens for it. Focus on speed, not on design or perfection. Fill screens with data that will provoke reaction. Remember what Wikipedia says on software prototyping:

"[Prototyping] is not a tool to prove that we are right. It is a tool to show us where we are wrong."

Repeat this for the next most important scenario and the next one. Use screens you have already sketched. Choose two or three scenarios you want to discuss with the customer. Don't decide on too many or you'll get poor feedback.

Before the workshop, skim through scenarios yourself, they are your “static prototype”. Mark places where you have questions or want to emphasize something, and write down notes. Discuss scenarios on screen, in your web browser or over a printed hard-copy - it doesn't really matter, just be very careful to avoid the conception that these are screens of the real computer program.

Of course, the same process applies to web pages and web application prototypes. Just remember to have a few predefined dummy pictures handy, it really speed things up if you don't have to worry about visual details at this point.

3. Discuss the Requirements Implied By Screen Prototypes

In the workshop with the customer, present your ideas for each screen: what particular elements mean and why they are there, what happens when user clicks a button, etc. Determine for each piece of data where it come from. For example if the table has a “Date” column, which date is it: the creation date, date of the last update or something entirely different. These are real software requirements, nail them. Pay special attention to data which has to be calculated or comes from other systems.

Be prepared to listen, and get the customer to do the talking. Your goal is to get feedback, just moderate a bit to stay on the topic and always get back to screen prototypes.

4. Improve Screen Prototypes with New Requirements

When you get the feedback, improve your screen prototypes and requirements accordingly, and always send them to the customer for confirmation. If you got through to the customer, her mind could still be processing those screen prototypes and could come up with quite a few surprises.

5. Specify Requirements To Complement the GUI Prototype

When a scenario is finished, invest five more minutes and "empty your head". Go through screen prototypes and document screens, one by one. Focus on getting everything on paper as it comes to mind. Don't analyse or structure anything, let the associations flow and just catch quick notes until you are finished. Only then apply some minimal structure. Make it a rule that you don't do anything that doesn't improve the information. In this two-stage manner, you will be able to do all this extremely fast. One particular way is to print your screens and write notes on the paper copy. Then copy these same screens to Microsoft Word and type the notes below relevant screens, structuring them as you go.

Conclusion

And that's it. When you are finished, you will have a large part of both software requirements and user interface specifications. For smaller applications, that might even be all you'll ever need.

This article doesn't cover everything about GUI prototyping, and I had to avoid many important aspects of software requirements discipline. But it is effective and you'll find this particular approach very rewarding: I surely enjoy my work better this way. In short, experiment, find what works for you and have fun!

History

  • 27th May, 2006: Initial post

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

ijese
Web Developer
Croatia Croatia
Igor Jese works in software development since early 1990s, with emphasis on software requirements and development methodology. He is a certified Software Requirements Expert and Project Management Professional, and also the author of several popular tools, including Mockup Screens tool for creating quick GUI prototypes and Simple Project ToDo for easy tracking of small software projects.

Comments and Discussions

 
GeneralSimple and to the point PinmemberEvoluteur26-Apr-10 13:35 
GeneralGUI development PinmemberJun Du27-May-06 9:23 
It appears that the previous article has been deleted and reposted with minor changes. I actually tried your "MockupScreen" quickly. I found it a useful tool. Here are my comments:
 
1) Prototyping screen shots is most effective for GUI projects or GUI intensive portion of a project. There are many different approaches to identifying requirements in other design areas.
 
2) In the project environment, prototyping tools help to visualize and present the GUI reqirements, particularly derived requirements. However, it won't identify the contractual requirements, which are usually defined by Customer before the design started. BTW, the derived requirements are those identified during the design phase, which are derived from and required for fulfilling the contructual requirements. The bottom line is that if you don't know the contractual requirements, you still don't know what to do with the prototyping tool.
 
3) In the product environment, there is no clear cut between contractual and derived requirements, as Customer doesn't have much to say, like with Microsoft products. Thus, prototyping tools can be even more useful. For example, they can help you:
- to nail down what you want your GUI to be.
- to communicate ideas among designers/developers.
 
4) I completely agree that you should provide wire frames (or even hand drawings)as prototypes, not actual GUI screenshots, because otherwise there is a risk that Customer may complain waht you've built does not match what they saw during the requirement analysis phase.
 
5) Static shots and dynamic navigations between the screens are equally important in story-telling a GUI product. Furthermore, navigating between screens often makes a smoother transfer from the top-level to detailed design.
 
6) I personally distinguish between GUI designers and GUI developers, which may not be as accurate as I hope. Designers are those who care more about what to do rather than how to do it. They can be system designers, graphics designers, marketing staff, program managers, and so on. In contrast, developers care more about how to do it. They are usually programmers. Thus, prototyping tools without navigation function are more appropriate for GUI designers, but not good enough for GUI developers.
 
7) Continue on 6). While prototyping tools are helpful to GUI designers and/or marketing guys, GUI developers may find that applying an agile approach (such as extreme programming) on the real development tool (such as VS.NET) may be more helpful than using a prototyping tool. Because the prototypes you created with VS.NET may become the baseline of the final software product. This is more like a development process issue rather than a tool issue.
 
And so on so forth.
 
Anyway, GUI is one of the most exciting areas of software development. Any commets are welcome.
 
- It's easier to make than to correct a mistake.

AnswerRe: GUI development Pinmemberijese27-May-06 10:16 
GeneralRe: GUI development PinmemberJun Du27-May-06 10:38 
GeneralStoryboarding [modified] PinprotectorMarc Clifton27-May-06 2:04 
GeneralRe: Storyboarding [modified] PinmemberAnna-Jayne Metcalfe27-May-06 4:15 
GeneralRe: Storyboarding [modified] Pinmemberijese27-May-06 5:35 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web03 | 2.8.141015.1 | Last Updated 27 May 2006
Article Copyright 2006 by ijese
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid