- Assessing Functional Requirements
- Describing the System
- Creating the Paper Prototype
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Describing the System
After the functional requirements are gathered, you are ready to create a text-based model of the system. Designing a system is really a process of creating even more detailed models. This enables the system to be evaluated and changed more easily than if you move directly from requirements to code. The text-based model of the system is created through a set of use cases. A use case is a description of the set of steps necessary to accomplish a function. A complete set of use cases describes at least 80 percent of the system and is the basis for more detailed modeling.
Identifying Actors and Use Cases
Before you can create a use case, you must identify the actors involved in your system. Actors are people or other systems that will interact with your system. The key to identifying an actor is that the person or system must receive something of value from your system. For example, a customer might receive a product from the system, or the company billing system might receive the required information to create an invoice.
When defining actors, be careful to define them generically based on role, not based on job title. This is because many people in an organization can fill a role. For example, if all the sales personnel are at a meeting, the company vice president might pick up the phone to take an order, thus becoming a salesperson. Typical actors include customer, salesperson, and manager.
When the actors are identified, you can match them with the use cases that they affect. When initially identifying use cases, limit them to simple one-line phrases. Later, you will expand the detail in each use case, but for now you are trying to create a system outline based on the actors and use cases.
Naming actors and use cases takes practice, but remember that an actor interacts with the system to receive a value. The use case is a functional name of the value received. A simple example is to name an actor as "customer" and the use case as "purchase product." In this example, the customer interacts with the system, and the value received is a product.
The design process creates a set of models used to describe the system. These drawings and descriptions are the blueprints used to create the final product. Imagine a set of blueprints for a house, or electrical schematics for a computer. In both cases, you can imagine a set of drawings that completely defines the product to build. Each set of drawings also has its own set of symbols that are unique to the profession in which they are used. Software modeling is no different. In our profession, we use the Unified Modeling Language (UML) to represent the elements in the system.
Although you will ultimately create a complete text-based set of use cases, the first artifact that you create in the modeling process is the use case model. This model is a visual representation of the actors and the use cases. Although this model is extremely simple, I have found that it serves as an invaluable graphical overview of the system. To create the use case model, we use the UML symbol for an actor, and the UML symbol for a use case. Figure 1 shows these symbols.
){kind=link}
The UML symbols for an actor and a use case
Documenting the Use Cases
Along with the use case model, you must create the text-based documentation. Documenting the use case provides the underlying detail necessary to fully understand how the actor interacts with the system. Information required for the use case documentation is typically gathered through one-on-one interviews with domain experts and other interested parties. Just like the facilitated sessions, the interview process requires experience and skill to complete successfully.
During the interview process, I typically ask the person to describe the sequence of events that he goes through to complete a task. For example, you might ask the person to describe how he takes and processes an order. The person then explains what forms are filled out, what departments are notified, and other key pieces of information.
The goal for the application architect is to completely understand the process so that it can faithfully be rendered in code. Sometimes the architect might know key pieces of information based on previous discussions or even his own experience. However, I often find that certain surprises emerge during these interviews.
In my experience, all companies have discrepancies between the way they think they operate and how they actually operate. When interviewing personnel for use case documentation, it's important to document how the business actually operates. In fact, it's often a good idea to have management personnel present during the interview process so that they can hear directly from the employees how work is actually accomplished. This often leads to a re-engineering of the business processes within the company. Interviews lead to discovery; discovery leads to improvement. It's the improved processes that you want to build into your final software.