Refined Requirements for Online Photo Shop

5.2.1 Refined Use Case Diagram

graphics/requirements_icon.gif

The first task in refining the requirements is to reevaluate the use case diagram. Based on the initial requirements, analysis, and design decisions described in Chapter 4, we update the use case diagram as shown in Figure 5.1.

Figure 5.1. Refined Use Case Diagram for Online Photo Shop

graphics/05fig01.jpg

The refined use case diagram clearly distinguishes the different parts of Online Photo Shop, as discussed in Chapter 4. Online Photo Shop provides a Web-based interface for ordering products, whereas the photo editor application is used to edit pictures on the local computer. Because of that, the photo editor and the Web order application are in different processes. This also means that they are two independent applications and have no anticipated dependencies. In addition, the new diagram shows additional use cases for loading and saving pictures in the photo editor, as well as a use case for uploading images to the Web application.

5.2.2 Refined Requirements List

The next task is to update the requirements. In addition to adding the new requirements, it is important to put more details into the requirements. These extra details include pre- and postconditions, functional descriptions, and constraints. Refinement of requirements will not be finished in this iteration, but the goal is to put all details of the use cases known at this point into the requirements to support the following activities:

  • Negotiating the deliverable functionality with the customer, including the constraints
  • Analyzing the requirements and developing a good design for the implementation
  • Planning the project and providing reasonably accurate effort estimates (the effort estimates will be refined throughout development)
  • Enabling project management to develop an accurate contract agreement with the customer

Table 5.1 shows the refined requirements for the current iteration.

For the remainder of the book, we show only the requirements that are to be implemented in the described iteration. The alternative would be to refine all the requirements in the first construction iteration, but we have not chosen that approach for several reasons. First, it is easier to focus on the functionality that needs to be implemented in the specified iteration. Second, if requirements must be changed because of design or implementation issues, the changes usually will affect only the current iteration's requirements, and the requirements in later iterations can take all these changes into account from the beginning. (If complete planning is done up front, it is like the Waterfall model. Changes in later phases could trigger many changes.) For reference, the complete list of refined requirements can be found in the Requirement Specification XML file of each chapter on the accompanying CD.

The refined requirements include more details on the actual use case functionality and consider known constraints. In every iteration, we refine the requirements that are to be implemented in that iteration. This allows us to choose the best possible design and therefore the best possible implementation for the system.

Table 5.1. Refined Base Requirement Description

Requirement

Type

Summary

F:photo_editor

Functional

Customers shall be able to perform basic photo postprocessing on their digital images. The GUI shall be similar to the GUI model provided in the file PhotoEditorGUI.vsd. The GUI model shows the screen layout and the approximate position of the necessary buttons. The buttons to be used are not defined. The buttons should be chosen so that they can be used intuitively.

F:error_handling

Functional

Errors shall be reported via exceptions. The exception-handling mechanism is based on the Microsoft Exception Management Application Block (described in detail later in this chapter) and needs to be extended to show error messages in a window on the screen. Every exception shall be displayed on the screen within a dialog window. A meaningful error message shall be displayed. For fatal errors, from which the application is not able to recover, the exception is written into the event log and the application is shut down.

F:picture_load_and_save

Functional

It shall be possible to load pictures into the photo editor application, alter them, and save them either to the same or to a new file. An error message is displayed if the image format is not known (see also image_format).

F:image_crop

Functional

If an image is loaded, then the photo editor shall provide functionality to select a region of interest and crop the image to that region.

F:image_rotate

Functional

If an image is loaded, the photo editor shall be able to rotate an image by 90 degrees in both directions.

F:image_flip

Functional

If an image is loaded, the photo editor shall be able to flip an image vertically and horizontally.

F:image_format

Functional

The supported image formats are JPG and GIF. The supported image sizes range from 100 pixels to 2,048 pixels for both width and height. An error is reported if the image format is not known.

C:platform_os

Constraint

The target platform operating system is Windows XP Professional. No special hardware requirement is necessary.

Introducing .NET

Introducing Software Engineering

A .NET Prototype

Project Planning

The Photo Editor Application

GDI+ Graphics Extensions

Advanced GDI+ Operations

Dynamic Loading of Components

Accessing System Resources

Performance Optimization, Multithreading, and Profiling

Building the Web Application with ASP.NET

Security and Database Access

Product Release



. NET-A Complete Development Cycle
.NET-A Complete Development Cycle
ISBN: 0321168828
EAN: 2147483647
Year: 2005
Pages: 123

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