People new to use cases are often unsure of where to start gathering requirements. I suggest creating a context diagram. A context diagram is a high-level, informal view of three things:
- the system you're going to be gathering requirements for,
- the things that need to interact with the system (use case experts call these things external entities), and
- a brief note about the interaction between each thing and the system (#3 is optional).
Because it's an overview and lacks much detail, this diagram is an easy way to start building momentum in your requirements gathering process.
Create a context diagram by drawing a circle in the center of the page. If your system has a name, use it to label the circle. If it doesn't have a name yet, just label the circle as "System." Then list each of the external entities around your system and draw a line between the entity and the system. If it's not obvious why an entity belongs on the diagram, make a note about the interaction between the system and the entity. Specifically, note what information is passed and who it is passing it (the system or the entity).
Below is a context diagram example for a fictitious website named RentLenses.com. This website allows photography enthusiasts to rent expensive camera lenses by the week.
A context diagram looks so simple that you might be tempted to just skip it. But because they are so easy to create, I prefer to draw them anyhow. Their simplicity helps spread two important pieces of information early in the project.
The context diagram answers the first and most essential question about your requirements: Who needs to use this system? By calling out the things that are external to the system, we define its boundary and scope. In the example above, we can see that building a credit card processing function is out of scope. Instead, RentLenses.com will use an external payment gateway. Incidentally, the external entities on the context diagram are also the first draft of the system's actors (identifying each actor is the next step in the use case modeling processes).
Equally important are the entities that do not appear on the diagram. The context diagram shows only the entities that will interact with the system in some way (either by passing information to it or by receiving information from it). If an entity does not appear, then building that interaction is out of scope.
With a completed context diagram in hand you can quickly vet the objectives and scope of the project among its stakeholders.