Manoa Tech http://www.manoatech.com/pages/index.php Actually Useful Use Cases, part 1 http://www.manoatech.com/pages/index.php?entry=entry090427-144854 Actors. Common recommendations include:
  • Document the use case steps independently from the UI
  • Include both user and system actions
  • Use a template to capture the various parts of a use case: user goal, pre-conditions, steps, post conditions, alternate paths, forms submitted, and so on.
But following the above steps is often not enough to fully integrate use case documentation into your development process, as many of you know. Process problems often mean that you're putting a lot of effort into writing use cases the "right way", but are getting limited results in terms of productivity. The tips on this list will get you better results from your use case documentation, and save you time on every development iteration. That being said, here we go...

1. Identify use cases by name, not an issue tracking number

Use case descriptions should survive and be usable across multiple development iterations and even across releases. That means that multiple issues may be written against the use case over time, including initial development, defects, and enhancements. If you are writing new use case documentation for each release, you are not only duplicating a lot of work, but you are also losing that valuable traceability that should convey knowledge from one development iteration to the next.

Since your use case will be around for a long time, you want to give it a name that will stick. One way to ensure this is to write the name in CamelCase -- make it clear that this is a long-lived label, not just a document title. You also want the use case name to describe how this case is different than others; for example, instead of using the name "Advanced Image Upload", you might use the name "UploadAndTagImage", which additionally prompts the user to tag and geocode uploaded images. This level of detail is different than using use case extension and should be used when our new UploadAndTagImage case replaces the previous UploadImage case. If tagging an image were an optional path that the user may embark upon, then you would document it as a use case extension (which I will write about in a future part of this article).

The above approaches will yield you a unique, long-lived, and descriptive name for your functionality. If you use a requirements management system or a requirements wiki, your use case documents may be linked to from your issue tracking system, code repository comments, other web pages, or other documentation. Having these long-lived cross-references in your requirements in the #1 thing that you can start doing today to improve your development accuracy and productivity. The other items on this list follow from this first step.

2. Use cases should be revision controlled

Using long-lived use case artifacts means that it will actually become easier to determine the differences between any two development iterations or system releases; however, your use case documents must be revision controlled in order to gain this benefit. This can be in the same revision control system as your source code, a proprietary document management system, or in a Wiki.

Using a Wiki is an especially good choice for non-technical business analysts -- the interface and usage model is similar to many of the Web 2.0 sites out there, and you can get the benefit of revision control without the analysts performing a separate check-in and check-out. If your requirements are going to be written by the developers themselves, it may be convenient to put requirements documents in the same revision control system as your code. Just be sure to choose a revision control system that supports a web-based front-end; this will allow you to link directly to your documents and achieve the cross-referenced nirvana that every project needs.

If possible, it is nice to be able to tag your requirements documents when they are approved for a specific software iteration or release. This functionality is almost always available in a typical revision control system or proprietary system. If using a requirements wiki, you may have to look for a plugin (search for Flagged Revisions for your wiki flavor) or use page metadata.]]> Simple PHP Blog http://www.manoatech.com/pages/index.php?entry=entry090304-161425 Simple PHP Blog to host the blog on this site. The app is, in fact, simple to install -- just extract the distro into your web directory, ensure that your file permissions are correctly set, and run the online setup procedure via a web browser.

It offers a large amount of interface customization. You can customize the sidebar widgets, color scheme, and layout theme via your web browser, as well as administer users and moderation. Other layout customizations are implemented by modifying the php files that are included in the installation package, or by creating new themes written in PHP.

My next steps with this will be to develop a layout theme and color scheme to match the rest of this site.]]>