Envisioning Process

The guidelines we give here are modified versions of those outlined by Laurie Litwack, who has worked on operating systems, server applications, and networking subsystems.

Who Does What During Envisioning?

At the beginning of the Envisioning Phase, the project team is selected and members are assigned to lead the six team roles. (Refer to Chapter 3 for guidelines about how to choose a team and how to work with large and small teams.) Each of the team roles plays an important part in the Envisioning Phase, so each must be represented.

Table 5.1 identifies some specific team role responsibilities for the Envisioning Phase. The lead for each team role ensures that these responsibilities are carried out and communicates with the rest of the project team.

Table 5.1 Team roles and Envisioning Phase responsibilities

Role Responsibilities
Product Management Deliver Vision Document
Manage customer expectations
Involve customer in prototype development
Manage project risks
Program Management Develop design goals
Describe solution concept
Outline project structure
Manage project risks
Development Design prototypes
Outline development options
Identify implications
Manage project risks
User Education Identify user performance needs and implications
Manage user expectations
Involve user in prototype development
Manage project risks
Testing Develop testing strategies
Specify acceptance criteria
Design bug-tracking system
Design risk management system
Manage project risks
Logistics Management Identify deployment implications
Identify support implications
Manage project risks

As the table shows, each role is involved in the task of managing project risks. The process of risk identification and management is discussed later in this chapter.

Several steps can be identified to help the team during the Envisioning Phase. These steps are similar to the Unified Process workflows, discussed in Chapter 4. We don't mean to imply that following these steps is the only way to complete the Envisioning Phase, but to provide a guideline for those new to the MSF Development Process Model. The headings are for descriptive purposes only; they are not intended as formal declarations of procedures or workflows. Additionally, these steps are sequential but should be followed in a flexible manner. For example, if the team is working on Step #4 (the implementation step) and realizes additional use cases are needed, it can return to Step #2 to develop the new set of use cases.

Step #1: Research

For the vision to be complete, the team needs to do some research, focusing its efforts on the customer and on other similar products being developed by or used by the organization. The goal of this step is to identify and record as much information as possible. Sources for this information should include the project customer, users, current applications and their documentation, as well as experts in the application's area or focus (domain), such as distribution or manufacturing. The team should limit notations about priorities to those obtained from these sources; additional prioritization will occur later. Using this information, the team can ultimately create a vision that outlines priorities, identifies dependencies, and roughs out a schedule.

Researching Other Enterprise Applications

If a previous version of this product exists, the team should start by understanding that version's vision. It's likely that the previous vision will include long-term goals for future versions that can and should be leveraged. Likewise, the team needs to understand the visions of any other applications concurrently under development.

Some of the questions to be asked when creating a vision for the new product include:

  • Is the new product expected to be a big leap or a small step for the organization?
  • Are the concept and the architecture being considered new to the organization?
  • What new features does the product bring to the organization?

Researching the Customer and Users

Throughout this book, we continually stress the importance of knowing and understanding the customer and the customer's business requirements before beginning any kind of development work. The Envisioning Phase is the time when the team focuses on the customer's problem and how users will work with the product to solve that problem. Areas the team should address include the following:

  • Business initiatives What business initiatives is the organization undertaking? How will these new initiatives affect the product?
  • Existing information What have other people discovered about this customer? Where can the team take advantage of any previous work? What customer information will need to be confirmed or clarified?
  • New hardware What new hardware products will impact the customer? How can new hardware be used to this project's benefit? For example, can features be included to take advantage of touch screens?
  • New technologies What new technologies will impact the customer? How can new technology be used to help the customer? For example, how will improved search capabilities or speech recognition affect users?
  • Support issues What problems did users have with other products like this one? What are the "Top 10 Support Issues" for the organization? What are the most requested features for new applications? What do the operations and support groups think of this product's vision?
  • User Education plans What are User Education's plans for documenting the product? What features and concepts from previous applications are difficult to grasp? What features from previous applications have been difficult to document? (Usually a feature that is difficult to document is difficult to use.)
  • Global issues What groups in other countries rely on the English language version of this product? How well will the new product meet the needs of foreign users? What research will be needed to ensure that the product can be used worldwide? Will a foreign (localized) version of the product be needed?

Researching Similar Products

The vision the team develops for this product must fit with the visions already developed for the other products used by the organization. In some ways, this is the easiest type of research, because it's a matter of leveraging existing knowledge and working with existing contacts within the organization to ferret out information that already exists. Questions the team should ask include the following:

  • Leverage points What were the visions of other products developed for the same customer? What can be done to leverage and support the work done for those products?
  • Operating system What do the current operating systems provide for this product? What will future versions of the operating systems provide? How will changes in the operating systems affect this product's architecture? How can new operating system features be leveraged and supported?
  • Schedule What other products, systems, or applications is the organization implementing during this product's time frame?

Step #2: Analysis

Synthesizing the business and user requirements gathered in the research step is by no means an exact science. One of the ways to boil down the information is to group it into simplified statements or questions with their solutions. For example, "The consulting group must enter hourly data in three different locations" and "The consulting group wants to enter data only once." Often one side of the equation can be stated, and the team has to determine the other side. The concepts presented on one side represent the current state, and the concepts presented on the other side represent the future state. Looking at a list of the organization's overall business goals can also help the team requirements for a project.

In Chapter 6 we discuss noun-verb concepts for determining logical and physical designs. Looking for key noun phrases and verb phrases can also be useful in identifying project requirements. If project stakeholders repeatedly use the same nouns and verbs when talking about the project, those phrases are probably important requirements for the project.

Business and user information can be analyzed to create product feature lists. As with requirements, the derived features should not have a scope or version applied to them at this point. The team will determine the current product's actual feature set, and some feature sets for future releases, in the implementation step discussed below.

To help document business and user requirements, UML use case and activity diagrams are very helpful for concisely communicating information. The use case model of the Unified Process can be used to describe the requirements in the language of the users. Additionally, simple word descriptions (typically in sentence form) of the specific use cases, as well as descriptions of usage activities and usage scenarios, provide good communication of requirements. When this step is complete, the team should have an exhaustive list of use cases, which will be the foundation of the entire development process.

Step #3: Rationalization

After the use cases and feature lists are created, those features that are similar in nature can be grouped into feature buckets, or sets of features, based on user actions, application actions, the data being used, or any other grouping that applies to the application's domain. At this point, the team is still working with features that describe current state as well as future state. For current state activity descriptions, the team can apply process re-engineering techniques to determine whether the activity can be modeled more efficiently in another manner. The design patterns discussed in Chapter 2 can provide examples of different and better ways to model processes in an application.

Step #4: Implementation

As each step of research, analysis, and rationalization is completed, and as any prototypes related to the category are developed, what has been learned is recorded so that over a period of time, a body of documentation about the project accumulates. In the research step, the team's job was not to analyze the information, but simply to record the information as it was encountered. During the analysis step, the research was refined into actual business and user requirements described by use cases, and candidate features were listed. The rationalization step grouped features into feature buckets. The final step is to determine what specific feature buckets will be implemented for the current product version.

At this point, the team prioritizes the feature buckets, with their corresponding features. The future-state use cases, use case diagrams, activity diagrams, and usage scenarios that describe this release of the product are gathered together, and a project vision is drafted. This draft includes the long-range goals for the project and validates that the current product version is moving in the right direction. At this point, enough information is known to determine how the product's tradeoff triangle of resources, features, and ship date is constrained, optimized, and accepted. The initial high-level project schedule can also be determined to provide guidance and reference for the Planning Phase.

Step #5: Validation

As mentioned, the team created the draft of the Vision Document during the Implementation step. The team now reviews and modifies this document. The Envisioning Phase's validation step is the point where the team members need to take a step back and look at their progress and deliverables to ensure that they are adequately prepared for the Vision Approved Milestone.


The envisioning process in not about creating documents; it is about communicating the vision of the project within the project team and with the project stakeholders. Prototypes are an excellent method of communication. At the heart of any prototype concept is the old adage "A picture is worth a thousand words." The level of detail in a prototype application is typically very shallow. It may consist of nothing more that screen shots or examples of typical screens. However, the application flow can be described by stepping users through a prototype that follows one of the use cases or usage scenarios defined by the team.

Don't expect to reuse significant amounts of code from a prototype. Reuse often leads to jumbled "spaghetti" code that limits the application's design process.

Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Year: 1999
Pages: 182

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