It depends on a number of factors. I am fortunate enough that my project is actually being re-engineered from an existing application. We are able to walk through the current app and model the workflow from there. We then ask questions of the Stakeholders like "Is there anything else you'd like to do?" "Is there anything you'd like to do differently?" We then model the new workflow and create Use Cases from that diagram. Those use cases are what we are using as the final requirements specification. For a new project, ask the stakeholder what they'd like to do. Ask them how they do it currently (in almost all cases, there is a current way of doing things even if it isn't through a computer). Try to get an understanding of two things: what information is going into the system (input), and what information is required from the system (output). Actually make that three, you also want to understand what steps are taking to achieve the desired output from the input. Let's take an example. I am a stakeholder in the accounting system for XYZ corporation. It has already been decided not to go with an existing application (like quickbooks or peachtree). Knowing that there is an existing application that performs a similar function to what you will be building, you download a demo of that application (or maybe several similar applications if they exist). Walk through the process of using that application with your stakeholder asking them along the way what they like about the process, what they dislike about it, how would they do it differently, and what would they keep the same. This process will help you determine what is needed for the new system. Sometimes, you are not fortunate enough to have an existing application so you have to gather information in a different way. No matter how you go about gathering information the questions are always the same, what do you want to do, how do you want to do it. After you get the what, the how might have to come through a dialogue between you and the stakeholder. Generate workflow diagrams (which the user may or may not understand) and walk through them with the user. From the results of that meeting, do a mockup UI. Show the user your system gathering the input and show some sample output (it does not need to be accurate). After a few iterations of this dialogue, you should have a good understanding of what the user wants to do and how they'd like to do it. Use your final workflow diagram to create your Use Cases. Even simpler than that is if your stakeholder has paperwork that they want to convert to an application. The paperwork is your input. Your application will initially store the input and allow it to be retrieved. From there, you'll learn what the Stakeholder wants to do with the stored data. Basically, requirements are rarely fully gathered up front for anything but the most trivial projects. You want to gather as much as you can, but an iterative process of gathering requirements and building from those requirements will ensure that the project runs as smoothly as possible and you will have a documented trail of the decisions made should something need to be changed down the line. Hope I was helpful. Michael [ January 30, 2004: Message edited by: Michael D. Brown ]
Joined: Jun 30, 2003
Thanks Michael, that was very useful. Some more questions, what do you use to create the workflow diagrams? Do you have one big workflow diagram or a few of that? I am thinking one big one might be better for a very clear overall picture. Too many workflow diagrams might lead to an application which consists of many incoherent sub-systems. From the workflow diagram, how do you decide to divide it up into use cases? I would think something like "Management of Membership records" as one use case, consisting of sub-flows like Create, Delete, Update and Search Member. Now, do i also include sub-flows like these in the workflow diagram?
Michael D. Brown
Joined: Nov 22, 2003
I use Visio to do my workflow diagrams (all my UML is done using Poseidon). You can have a high level workflow diagram, but honestly it works best if you break it down into various actions. Your workflow diagrams and use cases should have a one to one ratio. Basically, break your project down into tasks, what does the user want to do. Here is an example. For a web forum application, one task might be user signup. How would a user signup to use the web forum? 1. They input their information (name, email, username, password, etc) 2. The system verifies that the information is valid (does the username exist already, is the password secure enough). 3. The system sends an email to the address entered during signup to verify that the email address does indeed belong to the person who signed up. 4. The user follows the verification process to show that he does own that email address. 5. Once verification is complete, the user's login is valid. There are a few points where the flow can deviate. For instance, what if the user put the wrong email address in? Will he have to start the creation process all over or will the system allow him to change that information and resend the verification email? This workflow will turn into your use case and that particular instance I mentioned can be an alternate flow in the use case. Now as you build your various workflow diagrams you can plug them into a high level diagram, but working from the top down will be a difficult thing to do. Basically your goal is to break the system down into various tasks. What does a user want to do? Give an overview those tasks using workflow diagrams and spell them out with your use cases. Here is the workflow diagram for this simple process. Hope this helps you more.
[ February 02, 2004: Message edited by: Michael D. Brown ]
The most important thing that you can do is to work closely with your stakeholders. Better yet, make sure that they're actively involved. See http://www.agilemodeling.com/essays/activeStakeholderParticipation.htm for some thoughts. Related strategies: 1. Use techniques -- essential use cases, essential UI prototypes, CRC cards, ... -- which are easy for users to understand. Easy techniques are inclusive, difficult techniques are not. See http://www.agilemodeling.com/artifacts/ for a list of potential techniques. 2. Use simple tools -- whiteboards,index cards, post it notes, ... -- that your users can work with. Simple tools are also inclusive. 3. Be flexible. - Scott