Capturing User Requirements through Use Cases
As a software project manager, I am responsibled for gathering user requirements from users and communicating it to the developers. I find it useful to capture requirements by documenting use cases. In school, I was taught UML Use Case Diagram. I find it too abstract and too simple to be considered useful to customer, me, and the developers.
user-web-1. User can broadcast a message to his/her friends.
Preconditions:
- User has registered an account.
Steps:
- User login on the website.
- User type a message in the Status input field.
- User click "Post".
Postconditions:
- The posted message appears on user's wall.
- The posted message appears on user's friends wall.
- User's friends get an email notification containing the posted message.
This is an example of an use case. Each use case has a unique ID (e.g. ”user-web-1″), which makes it easy to communicate among team members. An use case title consists of an actor and an action. The actor indicates the types of users that will be using this software (it is usually an user role). The action describe what the user wants to achieve (e.g. register an account, post a message, send an email). Optionally, there may be a list of preconditions, which describes some perquisites/assumptions/context. The steps are a series of physical actions that user has to perform to achieve an objective. I will talk more about the steps later. Postconditions describes the consequences of carrying out these steps. Use case is written in such a way that an end user can easily understand. When the software is developed, an user can performs the steps in each use cases to verify if the software meets the requirements.
Listing Steps
This is not a technical specification, use case should not contain technical detail. The steps should not describe the UI (i.e. layout, color, fonts). The purpose is to capture user experience. Designer should design effective UI to enable such interaction, developer should implement features that deliver this functionality. Each steps can be further broken down in finer detail. There is no rule on how detailed the description should be. I make sure it is as simple as possible (giving room for designer and developer to express their creativity), and detailed enough for me to communicate with both user and developer.
Advantages of use case:
- Gives insight to user experience. Developers can review the use cases and suggest improvements to user experience.
- Testable by user. Both developer and user can perform the steps to verify that the developed software meets the user’s requirements.
Disadvantages of use case:
- The use case does not contain technical information. Developer needs define technical specifications based on this use case.
- Use case is useful for testing usability, it cannot be used to test technical requirements (i.e. stability, performance).
During the requirements gathering phase, all the use cases are documented in an Use Case Document (UCD). Whenever the implementation of an use case is completed, the tester (user) will use the UCD to verify that the implementation meets user’s requirements. Before each software release, there is a code freeze period where all documented use cases will be tested as part of the QA process.
Tags: developer, requirements gathering, software development, software testing, UAT, user cases, user experience, users
I think use cases are a great way to develop (along with an agile framework).
Using this style does require that developers have a more complete understanding of coding and business thinking than if you have them only work from rigid technical specs. This is a additional effort but is well well worth it.