Software Design Specification.
The objective of the software design specification (SDS) is to ensure that the final outputted software product meets the requirements of the end customer, i.e. functions as expected, is reliable, is easy to use, does not demand inordinate efforts to train staff in its use, etc.. Specifically, the software design specification is a description of the software components and sub-systems to be provided as part of the product. (Note: if there is only one software module, the design specification should contain enough information to enable the necessary code to be produced. In such situations, documents such as a module design specification, test specification and an integration test specification may not be required).A comprehensive SDS will detail the following generic information:
i) The specific “need(s)” to be fulfilled by the software.
ii) Information on how these “needs” will be met via linking to a set of “features”.
iii) How the “features” will address the customer requirements.
iv) How the “features” will be implemented.
v) Reference to the specific or overall approach to confirming effective implementation, i.e. the validation process.
“Software Validation | Introduction to the Concepts & Practices associated with Validating Software”.
In many organizations and especially those with a pre-defined quality management system, the format of software design documentation will be standardized. The following are generic requirements, widely applied, but can be modified to suit particular organizational needs.
i) Purpose of the software design specification (SDS) document. What is the end objective, the specific “needs” to be fulfilled? There may be possible options in addressing the customer “needs”. What scope limits may apply to the end software functionality? What may be the functional specification behaviours to be enabled and those not to be enabled?
ii) Approach to solving the customer “needs”.
iii) Reference documentation. As the software design specification is one in a series of related development and test documentation it must be clear where this document resides within the structure and hierarchy of the overall project. In addition, there may be documentation which details the change management and change control processes to be followed, the approach to auditing etc., which should all be referenced.
iv) Definitions, acronyms, and abbreviation.
v) Description of the system architecture, structure and relationships, user interfaces.
vi) Description of components. It may be preferable to create one or more component diagrams which detail the planned tasks to be performed and detailing the various interactions.
vii) Relationship to other components.
viii) Design decisions and trade-off’s.
viii) Costing – The estimated resource requirements, (often will be primarily the staff costs, but also hardware, equipment dedication times) for the range of tasks to be performed.
ix) Risks – Where there are potential risks to the entire project or risks in terms of significant variation to timelines, costings, etc., these need to be highlighted and options for minimizing and mitigating considered.
x) Pseudo-code for components.
xi) Appendices.
