Back Up Next

Chapter 7: Analyzing Business Requirements

Certification Objectives. 2

Defining Total Cost of Ownership. 3

How TCO Works. 3

People, Process, and Technology. 4

Costs. 4

Scope of Total Cost of Ownership. 7

TCO and IT Life Cycles. 8

TCO in the Enterprise. 10

The Microsoft TCO Spreadsheet Tool 10

Exercise 7-1: Identifying Costs. 12

Establishing Business Requirements. 13

From the Classroom.. 13

Establishing the Type of Problem to be Solved. 19

Establishing and Defining Customer Quality Requirements. 19

Minimizing Total Cost of Ownership. 20

Increasing the Return on Investment (ROI) of the Solution. 20

Analyzing the Current Platform and Infrastructure. 20

Incorporating Planned Platform and Infrastructure into the Solution. 22

Analyzing the Impact of Technology Migration. 22

Planning Physical Requirements for the Solution. 23

Identifying Organizational Constraints. 23

Establishing the Schedule for Implementation of the Solution. 25

Identifying the Audience for the Solution. 25

Exercise 7-2: Identifying Requirements. 25

Certification Summary. 26

Two-Minute Drill 27

Answers to Exercise 7-1: Identifying Costs. 29

Answers to Exercise 7-2: Identifying Requirements. 30

 

Certification Objectives

·       Understanding and Minimizing the Total Cost of Ownership

·       Analyzing the Extent of a Business Requirement

Continual improvement of IT services while simultaneously reducing IT costs are conflicting goals. Total Cost of Ownership (TCO) is the process of creating a set of repeatable tasks tailored for a specific organization. These tasks produce the analytical results that suggest areas for improvement. It is then possible to track the resulting change.

Microsoft and Interpose, Inc., a Florida organization that became part of the Gartner Group, developed a TCO methodology that maps to the Microsoft Solutions Framework. This chapter explains the Microsoft-Interpose TCO Model and discusses the practical application of TCO.

Business requirements are the foundation of analysis. The requirements are the primary communication device between the business area experts and the technical development team. Business requirements are transformed into a set of technical specifications. These specifications are influenced by the technical architecture of the target platform but must retain the intent of the business requirements. This chapter describes the gathering of business requirements.

Total Cost of Ownership (TCO) Model

Several TCO models exist with varying degrees of success. The Microsoft-Interpose model is simple, yet complex enough to support more precise analytical conclusions. Although this model is flexible, a consistent application of the principles must be followed with a high degree of discipline. This strict discipline is necessary to get the most benefit from the model.

Defining Total Cost of Ownership

Total Cost of Ownership (TCO) is the dollar amount of expenses and depreciated costs invested by an organization for each IT asset. Examples of IT assets are a workstation on the network, an operating system, a printer, and a communication device such as a router or hub.

How TCO Works

The implementation of TCO involves creating a baseline set of data, recognizing the issues that the analyzed data represents, taking actions on those issues, and then measuring progress toward resolving the issues.

Creating a Baseline

An organization must first mark where they began. Some organizations may not know what IT assets they have, how the IT assets are distributed, or the true costs of each asset. There will be a set of tasks that an organization must accomplish but the way the organization performs the tasks must be documented to create a repeatable process for the next iteration. The tradeoffs and decisions made must be documented at each step. Once the baseline is created, the results may be compared to industry averages.

Industry averages for the TCO model were collected from 120 different organizations. Although immature, these averages (called metrics) may be used to make rough comparisons between the industry TCO figures and a specific organization’s figures.

Recognizing Problems

Once a set of TCO metrics has been collected, the data may be analyzed and compared to the industry averages and to previous TCO metrics of the organization. This analysis and comparison may indicate issues that need further investigation. If an issue is determined to be a problem, then a resolution may be proposed but this resolution must consider the risks and the impact of the resolution on the IT organization.

Change Validation

Once a resolution has been implemented, the metrics must be re-collected and compared to the previous set of metrics to determine the amount of change that the organization accomplished. Ideally, the resolutions implemented by the organization should result in positive changes.

People, Process, and Technology

People, process, and technology are interrelated parts of a comprehensive view of the TCO model. Balancing the proportions of water, lemon juice, and sugar makes good lemonade. Too much sugar and the drink is too sweet; too much lemon juice and the drink becomes too sour. A good IT department consists of a balanced mix of people, process, and technology. Some organizations attempt to buy their way into enhanced information technology maturity by purchasing the latest and greatest technology. The introduction of new technology by itself may have a detrimental impact.  Microsoft endorses not only technology enhancements but also improvements in the information technology processes and upgrades in IT staff’s technical skills.

Microsoft attempts to assist their customers’ improvement efforts by offering enhanced technology and by attempting to support their customers in creating successes with that technology. Microsoft does this by making various forms of training available to the implementers of their technologies. The certification programs enable organizations to distinguish individuals who are successful with Microsoft technology. Microsoft also offers consulting services, an elevated support tier, and partnerships with other consulting organizations that have been effective in implementing Microsoft’s technologies.

Costs

The Microsoft-Interpose TCO Model identifies seven categories of costs; five are considered direct IT costs and two are indirect IT costs.

Direct Costs

Direct costs are predictable costs such as scheduled replenishments of supplies such as printer paper or diskettes. Another direct cost is the scheduled upgrade of desktop computer hardware. These costs are reflected in a periodic IT budget and, because they are included in an IT spending plan, are identified as direct costs.

Some IT expenditures are not planned. One example is the replacement of a failed hard disk. Although the replacement was not planned and therefore the cost was not budgeted, this is still clearly an IT expense and would be categorized in one of the four direct categories.

The differentiation between direct and indirect categories highlights costs that have been buried in the costs of business departments that do not report any IT costs.

Hardware and Software Costs

This includes all capital expenditures such as costs to lease and depreciation on new computers or network equipment and upgrades to existing equipment. Also included are expensed software and software upgrades.

Management Costs

This category includes all administration costs for the network, computers, shared disk drives, CD-ROM banks, and the labor costs for the staff to manage this equipment. Any travel expenses incurred by IT support personnel are also included in this category.

Development Costs

Systems application development, testing, documentation, and training are grouped in this category. Also included are the costs to tailor shrink-wrapped software for the organization and to update the documentation and training to reflect the tailoring.

Support Costs

These are costs associated with the help desk, all support contracts, purchasing administration costs, and personnel management administration costs. IT supplies such as diskettes, CRT wipes, and ergonomic accommodations are also included here.

Communication Costs

Access charges and leased-line costs are included in this category. Just like individuals, businesses must pay telephone companies and long distance carriers fees to install communication lines. After the necessary hardware is installed, monthly usage fees are normally billed to the organization. Although modems have become a standard part of a desktop computer, some organizations may categorize the cost of modems under communication costs.

Indirect Costs

This category includes costs not included in an IT budget. These costs are hidden in the expenses of the business departments of the organization. The business departments, also called user communities, are the parts of an organization that use IT services. Although these costs may add up to significant dollar amounts, sometimes, detective work is needed to account for them because they may not be obvious. User interviews and review of help-desk logs may reveal IT costs not previously detected. Examples of these hidden costs are discussed in the appropriate category descriptions.

End-User Costs

This category takes into account the time spent by end users helping their co-workers figure out how to do some task on the computer or solve a computer-related problem. For example, the time spent changing a screensaver or adding desktop options are also included in this category. The cost of labor to recover a user’s computer after they deleted the registry database or io.sys is also included, for example.

I have experienced variations on the theme of indirect end-user costs. In one organization the user community did applications development in an effort to develop solutions in a timely manner. Unfortunately, the users discovered it was difficult to do the job they were hired to do in addition to the applications development role they had taken upon themselves. Although these individuals completed the application and the organization used it for five years, the application had numerous issues. It had not been tested thoroughly, the application was rarely enhanced, and the hardware/software platform had to be carefully preserved to allow the application to continue to execute. In this situation, there were many indirect IT costs that were never understood by the organization and the individuals paid a steep personal price to implement the application.

Not included in this category are the costs of end-users surfing the web or playing computer games.

Downtime Costs

The expense of lost productivity because the network went down is accounted for in this category. The costs of paying wages for time spent without adding value to the organization may be quantified. Perhaps the business community had to put in paid overtime to catch up after an unplanned network crash.

Also included in this category are the costs for unproductive time due to the network being down for planned maintenance. Most organizations attempt to schedule maintenance activities during weekend or off- hours to minimize this cost. Of course, if the organization works 7 days a week, 24 hours a day, this cost may not be completely avoidable.

Scope of Total Cost of Ownership

The Microsoft-Interpose TCO model, applies only to the client/server world and client/server costs. The mainframe and all costs associated with it are excluded. This is no doubt because Microsoft is not in the business of writing software for the mainframe environment. Microsoft realizes that as components become increasingly more distributed the difficulty in accurately measuring IT costs increases. Forecasting and change control then become almost impossible.

Also excluded are the costs or benefits resulting from a change in end-user productivity because of a change in the user’s IT environment. Changes in the expense of conducting business are not included because of the difficulty of clearly relating the change to an IT action. The IT change may have served only as a catalyst for the impending business change, forcing the impact on the business to happen sooner rather than later.

The TCO model is based upon three assumptions:

1.     Three-year straight-line depreciation is used for hardware.

2.     Labor costs include overhead allocations.

3.     All costs are annualized.

TCO and IT Life Cycles

The TCO Model is a continuous improvement technique because it is designed to be like the Plan-Do-Check-Act cycle of the Quality Assurance realm. After a business has determined its current status by using a TCO assessment, the data is analyzed and issues are identified. There issues then become improvement projects. After improvement projects have been completed, another assessment must be made and compared to the previous one to see the impact on the organization. The TCO Model maps to the MSF IT cycle. The phase mapping is reflected in Table 7-1.

IT Phase

TCO Phase

Manage

Analysis

Plan

Improve

Build

Manage

Table 1: MSF IT cycle phases to TCO cycle phases.

The Analysis Phase

In the analysis phase, the IT costs are measured and documented. A critical factor is an accurate IT asset census. For many organizations this data may be obtained from current inventory management records or other financial data.

A repeatable process for this measurement must be established. This process must be kept simple and inexpensive to duplicate, yet it must be rigorously followed. The data must be collected consistently to yield any real value.

The industry-specific averages are also collected in this phase. These averages must come from the same type of industry as the organization. This is important because these industry averages are used to compare with the organization’s data. The comparison creates a baseline report. The baseline report is the starting point to which, after changes have been made to the organization, the next set of data will be compared.

The Improve Phase

After a TCO assessment, issues are identified by comparing the TCO data to industry averages and to previous organization data. These issues may become improvement projects.  What-If analysis may be valuable in this phase to simulate costs and benefits of an improvement project. Further modeling may simulate the impact of an improvement project on the enterprise.

These projects are then prioritized and several may be selected. Then the tasks are completed to resolve IT issues. Resources are applied to the issues to ensure change.

Remember that the improvement phase is part of a cycle and the complete cycle is repeated. In the first cycle the baseline data are established in IT assets, IT management, and IT costs. The improvement projects and the tasks to meet the improvement objective are the final deliverable from this phase.

The Manage Phase

The activities in the Manage phase take the data collected from the two cycles of the analyze phase and compare them to see if any progress has been made. The focus of this comparison is those projects identified in the improve phase as the projects to be implemented in the current cycle. The industry averages are also used as benchmarks in this phase. There are four major activities for this phase:

1.     Review and perhaps integrate new ideas. In the process of the analyze-improve-manage cycle practices will be identified as those that reduce IT costs. These practices may allow the organization to be more aggressive in its TCO improvement plans.

2.     Institute the full revolution of the improvement cycle. An awareness of continual improvement begins to permeate the entire IT department once the full cycle has been completed and individuals can see the results of their efforts.

3.     Monitor, track, and adjust the projects affected by the TCO results. The improvement projects must be managed like any project. They must have due dates, deliverables, and individuals must accept responsibility for accomplishments. These projects will usually compete with other IT projects for scarce organizational resources. The costs and benefits must be reassessed at each cycle to determine whether stated goals have been met or have changed.

4.     Adjust the baseline metrics. The baseline report is again generated in preparation for the next cycle.

TCO in the Enterprise

TCO specialists are available as consultants to perform the TCO assessment in approximately 6 weeks. The deliverables at the end of this period are as follows:

·       A completed TCO cost model spreadsheet. A good example of a cost model spreadsheet is shown in Figure 7-1. This is generated from the Desktop TCO Calculator, which is available on the Microsoft web site (see the next section, “The Microsoft TCO Spreadsheet Tool”).

·       A final presentation of findings and recommendations based on those findings. This final presentation from the consultants may be given to the organization’s top management.

·       Identification of the data sources and assumptions. Assumptions should always be validated with the customer and re-validated at every opportunity. Conclusions from these findings must always take into account the source of the information and all assumptions.

·       A graphical analysis showing the comparisons to industry averages. Once again, the Desktop TCO Calculator has graphical analysis of the data available in many different forms.

The Microsoft TCO Spreadsheet Tool

A spreadsheet tool is available from the Microsoft web site (http://www.microsoft.com/office/tco/ to assist in collecting data. The upside to this tool is that it is free for the download; the downside is that it contains no industry averages for comparisons. This tool is helpful for doing What-if analysis.

An excellent white paper for this topic may be found at http://www.microsoft.com/solutionsframework/TCO/TCO.htm.

The spreadsheet wizard consists of a series of screens that guide you through the data entry process and then format the information into an intelligible report at the end of the session as well as performing all needed calculations. This whole wizard is implemented in VBA in an Excel spreadsheet so it is easily tailored. The first screen of the wizard, shown in Figure 1, explains the algorithm for the ROI calculation.

Figure 1: Screen 1 of the TCO/ROI Wizard

Figures 7-2 and 7-3 show a report and graph based on sample data you would enter using the wizard.

Figure 2: ROI report from the TCO/ROI Wizard based on sample data

Figure 3: Graphical analysis based on the sample data

There are other reports and graphs available in the wizard. The user may also return to the data collection screens and change the data. The complete studies can be found at http://microsoft.com/office/tco.

Exercise 7-1 will test your knowledge in identifying costs.

Exercise 7-1: Identifying Costs

Identify the cost categories for the following items.

1.     Lease Cost for the mainframe.

2.     Lease cost for the database server.

3.     Office Suite upgrade costs.

4.     Cost of networking closet racks.

5.     Salary of Networking Manager.

6.     Benefits for Networking Manager.

7.     Tuition for Networking Management School.

8.     Auto mileage to Networking Management School.

9.     Consulting fees to tailor installed software.

10.  Development costs for credit card processing software.

11.  Salaries for the Help Desk Supervisors.

12.  Cost of diskettes, printer paper, and laser jet cartridges.

13.  Costs to inventory and monitor the supply of diskettes, printer paper, and laser jet cartridges.

14.  Purchase price of modem bank.

15.  Lease cost of T1 lines.

16.  Salaries of users unable to work because the network is down.

17.  Salaries of users fixing other’s computer problems.

Analyzing the Extent of a Business Requirement

A previous chapter explained the first phase of the MSF cycle that resulted in the vision/scope milestone. We saw that the vision activity attempts to encompass all requests for functionality from the user community, while the scope activity attempts to set the boundaries of the project. Individual business requirements can be discussed only in context of the established vision and scope of the project.

Exam watch: While taking the exam, carefully read each sentence in the scenario-based questions. Do not read anything into them. As in real life, opinions about the development issues are presented from different roles in the organization. The questions may be based on these opinions and it is up to you to either remember them all or go back to the text of the scenario to review the opinions.

Establishing Business Requirements

Business requirements must be established by the business community, not by the IT group. Although the IT community may make suggestions to the business community, IT should not drive the definition of the business requirements. The users may not assume ownership of the final product claiming that IT forced requirements on them. IT should not assume they know the business plan. Application development history is full of examples of a brilliant solution developed for requirements that existed only in the minds of IT.

One of the best reasons for producing a printed requirements document is that it may serve as a contract between the business community and the technical team. Scope creep, the addition of newly discovered requirements by users, may be managed proactively with a Requirements document that was agreed on by both parties.

From the Classroom

Business Requirement Analysis

The analysis of business requirements is not an exact science in all cases. Business needs change; therefore business requirements have a tendency to evolve, although this is not the biggest concern of the business community. Ensuring that the identified business requirements accurately match the true needs of the business is paramount to developing an application for which users will be willing to assume ownership. Such an application will contribute to the success of a business or department. On the other hand, an application developed using phantom business requirements, or those born of the imagination of application developers or IT personnel, will most likely generate discord, inefficiencies, and occasional outright resentment of the tool. Cooperation among the users, developers, and business community is paramount to the creation of a successful business tool.

Almost as important as the development of accurate and useful business requirements is the proper documentation of said business requirements. Production of a requirement's document provides a source of information that can be referred to by non-technical individuals to research and reference the base business requirements under use in the development of the business application. This document can provide a roadmap for current and future development efforts. Having the full range of identified business requirements identified in a single document can ensure less confusion, misunderstanding, and miscommunication during the development process.

Michael Lane Thomas, MCSE+I, MCSD, MCP+SB, MSS, MCT, A+

Problems in the Requirements Analysis Phase

The analysis phase is an excellent opportunity to begin identifying risks for the project. These risks may be closely related to the problems that appear in this phase. Problems may be organizational problems, people problems, business process problems, or regulatory or government problems.

The business community may legitimately not know their own business. One example of this situation is a government unit that must conduct business as instructed by legislation. The exact interpretation of legislative verbiage may need to be completed before business requirements can be defined.

Another variation is that the business community may not be able to imagine how their daily tasks may be interpreted into a computer application. Although the business requirements must be stated independently of any implementation decisions, it does help, for example, to work with users who have been exposed to several different alternatives of a list box. Sometimes it is necessary to discourage a user excited by the idea of getting a computer-based solution from designing the application as they are stating requirements.

The business community may believe that it is easy to develop applications while the IT community may believe that it is easy to conduct the business. One by-product of requirements analysis may be an increased mutual respect between the business and IT communities in an organization.

Interviews

Before interviewing begins it is helpful to compile a list of individuals and an explanation of what perspective they can give to the analysis process. It is important to talk to people whose vision may differ from the over-all, visionary perspective of the ideal world-as-it-should-be to the individuals responsible for working with the application daily and basing decisions on the information presented by the application.

There are several advantages to having this material before you begin. It aids in planning and helps to expedite the process. I attempt to pre-qualify the individuals I want to interview by sending a brief questionnaire that basically tries to answer the question of who has the power internally to get what they want. In the sales process a salesman attempts to pre-qualify a candidate mainly to find out if they have the real power to make purchase decisions.

If the application extends across departmental boundaries or even geographic boundaries, there may be conflicts of interest that appear during the interviews. I prefer to identify these areas and get all concerned parties into a war-room to make decisions about the tradeoff and hopefully reach a conclusion so that the project may go forward.

Requirements Documentation

The business requirements must be captured in terms understood by the business community. The requirements may be explained textually in a business requirements document. There are two major advantages to having a single document that defines the requirements for an application development project:

1.     It is a single-source repository for all requirements that may include supporting materials in the appendices.

2.     It is a document that the business community may review without IT expertise and then sign off on an agreement for the ensuing development effort.

Because of these two advantages, I prefer to treat all other tools for requirements gathering as an addendum to the requirements document. Use cases, storyboarding, and screen prototyping are extremely helpful in further defining areas of requirements that are difficult to make clear by the use of text alone. The products from these additional tools may be included in the Requirements document.

There are tools on the market to assist you in gathering requirements. Rational Software’s product, RequisitePro, is one that not only performs as a repository for all textual requirements, it also integrates with Rational Software’s SQA-Test and forms the foundation for test suits used in regression tests.

Requirement Analysis Conceptual Aids

There are a number of techniques in use today to help the requirements gathering process. Use cases, storyboarding, and screen prototyping have already been mentioned.

One point at which to begin discussing requirements is with the definition of what kind of information needs to be kept by the business. The data is a very tangible need and one that provides an excellent springboard into discussions of functionality. Business users quickly understand the diagramming techniques involved in an Entity Relationship Diagram(ERD) and most users enjoy the data modeling process. The diagram is only a small portion of data analysis. The entities and all columns or fields must be defined. The relationships between entities must also be defined. Definitions should be captured as soon as an entity or field is mentioned. The risk of forgetting what was meant by a name increases with time. An example ERD is shown in Figure 7-4.

Figure 4: Entity Relationship Diagram

Functional decomposition may be used to create a hierarchical tree-structure diagram, which, in the topmost layers, may suggest the structure of the workflow. See Figure 7-5 for an example. The diagrams are only part of the requirement. Each node must be backed up with a textual description, definitions of all tasks, and the identification of all data used in the process. The purpose of functional decomposition is to break down the tasks in a business process to a fine granularity. The lower functions may then be described precisely and in detail.

Figure 5: Functional Hierarchy Diagram

Screen prototyping and storyboarding aid the users in defining the workflow they want to use in the future. Some of this may be based on existing screens and production applications because that is what the user is familiar with. Although it may be difficult to get the user to think in revolutionary rather than evolutionary terms, the benefits will be that old mistakes or inconveniences are not duplicated in the new application. See Figure 7-6 for an example.

Figure 6: Screen Prototype or Storyboarding

Data Flow Diagrams depict the information flow through the business functions. Here again a high-level business function may be further decomposed into a finer granularity. In these diagrams, each business process (the verb-noun pair in an oval) has information passed to it and in turn passes information to other processes. The name of the information is written above the arrow that points in the direction the information is going. See Figure 7-7 for an example of a DFD.

Figure 7: Data Flow Diagram

Exam Watch: Data modeling and the use of Entity Relationship Diagrams and business process modeling supported by both Functional Hierarchy Diagrams and Data Flow Diagrams are techniques that have been used successfully and are considered standard techniques that many business applications analysts will use. Please remember that the object of the exam is to test individuals on concepts that are proven in the field.

Identifying Risks

While proceeding through the requirements gathering phase, maintain a list of issues. As soon as they are identified, these issues should be assigned to an individual for further research and that individual is asked to specify a due date that will fit their schedule. It may be that the individual cannot discover any more information about an issue. All unresolved issues become risks that must be taken into consideration. In this phase, the business risks are enumerated. Technical risks may then be added to the list as they are discovered but these technical risks are not assigned to business users to investigate.

Ending the Requirements Analysis Phase

There are no obvious triggers that clue you in when one phase ends and another begins in the applications development process. To proceed from vision/scope to analysis to design is a progression along a continuum. Requirements should be complete but not too detailed. There are increasing risks in an application that remains in the requirements analysis phase too long. Analysis paralysis is the term used to identify development projects that stay in the requirements gathering phase too long. This is not, hopefully, the last chance to discuss requirements with the users and, as development progresses, issues can be clarified.

Establishing the Type of Problem to be Solved

Determination of the type of application to be developed will drive the choice of technologies for the architectural design. This is discussed in more detail in Chapter 9, “Defining the Technical Architecture for a Solution.” At this point in the analysis phase, a high-level identification of the problem is sufficient. Will the application solve a messaging type of problem? Will it use communication technologies? Many applications require solutions arising from multiple problem types.

Establishing and Defining Customer Quality Requirements

The customer must dictate what level of quality they need to have built into the application. Quality in production applications means how often the application fails and what happens when it does fail. If a customer needs an application to be available 24 hours a day, seven days a week with no downtime, the design of the application and the technical architecture will need to accommodate these requirements. This is a much different application than one that needs to be available only during working hours to a localized group of business users.

Another consideration is the vitality of the help desk in the organization. If the help desk is already overworked and cannot tolerate an increased workload without additional resources, the application may need to have sophisticated help capabilities.

What happens to transactions when an application fails is a discussion with the customer that is often overlooked. Most transactional applications require the ability to roll back the data to a stable state if a transaction fails. How the rollback is controlled, whether by the database or by the application program, often dictates how much control the end user needs to determine how to recover.

Online documentation versus hardcopy documentation is a separate aspect of quality and is an integral aspect of the training decisions. If formal end-user training is planned, then the online help system may be a part of the training and the hardcopy documentation may not be needed.

Minimizing Total Cost of Ownership

Remember that the TCO is comprised of both direct IT costs and indirect costs. Difficulties in estimating TCO in the requirements analysis phase result from not knowing the amount of training needed, not knowing the level of help desk support that will be needed, and not having a good sense of the technical sophistication of the users. Specific aspects of TCO that can be defined in this phase are the number and location of users and their workstations, the targeted technical platform, the use of development consultants and their travel expenses, and the labor rates of the staff to manage the application and the technical platform.

Reliance on industry benchmarks at this date may be hazardous because of the immaturity of the cost data but this should improve during the next decade.

Increasing the Return on Investment (ROI) of the Solution

A reasonable cost-benefit analysis may be difficult to create for one application, but this can form the basis of an estimated Return on Investment (ROI). Lower costs and increased benefits result in a better ROI. Although costs may be fairly simple to quantify, benefits may be difficult. If a new application saves an individual 50% of their time spent on a particular set of tasks, the fear-of-change factor may kick in and the extent of the savings may be hidden. Or the extent of the savings may be inflated due to overly optimistic estimates by the development team.

Analyzing the Current Platform and Infrastructure

Most business processes now have some form of automated support. I rarely find a project that starting without a production application. Unfortunately, the production application is often viewed as a time-saver and cost-cutter for the new development project. I have worked on many projects where the business community’s idea of requirements analysis is the instruction to “Make the new application look exactly like the old application.” The current production programs, hopefully, exist as source code. Other documentation may also exist for production programs. Some users assume that the requirements have been captured and are accurately reflected in the source code of the current production programs.

The assumption on the part of the users is that they do not need to be involved in the requirements analysis phase. This can be a serious mistake because many users assume that the project will incorporate some amount of workflow analysis. I find myself repeating that if the only tool you have is a hammer, everything looks like a nail. The users must be convinced that the new application cannot be modeled on a workflow from even just five years ago. The danger is that the users may continue to do daily tasks because that is the way the tasks have always been done and not because the task adds any value to the process.

Another drawback to analyzing the existing application is that the software development platform may no longer exist, may be an old, unsupported version, and may require that the IT requirements analyst learn a development tool that they have no desire to learn. Although a loop index in one language may appear the same as a loop index in other languages, the implementation of the construct may differ and may not be well documented in the older tools. If support cannot be found for the existing development tool, the only way to determine how the existing application works may be to play with the tool. This can be very time-consuming and resource-intensive.

One aspect of the production systems that is valuable is the definition of the user roles and responsibilities. The current roles may change drastically with new technology and it is helpful to know what the roles were and how they will be redefined. It is natural for an end user to ask what happened to their daily report after the new application with advanced communication features does away with their perceived requirement. The analyst needs to see what the roles were and how they are changing to assist the end user to understand why the report is no longer being generated.

Incorporating Planned Platform and Infrastructure into the Solution

A difficult aspect of Information Technology planning is enabling upgrades. Often, planned solutions in an application design must be re-worked because the infrastructure of the hardware of foundational software is not ready. For example, if a network still has nodes running Windows 3.1 and these nodes, as well as Windows NT workstations need to run an application, then either the application must be 16-bit or there must be two versions of the application, one compiled for 32-bit machines and another for 16-bit machines.

Multimedia or imaging applications often drive the need to upgrade the bandwidth of the network. Many of the older networks are 10 mps and must be upgraded to 100+mps to provide adequate response time to handle graphics applications.

A common problem is upgrading hardware and not receiving it in time to roll out the application. These are all risks that must be identified and plans made to either circumvent the situation or to find a temporary fix.

Analyzing the Impact of Technology Migration

Changes in an organization must be handled with care. The best way to manage change is to plan before the change must be made. There are different aspects to changes caused by new computer systems. There are the technical and the social elements of a technology migration.

The technical aspects of changes in an organization’s technical environment may include different computer hardware, different development tools, different shrink-wrapped application, and perhaps even different storage or communication devices. Any and all of these may impact current applications upon which the organization is dependant. Any change in technology must be thoroughly tested before installation in a production environment. This may involve creating a complete test lab that simulates the current production environment, installing an evaluation copy of software or a trial piece of hardware and ensuring that it works as expected.

One hardware/software issue that continues to plague development teams is the 16/32 bit architecture issue. If some of the target hardware platforms are running older operating systems, Windows 3.1 or DOS, 16 bit applications must be developed and maintained for these machines. If there is a mixture of architectures such as in a network that has Windows 3.1, Windows 9x, and Windows NT, the choices must be considered. These choices are:

·       The team writes code for the lowest common denominator, the 16 bit architecture, and loses out on the power of 32 bit systems.

·       The team, using compiler directives, writes code for 16 bit and 32 bit architectures and then maintains 2 sets of compiled executables.

·       The team only writes 32 bit code; individuals with 16 bit architectures won’t be using the application.

The social aspects of change are sometimes even more important than the technical aspects. For example, in the process of rewriting an existing production application, the task of delivering reports to department managers was eliminated. Although the information contained in the reports was also online, and the managers had all been trained in accessing it, they complained that they weren’t getting the same information. What they were not getting any more was the trigger of receiving reports that told them it was time to check the status of specific data. Once this was recognized, a small application was written to send them a reminder by e-mail.

Planning Physical Requirements for the Solution

Some physical requirements will be apparent in the requirements analysis phase such as the need for bar-code readers in a retail application. But other technical architecture requirements may be dictated by the strategic IT plan. These may include a decision to keep all data on the mainframe rather than distribute it because of greater failure recovery or heightened security. Although the technical architecture may be sketched out in the requirements phase, there is a danger in too much detail because that may lock your solution into a dependency on specific technology.

Identifying Organizational Constraints

There are always some constraints on the product we are able to deliver. The less obvious ones may be issues that, if properly addressed in the upstream portion of the application development life cycle, may cease to be an area of contention even though they may still be an issue.

Financial Situation

Business users have fun in the visioning portion of requirements analysis because they can have anything they want but as the requirements continue and resource needs become firmer, the cost of having everything may outweigh the benefits. Resources are ordinarily limited and the development effort is normally limited by the availability of funds.

Company Politics

Politics within an organization may sway the acceptance of new applications. Although individuals high on the organizational chart may prove to be valuable allies for the acceptance of changes, individuals tasked with daily operations may hold more real political power. In the end, a wise applications development team takes into consideration the response of all concerned when it comes to changing the way an organization conducts business. This could also include communities outside of the organization such as the general public, suppliers, and distribution channels.

Technical Acceptance Level

Acceptance of new technology or a new software application relies heavily on the amount of understanding the users have of the new technology. If the users have a frame of reference, they find it easier to understand the new technology and they are always looking for the ”What is in it for me” factor. If they understand the foundational concepts and see benefits to be gained, acceptance is greatly enhanced.

Training Needs

The need for end-user training should be stated in the requirements phase as a targeted goal. If the end users will need only an hour of training, that goal is much easier to react to than if they need a week of offsite training. Sometimes it is easy to forget that end users have assigned duties for which they are responsible. Extended training requires a shuffling of work assignments to get coverage for those duties.

Establishing the Schedule for Implementation of the Solution

Scheduling the installation of a new application must be accomplished with the involvement of a group of individuals. Of course, the end user for the application will be impacted. They may need to be trained, which means time away from their duties. The end user may also need additional help during the first attempts at using the application. The workload of these individuals must be lightened to give them enough time to get up to speed with the new application. Installation of new hardware may also require the end user to be away from their work area. If the workflow has changed drastically because of the new application, the workload of all affected end users may need to be adjusted to accommodate additional or lightened demands on their time.

Identifying the Audience for the Solution

The target audience for any technical solution falls into three main categories:

1.     the individuals who pay the bill

2.     the end users of the application

3.     the development team that is responsible for maintenance and enhancements

The individuals who authorize payment often are influenced by the end users of the application and will pay based on the recommendation of the end user. If an application crosses departmental or geographic boundaries, this individual may be the only one in the organization who knows the overall success of the application.

The end users of the application may need to wait for a subsequent phase to get all the functionality they need to completely automate a process.

Exercise 7-2 will put into practice the business requirements analysis covered in this chapter.

Exercise 7-2: Identifying Requirements

The nutrition department of a large hospital wants an application to aid them in planning meals for special nutritional requirements such as low sodium diets, low cholesterol diets, low fat diets, or low calorie diets.

The lead nutritionist states, “We must be able to track for every food and quantity the sodium, calories, fat, and cholesterol that the food contains. We need the ability to combine these foods into recipes and then combine the foods and recipes into meals. What we need is a comprehensive catalog of foods. We don’t care about instant response time so long as we don’t have to wait too long.”

The CIO states, “Because of our evolutionary upgrade plan for the client hardware, we cannot promise that when applications are first put into production they will all be running on 32-bit machines. We will have a mixed bag of NT, Win95, and Win3.1 for some time to come. Because the enterprise standard database is SQL Server, all applications needing database technology will use SQL Server and Access.”

The CFO comments, “We also need to minimize overall the daily costs of meals.”

Place a check next to valid business requirements.

1.     There will be a foods database.

2.     There will be a food table that contains the food name, sodium content, calorie content, fat content, cholesterol content, serving size, and cost per serving.

3.     The application will run only on 32-bit client workstations.

4.     There will be a recipe table that contains the foods that make up the recipe.

5.     There must be two versions of the application, a 32-bit and a 16-bit version.

6.     There will be a meals table that contains the foods and recipes that make up the meal.

Certification Summary

TCO of a technical solution is calculated using both direct and indirect costs and is an excellent approach to continuous improvement of the development process. The TCO lifecycle of improve-manage-analyze roughly corresponds to the MSF life cycle.

Business requirements are derived from all levels of the business community. The requirements are then packaged in a form the business community can easily understand and will be able to sign off on. They then become the foundation of the design phase and can provide a base for testing during the development process.

Two-Minute Drill
Continual improvement of IT services while simultaneously reducing IT costs are conflicting goals.
Total Cost of Ownership (TCO) is the process of creating a set of repeatable tasks tailored for a specific organization.
Business requirements are the foundation of analysis. The requirements are the primary communication device between the business area experts and the technical development team.
Several TCO models exist with varying degrees of success. The Microsoft-Interpose model is simple, yet complex enough to support more precise analytical conclusions.
Total Cost of Ownership (TCO) is the dollar amount of expenses and depreciated costs invested by an organization for each IT asset.
The implementation of TCO involves creating a baseline set of data, recognizing the issues that the analyzed data represents, taking actions on those issues, and then measuring progress toward resolving the issues.
People, process, and technology are interrelated parts of a comprehensive view of the TCO model.
The Microsoft-Interpose TCO Model identifies seven categories of costs; five are considered direct IT costs and two are indirect IT costs.
The Microsoft-Interpose TCO model, applies only to the client/server world and client/server costs. The mainframe and all costs associated with it are excluded.
Also excluded are the costs or benefits resulting from a change in end-user productivity because of a change in the user’s IT environment.
The TCO Model is a continuous improvement technique because it is designed to be like the Plan-Do-Check-Act cycle of the Quality Assurance realm.
TCO specialists are available as consultants to perform the TCO assessment in approximately 6 weeks.
While taking the exam, carefully read each sentence in the scenario-based questions. Do not read anything into them. As in real life, opinions about the development issues are presented from different roles in the organization. The questions may be based on these opinions and it is up to you to either remember them all or go back to the text of the scenario to review the opinions.
Business requirements must be established by the business community, not by the IT group. Although the IT community may make suggestions to the business community, IT should not drive the definition of the business requirements.
One of the best reasons for producing a printed requirements document is that it may serve as a contract between the business community and the technical team.
Data modeling and the use of Entity Relationship Diagrams and business process modeling supported by both Functional Hierarchy Diagrams and Data Flow Diagrams are techniques that have been used successfully and are considered standard techniques that many business applications analysts will use. Please remember that the object of the exam is to test individuals on concepts that are proven in the field.
Determination of the type of application to be developed will drive the choice of technologies for the architectural design. At this point in the analysis phase, a high-level identification of the problem is sufficient.
The customer must dictate what level of quality they need to have built into the application. Quality in production applications means how often the application fails and what happens when it does fail.
Remember that the TCO is comprised of both direct IT costs and indirect costs. Difficulties in estimating TCO in the requirements analysis phase result from not knowing the amount of training needed, not knowing the level of help desk support that will be needed, and not having a good sense of the technical sophistication of the users.
A reasonable cost-benefit analysis may be difficult to create for one application, but this can form the basis of an estimated Return on Investment (ROI).
A drawback to analyzing the existing application is that the software development platform may no longer exist, may be an old, unsupported version, and may require that the IT requirements analyst learn a development tool that they have no desire to learn.
A difficult aspect of Information Technology planning is enabling upgrades. Often, planned solutions in an application design must be re-worked because the infrastructure of the hardware of foundational software is not ready.
Changes in an organization must be handled with care. The best way to manage change is to plan before the change must be made.
Any change in technology must be thoroughly tested before installation in a production environment. This may involve creating a complete test lab that simulates the current production environment, installing an evaluation copy of software or a trial piece of hardware and ensuring that it works as expected.
Although the technical architecture may be sketched out in the requirements phase, there is a danger in too much detail because that may lock your solution into a dependency on specific technology.
Scheduling the installation of a new application must be accomplished with the involvement of a group of individuals.
If the workflow has changed drastically because of the new application, the workload of all affected end users may need to be adjusted to accommodate additional or lightened demands on their time.
The target audience for any technical solution falls into three main categories: the individuals who pay the bill; the end users of the application; and the development team that is responsible for maintenance and enhancements.

Answers to Exercise 7-1: Identifying Costs

1.               Mainframe costs are not included in TCO.

2.               Hardware and Software Costs

3.               Hardware and Software Costs

4.               Hardware and Software Costs

5.               Management Costs

6.               Management Costs

7.               Management Costs

8.               Management Costs

9.               Development Costs

10.            Development Costs

11.            Support Costs

12.            Support Costs

13.            Support Costs

14.            Communication Costs

15.            Communication Costs

16.            Downtime Costs

17.            End-user Costs

Answers to Exercise 7-2: Identifying Requirements

The following numbers should be checked: 1, 2, 4, 5, 6