The Analysis Phase


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 Cases

One 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:

  • Generate Map: The user submits a form with a street address. The system displays a physical map of the street address, with the map zoomed in at the default level.

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:

  • Generate Map

    • Main success scenario: The user submits a form with a street address. The system displays a physical map of the street address, with the map zoomed in at the default level.

    • Alternative scenarios: If the address is invalid, the address form is redisplayed with an error message notifying the user why the operation failed.

      If the default zoom level is unavailable for the requested address, display a map at the greatest zoom level available for the location.

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 Cases

Typically 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:

  • Primary actor: A description of the user who drives the operations outlined by the use case. The description of the primary actor can include things such as the role of the user (e.g. anonymous, basic, administrator, etc.) as well as characteristics of the user that may be relevant to how they interact with the application (e.g. age, disabilities, etc.)

  • Preconditions: Those conditions that must be met for the use case to proceed.

  • Main success scenario: A more granular, step-based description of the way the application works than is given in the basic or casual formats.

  • Alternative scenarios: More granular, step-based descriptions of the ways the application will handle alternative uses than are given in the casual format.

  • Special requirements: A list of requirements for the use case that don't fit as part of the main or alternative scenarios.

  • Open issues: A list of notes including questions that must be answered to fully implement a solution for the use case.

The following is an example of a formal use case. Note that this example does not have any open issues.

  • Generate Map

    Primary actor: Customer

    Preconditions: Customer is already viewing the form that allows the user to specify an address and click a button to submit the form.

  • Main success scenario:

    1. Customer fills out address form.

    2. Customer submits address data.

    3. System requests map data from mapping service.

    4. System draws map at default zoom level.

  • Alternative Scenarios:

    3a.

    System detects invalid address format and redisplays form with error message.

    3b.

    Mapping service is unavailable and system displays error message.

    4a.

    Data is not available for default zoom level and system displays map at next highest available zoom level.


  • Special Requirements:

    This portion of the application must be accessible (508 compliant).

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 Cases

Now 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:

  1. Determine the types of users. An application can have many types of users. Each user will have different use cases. A simple example is one in which an application has a standard, anonymous user type and an administrative user type. The administrative user typically expects additional features that are not enabled for standard users. Your application might have additional tiers of users as well. For example, in addition to standard and administrative users, your application might have registered users who have access to features not available to standard users.

  2. Determine the basic goals each type of user can achieve. For example, all users might be able to generate maps, but only registered users can save maps. Additionally, only administrative users might be able to view the logs and analytics for the application.

  3. Fill out each use case with the appropriate sections.

  4. Evaluate the use cases. It's important that you take your time with the use cases to make sure they are correct and appropriate before moving to the design phase. Getting the use cases correct helps ensure the best possible result of the design and implementation phases. It's much easier to make changes to the use cases before you've designed or implemented the application than to revise them afterward and have to redesign and re-implement the application.

Using UML in Analysis

UML (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.





Advanced ActionScript 3 with Design Patterns
Advanced ActionScript 3 with Design Patterns
ISBN: 0321426568
EAN: 2147483647
Year: 2004
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net