Solutions Design Documents

Purpose

Solution design describe specific characteristics that a product must have to meet the needs of the stakeholders and the business itself. They fall into two large groups. Functional requirements define what a product must do, what its features and functions are.

In laymen terms this is a document that allows both the Solutions Team and business users to collaborate in and around a new feature or enhancement requested.

In the document we establish key components that have in the past shown to ensure optimal delivery satisfaction:

• Rationale for the requested item/s (Aids parties to ensure that the reason for requesting the item/s make/s sense)
• Requirements for the requested item/s (Offers a hit-list of requirements for the technical team to hit)
• Front-End & Back-End Implementation Idea's/Suggestions (Offers the Technical Team a chance to brainstorm and table suggestions for practical technical implementation and feasibility)
• Sign off Criteria (NB but often most neglected - sign off criteria doubles as testing criteria and offers both technical and non-technical users the opertunity to specify what they will need to see/not see and have happen/not happen to consider the feature complete - this helps define the scope and offers the technical team practical hit points on delivering automated testing)

How To Get Template

We have saved a template file to the organisations Google Docs Templates.

Anywhere you create a new Google doc you should have the option to do so from a Template.

(From Google Drive if you right-click the context menu offers you such a option)

Look for the SDD or Solutions_Design_Document_Template

(From Google Drive Template Gallery)

Clicking on the template will create a new document with it as the base in the location you have specified.

How to Complete

The document consists of predefined headings. Each invites all parties to complete to aid in feature/enhancement delivery and defining.

Glossary

Meant to add any business domain or technical wording and explanation that won't be clear to all users. (Boyscout Rule: if you find yourself asking and getting clarification for a term be sure to add it to the glossary)

Requirements (The What)

What the feature or enhancement requirements are - practically what new is needed, what should it do, what should change, what should be removed, what should happen if something is added, removed, changed etc. this is esentially the business logic well worded and well-thought-out. (TIP - consider CRUD - we know these are the 4 information actions a system performs, it aids the business users immensely if we can flag up questions like: What if we delete a record? etc. etc.)

Rationale (The Why)

This is the section where the requester/s post their reasoning and motivation for the enhancement/feature. This aids parties to understand why something is needed and often leads to better solutions as what is asked isn't always that which will resolve the issue as reasoned.

Critical Path/User Story (The How)

An alternative approach to defining requirements - we invite the document drafters to close their eyes and consider the paths that they can imagine taking to make use of the feature/enhancement. The more scenarios the merrier.

System Parts Needed (The Implementation)

A section for a technical user to consider how best and what parts/changes will be needed form a system perspective. This offers a chance to do planning before getting stuck into implementation.

Front ENd

A section for wireframes, write-ups, diagrams for front end changes envisioned. New mark up, new forms, etc.

Back End

A section for wireframes, write-ups, diagrams for back end changes envisioned. New Tables, Fields, Controllers, etc

Testing & Sign off Criteria

By default, split into admin and non-admin users these are the Acceptance tests for having the feature/enhancement pass. These will outline practical application interaction taken and the desired outcome. Think I log in, and I see X, Y and Z. These will inform Cypress tests, Feature Tests and more. This also acts as the success criteria for the delivery of the feature/enhancement.