Analysis is probably the most crtical phase of the development process. It is in the analysis phase that the question, “What should the application do?” is answered.  If we do not understand what the clients (or potential customers) want, then is is nearly impossible to develop software that will satisfy them. Often the clients themselves don’t know what they want. Sometimes what the clients say they want doesn’t communicate what they really want.

You wanted a what?!?!

My Software Development Philosophy

Don’t Re-Invent the Wheel

   The Use-Case document helps address this issue. The Use-Case document captures and represents information about who will be interacting with the software system being developed and what the system will do.  The entities that interact with the system are identified as “Actors”. Actors include both people and external systems. Actors are labeled according to the roles that they play when interacting with the system as opposed to being labeled by their actual identities (i.e. “Application Designer” instead of “Adam”). Associations are indicated between the actors and the actions in which they are involved. These actions are depicted as use-cases. Use-Cases describe the interaction between the users and the systems participating in single action.  Use-Cases are often derived by extracting common elements from mutliple scenarios (a.k.a. user stories) which depict specific instances of the same general action.   Use-Case documents help both developers and clients understand who the system will be used by and what the system will do.

   Prototyping is another technique which helps the client and developer understand what the software needs to do.  Prototypes can take the form of working programs or simple documents.  Prototypes often illustrate the input consumed by the system and the output produced by the system.  They often contain make believe data for illustration purposes only. Prototypes are most valuable when they are able to be produced quickly.  In addition to helping to determine what the system needs to do they also help to establish a “look and feel’ for the system.

  Putting a client on the team is another technique that will help to develop software that exceeds expectations.  Having a client on the team means having a representative from the client on-hand during a large portion of the development process.  This will make the client feel like a partner rather than just a sales target.  Developers will be able to get immediate feedback from the client when it is needed which will prevent misunderstandings that may go uncaught between client reviews. A client representative merely through observation is likely to come up with constructive ideas that the developers would not have thought of themselves because they are not domain experts.