Sections of this topic
The Requirements document has been completed and approved. The next step in getting the product built according to the client’s wishes will be to create a Technical Specifications document to communicate all the technical information gathered from meetings. The document will contain detailed technical instructions and information for the development team (Developers, Engineers, Architects, and IT Managers).
Technical Specifications for most applications will include detailed data on the:
- design (look and feel) of the application,
- different data bases, constraints, tables, and platforms involved,
- images for designing and navigating through the application (i.e., graphics, process flow diagrams, data relational diagrams, charts, etc.)
- fields involved (i.e., length, numerical only, drop-down lists, check boxes, bullets),
- fonts, colors, images, or logos used (when and where),
- usage of new or reused application codes,
- types of error messages presented (when and where),
- types of security, privileges, and privacy notices to be created,
- functionality for web only, downloadable, or portable applications,
- necessary coding for static or future products,
- gathering of content,
- table of contents, glossary and appendix.
Depending on the product, the technical specification may also include detailed information on the:
- size and shape of a new, redesigned, or restructured product,
- characteristics to be included,
- types of benchmarks, compliance, or branding,
- transference and storage of the data or product (depending on the medium),
- functionality,
- layering,
- maximum load,
- durability, etc.
There is an inordinate amount of questions and information that need to be addressed and gathered for Technical Specifications. Depending on the industry, different specifications will be gathered. For car manufacturers, data gathered may involve specifications for building engines. For pharmaceutical companies, specifications may involve the environment under which instruments or medicines will be manufactured. Meetings with subject matter experts and those involved will aid in gathering all relevant data.
Once all data has been collected, organize the information into a logical, readable format. When the document is completed, and appropriate parties (project managers, manufacturers, engineers, etc) have approved and validated it, the development team can now use the Technical Specifications to begin building a well-defined prototype.
As a note, Technical Specifications differ from Functional Specifications. Functional specifications are written for the manager/supervisor, describing how the product works based on the Requirements document. It does not contain any detailed technical data. For example, if the product is an application, the Functional Specifications will describe the flow of the program, how one section leads to another, the type of system/equipment needed, as well as error messages. In addition, Functional specifications are different from User Guides; although in some ways they are similar. The User Guide contains a set of instructions for the user to follow; how to use the product, what to do and not to do, and what to expect. No matter which type of document is written, remember to always write for your target audience.
More information on User /Operations /Training Documents will be described in the next post. If you have any questions, or feel I’ve left out information or wish more information on an item, please leave a comment.
