During the business analysis phase of the solution life cycle you define business goals by analyzing a business problem and identifying the business requirements and business constraints to meet that goal.
This chapter contains the following sections:
Business analysis starts with stating the business goals. You then analyze the business problems you must solve and identify the business requirements that must be met to achieve the business goals. Consider also any business constraints that limit your ability to achieve the goals. The analysis of business requirements and constraints results in a set of business requirements documents.
You use the resulting set of business requirements documents as a basis for deriving technical requirements in the technical requirements phase. Throughout the solution life cycle, you measure the success of your deployment planning and ultimately the success of your solution according to the analysis performed in the business analysis phase.
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.
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.
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.
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.
Identify areas that are critical to success to allow stakeholders and designers to concentrate on the most important criteria.
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.
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.
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:
Current employees only
Current and previous employees
Clearly stating the expected benefits to users helps drive design decisions. For example, here are some benefits that a solution can provide to users:
Remote access to company resources
Simplification of daily tasks
Sharing of resources by remote teams
Self-administration by end-users
Express operational requirements as a set of functional requirements with straightforward goals. Typically, you create operational specifications for areas such as:
Reduced response time
Availability and uptime
Reduced error rate
Information archival and retention
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:
Ability to restore services within 10 minutes of an outage
Ability to replay the last 48 hours of inbound message delivery
Online transactions completed within 60 seconds during peak periods
End-user authentication completed within four seconds during peak periods
Express existing usage patterns as clearly measurable goals. The following questions can help determine such goals.
How are current services utilized?
What are the usage patterns (for example, sporadic, frequent, or heavy usage)?
To which sites do your users typically connect?
What size messages do users commonly send?
How many transactions do users typically complete per day or per hour?
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.
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.
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.
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 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.
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:
Authorized access to proprietary information
Role-based access to confidential information
Secure communication between remote locations
Invocation of remote applications on local systems
Secure transactions with third-party businesses and organizations
Enforcement of security policies
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.
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:
You can adapt to requirement changes due to business growth.
You can leverage the existing infrastructure as you transition to your ultimate deployment implementation.
You can accommodate capital expenditure requirements.
You can leverage a small supply of human resources.
You can allow for partnership possibilities.
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.
Business constraints play a significant role in determining the nature of a deployment project. One key to successful deployment design is finding the optimal way to meet business requirements within known business constraints. The business constraints can be fiscal limitations, physical limitations (for example, network capacity), time limitations (for example, completion before significant events such as the next annual meeting), or any other limitation you anticipate as a factor that affects the achievement of the business goal.
This section describes several factors to consider when defining business constraints.
Typically, a deployment project replaces or supplements existing software infrastructure and data. Any new solution must be able to migrate data and procedures from the existing infrastructure to the new solution, often retaining interoperability with existing applications. An analysis of the current infrastructure is necessary to determine the extent migration issues play into the proposed solution.
The schedule for implementation of a solution can affect design decisions. Aggressive schedules might result in scaling back of goals, changing priorities, or adopting an incremental solution approach. Within a schedule, significant milestones might exist that deserve consideration as well. Milestones can be set by internal events such as scheduled service rollouts or external events such as the opening date of a school semester.
Most deployment projects must adhere to a budget. Considering the cost of building the proposed solution and the resources required to maintain the solution over a specific lifetime including the following:
Existing hardware and network infrastructure. Reliance on existing infrastructure can affect the design of a system.
Development resources needed to implement the solution. Limited development resources, including hardware, software, and human resources, might suggest incremental deployment. You might have to reuse the same resources or development teams for each incremental phase you implement.
Maintenance, administration, and support. Analyze the resources available to administer, maintain, and support users on the system. Limited resources might impact design decisions.
In addition to maintenance, administration, and support, analyze other factors that affect the cost of ownership. Hardware and software upgrades might be necessary, the impact of the solution on the power grid, telecommunications cost, and other factors influence out-of-pocket expenses. Service level agreements specifying availability levels for the solution also affect the cost of ownership by requiring increased redundancy.
The implementation of a solution should provide a return on the investment into the solution. Analysis of return on investment typically involves measuring the financial benefits gained from the expenditure of capital.
Estimating the financial benefits of a solution involves a careful analysis of the goals to be achieved in comparison with alternate ways of achieving those goals and with the cost of doing nothing at all.