4.3 Execute (develop solution requirements)

---

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.

Note 

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

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.

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.

Note 

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:

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:

Performance

Concurrent accesses from multiple users must be supported.

Availability

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

Reliability

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.

Security

• 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

---