There is a classic cartoon about software development that shows a room full of programmers at their keyboards and one of them (presumably the leader) leaving the room and saying "You all start writing the software while I ask the users what they want." This behavior results in a system that does what the developers think the users need, not what the users need.

Your users (the buyers and sellers in Joe’s case) need to be part of the project team. But how can they contribute when they do not write software? In a properly managed project, you should spend reasonable time performing analysis of the problem before designing a solution. The analysis phase of a project uses a diagramming notation called Use Cases, part of the Unified Modeling Language (UML), an industry standard for specifying user requirements.

A Use Case is a simple graphical representation of how the user will use the application. It does not take a programmer or software developer to specify a Use Case; in fact, it has been our experience that end users (managers, salespeople, marketers, field workers, etc.) are often better at developing Use Cases. This is because they think in terms of describing the problem, not solving the problem (like many software developers do). For every important operation identified by your users, a Use Case diagram is created. Other people (vendors, customers) will be represented in the use cases, as will the systems they need to work with (the Inventory Management System). It is important to note that Use Cases include all the steps in an operation. Use Cases are not simply flow charts, and they do not only show computer-based operations (the "offer made" in the illustrated Use Case in figure 1 is a manual operation).

At this initial stage you may not think you are doing anything specific to a wireless application – this is a basic step that should always be included in projects, but is often skipped. You may think that since you are just porting an existing application or web site you do not have to determine how the users will be using the system – the wireless users will use it the same way your existing users do, right? Wrong. There are unique concepts to consider when developing a mobile application, such as:

• The user will ALWAYS have their device with them. When you think of the Use Case, think of what you could do if you had immediate access to ANY piece of information. It is important not to be limited to existing ways or processes.
• What is the end result of information the user must have? For example, instead of thinking about the user first looking up some information from System A and then something else from System B, determine what is the final information you need and let the back end system do the lookups or processing.
• Wireless devices can have information "pushed" to them (think of a pager). So you do not have to limit yourself to the user being at a terminal or calling up a particular report – you can send them the information they need.
• Is there particular information that the user will need at a certain location or at a particular time? If so, you should build a Use Case for this need.

You will also see common concepts emerge (like both the Buyers and Salespeople need to look up current on hand information). From the Use Cases the software development team will be able to approximate the effort and estimate the project’s complexity, duration and cost. Use Cases are extremely useful for reviewing and prioritizing a project – you may choose the five most important Use Cases to the customer to implement in the first phase of a project, and save other less important items for another phase.

Let’s check in on Joe

One of the Use Cases defined by Joe is for when the Buyer is meeting with a Vendor and the Vendor makes a special offer to the Buyer ("If you agree to buy 10,000 of these now we can offer you an extra 15% discount."). The Buyer would need immediate access to the number currently in inventory (Current On Hand) and the past three weeks sales to make an informed decision.