Skip Navigation
Forum Unified Education Technology Suite
  Home:  Acknowledgments and Introduction
  Part 1:  Planning Your Technology Initiatives
  Part 2:  Determining Your Technology Needs
- The Needs Assessment
- Knowing What Resources
are Already in Place
  Part 3:  Selecting Your Technology Solutions
  Part 4:  Implementing Your Technology
  Part 5:  Safeguarding Your Technology
  Part 6:  Maintaining and Supporting Your Technology
  Part 7:  Training for Your Technology
  Part 8:  Integrating Your Technology
  Appendix A: Sample
Acceptable Use
Agreements and Policies
  Appendix B: FERPA Fact Sheet
  Appendix C: Web Guidelines
  Appendix D: Sample Security Agreements
  List of Tables and Figures
    Powerpoint Overview (700KB)
NCES Webmaster
Part 2: Determining Your Technology Needs (continued)

Writing a Statement of Needs

Once a set of functional needs and technical considerations (including security and ethical standards) have been identified and prioritized, they must be translated into a statement that accurately describes the required capabilities of the desired technology solution (see Documenting Results). Planners should try to include all members of the technology committee during the development of this document. After all, the more people who participate in these discussions and the formulation of these plans, the more users who will accept responsibility for the decisions that get made-and as any good leader will tell you, this type of "buy-in" is critical to major organization-wide initiatives.

What Should Be Included in a Set of Functional Specifications?

A Functional Specifications document is a natural extension of a Needs Statement. It describes in detail what technical capabilities a new (or upgraded) computer system should offer. Consider this analogy: As a wise consumer, you create a checklist of your needs before shopping for a new car (a Needs Statement). You then translate your identified needs into a list of performance characteristics the vehicle should possess. For example, perhaps you determine the investment should:

  • carry your family of four (and even a fifth person on rare occasions)
  • keep the four of you (and your luggage) comfortable on day-long trips
  • handle smoothly on rough or unpaved roads
  • keep up with freeway traffic
  • get reasonable gas mileage
  • retain value after four years of ownership
  • be easily serviced

With this list, you are ready to visit showrooms and search for candidates that match your Functional Specifications. Without such a list, you're apt to flounder and end up with a vehicle that doesn't meet your needs. The Functional Specifications document plays the same role as the list of car characteristics in that it specifies what capabilities a technology solution should offer.

There are many different views about what belongs in a set of Functional Specifications. Consultants and product vendors tend to recommend their favorite (often proprietary) method of data or process modeling, function charts, and other items that non-technical decision-makers might find difficult to understand. A good rule of thumb is to view the Functional Specifications as a concise description of a new technology system's capabilities, which is then compared to what can be purchased from a commercial vendor or built by developers.

Always be sure to require that vendors respond to your specific technical and functional requirements. Don’t accept a proprietary solution developed by a vendor in response
to their estimation of your needs.

When developing Functional Specifications, it can make sense to include details about the organization's current computer system; the information it contains, and processes it regularly performs. Even though the current system does some things well, there may be better ways to perform the same functions, or there may be ways to combine functions and improve efficiency. Moreover, compatibility with existing specifications is a desirable characteristic.

Figure 2.4 contains a suggested outline for a Functional Specifications document. This document is organized somewhat like the Needs Statement, but it is concerned with the characteristics of a system itself rather than the requirements it would need to meet. Obviously, the Functional Specifications should reflect the Needs Statement. While the terminology in the sample Functional Specifications document may look technical, it is simply a list of the capabilities a system has to provide, the functions it must be able to perform, and performance specifications concerning "how much, how fast, and how many" it must be able to handle.

Establishing functional specifications is a highly specialized task that demands the attention of someone who possesses considerable technical expertise.

The following is a more detailed description of the items listed in Figure 2.4 that might go into a thorough Functional Specifications document:

Section 1: Introduction

Section 1 should provide an overview and introduction to the functional specifications document, including background on the organization and initiative, and the objectives and scope of the document.

Section 2: System Contents

This section should include a description of the types and amount of information the system is expected to process, store, and transmit. Additional details can be provided as necessary to fully describe the specifications. For example, under Instructional, it could be helpful to note that English classes need on-line access to reference materials, tutorial programs, enrichment materials, and teacher guidelines, as well as the use of word processing programs and the storage of "portfolios" of student work.

Section 3: System Functions

This section should include a list of specific functions the system must to be able to accomplish (or enable staff to accomplish). These functions could fall under the following categories: System Storage and Retrieval Capabilities, Calculation and Processing Capabilities, Reporting and Output Capabilities, and Telecommunications Capabilities. For example, it could be noted that each classroom must have access to a central repository of information resources such as encyclopedias and dictionaries.

Section 4: Access and Capacity

This section should contain details about system access and capacity, including:

  • desired hours of operation
  • security requirements
  • backup frequency
  • disaster recovery

The desired capacity of the system must also be identified (i.e., the number of potential users, the number of users who can use the system simultaneously, and the amount of information that can be stored). For security purposes, software and network specifications must allow administrators to restrict who has access to the system, who has access to specific programs, and even access to individual pieces of data (i.e., data elements) within programs. Administrators also must have software that will identify and report viruses and irresponsible (or malicious) users. Backup and recovery tools are also common requirements in order to ensure system security.

Section 5: Technical Parameters

This section should specify, to the extent possible, all technical and communications standards to which the system must adhere. This would include platform and operating system requirements, portable storage requirements, processing speeds, and electronic data exchange standards (e.g., XML, or Extensible Markup Language, compatibility). This section would also specify which computers within the system should have access to the Internet (or other network), and what types of information will be transferred across the network (e.g., student transcripts, shared participation in on-line instructional programs).

Previous Page -- Part 2 Next Page -- Part 2 continued