This article is geared toward systems analysts who need to efficiently verify requirements proposed by business or end users. There are several techniques for doing so, and one of the most appropriate is prototyping. It is a known fact that a graphical representation is better understandable and in less time. Business and end users usually have no time to review software requirement specifications and may not comprehend technical language or the format in which the specification is written. They are usually skimming Use Cases assuming that the analyst should know everything and they dont need to ask questions. Prototyping is fun to end users to play with and accordingly a good way to confirm that requirements are gathered correctly or to find out what exactly should be changed. There are several ways to create a prototype. Using numerous screenshots or mockups is one example. Simple software written in one of the programming languages is another approach. Known as horizontal and vertical prototyping accordingly, each way has pros and cons. Screenshots are easy to create, for example using HTML editor, Visio, PowerPoint or even MS Paint. At the same time, users may not experience the sequence in which an application performs some function. Really then, a working application seems like an ideal solution due to the vivid reflection of the users vision. Unfortunately, this could lead to a 'trap' such as, "This is exactly what we need, just add an ability to save my work in a file, and well be done!" The result of this is an undoubtedly predictable future refactoring because the prototype does not deal with non-functional requirements and therefore the prototypes architecture does not support them. In this article we will apply the term "application" to a thick, reach control Windows or Mac application. Web-applications will be indicated if applicable. Development tools like Borland Delphi or Microsoft VC++ are out of scope. (VB or VB.NET seems to be a better solution but requires a run-time library to be installed on the users PC which is not always possible.) What to do? The most effective way to solve a problem is to find out two contradictions, confront them as a pair, choose one with the highest priority and then decide how to overcome the other opposition. In our case we have the pair: the prototype should be interactive and give to end users a clue as to what kind of application will be finally delivered, but the prototype should not be interactive enough that a wish to add functions appears. As we can see our goal is to keep a first and solve a second statement. Thus, we have to create static applications windows or dialogs and make them interactive. It sounds impossible at first, but modern office applications have all the capabilities for what we need. Below we will go trough a list of several solutions, each of which may be appropriate in different cases. HTA executable Web-page HTA, also known as HTML Application, is an easy way to turn any Web-page into an executable application with the ability to interact with files, databases and even sockets. Any HTML editor like Macromedia Dreamwaver deals with layouts and controls that help to create the application interface quickly. Then, the extension of the stored html file has to be renamed to .hta, and this is the only difference between the Web-page for the Internet browser and the executable Web-page. With VBScript or JavaScript, with access to ActiveX controls and COM objects HTA performs as a fully fledged program. To simulate a multi-dialog, several HTA files may be created and cross-linked. That seems good so far, but HTA as a Web-application has a limitation in the controls that can be used. For example, menu bars as well as tool bars are not allowable in Web-application, though it is possible to find a script for them. Also, security issues may block some functions. Finally, the analyst should be able to develop using a scripting language. MS Visio not just a drawing tool Everybody knows and almost everybody uses this drawing tool. Fortunately, MS Visio is more advanced than a simple vector drawing utility maybe too advanced. With Windows XP User interface template selected from a drawing type you will get numerous stencils to present almost everything you need. If this is not enough there are plenty of other stencils to choose from. This is extremely helpful for the analyst when an application with non-standard controls like SCADA systems has to be implemented. Also, notice that you can add more pages to your drawing by using the Insert New Page menu item. Each Visio page named properly can be used for a single window or a dialog, but the number of dialogs in a real application usually exceeds the number of pages visible at the bottom of the Visio window at a time. Scrolling and jumping between pages can confuse the end user to whom you are trying to explain how you understand their needs. As a result, the analyst may come to the assumption that the requirements are wrong whereas the user is just trying to look like a literate PC user. It would be better if the analyst would be able to click on a control as if the user was working with a real application and a system responds accordingly. This behavior is configured by Behavior. Each control (stencil actually) on your prototype has Go to page or Run macro settings in menu item Format Behavior Double Click. The name of pages that are the same as real dialogs allows you to easily assign which drawing should be opened when you or the user double clicks to a button, for example. Thus, you can jump between pages simulating a real application whereas everyone understands that it is not. Worksheet compiler If about 10-20 years ago someone would mention that a text editor could be a base for a full functional application, you would never believe that. Nowadays it is nothing unusual that a front end may be created using Word or Excel. While it would be a toy application (though it is a simple way to learn common programming techniques), Excel could help to imitate a final software product. Though Visio also allows inserting OLE objects, Excel does it in a more robust way. First, dialog boxes may be created in VB editor (VBE) with some limitations, like an application menu. Second, many UserForm controls can be embedded directly into a worksheet. These controls are accessible from the Control Toolbox toolbar. Just notice that Other controls button hides even more: TreeView, ToolBars, StatusBars, etc. Using a mixed approach by creating an application skeleton on a worksheet(s) and additional dialogs in VBE seems to be better. In some cases, you can save yourself the time of designing custom dialog boxes by utilizing one of several prebuilt dialogs, such as: a dialog for selecting a file for open/save, or a dialog for specifying directory. Menu items are not a part of UserForm controls, so be creative! What about the compiler? Generally speaking, Excels worksheet cannot be compiled but it is possible to create add-ins. Excel add-ins are always hidden but the user can access dialog boxes from different worksheets. Thus, you can minimize your work with common dialogs. This article is not intended to compare all prototyping ways described above, or to find out the advantages of each of them. The goal is to show how a prototype could be created using different means. Use discretion in selecting the best solution that is suitable for you situation. Needless to say, that same techniques are applicable to Web-applications. |
