Top ten tips for software prototyping

Today's users have become more sophisticated. They don't want software that just works - they want software that is easy to use. A software prototype is useful for understanding the user interface and making it easier to use. Unfortunately, many managers, analysts, and developers don't understand how to efficiently create software prototypes. Here are the top ten tips to help you rapidly prototype software:

1. Start from a high-level requirements specification. This can be relatively short document with a few key use cases.
   
2. Start with screen flow. Don't worry about individual screens initially. Instead, try to figure out the number of screens and how the screens relate to each other.
   
3. Start with the most imporant screens. Identify the most important screens based on the most common use cases and prototype those first. Initially, your software prototype should ignore simple or infrequently used screens.
4. Start with low fidelity screens and refine. Your software prototype should be crude initially. Just get the right controls and text on the screen. You can worry about making the screens beautiful later.
   
5. Get feedback early and often. As soon as your software prototype has one or two screens, start showing them to users and other interested parties. Every time you add or revise screens, get feedback as soon as possible.
   
6. Involve real users. Make sure that you involve people that will actually use the system. If there is more than one type of user, make certain that you have a reprentative of each type. For instance, if managers use one part of the software and low-level employees use another part, then you need to review the relevant parts of the system with both managers and low-level employees.
   
7. Use a "fast" software prototyping tool. The software prototyping tool should be easy and fast to change. Otherwise, you will be reluctant to make necessary changes. We believe that our Lucid Spec product is the perfect tool :)
   
8. Pay attention to validation and business rules. Once you have prototyped screens and defined flow, you need to capture the validation and business rules of the system from users. You will usually identify missing features in your software prototype when you do this.
   
9. Finish with a functional specification. The functional specification should contain screen shots with additional validation and business rules. Review the functional specification one last time with users.
   
10. Use common sense. Always ask yourself "what is the least understand or riskest part of the software?" This will help you decide where to spend time on your software prototype.
    

Types of Software Specifications

Developers often confuse the various types of software specifications. There are many types of software specifications, but here I'm focusing on describing the most common types: requirements, functional, and design.

• Requirements Specification: Requirements Specifications are used to define the problem(s) that you need to solve. In other words, they define the "what". Requirements Specifications may contain both qualitative requirements (the software should be easy to use) and quantitive requirements (response time must be less than 2 seconds). They often contain high-level Use Cases.
  
• Functional Specification: Functional Specifications define how you are going to resolve the Requirements Specifications. In other words, they define the "how". If a user interface is involved, they usually contain screenshots and descriptions of how the screens work. We (Elegance Technologies) created Lucid Spec to help write Functional Specifications.
  
• Design Specification: Design Specifications define how you are going to implement the Functional Specifications. In other words, they also define the "how", but the "how" is related to software implementation issues. This software specification usually contains things like UML class diagrams, interaction diagrams, database design diagrams, etc.

Many software organizations use Agile software development processes today. As a result, some developers believe that they don't need to write software specifications anymore. This is not true! Developers may not write all the software specifications upfront, but they should write the portion of the software specifications relevant to their current software development iteration.