4.3 Execute (develop solution requirements)

 < Day Day Up > 

4.3 Execute (develop solution requirements)

We will begin this phase by capturing the system context for the proposed project. This helps establish the project scope and provide a high-level system view to be validated with the customer. It identifies the proposed portal solution (in the center), with the end users on the left and the functional systems on the right.


Building the task management system is also part of this project.

click to expand
Figure 4-1: IFB system context diagram

Step 1A - List users/existing systems and Functional Requirements

Next we need to document a full list of system users [1] as well as the functional requirements. Based on the Project Description and the System Context Diagram, we can derive the following list of actors and existing systems and the major functionality needed:

  • Users and existing systems:

    • Store employee

    • Manager

    • Associate

    • Corporate

    • Applicant

    • Skills database

    • Resumé database

    • Labor scheduling system

    • HR Center of Excellence

    • Task management system

    • Time and attendance system

    • Item replenishment system

    • Point of sale system

    • Back door receiving system

    • Identity management system

  • Functionality required:

    • Access portal (authenticate and authorize)

    • User management (enroll, deactivate, remove)

    • Fill job vacancy

    • Enter staffing requirements

    • Indicate time away (unavailable)

    • Generate schedules

    • Review schedule

    • Manage compensation and benefits

    • Update personnel records

    • Develop career strategy

    • Assess skill requirements

    • Staff training

    • Manage performance

    • Receive inventory

    • Audit inventory

    • Search for customer service information

    • Create task list

    • Assign tasks

    • Review tasks

    • Track tasks

    • Corporate collaboration (e-mail, e-meeting, IM) Step 1B

From these lists, we derived the initial high-level Use Case Model. This is shown graphically in Figure 4-2 on page 173.

click to expand
Figure 4-2: IFB Use Case Model

Table 4-1 provides additional detail on the description of these use cases.

Table 4-1: IFB use case descriptions

Authenticate and Authorize User

All internal users authenticate with system, establishing a distinct role for interaction,

Apply for Job

Job applicant submits application

Review and Guide Schedule

Store associate can access current schedule and enter conflicts to affect future schedules

Access Customer Service Content

Store associate can access customer service information to assist a customer

Receive and Audit Inventory

Store associate can perform inventory audit operation and scan in shipments

Review and Perform Tasks

Store associate reviews currently assigned tasks and updates status as tasks are performed

Job Solicitation

Store manager enters staffing requirements and selects applicants to fill vacancies

Manage Tasks

Store manager creates new tasks, assigns staff to tasks and subtasks, and tracks task status

Generate Schedule

Store manager sets inputs to scheduling system

Update Personnel Record

Store manager can modify personnel records of any store employee. Employees can update limited personal data on their own personnel records

User Management

Store manager creates, activates, deactivates, and removes users and role bindings within system

Employee e-Learning

Corporate employees develop career strategy, assess skill requirements, and participate in training

Corporate Collaboration

All employees send and receive e-mail, participate in e-meetings, and participate in synchronous chat

Manage Compensation and Benefits

Store manager can modify employee HR profiles. Employees can access HR services

Step 1C - Inventory large reusable assets

Recall that the next crucial step in the process is to survey the available set of large reusable assets available to you as an architect to leverage. Once again, we will use the Portal composite pattern.


At the conclusion of this exercise we mention that several of the use cases described above that do not match the Portal composite pattern generic use cases are in fact very generic to B2E (ODW) portals. Thus, moving forward you can use this or other ODW solutions as a large reusable asset.

Step 1D - Match solution use cases with generic use cases

Here we categorize those aspects of the current project that match up completely with the reusable asset. In our current task, this involves matching the IFB use cases with the generic use cases of the Portal composite pattern.

Table 4-2 on page 174 show the result of this matching analysis. It should be noted that this initial mapping is somewhat pessimistic. Many of solution use cases can be made to fit into the Portal composite pattern (PCP) under the very broad Access Enterprise Application generic use case. Given that the Task Management functionality and part of the scheduling functionality were also delivered as part of this project, we have deferred including these as a complete match up front.

Table 4-2: Matching the IFB use cases to the generic PCP use cases

Solution Use Cases

Matched PCP Use Cases

Authenticate and Authorize User

  • Authenticate (AccI)

  • Authorize (AccI)

Apply for Job

Review and Guide Schedule


Access Customer Service Content

  • Search for Content (IA)

  • Review Corporate Information (SS)

Receive and Audit Inventory


Review and Perform Tasks


Job Solicitation


Manage Tasks


Generate Schedule


Update Personnel Record

Access Enterprise Application (SS)

Manage Compensation and Benefits

Access Enterprise Application (SS)

User Management


Employee e-learning


Corporate Collaboration

  • Synchronous Chat (C)

  • Participate in e-meeting (C)

  • Visit TeamRoom (C)

Step 1E - Identify delta use cases

The next step is identifying each of the unmatched (delta) use cases and classifying their associated business and/or integration patterns. Figure 4-3 on page 176 maps the remaining use cases into the primary business patterns, and (where appropriate) to an integration pattern that could potentially be used to integrate this functionality into the baseline solution:

click to expand
Figure 4-3: Classifying IFB delta use cases

At the business and integration pattern level, none of these delta use cases fall outside the coverage of the Portal composite pattern—in other words, they don't involve either Extended Enterprise or Application Integration patterns.

The final steps in developing the solutions requirements call for documenting the NFRs and performing a walkthrough/validation exercise with the customer.

Step 1F - Identify and document NFRs

The NFRs for the IFB project follow:


Concurrent accesses from multiple users must be supported.


Configurable to achieve 24x7, but not required in the first installation—nor is such availability critical


The system should respond at least 93% of the time with scheduled maintenance windows allowed.

Response time
  • Access to HR system should be less than two seconds.

  • Access to task management facilities should be less than one second.

  • Public workstations (POS and store kiosks) must not display secure data.

  • All other access types can display only that data appropriate for an authenticated role.

  • Need good single sign-on (SSO) support for back-end systems, particularly the HR system. This is both for user convenience and to ensure proper back-end system access and auditing.

During the walkthrough you will certainly want to validate as many usage scenarios as possible. For example, the lone Security NFR implies that not all system functions will be available to the POS system. You should ensure that meeting this requirement does not exclude the degree of system access expected by the customer.

[1]Roles or actors

 < Day Day Up > 

Architecting Portal Solutions
Architecting Portal Solutions: Applications Development
ISBN: 0738498645
EAN: 2147483647
Year: 2003
Pages: 82
Authors: IBM Redbooks

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