The analysis phase is concerned exclusively with what the application is supposed to do. The question of how the application will accomplish the goal is deferred to the design and implementation phases. In many ways, the analysis phase can be the most challenging because it requires that you take (often vague) ideas and translate them into specific functional requirements. You must create a map of what the application looks like from a distance. Although you can get away with a minimal analysis phase for a small project, the analysis phase becomes increasingly important for a project's success as the project increases in size and scope. Although you might be able to walk around your neighborhood without a map, if you wanted to cross the country, you'll undoubtedly agree that you need a map. This is true of application development as well. All too often, the analysis phase is glanced over or deemphasized. Poor analysis leads to frustration for all parties involved (the developers who have to constantly make guesses and refector, the managers who have the responsibility to see the project through to a successful completion, the client who wants the working application, customers that have to use the application that may suffer from limited feature sets and bugs due to poor analysis, etc.). The goal of analysis is to provide a clear specification that outlines the needs of the user. Unlike later phases, the analysis phase should be as non-technical as possible. The outcome of the analysis phase is generally a document that outlines the functional requirements. However, it's important to understand that there are many ways to approach gathering these requirements, and the resultant document has no one required format. What is most important is that you, your team, and/or your company uses an approach and document format that works best for you while still achieving the goal of clearly defining this map for the application you want to build. Although there's no one required approach or format, we'll present one common approach to analysis using use cases. If you are new to the idea of doing formalized analysis then you may find it useful to try using use cases. We also encourage you to research other techniques and document formats to find what works best for you. Introducing Use CasesOne way to define the functional requirements of an application is simply to list everything that the application should be able to do. Although that approach is not necessarily wrong, it is naïve in that it fails to take into account the real-world use of the application. Applications don't exist in isolation; they interface with all sorts of users. Therefore, it's much more realistic and useful to approach the functional requirements from the standpoint of how the application is used. This approach naturally leads to a kind of functional requirement called use cases. Use cases present the application requirements by showing various ways in which users might interact with the application. The following is an example of a simple use case:
Use cases can be formatted in many ways. Generally, use case experts talk about three basic formats. Brief: One paragraph outlining the main success scenario. The preceding example was in the brief format. Casual: Multiple paragraphs outlining not only the main success scenario, but also alternative scenarios. The following is an example of a casual format use case:
Formal: The most elaborate of the formats for a use case document. This format lists all the steps for the use case as well as supporting data such as actors and conditions. The formal use case is discussed in more detail in the next section. Writing Formal Use CasesTypically you'll want to create formal use cases for a functional requirements document. In this section we'll look at how to create a formal use case. A formal use case can include the following sections:
The following is an example of a formal use case. Note that this example does not have any open issues.
Now that we've had a chance to see the structure of a formal use case, we'll next look at how to start writing these use cases for an application. Forming Use CasesNow that you've seen how to write a use case, it follows that you'll want to know how to start forming these use cases. For example, what level of granularity is appropriate? Should you have ten uses cases or a hundred? The answer to these questions is subjective. There is no one correct set of use cases for an application. However, you will likely find the following guidelines to be helpful:
Using UML in AnalysisUML (Unified Modeling Language) is a language in common use for modeling applications. Although UML is perhaps most frequently used during the design phase (as we'll see in the next section) it is not uncommon to use UML during analysis as well. One of the three parts of a system model in UML is what's called the functional model. The functional model allows you to create use case diagrams, which can be very helpful. UML use case diagrams generally are not detailed enough to be used apart from written use cases. However, they are often a nice addition to written use cases as they provide a visual representation of the uses cases, actors, and systems. Figure 1.1 illustrates actors and uses cases for a common system, a store. Figure 1.1. An example of use cases in UML.
|