Architecting Portal Solutions: Applications Development
|
| < 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.
| Note | Building the task management system is also part of this project. |
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.
Table 4-1 provides additional detail on the description of these use cases.
| 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.
| Solution Use Cases | Matched PCP Use Cases |
|---|---|
| Authenticate and Authorize User |
|
| Apply for Job |
|
| Review and Guide Schedule | |
| Access Customer Service Content |
|
| 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 |
|
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:
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
|
| < Day Day Up > |
|