1 Overview
This document is intended to outline the roles, activities, and (ultimately) interactions that will make up the functionality of the Overlord:DTG application. Having well understood user scenarios should lead to better designs that appropriately meet the needs of those users. It is important to understand who those users are and what they need.
2 User Roles
All applications have a defined population of users. It is often important to identify those users as well as what roles they have within their organization. This section will outline the different user roles that Overlord:DTG is expected to support. The goal is to identify the types of users who will be interacting with the application.
The following are a list of Roles that should be supported by Overlord:DTG:
- Business Analyst - non-technical users who are subject matter experts. These users are responsible for ensuring that the Business Problems defined within the application are properly defined and documented.
- Project Manager - non-technical users who are responsible for the overall success of Solutions to Business Problems. These users are typically facilitators - they are responsible for ensuring that other Roles are completing their tasks appropriately.
- Architect - technical users who are tasked with defining Solutions to Business Problems. These users need to understand the Business Problem definition and be able to define an appropriate Solution to it.
- Developer - technical users who are responsible for implementing technical assets (ServiceComponents, CompositionComponents) according to Solution definitions created by Architects.
- Tester - users who are responsible for testing the Components produced by the Developer.
The above list should be considered preliminary - additional roles such as Technical Lead, and Data Architect are likely to be added in the future.
3 General Activities
This section serves as a high level list of the activities that can be performed within the Overlord:DTG application. The list of activities is very coarse grained and should not imply how these activities are performed (no UI interactions are described). Each activity will include the Role(s) associated with it, hopefully identifying which user population will be performing the activity. In some cases, multiple Roles are associated with an activity. In such cases, the Role that is primarily responsible for the activity will be highlighted (if such a primary Role exists).
- Define and manage Business Problems [Business Analyst, Project Manager]
- Create and update Business Requirements for a Business Problem [Business Analyst]
- Create a Solution for a Business Problem [Architect]
- Browse/manage Solutions [Architect]
- Create new assets in a Solution [Architect]
- Service
- Composition
- HumanActor
- Task
- Event
- Rule
- InformationType
- Discover and add existing (already defined) assets to a Solution [Architect]
- (see “Create new assets” above for list of assets)
- Manage Solution assets (group, remove, etc) [Architect]
- Manage assets by type [Business Analyst, Project Manager, Architect]
- (see “Create new assets” above for list of assets)
- Upload/manage Deployment Units [Architect, Developer]
- Browse Components (ServiceComponent, CompositionComponent, etc) [Architect, Developer]
- Link Components to logical constructs (e.g. ServiceComponent → Service) [Developer]
- Validate that there are Components appropriately linked to all logical assets within a Solution [Architect]
- Understand all Solutions that rely on specific assets [Business Analyst, Architect]
- Understand all Compositions that use specific assets [Architect]
4 Top-Down Scenarios
This section contains a number of user scenarios and interactions that focus on a top-down style of design. For information about what top-down design is all about, please see the DTG - Concepts document’s “Top-Down Design/Development” section.
4.1 Scenario - Full SOA Project Lifecycle
4.2 Scenario - Adding an Asset to a Solution
4.3 Scenario - Creating a New Service
4.4 Scenario - Creating a New Composition
5 Bottom-Up Scenarios
This section contains a number of user scenarios and interactions that focus on a bottom-up style of design. For information about what top-down design is all about, please see the Overlord:DTG - Concepts document’s “Bottom-Up Design/Development” section.
One of the goals of Overlord:DTG is to allows users to user as much or as little as they want. To that end, users should be able to interact with the assets managed by the application regardless of higher level organization of those assets. In other words, an Architect should be able to define things like Services and Compositions without working within the context of a Solution to a Business Problem. Similarly, Developers should be able to create implementations and manage their lifecycle without necessarily tying those implementations back to logical assets defined by an Architect.
5.1 Scenario - Service Management
5.2 Scenario - Composition Management
Comments