The Technical Specification Document

The next step in project development is to produce a “technical spec,” which is a document describing how you're going to implement everything listed in the requirements document. The technical spec has to be separate from the requirements document because the audiences are different. While your functional requirements document is a “public” document that spells things out in nontechnical terms for a nontechnical audience (your users), the technical specification document is to help you with your current and future development efforts. Its audience is technical project managers, architects, and developers. If you do your job in producing the technical spec correctly, your developers will use it as a roadmap as they implement the systems specified in it. Because implementation is often where we learn things while initially writing the technical spec, the spec has to be “living” during the course of implementation.

The technical specification should contain a summary of the problem that the software addresses, a list of the original requirements for the system, as well as your real use cases if you've chosen to model your detailed requirements using real use cases (see the discussion in the section Quality Assurance), the data model diagram, an XML DTD, and a SQL Schema (the last two of which we'll discuss further in the next few chapters), in addition to other technical considerations, such as the development environment, the testing methodologies, the project plan, the separation of duties, and a user interface walk-through.