Portal Server Use Cases

Use cases are written scenarios used to test and present the system’s capabilities and form an important part of your high-level design. Though you implement use case scenarios toward the end of the project, formulate them early in the project once you have established your requirements.

When available, use cases can provide valuable insight into how the system is to be tested. Use cases are beneficial in identifying how you need to design the user interface from a navigational perspective. When designing use cases, compare them to your requirements to get a thorough view of their completeness and how you are to interpret the test results.

Use cases provide a method for organizing your requirements. Instead of a bulleted list of requirements, you organize them in a way that tells a story of how someone can use the system. This provides for greater completeness and consistency, and also gives you a better understanding of the importance of a requirement from a user perspective.

Use cases help to identify and clarify the functional requirements of the portal. Use cases capture all the different ways a portal would be used, including the set of interactions between the user and the portal as well as the services, tasks, and functions the portal is required to perform.

A use case defines a goal-oriented set of interactions between external actors and the portal system. (Actors are parties outside the system that interact with the system, and can be a class of users, roles users can play, or other systems.)

Use case steps are written in an easy-to-understand structured narrative using the vocabulary of the domain.

Use case scenarios are an instance of a use case, representing a single path through the use case. Thus, there may be a scenario for the main flow through the use case and other scenarios for each possible variation of flow through the use case (for example, representing each option).

Preparing to Develop Portal Server Use Cases

When developing use cases for your portal, keep the following elements in mind:

• Priority. Describes the priority, or ranking of the use case. For example, this could range from high to medium to low.

• Context of use. Describes the setting or environment in which the use case occurs.

• Scope. Describes the conditions and limitations of the use case.

• Primary user. Describes what kind of user this applies to, for example, an end user or an administrator.

• Special requirements. Describes any other conditions that apply.

• Stakeholders. Describes the people who have a vested interest in how a product decision is made or carried out.

• Precondition. Describes the prerequisites that must be met for the use case to occur.

• Minimal guarantees. Describes the minimum that must occur if the use case is not successfully completed.

• Success guarantees. Describes what happens if the use case is successfully completed.

• Trigger. Describes the particular item in the system that causes the event to occur.

• Description. Provides a step-by-step account of the use case, from start to finish.

Example Use Case: Authenticate Portal User

Table 3–1 describes a use case for a portal user to authenticate with the portal.

Table 3–1 Use Case: Authenticate Portal User

Item	Description
Priority	Must have.
Context of Use	Only authenticated end-users are allowed to gain access to the portal resources. This access restriction applies to all portal resources, including content and services. This portal relies on the user IDs maintained in the corporate LDAP directory.
Scope	The portal end-users identify themselves only once for a complete online session. In the case that an idle time-out occurs, the users must reidentify themselves. If the portal end-user identification fails more often than a specified amount of allowed retries, access to the intranet should be revoked or limited (deactivated) until a system administrator reactivates the account. In this case, the portal end-user should be advised to contact the authorized person. The identified portal end-users are able to access only the data and information that they are authorized for.
Primary User	Portal end-user.
Special Requirements	None.
Stakeholders	Portal end-user.
Preconditions	The portal end-user: is an authorized user. has a standard corporate LDAP user ID. The LDAP user ID must be provided to each employee. has an authorized LDAP entry. has access to the corporate intranet. does not have a guest account.
Minimal Guarantees	Friendly customer-centric message. Status—with error message indicating whom to call.
Success Guarantees	Presented with Portal Desktop home page. Authentication. Entitlement. Personal information.
Trigger	When any portal page is accessed and the end-user is not yet logged in.
Description	End-user enters the portal URL. If the customization parameter [remember login] is set, then automatically login the user and provide a session ID. If first time user, prompt for LDAP user ID and password. End-user enters previously assigned user ID and password. Information is passed to Access Manager for validation. If authentication passes, assign session ID and continue. If authentication fails, display error message, return end-user to login page; decrement remaining attempts; if preset attempts exceed limit, notify user and lock out the account.