Planning What to Build

How do stakeholders and the project team reach a common understanding of what to build? Most often, what to build is embodied in requirements, diagrams, and designs. The means and timing of what to define varies widely. Rapid development approaches (e.g., eXtreme programming^[1] and MSF for Agile Software Development) use a well-structured build process to incrementally identify, build, test, and deploy solution features and function (i.e., define a little, build a little). At the other end of the spectrum, more formal build approaches thoroughly plan and verify what needs to be done before proceeding with solutions development. Both ends of the spectrum and everything in between have merit. Which approach to use is up to the stakeholders and project team in deciding which one best fits their solutions delivery philosophy and project constraints.

^[1] K. Beck, eXtreme Programming Explained: Embrace Change (Reading, MA: Addison-Wesley, 2000).

For the purposes of this book, the following sections attempt to take an approach-neutral view of planning what to build.

Decomposing and Refining Requirements

Lead Advocacy Group: Architecture

Requirements iteratively gathered during planning further define and refine a solution described by high-level requirements gathered during an Envision Track. They collectively form a detailed description of a solution. As with high-level requirements, detailed requirements address various domains such as business, end users, operations, and systems requirements. They include specifying a solution's behavior, how it interacts with its environment (be it other solutions, users, or administrators), features, functions, and expected operational characteristics (e.g., availability).

How Much Specificity Is Needed?

Requirements are costly to gather and maintain. Especially because they often change before a team acts on them. This is caused in part by changes in the business environment, changes in technology, and changes in project constraints. Compounding that, what are stated as requirements sometimes end up not being what is expected. Therefore, a team should determine what requirements should be collected and when.

Keep in mind that the purpose of requirements is to sufficiently, consistently, and clearly describe and understand a solution. Therefore, a team should gather the fewest requirements necessary to achieve that purpose. This presents a challenge in determining the amount and understanding how the blend of team experience levels and abilities influences that amount.

Often, more experienced and skilled team members require less specificity. Conversely, team members with less experience and skill often require more specificity. The level of specificity is also influenced by tools and processes used to gather the requirements.

Qualities of Service

As mentioned earlier, a significant source of requirements is defining expected operational characteristics of a solution, commonly called qualities of service (QoS). For example, an availability requirement is defined as a solution shall provide service 99.999 percent of the time (also referred to as achieving five 9s). Another example is a regulatory requirement defined as a solution shall comply with HIPAA transactions standards.^[2]

^[2] Health Insurance Portability and Accountability Act of 1996 (HIPAA), Public Law 104191, 104th Congress (August 21, 1996).

QoS are not a new concept. They are sometimes referred to as nonfunctional requirements and informally referred to as the "ilities" because so many of them end that way (e.g., maintainability). QoS are commonly found within a Service Level Agreement (SLA). Because providing high QoS in all areas is often prohibitively costly, a project team and the stakeholders need to come to an agreement on what is necessary. Often an organization will be able to provide a basic level of QoS through good design principles.

Tables 8-2 through 8-5 provide some common and emerging QoS to consider for a solution and its components.^[3] Keep in mind that not all QoS are relevant to all solutions.

^[3] Sam Guckenheimer, Software Engineering with Microsoft Visual Studio Team System (Upper Saddle River, NJ: Addison-Wesley Professional, 2006), 6771.

Table 8-2. Performance-Oriented Qualities of Service

Performance
Responsiveness	Allowable amount of delay when responding to an action, call, or event
Concurrency	Ability to perform well when operated concurrently with other aspects of a solution and with its environment
Efficiency	Capability to provide appropriate performance, relative to the resources used, under stated conditions
Fault tolerance	Capability to maintain a specified level of performance irrespective of faults or of infringement of system resources
Scalability	Ability to handle simultaneous operational load
Extensibility	Ability to extend a solution without significant rework

Table 8-3. Trustworthiness-Oriented Qualities of Service

Trustworthiness
Security	Ability to prevent access and disruption by unauthorized users, viruses, worms, spyware, and other agents
Privacy	Ability to prevent unauthorized access or viewing of data

Table 8-4. User Experience-Oriented Qualities of Service

User Experience
Accessibility	Extent to which individuals with disabilities have access to and use of information and data that is comparable to the access to and use by individuals without disabilities
Attractiveness	Measure of visual appeal to users
Compatibility	Conformance to conventions and expectations
Discoverability	Ability of a user to find and learn features of a solution
Ease of use	Cognitive efficiency with which a user can perform desired tasks
Localizability	Ability to be adapted to conform to the linguistic, cultural, and conventional needs and expectations of a specific group of users

Table 8-5. Manageability-Oriented Qualities of Service

Manageability
Availability	Degree to which it is operational and accessible when required for use. Often expressed as a probability
Reliability	Capability to maintain a specified level of performance when used under specified conditions, commonly stated as mean time between failures (MTBF)
Installability and uninstallability	Capability to be installed in a specific environment and uninstalled without altering the environment's initial state
Maintainability	Ease of modification to correct faults, improve performance or other attributes, or adapt to a changed environment
Monitorability	Extent to which health and operational data are automatically collected while operating
Operability	Extent to which a solution is controlled automatically while operating
Portability	Capability to be transferred from one environment to another
Recoverability	Capability to reestablish a specified level of performance and recover the data directly affected in the case of a failure
Testability	Degree to which the solution facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met
Supportability	Extent to which operational problems are corrected
Reusability	Ability to repurpose solution components with little rework
Conformance	Adherence to applicable rules, regulations, policies, and standards
Interoperability	Capability to interact with other solutions in the environment

Prioritizing Requirements

In support of trade-off decision making and forming a versioned release strategy, a team needs a means to prioritize requirements (and features). There are many good approaches to prioritizing requirements.

A commonly used, simple approach is to sort the requirements into three categories: must have, should have, and nice to have. The must-have category contains requirements that are essential to a solution. Stakeholders, customers, and users would be dissatisfied if these requirements were not reflected in the delivered solution. The should-have category contains requirements that, although not critical to the success of a solution, have a compelling motivation to be in a solution. Stakeholders, customers, and users would not be pleased if these requirements were not reflected in the delivered solution. The nice-to-have category contains requirements that, although not necessary, would increase user experience and customer satisfaction. Another similar approach commonly used is referred to as MoSCoW (Must-, Should-, Could-, and Won't-have requirements and features).

Another more systematic approach to prioritizing requirements is to use Kano Analysis.^[4] Kano Analysis purports customer satisfaction is related to customer expectations surrounding the performance and functional completeness of a solution. This relationship is usually depicted as shown in Figure 8-2.

^[4] David Walden, "Kano's Methods for Understanding Customer-Defined Quality: Introduction to Kano's Methods," Center for Quality Management Journal 2, no. 4 (Fall 1993), 128.

Figure 8-2. Kano Analysis diagram

The horizontal axis indicates how much the delivered solution meets customer expectations. The vertical axis indicates customer satisfaction. The three graphed lines convey three requirements categories with different behaviors relating customer satisfaction with customer expectations:

• Dissatisfiers Expected requirements that when absent in a solution generate significant dissatisfaction whereas their presence generates a diminishing dissatisfaction toward a neutral feeling

• Satisfiers Requirements that generate proportional satisfaction with the quality and quantity of what is delivered

• Delighters Unanticipated requirements that when present in a solution generate significant satisfaction whereas their absence is acceptable and therefore does not generate dissatisfaction

Following this method, a team better understands customer satisfaction as related to the presence and absence of requirements and features. As such, when gathering requirements, make sure to ask the respondents about how they feel about degrees of delivering on requirements (i.e., from not delivering on the requirement through moderately delivering up through overdelivering on the requirement). The key is to find where the optimal balance between requirement delivery and customer satisfaction is.

The Kano Analysis diagram can also be used to communicate graphically the expected portions of delighters, satisfiers, and dissastisfiers in each iteration and in each release. As depicted in Figure 8-3, each iteration encompasses the indicated proportions of three requirements categories. As also depicted, the release is the expected proportion for the releasesidentified as the minimum acceptable level.

Figure 8-3. Example of managing iterations using the Kano Analysis diagram

Documenting Requirements in a Functional Specification (Deliverable)

Lead Advocacy Group: Product Management

Part of forming a shared vision is presenting the requirements in a form that all team members are able sufficiently, consistently, and clearly to understand for a solution. This often involves a detailed description, as viewed from a user perspective, of what a solution will look like and how it will behave. With increasing usage of tools to retain and present this information, a growing trend is for teams not to capture this information in a physical document called a functional specification. Rather, the constructs of a functional specification are contained within a combination of tools and other documents.

A functional specification represents a detailed description of a solution, detailed usage scenarios, and design goals and contains detailed requirements specifying its behavior and how it interacts with its environment (be it other solutions, users, or administrators). Requirements cover all aspects of a solution and often come from various domains such as business, end users, operations, and systems requirements.

Because the principles and underpinnings of a functional specification remain valid, it is up to the team to decide whether a physical document is needed. Beyond describing a solution, a functional specification serves many purposes:

• A contract between the team and stakeholders on what will be delivered

• A basis for estimating work

• A common reference point to synchronize the whole team

• A logical way to break down the problem and modularize a solution

• A path and structure to use for planning, scheduling, and building a solution

A functional specification is the basis for building the master project plan and schedule as well as a solution design. As such, once baselined, a functional specification should be changed only through change control.