Identifying Risk Factors and Dependencies


Identifying Risk Factors and Dependencies

Once the project description is completed, the next step is to assess the risks and dependencies associated with the project. Knowing this information up front mitigates the risks early in the project life cycle. You must also document all assumptions. Once you obtain factual data, some of the assumptions become assertions and can be removed from the list. Some of the risk factors and dependencies for the GreaterCause application are listed in the following sections to illustrate some possibilities.

GreaterCause Risk Factors

Following are some of the GreaterCause risk factors:

  • Portals may be restrictive in how they exchange information with GreaterCause.com site.

  • Will a generic composite view template with limited UI customization meet the needs of the portal providers?

  • Will the architecture support phase-2 functionality for funds disbursement?

  • Will the portal provider agree to single sign-on semantics? It is expected that the portal-domain will authenticate the user before forwarding the request to the GreaterCause.com site.

GreaterCause Dependencies

Following are some of the GreaterCause dependencies:

  • Project will use the Struts MVC framework. Engineers associated with this project will need to be trained on Struts.

  • Site functionality can only be finalized after obtaining buy-in of pilot portal-alliances.

  • Pilot portal-alliances must agree on using Web services for receiving the featured-NPO list.

Note 

Apart from documenting functional requirements of the system, one must also document the nonfunctional requirements that address the need for performance, load balancing, failover, platform dependencies, framework usage, adherence to standards, vendor preference, usability, etc. These are specific to organizations, applications, and platforms; as such, they will not be discussed in any detail in this book.



Identifying Use Case Packages

A use case diagram represents some behavioral aspect of a system, subsystem, or a class. It consists of a set of conceptually and semantically related use cases. The aggregate of all the use cases in all the use case diagrams represents the system functionality; this is also called the static use case view of a system. However, each individual use case with its associated set of sequences of actions constitutes the dynamic view of the system. The focus should be on creating use cases that factor common behavior, and then grouping use cases that are relevant to each other, both conceptually and semantically, in producing a desired system behavior. Such groupings form independent, self-contained functional units that could be packaged as subsystems during the analysis phase. Use cases in each package must have strong cohesion to each other and exhibit loose coupling with other packages.

Decomposing the system into packages has the advantage of modularizing the system, making it simpler to understand, manage, and document. The atomicity at the level of subsystems enables concurrent analysis, design, and development effort of different subsystems. The package hierarchy defined in the requirements phase can be used to model the structural view of the system during the analysis phase, and each package could potentially result in a subsystem. However, during the analysis phase you will also discover several supporting objects interacting with multiple packages. For example, the authentication module, the error reporting module, and the service locator module could be common to several packages; therefore, in the analysis phase, the package structure will need to be modified for housing such components. During the analysis phase, you may find the need to break down a package into subordinate packages; make sure the nesting is not more than a couple of levels, otherwise the packages get harder to manage.

Once the key abstractions are identified in the system context, we are able to distinguish functionally related use cases and move these into packages. Let's briefly define these groupings and then assess whether each grouping cohesively expresses an independent functional unit. Figure 1-4 depicts the system's use case packages with dependency relationships between several packages. This relationship is shown using a dashed line with an arrowhead pointing in the direction of the package that the other depends on. The dependency implies that a package is dependent on another package for some services or has structural knowledge about the elements in the other package.

click to expand
Figure 1-4: Decomposing the system into packages

GreaterCause Use Case Packages

GreaterCause use cases are distributed among packages shown in Figure 1-4. Refer to the use case diagrams corresponding to each package under the later section "GreaterCause Use Case Summary" for package description and for the use cases allocated to each package. The use case diagrams associated with each package in the section "GreaterCause Use Case Summary" depicts package interactions or dependencies using actors as stand-ins for related packages.

Once the decomposition has been accomplished, the use case diagrams can show package interactions or dependencies using actors as stand-ins for package-related functions. This notation supports the definition of a system context where every subsystem boundary scopes the behavior from the point of view of all the actors interacting with the subsystem.