Russell, a business analyst with a major logistics services company, has great things to say about using CaseComplete to elicit requirements and generate project documentation:

... Try CaseComplete by Serlio. This tool is very intuitive, inexpensive, and flexible. It outputs your requirements in Word format, but handles all the format olympics required as requirements evolve. You can use it to maintain your business models, capture rationale for requirements, use it for the basis of testing and training. Even if you migrate to enterprise tools later, you can use this for the elicitation and documentation process, then upload the requirements.

We've used this on projects of all sizes very successfully. In some projects the developers have taken our model to build upon developing their SRS documents in Case Complete. This saves them a great deal of time and creates a common format between us.

You can download a 30 day trial.

I highly recommend this tool.

Thanks, Russell!

Are you using CaseComplete in an interesting or unique way? Let us know.

So why should you write use cases anyhow? Why are they any better than other ways of specifying requirements?

There are many reasons, but two are key: First, use cases guide us toward the more important requirements and second, use cases are more easily understood.

Traditional ways of gathering requirements involve answering the question of what:

What does this system need to do?

While this seems like a reasonable question,  the answer is a typically a long list of shalls lacking much context. For example:

• The system shall route emergency vehicles with high priority.
• The system shall have the capability to perform remote data protection.
• The system shall log all security events.

Lists like these are accurate, but deceptively problematic. Once the list has more than a dozen-or-so items, it becomes difficult to think about how the items relate. On its own, the list gives us little clue as to when the requirements apply. This makes it harder to figure out how these requirements should be designed and tested. Since the list doesn't indicate who each requirement is written for, it's not obvious if we missed any.

Use cases, on the other hand, involve answering the questions of who, why, and how:

• Who needs to use this system?
• Why do they need to use it?
• How will they use it?

The use case-approach is unique in that it is driven by who will use the system. By starting with who will use the system (the actors) and why they will use it (their goals) we're led to towards requirements that are important to the the people who will actually use the system. We can look at the list of goals we've identified for an actor and readily see if we missed any.

Unlike requirements, use cases are not lists. They are stories. A single use case tells the story of how an actor will use the system to achieve one of their goals. And a collection of short stories are easier to understand than a long list of shalls.

Well I haven’t blogged as much as I intended to this year, but here’s another quick tip as we close out the year.  If you have an extension attached to a step in your use case and you decide that you want it attached to a different step, it’s pretty simple to move it.  First select the extension.  It doesn’t matter if you select the extension’s substeps because those will always stay with the parent extension since they can’t exist on their own.  It is important to select the entire extension, not just the text in the extension (see below for more detail). Right click on the extension and select cut.  The extension and the substeps will be removed.  Now right click on the step you would like to attach the extension to and select "paste extension(s) to step".  The extensions and substeps will now be attached to that step.  Likewise, you can copy or move an extension to a step in a different use case: select copy or cut on the selected extension, open the desired use case, and select paste on the desired step.

To select the entire extension for cut/copy/paste manipulation, click to the left of its number, or use standard click/drag, but make sure you move below the extension text: the entire line will be highlighted including the number.  If you click/drag so only the text is highlighted, then any cut/copy/paste operations only affect the text in the editor, not the extension and substeps.

You can see more copy/paste tips in the dynamic help topic for the main success scenario or extensions.

Here's a quick tip that is probably no big surprise but you may not have thought about.  If you have a list of items in some other application such as Word, Excel or just plain text, and each item is on its own line, you can copy the list and paste into any Case Complete bulleted list or grid.  When you paste, each item will be pasted as its own separate bullet or grid entry.  For example, try copying these three lines:

One
Two
Three

and paste them into the Actor goals, or the Requirements list (when in description view).  3 new goals or requirements will be created.  In this way, you can quickly create new use cases, actors, requirements, goals, open issues, notes, etc. when the text exists elsewhere.

Somewhat related: new in version 2.5, you can now select multiple notes, goals and open issues in order to copy and paste more than one at a time.  Of course, you can do this with steps in the flow of events too, but you've been able to do that since version 2.0.  However, the UI has been improved making it much easier in 2.5 (you no longer have to drag starting at the left of the numbered step).

It's been quite a while since I last posted.  Hopefully in the upcoming weeks I'll start posting Case Complete tips, especially now that version 2.5 has been released.  In the meantime, here's a fun one to get the ball rolling.  Those of you who know me probably won't be suprised to learn that I still have my disk from my Intro to Programming course in college.  I won't say how long it's been, but you'll get an idea from the pictures below.  Well I found the disk while cleaning out a file cabinet and I thought, what a great picture.  The disk is from a Terak which we programmed using UCSD Pascal.

We've come a long way:

Won't fit!

OK, let the packrat jokes and the age jokes start rolling in (but keep in mind I don't have any punch cards!)

Did you know you can change properties for more than one item at a time?  For example, let’s say you would like to set complexity to medium for a large number of use cases.  First select the use cases that you want to change in the main list (either by shift-click, control-click, or mouse drag to the right of the name).  Then using the property window in the lower right corner, set the value of the complexity property to medium - all selected use cases will have their complexity set to medium.  This is true for any property that shows in the property window including release, preconditions, assigned to, etc. (on some fields, you will need to type in the value directly as opposed to selecting it from the dropdown list).

Something to note when you do a multi-select: the property window will only show the value of a property if all selected items share the same value, otherwise, it will be blank.  For example, if you select a use case with medium complexity and one with high complexity, the complexity property will be empty since they don’t share the same value.  But that doesn’t prevent you from setting the value, and once you do, it will show since the two use cases now have the same value.

Some of the forms and dialogs that Case Complete brings up are pretty tightly packed with information, for example the Use Case details form.  As a result, you may find that some of the fields require scrolling to see the entire contents.  There are a couple things to know which you may help you out in this regard.

First, almost all dialogs in Case Complete are resizable by grabbing the lower right corner of the window with your mouse, or by maximizing the window using the maximize button in the upper right corner.  As the window grows, the fields on the form will also grow to use up the available space.  The size and location of your window will be remembered for the next time you start Case Complete.

Second, check to see whether you are running in high DPI (large size) mode.  To check this, go to the advanced display properties page (right mouse on your desktop, select properties, select settings tab, click advanced button: DPI setting is on the general tab of the resulting dialog).  Normal resolution is 96 DPI, but you may be running with 120 DPI or higher, which makes everything appear larger on your screen.  Many laptops come configured at 120 DPI because their native screen resolution is so high that it makes it very difficult to read the tiny fonts that result with normal DPI.  But if you mostly run with your laptop docked with a monitor, or if your eyes are good, then consider switching to 96 DPI.  Not only will you increase your screen real-estate, but you’ll find many applications and websites will behave better at 96 DPI since many are not tested in 120 DPI mode.

Finally, Case Complete 2.0 made improvements in this area by adding another tab to the use case dialog and by changing preconditions and success guarantee to multi-line fields.  So if you haven’t upgraded yet, you might want to check it out.

I received an inquiry from a potential customer the other day asking whether Case Complete (and use cases in general) are useful for established products.  As a VAR, they make minor changes to existing products, such as adding buttons or menu items but they never start projects from the ground up.  My response is below, but what do you think?  Are use cases only useful for new projects, or can they be useful for maintenance projects and other tasks too?  Feel free to leave your comments here or in the forums.

True, Case Complete is ideally suited for new projects, but it definitely can be useful in many other situations.  Here are some ways that I think it can help:

• New and modified use cases: As you add features and capabilities to any product, there will likely be new use cases that should be documented, as well as modifications to existing use cases.  Taking the time to document a seemingly insignificant feature such as adding a button often leads to interesting “what if” and “what about xyz” questions, especially when the use case is shared among stakeholders who have different perspectives (e.g. developers, testers, domain experts, customers).  Remember that Use Cases document the extensions (alternative flows) not just the main flow of events.
• Document an existing system: Perhaps the existing documentation is out of date or non-existent.  Once documented, the use cases can be used for many things such as test plans, training guides for new team members, replacing legacy systems (how did the old system work?), or serve as the basis for end user documentation.
• Document your business processes: Use cases are a great way to document how your business works.  For example, what are the steps that should happen when you get a new client lead? What roles (actors) are important in your organization?  What are their responsibilities?  What processes/activities (use cases) do they carry out?  What processes do they only play a minor role in
• Project planning: We use Case Complete to track feature requests and project tasks for Case Complete itself.  True you can do this in Word, Project, or a defect tracking system, but some of the features of Case Complete are really well suited for this. For example: easily indicate applicable release, status, priority, and complexity of each feature. Also easily add notes, open issues, hyperlinks between use cases, related documents, screenshots, and URL’s.  You can then order by release date, priority or any other column, and produce any number of reports that show as much or as little as you want.  For example, maybe you only want a list of open issues to use as a meeting agenda.  I’m biased, but I think all of this is much easier with Case Complete than with other project tools.  If you still like to use Microsoft Project, you can export Case Complete data into Project.

Some of you may have noticed that we released a minor update to 2.0 last week, cleverly named "build 2133".  There were a half dozen or so small fixes that went into this build, most of which people will never run into, so there isn’t any need to rush out and install this update (see the release notes for a list of what was fixed).

One item that may be worth noting is a couple of fixes for related documents that are specified using a relative path instead of an absolute path.  What’s the difference?  An absolute path starts out with a fixed location, e.g. C:\temp\MyFile.doc or \\MyCompanyServer\SharedFolder\MyFile.doc.  A relative path, on the other hand, specifies a location relative to your current location, in this case the folder that your use case model is located in.  For example, it could be specified using just the name of the file, e.g. "MyFile.doc", as long as that file is in the same folder as the use case model.  Or it could specify a folder located in the same spot as the use case model, e.g. RelatedDocs\MyFile.doc.  Note that neither one starts with a leading slash, which is how we know that it’s relative.

This is relevant to Case Complete because when you specify a related document, you can specify either kind of path.  Recall that a related document is any document external to Case Complete, such as a Word or Visio document, which you can associate with any use case, actor or package.  The kind of path you use is especially important when you are working on a team, since you want others to be able to open the document that you specify.  If you have a common shared repository of documents, (as in the \\MyCompanyServer example above), then by all means, use an absolute path.  Otherwise, you may want to consider putting them in the same folder as the use case model, or in a sub-folder.  In this case, you should also put these documents under version control just as you would for the use case model files.  When team members load the project files from the version control system on to their computer, they can locate the project wherever they want, e.g. one person may have it on the C: drive and another may have it on the D: drive.  But since the paths of the related documents are relative, it doesn’t matter where the project files are located.

As one of our customers pointed out, using relative paths also has benefits when generating Word reports.  The related documents section in the generated report uses hyperlinks to the files so that readers can easily open the related document.  Using relative paths allows you to package up the Word reports and all the related documents (into a zip file for example) and distribute to other stakeholders.  The stakeholders can unzip the files to any location on their hard drive and view the reports at their leisure and have ctrl-click access to the related documents regardless of whether they are hooked up to the network or not.  One thing to note is that you must first save the Word document before hyperlinks for relative paths will work.  Not surprisingly, you must save the report to the location implied by the relative paths.

This is getting long, so just a quick mention of how to specify a relative path in Case Complete.  If you browse to the file when adding the related document, you can edit the path to make it relative after it is added to the list (press F2 to edit).  The 2.0.2133 release adds a new context menu item to allow you to type it in directly.  You can use relative paths with the initial 2.0 release, however it will not be able to handle them if you are using automatic picture insertion in your Word reports.  Hope this information can be of some use to you.

Here’s a little bit about myself and my role(s) at Serlio Software. I am one of the 4 co-founders of and am currently the architect and lead developer of CaseComplete. In the summer of 2004, I had the privilege to be one of the authors for Microsoft’s MSF-Agile process that will soon be released with Team System. Prior to forming Serlio, I and the other co-founders worked at Rational Software (now a division of IBM) where we were on the development teams for Rose and XDE, hence our interest in development tools and best practices.

Working for a small company like Serlio, I wear many hats. For example, I also do technical support, so you’ll see my name quite a bit in replies to emails sent to support and to questions posted on the forums. Having developers involved with tech-support duties is a good thing IMO. When developers lose site of the day-to-day issues that users are having, the product can become bloated with features that no one needs or uses, while nagging little issues go ignored. So, here’s where you come in – what are the nagging little issues that you have with Case Complete?  What are the things that you wish Case Complete would do, or do differently? Help yourselves by helping us make Case Complete the best it can be by posting your thoughts in the forums. Thanks!