Chapter 3 Technical Requirements

This chapter discusses some of the processes and procedures that occur during technical requirements analysis.

Technical requirements analysis begins with the business requirements documents created during the business analysis phase. Using the business requirements as a basis, you perform the following steps:

The use cases are also the basis for designing the logical architecture in the design phase. The logical architecture and the system requirements together form the deployment scenario, which later is an input to the deployment design phase.

The following figure shows the technical requirements phase in relation to the business analysis, logical design, and deployment design phases.

As with business analysis, no magic formula for technical requirements analysis exists that generates the usage analysis, use cases, and system requirements. Technical requirements analysis requires an understanding of the business domain, business objectives, and the underlying system technology.

Usage Analysis

Usage analysis involves identifying the various users of the deployment you are designing and determining the usage patterns for those users. The information you gather provides an idea of the expected load conditions and is later used to determine performance requirements and other system requirements. Usage analysis information is also useful when assigning weights to use cases, as described in Use Cases.

During usage analysis you should interview users whenever possible, research existing data on usage patterns, and also interview builders and administrators of previous systems. The following table lists topics to consider when performing a usage analysis.

Table 3-1 Usage Analysis Topics
Topic	Description
Number and type of users	Identify how many users your deployment must support, and categorize those users, if necessary. For example: A Business to Customer deployment might have a large number of visitors, but only a small number of users who register and engage in business transactions. A Business to Employee deployment typically has to accommodate each employee, but some might need access from outside the corporate network. In a Business to Employee deployment, managers might need authorization to areas that regular employees should not be able to access.
Active and inactive users	Identify the usage patterns and ratios of active and inactive users. Active users are those users logged into the system and are interacting with the system’s components. Inactive users can be users who are not logged in or users who log in but do not interact with the system’s components.
Administrative users	Identify users that access the deployed system to monitor, update, and support the deployment. Determine any specific administrative usage patterns that might affect system requirements. For example, administration of the deployment from outside the firewall.
Usage patterns	Identify how users of various types will access the system and provide targets for expected usage. For example: Are there peak times when usage spikes? What are the normal business hours? Are users distributed globally? What is the expected duration of user connectivity?
User growth	Determine if the size of the user base is fixed or if the deployment expects growth in the number of users. If the user base is expected to grow, try to create reasonable projections of the growth.
User transactions	Identify the type of user transactions that must be supported. These user transactions can be translated into use cases. For example: What tasks will users perform? When users log in, do they remain logged in? Or do they typically perform a few tasks and log out? Will there be significant collaboration between users that requires common calendars, web-conferences, and deployment of internal web pages?
User studies and statistical data	Use pre-existing user studies and other sources to determine patterns of user behavior. Often, enterprises or industry organizations have user research studies from which you can extract useful information about users. Log files for existing applications might contain statistical data useful in making estimates for a system.

Use Cases

Use cases model typical user interaction with the deployment you are designing, describing the complete flow of an operation from the perspective of an end user. Prioritizing design around a complete set of use cases ensures a continual focus on the delivery of expected functionality.

Each use case can include quantitative estimates about user behavior, which you can later use to determine system requirements for performance, availability, and other qualities of service. Use cases are also the starting point for designing the logical architecture, as described in Chapter 4, "Designing the Logical Architecture".

You often assign relative weights to use cases, with the highest weighted use cases representing the most common user tasks. The weighting of use cases helps to determine system requirements.

System Requirements

System requirements describe the quality of service a deployed system must provide to meet the business requirements arrived at through business analysis. You typically use the usage analysis and use cases together with the business requirements to derive system requirements.

The following table lists system qualities that are often used to specify system requirements.

Table 3-2 System Qualities Affecting Deployment Design
System Qualities	Description
Availability	A measure of how often a system’s resources and services are accessible to end users, often expressed as the uptime of a system.
Latent Capacity	The ability of a system to handle unusual peak load usage without additional resources.
Performance	The measurement of response time and latency with respect to user load conditions.
Scalability	The ability to add capacity (and users) to a deployed system over time. Scalability typically involves adding resources to the system but should not require changes to the deployment architecture.
Security	A complex combination of factors that describe the integrity of a system and its users. Security includes authentication and authorization of users as well as the secure transport of information.
Serviceability	The ease by which a deployed system can be administered, including tasks such as monitoring the system, repairing problems that arise, and upgrading hardware and software components.

The system qualities that affect deployment design are closely interrelated. Requirements for one system quality might affect the requirements and design for other system qualities. For example, higher levels of security might affect performance, which in turn might affect availability. Adding additional servers to address availability issues might affect maintenance costs (serviceability).

Understanding how system qualities are interrelated and the trade-offs that must be made is the key to designing a system that successfully satisfies both business requirements and business constraints.

The following sections take a closer look at the system qualities that affect deployment design, providing guidance on factors to consider when formulating system requirements. There is also a section on service level requirements, which are a special set of system requirements used to create service level agreements.

Availability

Availability is a way to specify the uptime of a deployed system. It is typically measured as the percentage of time that the system is accessible to users. The time the system is not accessible (downtime) can be due to the failure of hardware, software, the network, or any other factor (such as loss of power) that causes the system to be down. In most cases, scheduled time for service (maintenance and upgrades) is not considered downtime.

Typically you measure availability by the number of “nines” you can achieve. For example, 99% availability is two nines. Specifying additional nines significantly affects the deployment design for availability. The following table displays the result of adding additional nines of availability to a system that is running 24x7 year-round, which is a total of 8,760 hours.

Table 3-3 Downtime for a System Running Year-round (8,760 hours)
Nines	Percentage Available	Downtime
Two	99%	88 hours
Three	99.9%	9 hours
Four	99.99%	45 minutes
Five	99.999%	5 minutes

Fault Tolerant Systems

Availability requirements of four or five nines typically require a system that is fault tolerant. A fault tolerant system must be able to continue service even during a hardware or software failure. Typically, fault tolerance is achieved by redundancy in both hardware (such as CPUs, memory, and network devices) and software providing key services.

A single point of failure is a hardware or software component that is not backed up by redundant components. The failure of this component results in the loss of service for the system. When designing a fault tolerant system, you must identify potential single points of failure and eliminate them.

Fault tolerant systems can be expensive to implement and maintain. Make sure you understand the nature of the business requirements for availability and consider the strategies and costs of availability solutions that meet those requirements.

Sun Cluster 3.1 4/04

Sun Cluster 3.1 4/04 software provides a high availability solution for deployments that require a highly available, fault tolerant system. Sun Cluster 3.1 4/04 couples servers, storage, and other network resources to provide a failover process that is achieved quickly and with little interruption of services to the users of the system.

Prioritizing Availability of Services

From a user perspective, availability often applies more to each service provided by the deployed system rather than the availability of the entire system. For example, if instant messaging services become unavailable, there usually is little or no impact on the availability of other services. However, the availability of services upon which many other services depend (such as Directory Server) has a wider impact on the system.

It is helpful to list availability needs according to an ordered set of priorities. The following table prioritizes the availability of different types of services.

Table 3-4 Prioritizing Availability of Services
Priority	Service Type	Description
1	Strategic	Services essential to operation. For example, many services depend on Directory Server.
2	Mission critical	Services that must be available at peak load. For example, database services to applications defined as mission critical.
3	Must be available	Services that must be available, but can be available at reduced performance. For example, Messaging Server availability might not be critical in some business environments.
4	Can be postponed	Services that must be available within a given time period. For example, Instant Messaging availability might not be essential in some business environments.
5	Optional	Services that can be postponed indefinitely.

For information on various design strategies to implement availability requirements, refer to Sizing for Availability.

Latent Capacity

Latent capacity is the ability of a deployment to handle unusual peak load usage without the addition of resources. Typically, you do not specify system requirements directly around latent capacity, but this system quality is a factor in determining availability, performance, and scalability requirements.

Performance

Determining performance requirements is the process of translating business requirement expectations on performance into system requirements. The business requirement typically expresses performance in non-technical terms that specify response time. For example, a business requirement for web-based access might state the following:

Starting with this business requirement, examine all use cases to determine how to express this requirement at a system level. Take into account the user load conditions, as determined during usage analysis. Express the performance requirement for each use case in terms of response time under specified load conditions or response time plus throughput. You might also specify the allowable number of errors.

The performance requirements are closely related to availability requirements (how failover impacts performance) and latent capacity (how much capacity there is to handle unusual peak loads).

Scalability

Scalability describes the ability to add capacity and users to a system over time. Scalability usually requires the addition of resources, but should not require changes in the design of the deployment architecture or loss of service due to the time required to add additional resources.

As with availability, scalability applies more to individual services provided by a system rather than to the entire system. However, for services upon which other services depend, such as Directory Server, scalability can have system-wide impact.

You do not necessarily specify scalability requirements with system requirements unless projected growth of the deployment is clearly stated in the business requirements. During the deployment design phase, the deployment architecture should account for scaling the system even if you do not specify scalability requirements.

Determining scalability requirements is not an exact science. Estimating the growth of a system involves projections, estimates, and guesses that might not be fulfilled. Here are three keys to building a scalable system.

Table 3-5 Scalability Considerations
Topic	Description
Usage analysis	Understand the usage patterns of the current (or projected) user base by studying existing data. In the absence of current data, analyze industry data or market estimates.
Design for reasonable maximum scale	Design with a goal towards the maximum required scale for both known and possible demand. Often, this is a 24 month estimate based on performance evaluation of the existing user load and reasonable expectations of future load. The time period for the estimate depends largely on the reliability of projections.
Set appropriate milestones	Implement the deployment design in increments to meet short term requirements with a buffer to allow for unexpected growth. Set milestones for adding system resources. For example: Capital acquisition Such as quarterly or yearly Hardware lead time For example, one to six weeks Buffer (10% to 100%, depending on growth expectations)
Incorporate emerging technology	Understand emerging technology, such as faster CPUs and Web servers, and how that can affect the performance of the underlying architecture.

Security Requirements

Security is the quality of a system that affects the integrity of the system and its users, including the integrity of the user’s transactions and associated data. As with other system requirements, the business requirements, usage analysis, and use cases drive the analysis for security requirements.

Authentication, authorization, and identity management, together with an enterprise-wide policy for enforcement of sound security practices, provide confidence that transactions are secure and that data stored on a site cannot be compromised.

Authentication

Authentication is how users identify themselves to a system and also how the system identifies itself to the users. Authentication is a key part of the system integrity that protects the system from unauthorized access.

You should understand user requirements to select the best authentication scheme for the deployment. For example, a Business to Customer deployment might allow users to register using a username/password combination. These users rely on a server certificate issued by a trusted certificate authority, such as VeriSign, to authenticate the selling system over a secure transport.

A Business to Employee deployment might instead provision employees from an existing user base. From within the company firewall, access is allowed to known secure locations. From outside the firewall, access to secure locations is through proxies that perform the authentication and redirection inside the company firewall.

Authorization

Authorization is the recognition of specific privileges to authenticated users. For example, users with administrator authority have access to parts of a deployed system that are inaccessible to ordinary users.

Authorization also plays a role in deployments implementing single sign-on (SSO). Authenticated users to a deployment can have access to multiple services without having to sign on more than once.

Identity Management


Note	Security requirements affecting the integrity of the infrastructure (for example firewall software and network design) are typically not considered during system requirements analysis. Instead, these security issues come into play during deployment design.

A deployed system must have a way to add, modify, or delete users who will be accessing system services. Depending on your needs, identity management can be accomplished by an authorized administrator or by the users themselves by means of a delegated administration interface. Deployments for medium or large enterprise should consider a delegated administration design. Delegated administration improves customer satisfaction and reduces the costs of system administration.

Serviceability Requirements

Serviceability is the ease by which a deployed system can be administered, including tasks such as monitoring the system, repairing problems that arise, and upgrading hardware and software components.

When planning requirements for serviceability, consider the topics listed in the following table.

Table 3-6 Topics for Serviceability Requirements
Topic	Description
Downtime Planning	Identify maintenance tasks that require specific services to be unavailable or partially unavailable. Some maintenance and upgrades can occur seamlessly to users, while others require interruption of service. When possible, schedule with users those maintenance activities that require downtime, allowing the users to plan for the downtime.
Usage Patterns	Identify the usage patterns of a deployment to determine windows of opportunity for maintenance. For example, on systems where peak usage is normally during normal business hours, the windows of opportunity occur in the evening or weekends. For geographically distributed systems, identifying these times can be more challenging.
Availability	Serviceability is often a reflection of your availability design. Strategies for minimizing downtime for maintenance and upgrades revolve around your availability strategy. Systems that require a high degree of availability have smaller windows for maintenance, upgrades, and repair. Strategies for handling availability requirements affect how you handle maintenance and upgrades. For example, on systems that are distributed geographically, servicing can depend on the ability to route workloads to remote servers during maintenance periods. Also, systems requiring a high degree of availability might require more sophisticated solutions that automate restarting of systems with little human intervention.
Diagnostics and Monitoring	You can improve the stability of a system by regularly running diagnostic and monitoring tools to identify problem areas. This can avoid problems before they occur, help balance workloads according to availability strategies, and improve planning for maintenance and downtime.

Service Level Requirements

Service level requirements are a set of system requirements that specify the conditions under which customer support must be provided. Service level requirements are the basis for service level agreements, which are typically signed during project approval.

As with system requirements, service level requirements derive from business requirements and represent a kind of guarantee to the customer about the overall system quality that the deployment must meet. Because the service level agreement is a contract between you and the customer, there should be no ambiguity in the specification of service level requirements. The service level requirements define exactly under what conditions the requirements are tested and precisely what constitutes failure to meet the requirements.

Previous Contents Next
Sun Java Enterprise System Deployment Planning White Paper