Defining the Problem Domain

To promote understanding of the problem domain, we ask ourselves several questions, some of which can be stated as follows:

• What business needs will the software try to solve?

• Who are the users of the system?

• What functionality will be supported by the system?

• What are the interactions between different subsystems?

• What components in the problem domain can be provided by a third party as off-the-shelf components?

• What components of the system can be isolated to form reusable, self-contained subsystems?

The answers to these and myriad other questions help us understand the solution space. We will be gradually answering these questions as we proceed through the book.

The first step in understanding the problem domain is to create a project description. A project description should explain the purpose of the project. It must be concise, and it should quickly demonstrate the business objective. You will be surprised how many different perspectives evolve at this time from different stakeholders. At this stage of the project, most stakeholders are concerned with return on investment. A project description is therefore the first consensus point between stakeholders because it clearly states the objectives of the new system.

Tip

Before you begin to write the system description, you may find it helpful to define domain-specific terms for your audience; this will establish a common vocabulary for communication. You may optionally provide an operational model for added clarification, as shown in Figure 1-1.

Figure 1-1: GreaterCause operational model

GreaterCause System Definition

The following terminology is consistently used in defining the problem domain.

• GreaterCause is a philanthropic application that is hosted at a central location.

• GreaterCause.com is the domain name of the site where the GreaterCause application is accessible as a hosted service. For brevity, the term "site" will refer to the GreaterCause.com site.

• Portal is a personalized single point of access for business and consumer services.

• Portal-Domain is the domain that hosts a consumer portal or a corporate intranet.

• GreaterCause.com Portal-Alliance is formed as a result of portals providing a pass-through or gateway component, also called a portlet, on the portal page for redirecting portal users to the GreaterCause.com site.

• NPO is a non-profit organization that registers with GreaterCause.com site for soliciting charitable contributions from prospective donors.

The GreaterCause.com domain is responsible for hosting the GreaterCause charitable-giving application at a central location. The site is accessible to the donors via various consumer portals and corporate intranets.

Portal-providers create an alliance (i.e. a service contract) with GreaterCause to procure the GreaterCause services for their user base. An agreement between a portal-provider and GreaterCause to serve the portal's users is termed Portal-Alliance. Each portal-alliance has an associated administrator ID and password using which the portal-alliance Administrator (an employee of the portal provider, or its designate) can maintain the portal-related profile information. The portal-provider interposes itself as a gatekeeper to the GreaterCause application by using a portion of the portal's real estate to provide an intelligent gateway or pass-through to the GreaterCause site for their subscriber base. The GreaterCause pass-through is available as a portlet. This portlet is aggregated into the portal view of the partnering portal-domains.

Non-profit organizations (NPOs) register with GreaterCause to list themselves in the GreaterCause database for receiving charitable contributions (i.e. donations) from the visitors of the GreaterCause.com site. Each registered NPO is provided with an administrator ID and password using which the NPO administrator can maintain its related profile information.

Although, GreaterCause.com visitors can donate to any of the available charities (i.e. NPOs), a portal-provider can influence the decision of a donor in the selection of a preferred charity; this is done by campaigning for the preferred NPOs. Portal-alliance administrators have the ability to log in to the GreaterCause.com site with their administrator ID and create campaigns for non-profit organizations at both the national and regional level. These portal-alliance–specific campaigns for preferred NPOs are stored at the GreaterCause.com site and subsequently featured by the portal-domains on their respective portal-page. The list of featured non-profit organizations (featured-NPOs), created by the portal-alliance administrator in the GreaterCause.com database, is provided via a web service to each portal-domain; this list is subsequently displayed by the portlet hosted within the portal-page. Prospective donors visiting the portals are provided with the option to donate to either the featured non-profit organizations, or pass through directly to the GreaterCause.com site for searching and donating to a non-profit organization of the donor's choice.

Once a portal-user is redirected to the GreaterCause.com site by the portal-provider, the GreaterCause service, as viewed by a portal-user, is customizable by portal-alliance administrators for preserving the branding and navigation structure of their respective portal-domains. The portal-domain, before redirecting the portal-user to GreaterCause.com, is responsible for authenticating the portal-user (a.ka. the donor). The portal-domain and the GreaterCause.com site mutually authenticate before redirecting the donors. Donor's registration information is provided by the portal-domain to GreaterCause.com during the redirection process.

All transaction history is logged using the donor's registration ID and portal-domain affiliation. Donors have the ability to view their history of donations for the current and previous year.

Tip

The description of the system provides a vocabulary that consists of real-world objects. Use case names are derived from this vocabulary and tend to express the behavior of the system in short, present-tense verb phrases in active voice; the use case being named must represent a reasonably atomic behavior of the system. In the use case context, a client is an external actor to the use case—which could be a human, another software system, or an asynchronous message. Therefore, a use case name is most effective when expressed from the perspective of the user.