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.