Database Software Project Design Specification Outline
Template Copyright © 1995-96 by Leszynski Company, Inc. – usage allowed by permission only
The information in this document conforms to the Leszynski Development Framework (LDF), see www.ldfinfo.com
Project Name:
{fill-in application name}
User Contact:
{fill-in contact person}
Phone:
{fill-in number}
Development Contact:
{fill-in contact person}
Phone:
{fill-in number}
Document Creation:
{fill-in date and person(s)}
Document Revisions:
{fill-in date and person(s)}
Purpose of This Document
This document provides a suggested outline for a database application design specification that falls within Leszynski Development
Framework guidelines. Hints for creating the content of each section and topic are emphasized with double underline and can be
deleted from the final document draft. Items to be filled in during the creation of the document are noted with {bracketed text} which
should be replaced with your text in the actual specification document.
Different specifications will have different layouts, depending on the responsible personnel and the needs of each project. The flow
of this example is only a suggestion to guide your specification process – there is no single "correct" outline for a spec document.
Many people working on an application of any size fail to predict the complexities of development, testing, budgeting, and
deployment. Even if your project is too small or your timeline too tight to allow for a specification as detailed as this outline, reading
through the outline before you begin your project will help alert you to the many facets of development and deployment.
For purposes of this specification outline, the term section is used to refer to a major segment of the document. Within sections are
subsections, and each subsection has several topics that describe individual application features.
Using this document is easier after reading about the specification design process in the “Creating Design Specifications” chapter of
Access Expert Solutions, written by Stan Leszynski and published by Que Corporation.
Database Software Project Design Specification Outline, Page 1
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Contents
Purpose of This Document .....................................................................................................................................1
Contents...................................................................................................................................................................2
1. Executive Summary ............................................................................................................................................6
1A. Overview ..................................................................................................................................................................... 6
Identified Problems ............................................................................................................................................................................ 6
Proposed Solution .............................................................................................................................................................................. 6
Project Scope ..................................................................................................................................................................................... 6
1B. Justification................................................................................................................................................................. 6
Cost Justification................................................................................................................................................................................ 6
Return on Investment ......................................................................................................................................................................... 7
1C. Resource Requirements ............................................................................................................................................. 7
Human Resources............................................................................................................................................................................... 7
Physical Resources............................................................................................................................................................................. 7
Capital Resources............................................................................................................................................................................... 8
2. Application Processes .........................................................................................................................................9
2A. Solution Description................................................................................................................................................... 9
2B. Primary Processes ...................................................................................................................................................... 9
2C. Application Navigation .............................................................................................................................................. 9
Setup .................................................................................................................................................................................................. 9
Launching the Application ................................................................................................................................................................. 9
Interface Philosophy ........................................................................................................................................................................ 10
Navigation Map ............................................................................................................................................................................... 10
2D. Initial Data Conversion............................................................................................................................................ 10
Source of Initial Data ....................................................................................................................................................................... 10
Converting and Validating Initial Data ............................................................................................................................................ 10
2E. Links to Other Systems ............................................................................................................................................ 11
Downloads ....................................................................................................................................................................................... 11
Uploads ............................................................................................................................................................................................ 11
Merges and Links............................................................................................................................................................................. 11
2F. Security Requirements ............................................................................................................................................. 11
Workgroup Security......................................................................................................................................................................... 12
Application Security......................................................................................................................................................................... 12
2G. Multi-User Issues...................................................................................................................................................... 12
3. Project Mechanics and Management...............................................................................................................13
3A. Project Management Overview .............................................................................................................................. 13
3B. Architecture and Tools............................................................................................................................................. 13
Platform/Language........................................................................................................................................................................... 13
Development Tools .......................................................................................................................................................................... 13
Reusable Components...................................................................................................................................................................... 13
3C. Equipment Requirements........................................................................................................................................ 13
Database Software Project Design Specification Outline, Page 2
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Client Configuration......................................................................................................................................................................... 13
Server Requirements ........................................................................................................................................................................ 14
Connectivity ..................................................................................................................................................................................... 14
Equipment Upgrades........................................................................................................................................................................ 14
3D. Application Deployment .......................................................................................................................................... 14
User Definition................................................................................................................................................................................. 14
Review Builds .................................................................................................................................................................................. 14
Testing ............................................................................................................................................................................................. 15
Unit Testing ................................................................................................................................................................................. 15
System Testing ............................................................................................................................................................................. 15
Test Plan ...................................................................................................................................................................................... 15
Preloading Data................................................................................................................................................................................ 15
Training............................................................................................................................................................................................ 15
Deployment...................................................................................................................................................................................... 16
Online Documentation ..................................................................................................................................................................... 16
User Documentation......................................................................................................................................................................... 16
System Documentation..................................................................................................................................................................... 16
Database Administration .................................................................................................................................................................. 16
Administrators.............................................................................................................................................................................. 17
Backup Policies............................................................................................................................................................................ 17
Disaster Recovery ........................................................................................................................................................................ 17
Adding Users................................................................................................................................................................................ 17
Localization...................................................................................................................................................................................... 17
Ongoing Support .............................................................................................................................................................................. 17
Supporting Users.......................................................................................................................................................................... 17
Reporting Problems and Enhancement Requests ......................................................................................................................... 17
Problem/Enhancement Resolution Guidelines ............................................................................................................................. 18
Future Releases ................................................................................................................................................................................ 18
3E. Project Management ................................................................................................................................................ 18
Affected Users and Related Parties.................................................................................................................................................. 18
Project Timelines ............................................................................................................................................................................. 18
Responsible Parties .......................................................................................................................................................................... 18
Project Administration ..................................................................................................................................................................... 19
Issue Management............................................................................................................................................................................ 19
Risk Management............................................................................................................................................................................. 19
Coding and Documentation Standards ............................................................................................................................................. 19
Future Phases ................................................................................................................................................................................... 19
3F. Financial Mechanics ................................................................................................................................................. 19
Costing ............................................................................................................................................................................................. 20
Third Parties..................................................................................................................................................................................... 20
Contractual Issues ............................................................................................................................................................................ 20
4. Data Structures and Rules................................................................................................................................21
4A. Data Models and Diagrams ..................................................................................................................................... 21
4B. Schema Definition..................................................................................................................................................... 21
Table Structures ............................................................................................................................................................................... 21
Stored Views.................................................................................................................................................................................... 21
Table Relationships.......................................................................................................................................................................... 21
Business Rules ................................................................................................................................................................................. 22
4C. Data Load.................................................................................................................................................................. 22
Initial Volumes................................................................................................................................................................................. 22
Database Software Project Design Specification Outline, Page 3
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Future Volumes................................................................................................................................................................................ 22
5. Screen Forms ....................................................................................................................................................23
5A. UI Guidelines ............................................................................................................................................................ 23
Form Layouts ................................................................................................................................................................................... 23
System Messages ............................................................................................................................................................................. 23
Fonts and Point Sizes ....................................................................................................................................................................... 23
Colors............................................................................................................................................................................................... 24
Buttons ............................................................................................................................................................................................. 24
Switchboard Menus.......................................................................................................................................................................... 24
Bar Menus........................................................................................................................................................................................ 24
Shortcut Menus ................................................................................................................................................................................ 24
Toolbars ........................................................................................................................................................................................... 24
Keyboard and Mouse ....................................................................................................................................................................... 24
Status................................................................................................................................................................................................ 25
Terminology..................................................................................................................................................................................... 25
5B. Structural Information ............................................................................................................................................ 25
{name of the first form} ................................................................................................................................................................... 25
Purpose......................................................................................................................................................................................... 25
Mockup ........................................................................................................................................................................................ 25
Data Source.................................................................................................................................................................................. 25
Navigation.................................................................................................................................................................................... 26
Controls........................................................................................................................................................................................ 26
Events and Procedures ................................................................................................................................................................. 26
Properties ..................................................................................................................................................................................... 26
Validation..................................................................................................................................................................................... 26
{name of the second form} .............................................................................................................................................................. 26
6. Reports...............................................................................................................................................................27
6A. UI Guidelines ............................................................................................................................................................ 27
Report Layouts................................................................................................................................................................................. 27
Fonts and Point Sizes ....................................................................................................................................................................... 27
Colors............................................................................................................................................................................................... 27
Bar Menus........................................................................................................................................................................................ 27
Shortcut Menus ................................................................................................................................................................................ 27
Toolbars ........................................................................................................................................................................................... 27
Terminology..................................................................................................................................................................................... 28
6B. Structural Information ............................................................................................................................................ 28
{name of the first report} ................................................................................................................................................................. 28
Purpose......................................................................................................................................................................................... 28
Mockup ........................................................................................................................................................................................ 28
Data Source.................................................................................................................................................................................. 28
Navigation.................................................................................................................................................................................... 28
Controls........................................................................................................................................................................................ 29
Events and Procedures ................................................................................................................................................................. 29
Properties ..................................................................................................................................................................................... 29
{name of the second report} ............................................................................................................................................................ 29
7. Appendices.........................................................................................................................................................30
Data Diagrams ................................................................................................................................................................. 30
Database Schema............................................................................................................................................................. 30
Database Software Project Design Specification Outline, Page 4
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Process Flow Diagrams................................................................................................................................................... 30
Form Mockups ................................................................................................................................................................ 30
Report Mockups .............................................................................................................................................................. 30
Project Timeline .............................................................................................................................................................. 30
Test Plan........................................................................................................................................................................... 30
Design Team Notes .......................................................................................................................................................... 30
History Application......................................................................................................................................................... 31
History Data..................................................................................................................................................................... 31
Integration Information ................................................................................................................................................. 31
Future Phases .................................................................................................................................................................. 31
Database Software Project Design Specification Outline, Page 5
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
1. Executive Summary
An Executive Summary section is a common requirement for business documents and exists to provide the project highlights for
managers. In a specification, this is probably the only section that executives at the program manager level and above will read. Its
purpose is to provide a clear, accurate, and concise synopsis of the project by highlighting the project's functionality, justification, and
cost.
As a general rule, writers of business documents try to keep the Executive Summary to one or two pages. For a specification, the
reality is that one page is impossible, two is desirable, and three or more is commonplace.
{Add a paragraph here describing how the Executive Summary section will provide the project highlights for managers.}
1A. Overview
The first portion of the Executive Summary section presents an overview of the software project by summarizing the problems it
addresses and the methodology that will be employed.
{Add paragraphs here with a project overview, a summary of problems to be addressed, and the methodology to be employed.}
Identified Problems
This component of the Executive Summary section provides a few paragraphs or bulleted list items that summarize the problems or
opportunities within the company that pointed to the need for the solution described in the spec. The text here need not identify all
specific problems or needs but should at least describe the ones that will be used as a basis for the cost justification topic later in the
summary.
{Add paragraphs and/or bulleted lists here summarizing the problems or opportunities that drive the solution process, and list the
issues that will be used as a basis for the cost justification.}
Proposed Solution
This topic briefly describes the proposed solution and how it will achieve the objectives itemized in the previous Identified Problems
topic. These paragraphs should note who in the company will be affected by the project and what the expected effect on their daily
workflow will be.
{Add paragraphs here describing the proposed solution.}
Project Scope
In this topic, provide a brief description of the scope of the project, including some or all of the following points:
• When will the project start and end?
• What are the major milestones: delivery dates and other deadlines?
• What parties will be involved and what are their individual responsibilities?
• What existing systems and workflows will be affected during development and deployment?
{Add paragraphs defining the project scope.}
1B. Justification
This subsection is essentially the "sales pitch" targeted at the readers that will be involved in approving funding for the project.
{In a paragraph, explain how this subsection will describe the justification for the project’s funding.}
Cost Justification
In this topic, answer the question "Why should the company spend money on this project?" as succinctly as possible. Usually, the
justification highlights one or more of the following benefits:
• Increased Profitability
• Decreased Expenses
• Increased Employee Productivity
• Increased Employee Job Satisfaction
Database Software Project Design Specification Outline, Page 6
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
• Enhanced Competitive Position
• Decreased Business Risk
{Add paragraphs here that define why money is well-spent on this project.}
Return on Investment
In some projects, the specific financial benefits of a project can be favorably contrasted to its costs, which provides a calculation
called return on investment (ROI). The ROI usually quantifies the payback period of the project in months or the total return over the
life of the project. If the increased revenues or decreased expenses from your project can be quantified, include a discussion in this
topic and possibly a table or graph for clarification.
It may not always be easy to tally a solution's positive economic impact on the company because you must measure both the benefits
of the solution and the costs of the problems it solved. The benefit of automating a process, for example, cannot easily be measured if
the process is new because no historical benchmarks exist yet. At the other end of the spectrum, the human resource overhead for a
process that has existed in the workflow for a long time can be measured exactly. When automation is applied, the time savings can be
quantified and the positive impact of the application computed.
{Add text here and/or the following table to quantify the payback period of the project and/or the total return on investment.}
Cost Item
Current
Process
New
Process
{nn}
{nn}
Times: # of Employees
{nnn}
{nnn}
Times: Average Hourly Burden
{$nn}
{$nn}
{$nn,nnn}
{$nn,nnn}
Hours Per Month For Task
Equals: Monthly Cost
Equals: Monthly Savings
{$nn,nnn}
1C. Resource Requirements
In the introduction to this third subsection of the Executive Summary, summarize the actual resources that will be consumed by the
project. The cost of a project is not only measured in direct cash outlays – there are other company assets that are used to create and
deploy an automated solution.
The costing items summarized here and described in the following three topics must total to the project cost number used in the
Return on Investment topic earlier in the spec. Later in the spec (in Costing), a line-item budget is provided, so this topic exists to "hit
the high points" for busy managers.
{Add an intro paragraph here explaining how this subsection summarizes what resources will be consumed by the project.}
Human Resources
In this topic, detail the human capital that will be expended to create the application. Human capital is measured in time increments
and in the cost of that time to the company. Include the cost of time spent by design team members, users, management personnel,
developers, contract coders, testers, trainers, and support personnel.
Some companies also measure “opportunity cost” when computing the expenditure for a project. This measurement assumes that,
while people are working on the project described in the specification, there are other projects that they are not working on. Thus, the
gains on the automation project are offset to some extent by the losses on the neglected efforts.
{Add paragraphs here detailing the human capital that will be expended on the project.}
Physical Resources
Automation projects also consume physical resources. The most common physical resources used by an application are the storage
space on workstation and server disks, and the wear and tear on the computers developing and running the application. While storage
space is sometimes hard to price, in some cases an application may usurp an entire server for itself, the cost of which is known.
Database Software Project Design Specification Outline, Page 7
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Other physical resources consumed by an application development project include: the overhead of contract programmers onsite or
staff developers working overtime (extra electricity, food, or equipment that will be consumed); intangibles like printer paper; the use
of corporate meeting facilities and training equipment; and rented furnishings or overflow office space. Such resource consumption is
often difficult to quantify, and most companies elect not to try to measure these costs in a spec unless they are unusually large for the
specific project.
{Add paragraphs here detailing the physical resources to be consumed.}
Capital Resources
This topic details the items that will require a cash outlay during the project that are not included in the two previous topics. Usually,
capital expenses are those that involve the purchase of tangible assets, such as the upgrade or purchase of software tools or
applications, server machines, workstations, network hardware, modems, printers, and other infrastructure items to support the
application.
{Add paragraphs or tables here summarizing the capital costs.}
Database Software Project Design Specification Outline, Page 8
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
2. Application Processes
This major section of the spec document describes the solution from a functional standpoint. It includes descriptions of the
following:
• What the software does, and how it performs these tasks
• The coordination of the application objects (tables, queries, forms, and reports) via program code
• The processing logic that the application applies to its data
{Add an intro paragraph here describing how this section will detail the solution’s functionality.}
2A. Solution Description
This subsection is usually a lengthy, matter-of-fact description of the project and varies greatly by project. It may include additional
topics for these and other subjects:
• Solution Mechanics
• System Architecture
• User Interaction
• Primary Objects
Topics here describe the current workflow in the process to be automated and the changes to the workflow that will be introduced by
the new system. Process flow diagrams of the current or proposed workflow may be used to clarify this information.
{Add paragraphs, diagrams, and/or additional topics here that provide a comprehensive description of the project.}
2B. Primary Processes
This subsection provides a technical description of the primary logic (code) processes in the system. Logic processes in database
applications include such routines as the following:
• Bulk import/export of records and the validation of the records before or after receipt
• Batch processes, such as mass updates of records at ongoing time points (computing annual pay raises and then updating
employee records, for example)
• Accounting processes, such as validating and posting transaction batches to a ledger
• Data massaging, such as the multi-pass crosstab processing required to produce budget reports that display actual and
projected expenses together
The process descriptions in this subsection constitute actual instructions to the programming team, and should be completely
explicit. In some cases, numbered (stepped) lists are adequate; in others, the design team should write pseudocode to describe the
process in detail.
{Add paragraphs, listings, and/or additional topics here that provide technical descriptions of each primary logic process.}
2C. Application Navigation
This subsection describes how users will interact with the application's interface and includes multiple topics.
{Add an intro paragraph here describing how this subsection details user-interaction.}
Setup
Describe here the requirements of the setup program or installation routine. Detail the components to be installed on the users
workstation, special setup logic requirements, version or license control issues, de-installation, and so forth.
{Add paragraphs here describing the setup process.}
Launching the Application
The specification should describe here how users will start the application. For example, the program group, the application icon and
its label, the window caption, and the command-line arguments should be provided for shortcuts that will point to the application, if
appropriate. Include relevant login or security information.
Database Software Project Design Specification Outline, Page 9
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
{Add paragraphs here describing how users will start the application.}
Interface Philosophy
This topic describes the pervasive interface approaches that will affect how users move within the application. Include in this topic
information on using a runtime engine or compilation, object security, and application “bulletproofing” techniques to move users
between application objects while restricting the availability of the built-in features of the platform. Also discuss here the standard
menu, toolbar, and other navigation metaphors to be used in the application.
This topic is for discussion of general strategies – specific information about interface look-and-feel goes in the Screen Forms
section later in the spec.
{Add paragraphs here describing the interface approaches.}
Navigation Map
In this topic, display a navigation map of the application, which is a flow diagram of a user's interaction with the forms and logic
processes. A navigation map helps the design team and prospective users review and approve the flow of the application. The diagram
shows each form in the application and a visual depiction of how the user moves between the forms. The information can also be
presented in text form.
{Add a flow diagram or textual description here of a user’s interaction with the forms and logic in the system.}
2D. Initial Data Conversion
Few applications are launched completely devoid of data. Instead, data is usually preloaded into an application from existing
databases, worksheets, a retail application, or hard copy records.
This subsection of the spec details which tables get populated before the application's initial release and from where. The
information here should be definitive enough that the development team can do the data loading based on instructions in the following
topics.
{Add an intro paragraph here describing how this subsection will detail the data tables to populate before initial release.}
Source of Initial Data
Include in the spec a matrix showing the tables that will be pre-populated, and the sources of the data for each. Describe the data
source by file name, table and field names, or other specifics, and be sure to note any record selection/filtration clauses if not all
records in an existing data source will be used. For example, when preloading records into a hospital patient information system, you
may choose to only import historical records from the mainframe for those patients that had visited the hospital more than one time in
the past ten years.
This topic should provide specific instructions so a person can be dispatched to fetch all of the data that will be preloaded into the
new system.
{Add paragraphs here providing data conversion/import instructions.}
Converting and Validating Initial Data
Sometimes, pre-populating a database application involves more than simply pulling records from an old platform into the new one.
Historical data may be formatted in a completely different fashion than the new structure requires and may involve complex conversion
procedures. For example, a database may be preloaded with information extracted from e-mail messages.
Use this topic of your spec document to detail the specific conversion algorithms to be used in data preloading and to map source
data fields to their new destinations. Be sure to note validation rules that must be met by each historical data record before it can be
loaded, and the logic to "clean up" the data to meet these rules. For example, you can use a table in this topic that shows the following
information:
Historical Table/Field. The location of the historical data, for example "Field PATS.NAME in the DB2 database".
New Table/Field(s). The destination in the new system for the historical data, for example "Patient.LastName and
Patient.FirstName".
Database Software Project Design Specification Outline, Page 10
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Conversion Logic. The conversion process to apply during the pre-loading, for example "Change the case of
PATS.NAME from uppercase to uppercase/lowercase, then take the first element in PATS.NAME and place it in
Patient.LastName and the second element into Patient.FirstName."
Rule. The criteria for record/field selection during the conversion, for example "Ignore patient names that are Null during
conversion and print an exception list showing single-name patients but do not convert them."
{Add details here about the source and destination of each data item to be preloaded and the conversion algorithms to be used.}
Historical Table/Field
{“from” location}
New Table/Field(s)
{“to” location}
Conversion Logic
{conversion logic process}
Rule
{record selection rule}
2E. Links to Other Systems
Few applications are an island with data captive to the system and not flowing from or to other systems or applications. Instead, data
may be imported from, exported to, or otherwise linked with other systems. Use this subsection of the specification document to detail
such requirements for your application.
{Add an intro paragraph describing how this subsection will detail imports, exports, and links.}
Downloads
Describe here the type of data that will be pulled into the application from other systems. For example, an inventory control system
may pull the current product pricing from the corporate AS/400 minicomputer each month before running inventory processing
routines.
Note in this topic the frequency of data downloads, the work that must be done in the host system to facilitate the extraction, the
linkage mechanisms to the external data, and detail the import and validation logic to be used.
{Add paragraphs here describing data downloads.}
Uploads
It is almost as common for your applications to send data to other systems as to receive data from an external source. For example, a
medical clinic billing system may collect all patient transactions entered during the day, dial the phone each night, and send the
transactions to an external billing vendor's computer which produces invoices from the data.
In this topic, detail any similar requirements of your application to send data to other computer systems. Note the frequency of the
exports, the validation to perform on the data before sending, the communication mechanism.
Also, define the methods for reporting success or failure of the automated process to the users. Import and export/upload validation
logic usually includes summary records or values called “checksums” to confirm that all records were received accurately. A checksum
is a unique number, usually created by totaling all of the values in a particular field in the data.
{Add paragraphs here describing exports.}
Merges and Links
In most PC database systems, users will expect the application to help them merge some of the database information to other
applications for the purpose of analysis or reporting. For example, users frequently request reporting routines to send data summaries
to spreadsheet programs for analysis.
If your application will help users merge data to a word processor, a spreadsheet, a presentation, the Web, or any other destination,
note the requirements for such features in this topic of the spec.
{Add paragraphs here describing how the application will merge its data to other applications.}
2F. Security Requirements
If the application will be secured, detail in this subsection the security requirements and their enforcement mechanisms in the schema
and user interface.
{Add an intro paragraph here noting how this subsection will define security requirements.}
Database Software Project Design Specification Outline, Page 11
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Workgroup Security
This topic details the workgroups designated for the application. It should include a document table showing security groups, the
users for each group, and a description of the general purpose for each group and its place in the security hierarchy.
{Add paragraphs and/or tables here showing the security groups.}
Group
Purpose
Members
Application Security
In this topic, map the groups detailed in the previous Workgroup Security topic to specific application objects and describe the
permissions at the object level. Such a relationship is best represented by a table in the document.
If the application will use programmatic security rather than workgroups, describe the structure and code for such security.
{Add paragraphs and/or tables here detailing the security model.}
Object
Groups
Permissions
2G. Multi-User Issues
The multi-user nature of the application is determined by the number of concurrent users expected and their anticipated data
entry/edit behavior. Detail these expectations in this subsection of the spec document, and lay out the resolution mechanism for any
problems that will accrue from the expected usage patterns.
Specifically, this subsection should describe multi-user loads and the expectation for related collisions. Define the approach to be
used in the application to resolve multi-user record write contention issues. Usually, the resolution is to decide between optimistic,
pessimistic, and programmatic locking strategies and between bound and unbound data forms and to note specific development
approaches to be used when applying the selected philosophy.
{Add paragraphs here describing the management of the problems arising from the user load.}
Database Software Project Design Specification Outline, Page 12
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
3. Project Mechanics and Management
This major section of the specification document describes how the project will be managed and delivered and clarifies issues that
are relevant to the development team members and management personnel.
{Add an intro paragraph here describing how this section details delivery issues.}
3A. Project Management Overview
As an introduction to the project management section, note here the specific issues and concerns unique to this project and important
to its managers and creators.
{Add paragraphs here noting the important issues for managers.}
3B. Architecture and Tools
No specification is complete without a description of the toolset to be employed by the development team. This subsection notes
technical information about the development environment.
{Add an intro paragraph here describing how this subsection details the development environment.}
Platform/Language
The primary platform for an application is its operating system and development languages, which should be noted in this part of the
specification. An application may actually involve multiple development languages, each one specializing in a different task: data
access, user forms, reports, interface extensions, business objects, reusable components, interoperability/automation, program code,
etc. List each of these language tools to be used in creation of the solution.
{Add paragraphs here defining the development languages and operating systems.}
Development Tools
Describe in this topic any third-party tools or extensions that will be employed in addition to the primary platform: development
tools, add-ins/wizards, ActiveX controls, Software Development Kit (SDK) products, code collections, and similar extensions.
{Add paragraphs here describing the development tools to be used.}
Reusable Components
Detail in this topic any components which already exist within the organization and can be reused or adapted for the application.
Reusable components include interface objects, business objects, class objects, Automation servers, compiled Dynamic Link Libraries
and executables, code procedures, and code libraries.
{Add paragraphs here detailing components that will be pulled from other applications.}
3C. Equipment Requirements
In this subsection, the spec document details the hardware requirements dictated by the application.
{Add an intro paragraph here describing how this subsection details the hardware requirements.}
Client Configuration
This topic notes the required configuration for client (user) workstations. Usually, a minimum configuration and a suggested
(average) configuration are both described. Configuration information should include hardware, software, peripheral, operating system,
and driver details.
{Add paragraphs here describing the required client system configuration.}
Database Software Project Design Specification Outline, Page 13
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Server Requirements
The machine on which the data will reside should be described in this topic. If the hardware will be purchased specifically for this
application, note the actual configuration requirements, preferred vendor, and any installation issues. If the application's data will
reside on a shared server, name the server, the path for the data back end, security configurations, and any issues involved in sharing
the server with other applications or databases.
{Add paragraphs here describing the data server.}
Connectivity
Describe in this topic any special connectivity requirements for users of the application. Connectivity issues arise in one of the
following areas:
User Logins. Describe how users of the application gain login rights to the network domain on which the data resides.
Drivers. Detail any requirements here for the users to install connectivity drivers in order to access the data. Describe if
the drivers will be installed by the application setup or by the user.
Remote Users. Users who will access the data over telephone lines or a wide-area network may have special modem,
software, login account, or other configuration needs, which should be listed in this topic.
Laptop Users. If the application allows for any form of data replication or checkout/checkin, the policies and procedures
for mobile users should be clearly spelled out in the spec.
{Add paragraphs here describing how users will connect to the application.}
Equipment Upgrades
This specification topic should name the user workstations that must be upgraded to comply with the configuration and connectivity
requirements previously mentioned in this section. Note here the complete list of required parts and labor per machine, the itemized
cost of each, and the time and manpower schedule for the upgrades.
{Add paragraphs and/or tables here listing required upgrades to user workstations.}
3D. Application Deployment
Since the entire development project is focused on a "ship date," the spec must include implementation plans to guide the project
team toward that date. This subsection provides information designed to help get the product (application) in the hands of the
customers (users).
{Add an intro paragraph here describing how this subsection provides implementation plans.}
User Definition
Describe in this topic the users of the application. In widely deployed applications, the user base is described by department name,
job title, workgroup, or other aggregate grouping. Users may even accrue to a system simply by virtue of the computer they use.
Smaller user groups can be described by actually naming the users.
It is equally important here to describe users of the system more generally by their attributes. Note the skill level, physical location,
workgroup membership, and other hurdles that users must leap to qualify to work with the application, both at deployment and in the
future.
{Add paragraphs here describing the users of the application.}
Review Builds
The most important early milestones in the development process are the prototype phases. Note in this topic how many application
reviews are in the development cycle, what will be provided in each review build, and when they occur. Describe the users that will
participate in each review and how the review process will work. You can communicate this information in a table like the one
following.
{Add paragraphs and/or tables here describing application reviews.}
Database Software Project Design Specification Outline, Page 14
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Build
User Interface Review
Working Model
Beta 1
Features Included
Distribute To
Testing
A good spec document should detail the plans for thoroughly testing the application. The following three topics describe the
procedures to be employed by those testing the application.
{Add an intro paragraph here describing how the next three subtopics describe the testing process.}
Unit Testing
Normally, the development team will test the application before user testing begins. Developers test discrete components (units) of
the software as they are completed and then test how the components work together with other components. In this topic, describe the
involvement of the development team in the testing process and the scheduling and verification of such efforts.
{Add paragraphs here describing the development team’s testing process.}
System Testing
Final testing of the integrated system is usually done through several releases in a cycle called system testing because the entire
system is tested as if the application is complete. Describe here the expected test releases and their feature sets, when releases will
occur, the composition of the test audience, the test audience, the feedback mechanisms for problem reporting and fixes, and any other
issues related to widespread testing.
It is important to detail the users' testing commitment here in addition to that of developers. Users involved in testing need to be
made to understand that their thorough testing is critical to the quality of the product, and their punctual testing is critical to the timely
delivery of the product. Most users underestimate the amount of testing required to create a solid application.
{Add paragraphs here describing the application’s testing.}
Test Plan
Specs for complex applications may include a detailed test plan here describing how to test each major feature of the solution. If the
test plan is lengthy, it may be preferable to include it in the Appendixes section and reference its location here.
{Add a test plan here or reference an appendix.}
Preloading Data
In the Initial Data Conversion section earlier, a strategy was detailed for converting and loading history data into the application.
That strategy was a mechanical one, whereas this topic is for describing the task in political terms. Historical data usually has
ownership, security, and maintenance issues that involve multiple departments or groups of users. In this topic, clarify and resolve any
such issues, and detail the resolution of such issues.
{Add paragraphs here describing the issues related to acquisition of historical data.}
Training
Describe in this topic the user training plan for the application. At the least, note the following points:
• Who will be trained.
• Who will do the training.
• A training timetable.
• What training materials will be created and by whom.
• What training facilities and equipment will be utilized and when.
{Add a training plan here.}
Database Software Project Design Specification Outline, Page 15
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Deployment
The deployment strategy for the application should be discussed in detail in this topic. The following issues should be defined
clearly, along with the parties responsible for each issue:
• Describe the release timetable for the initial deployment, and show how the training and equipment upgrade schedules
precede or overlap deployment.
• Note the order of deployment by user, workstation, or workgroup.
• Note the expected impact on user productivity during deployment.
• Detail the parties responsible for managing deployment and the hands-on installation.
• Describe potential deployment problems and the strategy for addressing each.
{Add paragraphs here describing the deployment process.}
Online Documentation
This topic should clearly describe the electronic documentation requirements for the system. If a Windows Help file, Multimedia
Viewer file, intranet Web site, or other tool will be distributed to users, outline its organization and contents. Remember to also list the
individuals involved in writing, editing, and testing the online documentation.
{Add paragraphs here describing the electronic documentation.}
User Documentation
The specification should detail here the requirements for producing hard copy documentation. If possible, provide an outline, target
page count, and other parameters for the user documentation.
Sometimes your spec can reference an existing document from a previous project to use as a model, rather than providing detailed
writer's guidelines here, or include the sample document as an appendix item.
More and more developers have adopted the model of turning the hard copy documentation into online documentation. If you utilize
this strategy, you will take special pains when you organize and write user documentation so that it can easily be converted to a
compiled Help file or online Web pages. You should note such documentation strategies here or reference a company style guide
document so that the documentation writers can refer to the specification or elsewhere for guidance.
{Add paragraphs here describing the hardcopy documentation.}
System Documentation
Each company, and development group, has its own standards for system documentation. Usually, a project of any modest or large
size is delivered with documentation on such elements as the following:
• Database Structure and Relationships
• Ongoing Maintenance of the System
• Principal Processing Logic
• Primary Development and Coding Techniques Employed
• Strategies for Extensibility
In this topic, include or refer to such system documentation elements. The documentation should list or diagram any information
here that will be useful for sustaining the ongoing health of the data and its use. System documentation should provide an adequate
road map for future developers to follow when diagnosing problems or designing enhancements.
{Add paragraphs here describing the system documentation.}
Database Administration
The preceding System Documentation topic noted that you should detail the important procedures for system maintenance. The
information presented in that topic provides a physical "map" to guide administrators through the database. This topic augments that
information by describing the political components of database administration, which should include at least the following points.
When writing the four topics below or your own additional topics, try to imagine that you were not involved in the creation of the
database but rather inherited the day-to-day administration of it after deployment, and ask: "What information would I need to be
successful in fulfilling such duties?"
Database Software Project Design Specification Outline, Page 16
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
{Add an intro paragraph here describing how the following four subtopics define the political components of database
administration.}
Administrators
In this topic, note who will administer the database and what the scope of each person's responsibilities and authority will be.
{Add a paragraph here describing the database administrator(s).}
Backup Policies
Note here the backup policies for the database back end, including backup times, responsible parties, and off-site storage plans.
Describe resolution steps for "bumping" users from the application so that repairs, compacts, tune-ups, and backups can get exclusive
locks on the data file(s).
{Add paragraphs here describing backup policies.}
Disaster Recovery
What are the disaster recovery policies for the application? In this topic, detail the recovery steps for the "worst case scenario,"
usually the destruction of the data server or the building in which it resides.
{Add paragraphs here detailing disaster recovery steps.}
Adding Users
In this topic, describe how new users will be added to the system and who will determine their security levels.
{Add paragraphs here describing who adds new users and how.}
Localization
The world keeps getting smaller, and design teams must often explore the ramifications of installing an application in a branch of the
company outside of the country it was created in. If the design team comes up with recommendations or strategies for making the
localization (translation) of the application easier, document those strategies in this topic along with any suggestions for transnational
installation, configuration, training, export/legal issues, and documentation.
{Add paragraphs here describing strategies for localization and export.}
Ongoing Support
The spec should address not only the ongoing management of the database but the ongoing support of its users as well. This is done
in the following three subtopics.
{Add an intro paragraph here describing how the following subtopics detail ongoing support.}
Supporting Users
This topic describes how users will be supported when they have questions. Note support mechanisms, including support by
telephone, e-mail, voice mail, fax, pager, intranet, knowledge base, or in person. Also designate support personnel and define targeted
response/turnaround times.
{Add paragraphs here describing support mechanisms.}
Reporting Problems and Enhancement Requests
Ideally, the company infrastructure provides a mechanism for users to report issues, problems, and suggestions generated as they
interact with the application. This topic should detail such mechanisms and how they will be set up and maintained.
{Add paragraphs here describing how users provide feedback.}
Database Software Project Design Specification Outline, Page 17
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Problem/Enhancement Resolution Guidelines
Every user and developer wants issues (especially bugs) addressed immediately, but managers usually have to prioritize the issues
for attention in order of importance, taking budgetary concerns into consideration. The policies and procedures for making such
tradeoffs should be noted in this topic, as well as the expected staging for interim releases that address accumulated issues.
{Add paragraphs here describing how reported issues are handled.}
Future Releases
In addition to planning for interim builds (sometimes called “maintenance releases”) in the previous topic, the spec document should
discuss expected major future development phases and releases. Some specs may actually detail future features in the current
specification – as a result of forethought applied by the design team – and note the expected future phase in which each feature will be
implemented. In other cases, this topic provides only a reference to the staging of future phases, with a notation of the timetable and
procedure to be used to begin design work on each future phase.
{Add paragraphs here describing the expected major future development releases.}
3E. Project Management
This subsection of the specification lays out the details related to ongoing management of the project.
{Add an intro paragraph here describing how this subsection will detail ongoing management issues.}
Affected Users and Related Parties
An application always has one or more direct (hands-on) users. There is usually also a "ring" of other people around this user group
that are affected by the application (this is called "spillover"). This topic describes affected parties and how they will benefit from the
application's calculations, reports, or other outputs, even if they are not direct users of the technology. Also define the alteration of the
workflow of nonusers, the linking of data from this project to other systems, or the flow of data beyond the target user group.
Because not all people affected by technology are affected in a positive way, this topic should also address such areas as worker
displacement or reassignment brought about by the solution. Note any political ramifications of such spillover and how these will be
addressed.
{Add paragraphs here describing affected non-user parties.}
Project Timelines
In this topic, note the definition of “final delivery”, including the specific components of the delivery:
Timelines. List here the process steps of the project, and the order in which they will be executed. Include a spreadsheet,
Gantt chart, or other visual depiction of the project timeline here or in the Appendixes section, if possible.
Milestones and Acceptance. Describe the major milestones of the project, exactly what will be delivered at each
milestone, and what review and acceptance processes will be used to assure that the delivery complies with expectations.
{Add paragraphs here defining “delivery” and “acceptance” and showing timelines.}
Responsible Parties
Each of the major roles in the project must be delegated to individuals in the company or to contract resources. This topic should
describe the parties involved in the project and their roles. An effective project team includes people with a variety of responsibilities.
{Add paragraphs here describing the project parties, or complete the table.}
Role
Program Manager
Project Manager
Development Manager
Developers
Ultimate Users
Person(s)
{name the hands-off manager responsible for fitting the project into the company's mission}
{name the hands-on manager responsible for oversight and delivery}
{name the manager of the development team}
{name the coders and testers}
{name the highest-level beneficiaries of the project}
Database Software Project Design Specification Outline, Page 18
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
User Representatives
Users
IT Liaison
Support Personnel
{list the user community representatives participating in design and development oversight}
{list the users of the released product}
{name the Information Technology group member who fits the project to IT's business model}
{list the ongoing maintenance and support staff}
Project Administration
In this topic, describe more clearly the guidelines and techniques that will be employed by the project manager to ensure a timely
and successful completion. Include a discussion of political issues such as scheduling of meetings, coordination of parties, lines of
authority and accountability, and resolution of disputes within the project team.
{Add paragraphs here describing people-management issues.}
Issue Management
Discuss in this topic what strategies will be used for managing open issues during development and measuring their completion. The
spec should establish clear communication and feedback methods and even name tools and methodologies to be employed, where
appropriate. Too many project development efforts rely on cryptic voice messages and hand-scrawled notes when better
communication and time-management technologies exists.
{Add paragraphs here describing strategies for managing open issues during development.}
Risk Management
As part of a realistic approach to managing development, the spec should list the possible pitfalls and failure scenarios that may
complicate the project. A strategy for dealing with the most likely or dangerous risks should be discussed by the design team, and then
documented here.
{Add paragraphs here describing contingency strategies for identified dangers.}
Coding and Documentation Standards
In some applications, most frequently those that will be delivered to or maintained by a large corporation's IT personnel,
development standards may be imposed upon the application development team. Any such standards or approaches related to coding
policies, source code and version control, in-line documentation, team development, object management, naming conventions, and so
forth should be described in this topic.
{Add paragraphs here describing development standards.}
Future Phases
In the topic Future Releases, future versions of the application were described from the perspective of their features and
functionality. In contrast, this topic notes items deferred to – or consciously planned for – future expansion, and discusses their
managerial consequences, as follows:
• What is the objective of each future phase?
• When does the phase start and end?
• Who will manage the phase?
• Who will design the phase?
• Who will develop the phase?
{Add paragraphs here describing future versions.}
3F. Financial Mechanics
This subsection provides the details to support the financial (costing) information provided earlier in the Executive Summary section.
{Add an intro paragraph here describing how this subsection will detail costs.}
Database Software Project Design Specification Outline, Page 19
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Costing
Provide detailed cost breakdowns here, listed by phases, months, milestones, or other logical arrangement. Remember to include the
cost of equipment upgrades, components and tools, training, and other nondevelopment capital outlays.
{Add paragraphs and/or tables here providing detailed cost breakdowns.}
Third Parties
Use this spec topic to name the parties outside of the company that will be involved in the development and deployment. Third-party
vendors may be utilized to provide contract services for design, project management, program coding, testing, documentation
authoring, equipment upgrades, or training. Each party should be listed, along with contact persons, scope of responsibility, and similar
management information.
{Add paragraphs here describing third parties and the management of their work.}
Contractual Issues
If any third-party labor is to be used in the course of the project (as defined in the preceding Third Parties section), you may want to
include here text describing the contractual or other legal relationship with each vendor. Note the contracting parties, the major
contract elements (which should include topics such as non-performance, poor performance, and code ownership), mechanisms for
enforcement and dispute resolution, and other legalities.
{Add paragraphs here describing the contractual or legal relationship with vendors.}
Database Software Project Design Specification Outline, Page 20
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
4. Data Structures and Rules
The first three main sections of the specification constituted the business issues and application processes portions of the document.
Beginning with this section, the specification content moves from a managerial plane to a highly technical one.
This major section provides the blueprint for construction of the foundation elements of the database application: the data tables and
the business rules for validating the data that they hold. Just as a house built on sand will settle and crack, an application built on an
incomplete data structure or inaccurate data will quickly show signs of strain, so this is the area where you will expend the most time
when creating the spec. The wishes of the users, as filtered through and clarified by the design team, are distilled from screen and
report designs into table structure definitions here.
{Add an intro paragraph here describing how this section provides the blueprint for the database back-end.}
4A. Data Models and Diagrams
In this subsection, include any visual representations of the database schema (structure). At the simplest level, a graphical
representation of the primary tables and their relationships is a common inclusion in this subsection. For more detailed specifications,
structure diagrams called “Entity Relationship” diagrams and “Object Role Model” diagrams may be appropriate. If the diagrams are
large or too awkward to place here, include them in the Appendixes section and reference their location here.
{Add diagrams here describing the database schema.}
4B. Schema Definition
This subsection provides a place to document each facet of the database structure.
{Add an intro paragraph here describing how this subsection will detail the database structure.}
Table Structures
For each data table, include a listing in this topic of the table fields, indexes, and all related properties. The layout and depth of this
information varies across different developers and projects. LDF advocates using spreadsheet documents to list tables and fields and to
capture the primary properties of both. This allows the design team a single, common platform from which to actively discuss and
clarify the fine points of the data structure. Alternately, databases designs can be recorded and diagrammed using various retail
development tools. Some development groups believe that the development team is responsible for assigning properties to table
structures and do not burden the design team with any details beyond the field names and sizes.
If the table structures can be expressed in tabular format in the spec document, include the tables here, or attach the layouts to the
Appendixes section and reference their location here.
{Add paragraphs and tabular listings here defining data tables and their elements, or reference the appropriate appendix.}
Stored Views
Saved views or queries are used to provide concurrent access to data in multiple related tables. Document here these saved objects:
• “Data aggregation” queries joining sibling records or tables in parent-child relationships, for quick access and reuse.
• “Record source” queries providing selective datasets used to drive forms and reports.
• “Action” queries to move, update, delete, and otherwise alter data records.
{Add paragraphs and tabular listings here describing saved queries.}
Table Relationships
In this topic, describe the relationships between the tables, how they will be created, and how data integrity between related records
will be enforced. The relationship information should match the visual depiction of the database structure in Data Models and
Diagrams previously.
{Add paragraphs and tabular listings here describing table relationships.}
Database Software Project Design Specification Outline, Page 21
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Business Rules
The database engine may provide some built-in mechanisms for data validation. Additionally, most applications include some
programmatic data validation. Since the integrity of data is one of the paramount missions of both the back-end database and its
application, validation criteria (called “business rules”) should be crafted by the design team in conjunction with the developers and
documented in detail in the specification. Validation may be performed during entry, edit, deletion, archival, and batch/bulk
processing.
{Add information here documenting all data validation rules.}
4C. Data Load
When building a database application, it is helpful to document for the development team in this subsection the quantities of users
and data that the application and data structure must ultimately support. Such information assists the developers in performance tuning
the application, load balancing, and addressing multi-user issues.
{Add paragraphs and/or tables here describing the amounts of expected users and data.}
Initial Volumes
List in this topic facts about the initial load on the application, including the expected number of concurrent users, data transactions,
and record loads for each table. Discuss also the quantity and quality of data to be preloaded from existing systems.
{Add paragraphs here describing the initial load on the application.}
Future Volumes
This topic should provide tables or graphs showing how the user and data loads on the application will change over time. Begin with
the load information in the preceding topic Initial Volumes and project it forward to various time milestones in the life of the project.
{Add paragraphs, tables, and/or graphics here showing how the data and user loads will change over time.}
Database Software Project Design Specification Outline, Page 22
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
5. Screen Forms
The degree of form information included in the specification varies by project. Because much of an application's cost is in the forms,
you will usually describe entry, edit, dialog, menu, and other forms explicitly in this topic to avoid expensive reworks later in the
project.
The navigation map diagram for moving between application forms, described in the Application Processes section earlier, fits just
as well in this topic, if you prefer.
{Add an intro paragraph here describing how this section defines the forms.}
5A. User Interface Guidelines
In this subsection, note the standards and policies of the company or user group that will dictate the "look and feel" of the
application’s forms. Standards are developed by taking into account the following considerations regarding the application’s expected
users:
• What are their skills and habits?
• What applications do they use now?
• What do they like and dislike about their current software toolset?
• What job are they ultimately trying to do with this application?
• What shortcuts do they need when in a hurry?
• How do they locate information?
• How do they enter and edit information?
• How do they verify and audit information?
• Do they multi-task or single-task?
• Do users job share? Equipment share?
• What are their abort patterns? When and why do they have to cancel or rollback processes?
• How do they deal with interruptions, keep their place when they leave their desk, and recover from disasters?
{Add an intro paragraph here describing how this subsection will illustrate interface standards.}
Form Layouts
Note here any standards for the layout of forms, such as the preferred location of command buttons, the justification
(left/right/center) of labels and other controls, the use of sunken versus flush or raised effects, whether MDI is allowed, and so forth.
{Add paragraphs here defining standards for form layouts.}
System Messages
Describe in this topic any special considerations about how messages (alerts) should be displayed for users. For example, some
applications make use of error messages built in to the platform/language, while in others the developers try to make the messages
more friendly and descriptive. Also, some companies put information about their HelpDesk or other technical support options in
system messages or prescribe specific captions to be displayed in alert dialog boxes.
{Add paragraphs here defining standards for alert messages.}
Fonts and Point Sizes
Note here the user interface standard to be followed by the development team for the use of fonts. A variety of issues crop up in this
area, including the following:
Fonts and Point Sizes for Buttons. If the application's standard will differ from the Windows standard, note that fact
here.
Fonts and Point Sizes for Data and Prompts. Depending on the application, the users, the resolution of the average
workstation, and other factors, the default font and size for labels, text boxes, combo boxes, and similar controls may
differ from the defaults provided by the platform or development tools.
Database Software Project Design Specification Outline, Page 23
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
It may also be wise to specify here the names of all fonts allowed in the application so that there is no danger that the developers will
include a font in the application that is not installed on a user's workstation.
{Add paragraphs here defining standards for fonts.}
Colors
Form layouts can range from the simple to the gaudy. If any company standards exist for use of color in labels, prompts, status
strings, or any other form or report controls, note them here.
{Add paragraphs here defining standards for the use of color.}
Buttons
Button sizes in applications vary across the map. If a button is sized to include all of its text, it can get quite large. Note in this topic
any standards for buttons, their size, shape, location, and captions. Describe also any layout standards for dialog boxes, for example
whether the OK and Cancel buttons are at the bottom or at the right (both are accepted Windows models), or are located somewhere
else.
{Add paragraphs here defining standards for command buttons.}
Switchboard Menus
A switchboard menu is a form that helps users navigate. It may utilize buttons, list boxes, tab controls, and graphics with hotspots.
Describe in this topic the standard to be employed for switchboard menus in the system.
{Add paragraphs here defining standards for switchboards (form-based menus).}
Bar Menus
Bar menus provide the overall navigation and generic options for the application. Describe in this topic any standards for bar menu
taxonomy, placement of options along the bar or pulldowns, and the tradeoffs between application-specific and form-specific menus.
You should also note here any standards for matching bar menu options to toolbar options and command buttons in forms, and the
programmatic approach to take when sharing code among these several activation methods.
{Add paragraphs here defining standards for bar menus.}
Shortcut Menus
Shortcut (right mouse button or “context”) menus are very useful and powerful options. As such, designers and developers of
applications must use some restraint to avoid the tendency to place dozens of options on these menus. Describe in this topic the
standard approach to shortcut menus and how the listed features will duplicate or augment features available on the bar menu or
toolbars.
{Add paragraphs here defining standards for shortcut menus.}
Toolbars
Toolbars are one of the most powerful Windows application features. Describe the standards for toolbars in your application, paying
special attention to standardized actions, locations, tool tips, and button faces.
{Add paragraphs here defining standards for custom toolbars.}
Keyboard and Mouse
Every application user has a different balance in their dependence on the keyboard versus the mouse. This fact can come into play in
simple areas in application development, such as the debate whether to place graphics on buttons or text with keyboard accelerators.
Note here any concerns or standards for keyboard and mouse use relevant to the project.
{Add paragraphs here defining standards for keyboard and mouse use.}
Database Software Project Design Specification Outline, Page 24
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Status
Most custom (and retail) applications lack sufficient visual user feedback. Define here any mechanisms that the application should
employ to provide users with status information. Examples include the following:
Mouse Cursor. Programming the mouse to become an hourglass in all areas where the user is waiting on the system
produces a big improvement in the usability of an application.
Status Bar. Define how the status bar area will be employed to tell users what is currently taking place or what action is
expected.
Message Boxes. Most data processes that affect records should show an alert before running to ask the user to confirm
the operation. In some applications, you will also show an alert at the end of the process so that the user knows the
process ran to completion. This is especially true of bulk operations like mass deletes or exports. Detail issues like these
in this topic.
{Add paragraphs here defining standards for the presentation of status information.}
Terminology
Most companies employ standardized terminology for their commonly used business terms, or they should. Document such terms in
this topic.
Within an application, it can be very confusing for users to see the same data item referred to with different terms, for example a
“Buyer:” prompt on one screen and a “Customer:” prompt on another but both relating to the same data item. The specification process
often forces a discussion of terms and how they should be consistently used, which benefits not only the current application but
company communication processes in general.
{Add paragraphs here defining standardized terminology.}
5B. Structural Information
In this subsection, include specific information for each form in the system. The information should be detailed enough to allow the
developers to build the forms and create the associated program code.
{Add an intro paragraph here describing how this subsection provides the specific layout for each application form.}
{name of the first form}
Each topic header from here to the remainder of the Structural Information section will be the name of a form in the application.
Each form is named, then followed by the topics from Purpose through Validation for that form.
{Add a paragraph here providing a short description of the named form.}
Purpose
Describe the purpose of the form and any unique attributes.
{Add paragraphs here describing the form.}
Mockup
Include a sketch, drawing, or screen capture of an actual mockup of the form here, showing as much detail as is required to allow a
developer to achieve the user's objectives. Some specification authors prefer to keep all the form mockups together, placing them in an
additional subsection (5C) after the structural information or as an appendix item.
{Add one or more diagrams of the form here.}
Data Source
Note the data source for the form, which may be a table, query, or SQL string (or an English textual representation of it). Describe
how the data source may change based on user interaction or other criteria. Note any allowed manual or programmatic filtration or
sorting capabilities.
Database Software Project Design Specification Outline, Page 25
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
{Add paragraphs here describing the form’s record source.}
Navigation
Describe how the form is activated and deactivated. Include a discussion of each of the following points:
Entering. Describe how this form is activated and any specific logic that will occur on the form's initiation (open, load,
activate, etc.) events.
Exiting. Note how the user leaves the form, whether by closing or branching to another form.
Bar Menus. Describe the contents of the menu to be used with the form and the logic attached to each nonstandard
option on the menu.
Shortcut Menus. List the options included on the shortcut menu for the form and the logic attached to any nonstandard
options on the menu.
Toolbars. Note the buttons that will be on this form's toolbar and the action or code routine that each tool will call.
{Add paragraphs here defining the form’s navigation and interface elements.}
Controls
Note any special properties or other considerations about controls that are not reflected by the mockup diagrams, including
information about property changes and events that should be programmed. For example, selecting a value in a combo box may require
code to trigger an immediate requery of a dependent control.
{Add paragraphs here describing unique control attributes.}
Events and Procedures
List in this topic any form events that should contain code procedures, and outline the procedure code. Also describe any nonevent
procedures that should be included, such as validation code, data processing routines, and the like.
{Add paragraphs and/or pseudocode here for form-related procedures.}
Properties
Describe the properties of the form that will be set to non-default values.
{Add paragraphs and/or listings here describing non-default form property settings.}
Validation
Validation features for form records can be a significant portion of both the design team's and development team's effort. As clearly
as possible, spell out the data validation requirements and enforcement mechanisms here for information that is entered or edited via
the form. Define validation at the field/control level, and detail how the validation event will be achieved (table rule, form rule,
program code at record save, program code in a batch, and so on).
{Add paragraphs and tables here describing data validation.}
{name of the second form}
Add another topic whose title is the name of the next form. Repeat for the form the previous subtopics from Purpose through
Validation and fill in the appropriate information. Then do the same for the third form, and so on until all forms are documented.
{Repeat here the preceding information for each form in the system.}
Database Software Project Design Specification Outline, Page 26
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
6. Reports
The people who read an application's reports are usually the ones who write the checks to pay for development. Thus, making sure
that their needs are properly met is one of the primary objectives of the specification.
In this section, the spec should clearly detail the reporting requirements, creating a plan for developers to follow.
{Add an intro paragraph here describing how this section defines the reports.}
6A. User Interface Guidelines
In this subsection, note the standards and policies of the company or user group that will dictate the design and programming of the
reports.
{Add an intro paragraph here describing how this subsection will define the standards and policies for the organization of reports.}
Report Layouts
Note here any standards for the layout of reports, such as the justification (left, center, or right) of labels, column headers, and
controls. Also describe the use of sunken versus flush effects, the look of headers and footers, and so forth.
{Add paragraphs here defining standards for report layouts.}
Fonts and Point Sizes
Note here the user interface standard to be followed by the development team for use of fonts. Describe how the fonts vary for
prompts versus data values, how page and group headers and footers will use fonts and sizing, and similar display issues. In general,
most users will prefer a larger standard font for reports than for screens.
It may also be wise to specify here the names of all fonts allowed in the application's reports so that developers understand the
limited range of fonts to use when creating reports. Otherwise, the look of different reports in a system might vary widely as different
developers each apply their own style, or reports may attempt to print using a font not supported by a specific printer.
{Add paragraphs here defining standards for fonts.}
Colors
Note here if report controls will have any coloration requirements that affect how they are previewed to the screen or how they will
print if the target printer makes use of color.
{Add paragraphs here defining standards for the use of color.}
Bar Menus
Navigation within reports that are previewed is usually limited to printing and closing the report. Describe in this topic the exact bar
menu options to be used/allowed for the application's reports in preview mode, any specific menu taxonomy, the placement of menu
options, and menu coding requirements.
{Add paragraphs here defining standards for bar menus.}
Shortcut Menus
Use this topic to list shortcut menu features, menu taxonomy, placement of options, and coding requirements if shortcut menus will
be allowed when a report is previewed.
{Add paragraphs here defining standards for shortcut menus.}
Toolbars
Describe the standards for toolbars to be displayed when reports are previewed, and note how the toolbar options tie to related bar
menu options.
{Add paragraphs here defining standards for custom toolbars.}
Database Software Project Design Specification Outline, Page 27
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Terminology
Document and define in this topic the standard company terms that will be used when creating reports. It is especially important to
consider report terminology and to make sure it appeals to the widest possible audience in the following two cases:
The audience extends beyond users of the application. Personnel reading reports who are not familiar with the system
will not understand terms defined only within the context of the system. Reports should use generic terms or include the
definition of specific terms in the report footer or endnotes, if necessary.
The audience includes managers. When managers will be using specific reports for corporate decision making, it is
important to use terms that fit their vocabulary and job role. For example, a report that shows the total value of inventory
items per product could legitimately label the total "InvQty," which is the table field name and a shorthand for "Inventory
Quantity." However, management-level users of the report may get more value from the data item if it were labeled
"Inventory On Hand" or other term that ties to their common vocabulary.
{Add paragraphs here defining standardized terminology.}
6B. Structural Information
In this subsection, include specific information for each report in the system. The information should be detailed enough to allow the
developers to lay out the reports and create the associated program code.
{Add an intro paragraph here describing how this subsection provides the specific layout for each application report.}
{name of the first report}
Each topic header from here to the remainder of the Structural Information section will be the name of a report in the application.
Each report is named, then followed by the topics from Purpose through Properties for that report.
{Add a paragraph here providing a short description of the named report.}
Purpose
Describe the purpose of the report and any unique attributes.
{Add paragraphs here describing the report.}
Mockup
Include a sketch, drawing, or screen capture of an actual mockup of the report here, showing as much detail as is required to allow a
developer to achieve the user's objectives. Some specification authors prefer to keep all the report mockups together, placing them in
an additional subsection (6C) after the structural information or as an appendix item.
{Add one or more diagrams of the report here.}
Data Source
Note the data source for the report, which may be a table, query, or SQL string (or an English textual representation of it). Describe
any parameters passed to the report and how the user will be allowed to enter or alter the parameters to show selective datasets.
Also describe in this topic the sorting and grouping that will be used to order the data on the report.
{Add paragraphs here describing the report’s record source.}
Navigation
Describe how the report is activated and deactivated. Note every place in the application where the report will be available and how
the user will activate the report at that point and select the data to be printed. Also note the following navigation points:
Bar Menus. Describe the contents of the menu to be used with the report and the logic attached to each nonstandard
option on the menu.
Shortcut Menus. List the options included on the shortcut menu for the report, if any, and the logic attached to any
nonstandard options on the menu.
Database Software Project Design Specification Outline, Page 28
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
Toolbars. Note the toolbar buttons that will be on this report's toolbar and the action or code routine that each tool will
call.
{Add paragraphs here defining the report’s navigation and interface elements.}
Controls
Describe nonstandard property settings for report controls and information about the use of report controls that is not obviously
inferred from the mockups. Detail the logic for computed control values, totals, and other report calculations.
{Add paragraphs here describing unique control attributes.}
Events and Procedures
List in this topic any report events that should contain code procedures, and outline the procedure code. Also describe any nonevent
procedures that should be included, such as calculation or layout routines that must occur before the report is run.
{Add paragraphs and/or pseudocode here for report-related procedures.}
Properties
Describe the properties of the report that will be set to non-default values.
{Add paragraphs and/or listings here describing non-default report property settings.}
{name of the second report}
Add another topic whose title is the name of the next report. Repeat for the report the previous subtopics from Purpose through
Properties and fill in the appropriate information. Then do the same for the third report, and so on until all reports are documented.
{Repeat here the preceding information for each report in the system.}
Database Software Project Design Specification Outline, Page 29
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
7. Appendices
In this section, attach supporting documents that are not part of the specification document file or are quite large and are less
obtrusive to the flow of this document when placed at the end.
{Add an intro paragraph here stating what items are included as appendices.}
Data Diagrams
If the diagrammatic representations of the database structure were too large to fit neatly into the subsection Data Models and
Diagrams of the spec body, attach them here instead.
{Add diagrammatic representations here of the database structure.}
Database Schema
Large and unwieldy table structure documentation may be easier to include here rather than the Schema Definition subsection of the
spec body.
{Add table structure documentation here.}
Process Flow Diagrams
Process flow charts are useful to help describe a workflow that has been targeted for automation or to convey the refined workflow
of the new system. Place such flow charts here or in the subsection Solution Description in the main portion of the spec.
{Add workflow diagrams here.}
Form Mockups
In an application with many forms, it may be organizationally easier to include all form mockups together here rather than as topics
in the Structural Information subsection of the form definition area of the specification body.
{Include form mockups here.}
Report Mockups
Attach report mockups here if you prefer to keep them out of the in the Structural Information subsection of the report definition
area of the specification body.
{Include report mockups here.}
Project Timeline
If the project timeline is expressed by a large task list or Gantt chart, include the timeline here rather than trying to cram it into the
Project Timelines area of the spec body.
{Add a project timeline, task list, or Gantt chart here.}
Test Plan
Include the test plan here if it is too large to place in the Test Plan section of the spec body.
{Add the test plan here.}
Design Team Notes
Attach relevant notes, documents, and work papers produced during the design team meetings and research.
{Attach design work papers here.}
Database Software Project Design Specification Outline, Page 30
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA
History Application
Attach reports, screen shots, training manuals, or other documentation from the existing system(s) to be replaced by this application.
Such information was probably used as the starting point for design discussions on this project.
{Add documentation here for the existing system(s) to be replaced.}
History Data
Document the data structures of legacy (history) data to be imported/preloaded into the new system.
{Include data structure documentation for legacy data here.}
Integration Information
Document the data structures and flow of other systems that will integrate (share their data or interfaces) with this application.
{Add integration documentation here.}
Future Phases
Include here any documentation and project planning information for future phases of this project that expands on the Future
Releases topic earlier in the spec.
{Add documentation for future phases here.}
—End of Document—
Database Software Project Design Specification Outline, Page 31
SPECSHEL.DOC Template Copyright © 1995-96 Leszynski Company, Inc., Bellevue WA