test

Sun Java Enterprise System Deployment Planning Guide

Defining Business Requirements

No simple formula exists that can identify all business requirements. You determine the requirements based on collaboration with the stakeholders requiring a software solution, your own knowledge about the business domain, and applied creative thinking.

This section provides some factors to consider when defining business requirements.

Setting Business Goals

Business analysis should articulate the goals of a deployment project. Clear goals help focus design decisions and prevent the project from going astray. Contrasting the business goals with current operations also helps determine design decisions.

Scope

Business requirements should state the scope of the deployment project. Make sure you identify areas that can be solved and avoid open-ended requirements that make the goal either unclear or unreachable. A poorly defined scope can lead to a deployment design that insufficiently addresses business needs or that is extravagant with resources.

Priorities

Prioritize your goals to ensure that the most important aspects of the deployment can be achieved first. Limited resources might require postponement or modification of some goals. For example, large and complex deployments generally require phased implementation of the solution. By stating the priorities, you provide guidance on decisions that might need to be made for your deployment design to be accepted by the stakeholders.

Critical Qualities

Identify areas that are critical to success to allow stakeholders and designers to concentrate on the most important criteria.

Growth Factors

As you set business goals, consider not only the current needs of the organization, but anticipate how these needs might change and grow over extended periods. You do not want a solution that is outdated prematurely.

Safety Margin

The design of your solution is based on assumptions made during this business analysis phase. These assumptions might not be accurate for various reasons, such as insufficient data, errors in judgement, or unanticipated external events. Make sure you plan for a safety margin not only in your business goals but throughout your planning so the solution that you design can handle unexpected events.

Understanding User Needs

Do the research necessary to understand the types of users that the solution targets, their needs, and the expected benefits to them. For example, the following list provides one way to categorize users:

Clearly stating the expected benefits to users helps drive design decisions. For example, here are some benefits that a solution can provide to users:

Developing Operational Requirements

Express operational requirements as a set of functional requirements with straightforward goals. Typically, you create operational specifications for areas such as:

Express operational requirements in measurable terms that all stakeholders can understand. Avoid ambiguous language, such as “adequate end-user response time.” Examples of operational requirements could be the following:

Supporting Existing Usage Patterns

Express existing usage patterns as clearly measurable goals. The following questions can help determine such goals.

Study the users who access your services. Factors such as when users access existing services and for how long are keys to identifying your goals. If your organization’s experience cannot provide these patterns, study the experience of similar organizations.

Understanding Corporate Culture

Requirements analysis should take into account various aspects of corporate culture and politics. Lack of attention to corporate culture can result in a solution that is not well received or is difficult to implement.

Stakeholders

Identify individuals and organizations that have a vested interest in the success of the proposed solution. All stakeholders should actively participate in defining the business goals and requirements. If a stakeholder does not participate or is uninformed of planned changes, the plans could have significant shortcomings. Such a stakeholder could even block the implementation of the deployment.

Standards and Policies

Make sure you understand the standards and policies of the organization requesting the solution. These standards and policies might affect technical aspects of the design, product selection, and methodology of deployment.

One example is the confidentiality of personnel data that might be owned and controlled by the human resources organization or unit managers. Another example would be company procedures for change management. Change management policies could dramatically affect acceptance of a solution and influence the implementation methodology and time table.

Regulatory Requirements

Regulatory requirements vary greatly, depending on the nature of the business. Research and understand any regulatory requirements that might affect the deployment. Many companies and government agencies require compliance with accessibility standards. When deploying global solutions, consider foreign laws and regulations. For example, many European countries have strict controls on storing personal information.

Security

Some goals that you identify might have implicit security issues that should be emphasized. Call out specific security goals essential to the solution. For example:

Site Distribution

The geographic distribution of sites and the bandwidth between the sites can affect design decisions. Additionally, some sites might require local management.

Such geographic considerations can raise the project’s training costs, complexity, and so forth. Clearly state requirements resulting from geographic distribution of sites. Highlight which sites are critical to the design’s success.

Using an Incremental Approach

Often, you view a software solution as a whole, comprehensive system. However, you often achieve deployment of the complete system incrementally by taking measured steps.

When adopting an incremental approach, you typically design a road map that provides milestones leading to the ultimate, comprehensive solution. Additionally, you might have to consider short-term plans for aspects of the comprehensive solution that are deferred for later implementation.

The incremental approach provides these advantages:

Understanding Service Level Agreements

A service level agreement (SLA) specifies minimum performance requirements and, upon failure to meet those requirements, the level and extent of customer support that must be provided. A service level agreement is based on business requirements defined during business analysis, which are later specified as service level requirements during the technical requirements phase. The SLA is signed during project approval, which occurs in the deployment design phase.

You should develop an SLA around areas such as uptime, response time, message delivery time, and disaster recovery. An SLA should account for items such as an overview of the system, the roles and responsibilities of support organizations, how to measure service levels, change requests, and so forth. Identifying your organization’s expectations around system availability is key in determining the scope of an SLA.