What is the difference between technical specifications and design documents?
A software design document can be at the level of a system or component, and generally includes:
- relevant goals or requirements (functional and non-functional);
- static structure (e.g., components, interfaces, dependencies);
- dynamic behavior (how components interacts);
- data models or external interfaces (external to the system/component described in the document); and
- deployment considerations (e.g., runtime requirements, third-party components).
Note that all of these descriptions are at an abstract level. The purpose is to give the reader a broad general understanding of the system or component. There may be many levels of design documents (e.g., system- or component-level).
A technical specification describes the minute detail of either all or specific parts of a design, such as:
- the signature of an interface, including all data types/structures required (input data types, output data types, exceptions);
- detailed class models including all methods, attributes, dependencies and associations;
- the specific algorithms that a component employs and how they work; and
- physical data models including attributes and types of each entity/data type.
So when should we actually write technical specification.? Before development? Along with development? or After ..?
@ShashwatTripathi generally, specifications are written before development, so that someone else (or you at a later time) can implement the components. Writing the specification after the development has been done, makes it kind of pointless (unless you use it as the technical documentation on what has been implemented).
I have come across this exact scenario working for a huge corp on a multi-year project. We worked backwards in creating a business requirements document after the project has been migrated to Test and then to Prod! Yeah, great project management, I know!
Doesn't the technical specifications get created after the details functionally decomposed Software Requirements Specification? How is an Architect to create a TS without SRS? It looks like he/she will need to assume a ton.
Agree, a TS should follow an SRS (system requirements specification). Note however hese terms are not standardized and a TS could get created as a either a detailed form of an SRS (typical in embedded systems), or it could be used to supplement a high-level SRS i.e. a design document (typical in commercial applications). The key point is that requirements, design and specification documents each describe one *specific view* on a system and its components. It is more important that a team agrees the views & level of detail required than meeting some formal definition.
Technical specifications, at least in the form of a technical design, are part of the design documents, along with, for example, requirements lists, functional designs, user stories, graphics design mockups, usability studies, UML diagrams, business process diagrams, data model specifications, etc.
Technical specifications of the type that you write after the fact, to document the finished product, are not generally part of the design documents, but they can be included in the set of design documents of a later version (for reference) or another product that relies on them.
Thank you. Also basically I need functional specification to know what to do and then design documents to know how to do, is that correct? Just a little question, what is the functional design you referred to (hope it wont add confusion to my understanding of functional spec)
A functional design defines the product's intended functionality, from a user's point of view, without going into implementation details. There are plenty of questions with excellent answers here that give exhaustive explanation about what a functional design is and is not.