Archive for the 'Requirements Gathering' Tag

The first question you’re probably thinking of is, “so, when do we get to do wireframes?”

The world isn’t only wireframes, little grasshopper.

What we are going to talk about is use cases. I write a lot of high level use cases in responding not only to request for proposals, but also for determining user needs when constructing the wireframes. Whether I do wireframes first or use cases first really depends on my mood of the day, what kind of project it is, and how complex the project is. In other words, it depends.

Sometimes I do the wireframe first to determine what the detailed use case is, or to spot any branches or scenarios I might miss. However, wireframes are time consuming (and I do them because I don’t like doing Photoshop mockups even more), and I think in bulleted lists, which is how I usually do use cases.

What’s A Use Case?

A use case is a set of five requirements for a task or set of tasks:

• A description of interactions between the user (normally referred to as the actor)
• The system the user is interacting with
• The scope of the interaction
• Dependencies associated with the interaction
• The goal

The use case covers branches, error messages and edge conditions; the main reason for use cases is they are used as a communication tool with developers so they know exactly what’s going on with the system, and how the system should react. The use case will also list dependencies like “user must be signed in.”

When you describe a use case, use active tone i.e. Register as a user, Pay for merchandise, Read mail are typical examples of how I would describe a task the user would take, and I may describe every interaction that user would make in completing that task.

Paying for merchandise may include error messages like:

• Invalid credit card
• Address doesn’t match credit card
• Name doesn’t match credit card
• Expiration date isn’t valid

A good detailed use case will cover every interaction and what to present to the user.

Why Use Cases?

Use cases are tied to personas in that they should describe what the system has to do and how it meets the needs of the target audience. Use cases also ferret out new needs and opportunities that may expand or control the scope of the application.

Detailed use cases are also used as a communication tool with developers: if the team is close knit, information architects and developers discuss the use cases and do a walkthrough so the interactions can be discussed in context with the rest of the website or application. Sometimes, the use case discovers technology barriers that require rethinking the use case or changing the use case to meet system requirements.

As much as we would like to think it’s the case, we can’t design in a black box: something always works not the way as we thought it was going to.

Use cases don’t talk about specific technologies, but they do talk about what the interactions have to do, so technology needs are a very important component of describing the requirements and scope of a use case.

Well documented use cases translate to excellent test plans because they cover every interaction, and are also useful for writing unit tests, which is what developers use to test their code before it’s complete. Good documentation and communication leads to less misunderstandings of what needs to be built.

Use cases that are well written are very effective tools for considering every situation the user or actor may run into, and limit development time because more communication means less question about what has to be built, and what quality assurance will find upon testing the website or application.

Should You Write A High Level or Detailed Use Case?

That depends.

Sometimes.

Not Always.

If the system you developing for is a platform and has a bunch of functionality already defined, listing out the high level use cases may be sufficient. Where I work at, we do a lot of SharePoint implementations, so we use high level use cases to make sure we’ve covered all the needed content in a website. SharePoint (as with a lot of software platforms) has a lot of functionality out of the box, so describing a use case at a high level is usually enough to get the developer started in development and figure what tool or component to use to satisfy the use case.

Detailed use cases are very useful if there’s a lot of custom development that needs to be done, because the last thing you want to leave to software developers is for them to determine the user experience. Detailed use cases also expose flaws the design patterns or technology that may require workarounds or alternate solutions.

What Tools Should I Use To Create Use Cases?

I know there’s a lot of people out there that spend a ton of time creating use cases using Unified Modeling Language — all the power to them — but the tool I use most often is Microsoft Word.

I hate stick figures. I dislike stick figures. I hate stick figures.

I’ve thought about using or creating another tool using PHP and web-based applications, because use cases are fairly repeatable, but I’m just lazy. I write my use cases out in bulleted or detailed form, depending on my needs, and one of the best books I’ve purchased for serious analysts is Writing Effective Use Cases (Agile Software Development Series). Seriously, Allstair Cockburn is a god in my eyes, because he hasn’t sold himself to the devil like Jacob Nielsen or Jesse James Garrett, and he’s provided a useful publication to boot.

Look at your organization and decide what kind of tool is best for communicating to your developers: some of them work best with wireframes, others with written documentation, even more with a white board and sticky notes. A few that I’ve worked at loved HTML click throughs or Azure mockups, because the use cases could be walked through from a user perspective. Most imporantly, if it’s agile and prevents rework, you’re doing the right thing.

Other Resources

• A List Apart’s article on use cases
• Rizwan has an effective, if organized, list of tips on writing use cases.
• This is a great post on Use Cases for User Assistance Writers.

One of the struggles with working as a consultant is clients that want everything in the world (and are willing to pay for it), yet don’t focus on the features or items of their implementation that they really need, and sometimes that is written directly in the statement of work. This happens in the corporate world, time after time. Clients are just like everyone else where the features that sometimes come from the CEO but have no return on investment associated with it.

Here’s how I work with clients to help define what they need instead of they want, and I’ve included an Use Case Prioritization Excel Template to start with. It’s simple, and meant to be that way, because long documents aren’t read.

Make a list of use cases that are relevant to the implementation

This is where I always start — what are all the percieved use cases the client needs for system success? When you develop requirements, there will always be additional use cases that will come out of disccusions,  the client’s going to have a pretty good idea of what they need to start with, because they called you, right?

Keep the assembly of this list simple, like an Excel document, and that document would have such fields as the use case, who the use case sponsor is, the opportunity, the cost (do a rough swag on this, and more often than not you are going to be 50 percent off because of unstated requirements), the priority (high, medium, low, or an agreed on numbering system as in the example document), and other notes. The sponsor’s important because like it or not, a CEO’s much more important to the project than a QA lackey.

Rank use cases based on importance

Some of the use cases will be absolutely necessary (i.e. if you are working on SharePoint, editing of pages and user permissions would be an absolute requirement). Some requirements, however, may not be as important, such as localization.

Even if that is a requirement, you can have two stages of implementation, planning for localization as a stub and setting up URLs for this versus a full implementation. Because of this, I would list this as two separate use cases, judging this as the simple versus complex implementation.

The importance should be judged on the opportunity, cost, and whether or not it’s an important feature for launch. One of the things to remember when developing use cases is that some can be accomplished through manual processes, like having the database administrator change data through raw SQL if the task doesn’t happen very often. No feature that has only an impact of making or saving $500 a year should be implemented, period.

Develop the system based on that list

The list is your bible for development, and if you stray from it, the development process goes awry. This list can also change; if you get a few iterations down the path, you can reorder items based on changing priorities of the client (or your project sponsor). Remember, this idea is to keep the features light and iterative so changing requirements don’t mean reordering the whole list or building a completely new system.

Keep track of progress with the list

Sometimes with software development, progress is the invisible path that no one sees. If you use the use case prioritzation list of keep track of where you are at (hopefully with honest developers giving you feedback), both the development team and the client will get a true nature of where they are at. In some situations, several use cases might be co-dependent on the same development components, and that should be noted.

I don’t know about you, but every time I’ve done the “hey, lets do the requirements gathering in a waterfall process,” by the time we get to the bottom of the waterfall, we’re nowhere close to where we started. That’s one of the reasons why I’m a huge fan of agile requirements gathering and software development.

Horse Pig Cow has a great post on the waterfall vs. the washing machine. It’s done in a presentation (I’m going to include it below).

| View | Upload your own

How to be A Good Product Manager (which is a phenomenal blog, by the way, and wish I had written most of the content) has this excellent post about requirements, and it applies requirements gathering. One of the traps that we fall into as consultants is that with certain clients, we go into the mode of just gathering requirements and not advising what the requirements should be (read: let’s design the Pontiac Aztec, quite possibly the ugliest car on the road).

Just gathering requirements is a bad idea. Advising on requirements is a better idea, because that’s how you add value.

Sure it’s like herding cats, but the reason many consultants are valuable is there’s some wonderful insight that they may have, however small it may seem, that adds phenominal value for the client. That’s why they are paying consultants what they do.

How so? We start the conversation about what the direction should be, even if it’s the wrong direction at the start. One of the essential points that the article makes is that in many cases, the customer has no idea what they want (a car), and what they may get may be anything from a Hummer or a Prius.

Our job is to ask questions that will lead to developing a better product, and not necessarily questions that lead to what we think the product should be. Many scenarios, it’s impossible to satisfy all parties, because they may ask for a car that is great for the environment (the Prius) and can run over people (the Hummer), because the requirements are conflicting. Our job is to find the best solution, not the solution that meets the needs of everyone.

Or what do they say — trying to make everyone happy will make no one happy?

For the day job, needless to say I do a fair amount of wireframing and writing of use cases, and there’s a lot of “what does this link do?” when reviewing the work with the developers (we try not to just throw stuff over the fence). No matter how much we annotate and clarify, there’s always the usual…

“You know, I didn’t quite think about it. I’ll just remove it for now.”

Part of it is lack of sufficient time to gather requirements, part is sometimes crafting a good user experience where coming up with something really cool is something that you can’t put a time frame on. Sometimes it could take five minutes and hit you on the road, like how to handle comments within an MySpace Open Social application I am working on now. It could take weeks where after you design it, it’s implemented and you realize, “man, that’s just not effective.”

At work and at some of the clients, I push for having an Information Architect around during the development process — not necessarily full time, but just around for questions — because issues will always come up. That’s why I am convinced that waterfall-style requirements gathering works well for building the Space Shuttle, but doesn’t work well for developing web applications because of the nature of the technology (ultimately flexible, low barrier to entry, the approach of “let’s throw everything against the wall, see what sticks”).

With wireframes, there’s always this “lost in translation” moment where Scarlett Johannsen asks Bill Murray, what does this do, and we haven’t quite covered it. I’m convinced it not a tool issue (Axure, Visio, whatever) but just an understanding of what we do is part art, part science. Apple gets it. Some other companies get it.