Software Requirements: The Requirements Set

This chapter is from the book

Requirements Pattern, A: Succeeding in the Internet Economy

Learn More Buy

This chapter is from the book

This chapter is from the book 

Requirements Pattern, A: Succeeding in the Internet Economy

Learn More Buy

Requirement Organization

The development of any Internet-based application requires the development of different work products that stem from the idea. Each of these work products is needed to build a high-quality Internet-based application. Each of these individual work products follows a process similar to a manufacturing process described in the previous chapter. Community, perspective, and focus are dimensions of the organization, which when working together will develop one or more of these work products.

This process is no different from any other manufacturing process. The perspective is the evolution of any product. The development of any product requires different roles for building each piece of the product. To explain the finer details of the framework and the association between categories, the example of building a house is used below.²

A Quality Home

When a house is being built, the idea (or architectural plan) evolves through perspectives (levels of abstraction from the concept) to produce a deliverable (the home). Each different perspective refines the details until the house is built. Each perspective is paired with a specific individual (or contractor) to build a deliverable that assists in creating the final product (see Table 3.1). The deliverable is built according to the perspective of the responsible individual. Each of these phases evolves from the information gathered and analyzed from the previous phase. Each phase has the perspective of another individual role. Figure 3.5 shows those involved in developing a home. Each individual with his own focus evolves deliverables (work products) through the different perspectives.

Table 3.1 Manufacturing a Home

Figure 3.5 Perspectives and Focus Areas for Building a Quality Home

Skipping a perspective in building the home increases the risk of building a faulty home. No one would want to live in a home they knew had skipped a phase of this process. Instead, inspectors are available at each phase (perspective) to spot possible defects and correct them early in the process (quality gate). The cost of correction after implementation, if possible at all, is too risky and expensive. To further reduce the cost of building a home, specifications or any of the deliverables from each phase can be reused or expanded upon to build other homes.³ This is only doable if the deliverable passed quality inspections for the original product.

The House That Zachman Built

In 1987 while working for IBM, John A. Zachman published a framework for discussing information systems architecture.⁴ He described the analogy between the software development process and the construction and manufacturing processes. This architecture is the basis of the requirements set framework. To understand the requirements set framework, it is important to understand John Zachman's architecture.

Zachman illustrated how the process, deliverables, perspective, and focus are conceptually the same. The process can also conceptually be the same for different business communities (for example, legal, human resources, and shipping). For simplicity, we will focus on software products for this example. The output of software development deliverables correlates to architectural output (see Table 3.2). The table documents the evolution of the software detail and how it is a process similar to construction and manufacturing.

Table 3.2 Software Development Deliverables Compared with Architectural Output

Different Perspectives for Either Process

The roles involved in building a home (see Table 3.3) identify the need for different perspectives. Each individual has a responsibility to concentrate on his particular perspective to ensure the building of a quality end product. As the evolution of the idea to final product occurs, different phases are followed through the different perspectives. Perspectives reflect the areas of responsibility of each role. For example, a designer's perspective is quite different from the owner's perspective; the builder's perspective is different from a designer's. What is important is that the owner's perspective is satisfied in the final product. Though each role has a different perspective, all roles work together as a team to build the quality end product

Table 3.3 Information Technology Community Perspective

the builder's perspective is different from a designer's.⁵ What is important is that the owner's perspective is satisfied in the final product. Though each role has a different perspective, all roles work together as a team to build the quality end product.⁶

The same is true with software development (including Internet-based products). Each phase (see Table 3.3) has a different perspective. Each phase develops another level of detail to build the final quality product. What is important is that the perspective of the "owner" (business executive) is satisfied in the final product.

Different Perspectives for Requirements

Each of the Zachman framework perspectives involved defining requirements and requirement details (see Table 3.4). The first three perspectives are require requirements that are more commonly referred to as "business requirements." The first perspective (planner) identifies the list of what is in and out of scope (primary requirements) as it relates to the initiating requirement (the product concept). The second perspective (owner) defines the requirements and their dependencies (derived requirements) on other requirements. The third perspective (designer) defines the specific details that are essential in defining the requirements and their relationship with other requirements. The details may include additional derived requirements due to the specific interaction between business communities.

Table 3.4 Perspective Requirements

requirements) as it relates to the initiating requirement (the product concept). The second perspective (owner) defines the requirements and their dependencies (derived requirements) on other requirements. The third perspective (designer) defines the specific details that are essential in defining the requirements and their relationship with other requirements. The details may include additional derived requirements due to the specific interaction between business communities.

The fourth perspective (builder) is the break away from the business requirements. These define specific requirements (derived requirements) that need to be satisfied in order to build the solution. These requirements may or may not be captured by the requirements engineer. In some companies, technology specialists such as a database administrator or technical architect may capture these requirements. In truth, these specialists are the suppliers of this perspective's requirements. It is the responsibility of the requirements engineer to ensure that the requirements are elicited, analyzed, specified, validated, and approved (especially high-price items or items that go against corporate standards) and to ensure they are managed.

The fifth perspective (subcontractor) begins the process for the next iteration of the product. These requirements include what metrics or information should be captured in order to judge the success of the product. For Internet applications, requirements may state the need to capture customer feedback, click history, response time, and sales figures. These are requirements geared toward understanding the success of the first iteration and providing valuable information that could foster a change in direction to retain market presence.

The sixth perspective (user) is the implemented product or iteration. Requirements relate more to the next iteration of the product, thus initiating the next cycle, which begins with the planner perspective.

Each business community has the same perspectives; each perspective for each community has a different specification. Each perspective follows the same subprocess to elicit, analyze, specify, validate, and approve the requirements for its community and perspective.

Different Views of the Same House

When building a home, each phase or perspective requires a different focus or view. These views concentrate on a specific area for that perspective. For example, the house requires an architect's view, a plumber's view, an electrician's view, a landscaper's view, and so forth (see Table 3.5). Each has similar deliverables: scope, owner's model, physical model, specifications, components, and the final product. Each deliverable at each perspective level has its own focus. Each focus (see Table 3.5) still has the same architectural perspective. Nothing can be viewed independently! All views and perspectives are important to build a high-quality house. Each focus area must narrow down a concept into finite detail to ensure compliance and quality and to ultimately meet the owner's needs.

Table 3.5 Focuses for Building a Home

Different Focuses of the Same Software Solution

Building software solutions also requires different focuses. In his Information Systems Architecture, John Zachman identified the following areas of focus:⁷

• Who is involved (people/organization/systems)?
• What is it made of (data)?
• Where are things located (network)?
• When do things happen (business events)?
• Why are things done (business policy)?
• How does it function (process)?

Though we are concentrating on the business area of information technology, the same focuses apply to each of the other business communities: business practice, business organization, and business support. Each of the business communities has a deliverable that has "who, what, where, when, why, and how" requirements to capture. They all need to be elicited, analyzed, specified, validated, and approved in order to build the specific deliverable.

The purpose of drawings, models, and other documentation deliverables is to enable the reviewers and those who must act on the deliverables to relate to them and to agree or disagree with the contents. The deliverables, in respect to requirements, are specifications used to validate for quality and to build upon.

Let's walk through the focus (special interest) areas to obtain an understanding of the specifics of each one. Note that each of these focus areas captures the functionality the product must have. This functionality lives with the product through each iteration until either the requirement is no longer needed or the entire product is no longer needed.

The People ("Who") View

This view focuses on associations to the product. The importance is that all the people, departments, organizations, and systems that interface with the product are well documented as to their needs. They trigger action on the part of the product.

The "who" needs include supplying information, accessing information, triggering functionality, and receiving results (such as reports). For example, a customer may submit an order and receive merchandise. The Internal Revenue Service may also be involved by being the recipient of quarterly financial reports. For the book retailer example, the shipping company personnel may have access to the book retailer's system in addition to the book retailer personnel having access to portions of the shipping system. For B2B, both forms of access from opposite systems are documented. In the world of the Internet, businesses, including competitors, are users. This category of requirements may need information such as supplier data.

It is important to also note who should not have access to the product. This observation spawns additional security-related requirements. The most common example in traditional manufacturering is the childproof cap used on medicine bottles. For the book retailer application, requirements could call for a user-initiated security key of the user's specified functionality and information. The objective is to prevent hackers from obtaining valuable customer or company information.

"Who" refers to the product interfaces. At each perspective, the interfaces may evolve into identifying security requirements as to what information they may have access to and what functionality they may perform. At the first perspective, you have a list of who should have access. You have a second list that clearly defines who should not have access. The "should not" list evolves as you refine the requirements through each perspective for specific functionality and information.

The Information ('What") View

This view focuses on the information requirements of the product. For software, this describes all the data needed to fulfill the requirement. For the book retailer and shipping connection, examples are the pickup location (warehouse) and the delivery location (customer site).

"What" represents the data needed by the Internet-based application. Data come in different forms, thanks to multimedia. Data can be textual, video, graphical, animation, and audio, all of which can be transmitted via files or messages across the Internet on cable, telephone, or wireless connections. The information can be distributed to PCs, laptops, televisions, personal digital assistants, and cellular telephones. All of these details are captured as requirements evolve through the different perspectives.

Data or object models are the most common deliverables in defining the "what" requirements. The models are more than just diagrams. A model contains textual information about the contents of the diagram. In fact, the diagram supports the textual description. Data and entity classes can be classified as information models for the purpose of explaining the "what" focus area.

An information model defines the common business vocabulary. Getting concurrence on specific definitions is the challenge of all good modelers. The models and the diagram depict relationships. These relationships define many of the business rules that must be supported. For example, a person cannot place an order without supplying at least one valid credit card number and a valid address. In the United States, the credit card address may be a post office box, but a shipping address must be a street address (a common oversight made by many online shopping sites) if a non–United States Postal Service (USPS) company is used.

Technical information models organize the information for performance for a specific technology. They are a step removed from defining the business. Both the business information model (defined at early perspective levels) and the technical information model are required. The technical model is built from the business model and will change more frequently than the business model. These changes are typically intended to improve performance or to take advantage of new technologies. These technology-related changes rarely affect the business model. However, any changes to the business model must be reflected in the technology model. The business model defines the business; the technology model defines how the business is supported technically. The businesspeople validate the business model, whereas technicians (and requirements engineers) validate the technology model.

In many business information models, audit trails may be left to the technology models. This is not true in the Internet world. When capturing "what" requirements, it is important to include confidential information that will provide audit trails. This requires information about the data that was captured: when and by whom. It must be proven that a transaction took place (especially changes and deletions). This information must be incorporated and approved by the business community.

The Location ('Where") View

"Where," the third focus area, represents the location or networking type of requirement. The "where" requirements, as with the "who" and "what" requirements, evolve through the different perspectives. Unfortunately, many requirements engineers capture this type of information later rather than earlier in the process.

Network engineers must meet the expectations of the different users as well as maintain the network infrastructure for the organization. Their requirement needs may be captured in other focus areas, but they must still take that information and reformulate it into their own models, evolving them into router configurations and other network work products. The information they need to capture includes

• The type of access by user, event, and function. The type of access could be batch file, online access, wireless access, or Internet access. Knowing this information assists in determining the type of communication that is needed to meet the requirement of the user.

• What is needed at each location. This includes what data and how much data will be transmitted from one node to another. How often will the transactions be executed? Are there peak periods? The objective is to determine the load on the network.

• Security requirements for each location. This includes security at the data and function by actor ("who") and access type. For example, a wireless transmission to a mobile telephone may be restricted to only summary information.

The "where" view focuses on connectivity. This entails describing the desired location where the product will be used and who must have access to it. For a stock-trading system, locations may be worldwide. Wireless has added a new dimension to the Internet. Devices such as handheld organizers can connect to the Internet application from anywhere. No longer must a device be physically attached. For the "where" requirements of an Internet application, location pertains to the traffic concentration areas for the customer base and the functions and amount of data they transmit.

The Event ('When") View

This view focuses on timings that trigger action by the product. It identifies when things must or usually occur, for example, the closing of the U.S. stock market at 4 p.m. EST. Can the book retailer accept the order for a next-day delivery request with the shipping company's logistics plan? The shipping company may have rules on what they can pick up late in the day and still be able to deliver to certain locations within a 24-hour period.

There are four basic types of events:

1. Initiated by time (for example, order received past shipper's latest pickup time)

2. Initiated by action from outside the product (for example, order placed for next-day shipment)

3. Conditionally triggered (for example, back-order products arrived at warehouse)

4. Arrival of information (for example, order picked up)

There are different models that can be created to reflect "when" requirements. The first perspective includes lists of the events with a list of associated responses. The events are to be correlated (requirement relationship) with "who" requirements in the detailed perspective, along with a list of conditions and actions the event incurs. When capturing the essential requirement details, the correlations between "what," and "how," and "where" as well as other focus areas have not yet been discussed. The point is that just as with any of the other focus areas, the "when" requirements evolve in detail and level of abstraction through the different perspectives.

The Rule ("Why") View

This view focuses on business rules and policies that must be adhered to when arriving at the solution. Rules are critical to the survival of a corporation. They can never be violated. Rules are defined for both normal and abnormal business circumstances. For example, an automobile can be sold as "new" only once during its life. A stock trader cannot cancel a submitted stock trade (buy) if the other party has already submitted his side (sell) of the transaction. The information about a customer order cannot be displayed if it is marked as secure without a password being supplied by the user.

The Internet has changed the way business is conducted. This means that the current business rules and policies that exist may need to be changed or tweaked or perhaps totally abandoned. This is a new economy based on a new business model that is filled with a new set of business rules. Keeping outdated business rules in place can limit business opportunities on the Net!⁸

Rules define the policies for a particular situation. When the situation in question occurs, it is an obligation that the rule be satisfied. These rules may affect the other focus areas, and these other focus area models must include a correlation to the business rule.

Some rules are defined outside the organization, including governmental (legal, IRS) and others rules dictated by competitors or the culture of the times. For example, state laws may prohibit a car from being sold as new when the mileage exceeds a specific number, which varies from state to state. Another example is the tax applied to the purchase. Is the ship-to or the ship-from tax charged according to the product's or service's value, and is it according to the date of order or the date shipped? This also varies from state to state and from country to country.

Policies that control the processing of the organization are usually defined internally. They define the culture and style of the organization. For example, the business rule for an Internet application for purchasing merchandise may state that the item must be requested from the supplier when the inventory dips below a specific level. Each item in the inventory may have its own specific reorder business rule.

Rules can also be technical in nature. For example, when the transaction reaches a specific level on the network, additional lines, typically reserved for backup situations, will be used to handle short periods of unexpected traffic.

There are five different types of business rules:

1. Constraints: limiting instructions. A person must respond to an end-of-auction notice within three days.

2. Heuristics: characterization instructions. A customer in good credit standing should be notified of sales of similar products that have been purchased by the customer in the past.

3. Computations: calculation instructions. Foreign currency will be calculated by using the value of the currency for the day the item was shipped multiplied by the price of the item.

4. Inference: implied instructions. A customer who charges 35 percent more than his average daily transaction level will be placed on the customer watch list.

5. Timing: conditional instructions. Once a back-ordered item is received in the warehouse, it must be shipped to the next customer in line by the end of the next business day.

Timing is a type of rule associated with or often documented as a "when" requirement. In fact, all the business rules must be associated with other focus-type requirements. They may correlate to "what, how, when, and where" requirements. They may affect community requirements other than those of information technology. It is important during validation to evaluate each business rule for its impact on other requirements.

The Process ("How") View

This view focuses on the workflow of a specific function: the procedure, step by step. For example, an invoice that is 30 days past due requires a secondary notice and placement of the client's name on the delinquent watch list. Alternatively, for the online access to your customized view, one of the process requirements could describe:

1. If an incorrect password is supplied to retrieve secure information, the user will be allowed three opportunities.

2. If after the third opportunity the correct password is not supplied, the secure data will not be displayed.

3. If the user has forgotten his password, he is allowed to select the "secret word" to remind himself of the password.

4. If the user assesses the "secret word," another opportunity to supply a correct password is made available.

5. If the password is correct, the system displays the information.

6. If the password is incorrect, the system notifies the user that he can request a new password.

In our Internet example, the key business processes for the book retailer are

• Order entry: includes presentation and ease of use for the client

• Payment: involves calculating the cost of the product plus any surcharges (taxes and delivery) in the client currency via the acceptable methods (credit card, bank note, and so on)

• Delivery: involves packaging the requested item (virtual or physical) and delivering the goods after the payment has been determined acceptable (but not cleared)

• Inventory management: involves the supply chain

• Settlement: involves the actual conversion for goods and services

Volumetrics

The following rules of thumb depict the average number of functional requirements. This is helpful when you are planning the requirement effort. It is also helpful when taking a first cut at validation to identify whether you have a complete set of requirements for a specific community, perspective, and focus. Again, this is just a rough estimate to raise a potential flag that something may be missing from the requirements set.

• There should be a "how" requirement associated with every "when" requirement.

• There should be five "how" transactions requirements (including object methods) that impact a business entity "what" to support: (1) a create function, (2) a read function, (3) an update function, (4) a delete function, and (5) a list (includes search) function.

• There should be at least one requirement for each cell (category described by community, perspective, and focus).

• There should be a business rule "why" for every relationship between "what" entities or entity classes.

• There should be a "who" associated with every "how," "when," and "where" requirement.

These guidelines pertain to functional requirements. As shown in the next section, functional requirements are only a portion of the requirements set.

Extensions to the Information Systems Architecture

The Zachman framework for Information Systems Architecture ties the perspective, focus, and deliverable together for developing software (see Figure 3.6). To develop a business solution using information technology requires different integrated views and details. The contents of each cell identify possible deliverables for a software development project. This comprises the functional focus. These areas describe what features the Internet product must have and perform.

Figure 3.6 Perspectives Objectives

Additional Focuses

Two additional focuses are required to cover the needed information to build the product, as they constrain the product development decisions. One area describes the constraints that must be applied to the product, and the other the constraints on running the project.⁹ These are called nonfunctional requirements.

1. The product constraint's view documents any restrictions that may affect how the product will be designed. In system engineering terms, these would include the system requirements¹⁰ pertaining to expectations as far as response time, security, and fault tolerance. Design constraints could also include restrictions as to the size of the application. Here they describe the environment and operation of the product. They may be referred to as quality of service (QoS) requirements.

2. The project constraint's view documents any restrictions that may affect the running of the project. This might include the number of resources and time constraints.¹¹ (Restrictions of tools, standards, and formats also fall under the category of project constraints.¹²)

The requirements that fall into these views should be written in a format that meets the same quality characteristics as functional requirements. They evolve through the same perspectives as the product's functional requirements. These additional focus areas include requirements that are crucial to the success of the Internet application.