How to design a solution

When designing a solution, you have to make sure that the solution is not based on a particular product. Below is a basic design document that you should use when designing a solution which is based on SSADM.

Its very important to remember when undertaking a new project, that good design will overcome bad programming, but good programming will never overcome a bad design. If you design a technology based solution that does not work when you need it, you would have used technology to drive up your costs.

The worst thing you can do is buy a product, then design your solution around that product.
i.e Buying Crystal Reports then finding a solution that only can use Crystal Reports functionality

What you should do is design a 'Report' solution, then evaluate all the reporting products on the market that can fulfill for your design which may in the end be the Crystal Reports product.

Another bad practise is to design your solution on the fly, so that means coding and designing at the exact same time without a clear path to the solution. If you dont know where you are going, every path will take you there. So I would advice you to use a design document like the one below to aid you in your solution process.

1 Introduction

2 Business Activity Model
2.1 Fact Finding Methods
Stakeholder Analysis

2.2 Functional Requirements
1) Easily to implement
2) Easy to maintain and upgradeable

2.3 Current Physical Data Flow Diagram
2.4 Current Logical Data Flow Diagram

3 Technical system options
3.1 Assumptions and Dependencies
The finished solution will be using the .NET Framework to access the Acme Network. Any databases that are used for the solution will use either SQL Server 2005 or SQL Server 2000.

3.2 General Constraints
3.3 Goals and Guidelines
The design goals for this project are as follows

· KISS (Keep it Simple Stupid).
· Design with the ability to provision numbers quickly and reliably.

4 Detailed business specification
4.1 Physical Data Flow Diagram: Option 1
4.2 Logical Data Flow Diagram: Option 1
4.3 Logical Data Model Diagram: Option 1
4.4 User Interface Design: Option 1
4.5 Risk Assessment: Option 1
4.6 User Roles: Option 1

5 Logical design

In this stage, technically feasible options are chosen. The development/implementation environments are specified based on this choice. The following steps are part of this stage:

· Define BSOs (Business Systems Options). Its purpose is to identify and define the possible approaches to the physical implementation to meet the function definitions.It also validates the service level requirements for the proposed system in the light of the technical environment.
· Select BSO. This step is concerned with the presentation of the BSOs to users and the selection of the preferred option.


6 Logical process design

In this stage, logical designs and processes are updated.

Additionally, the dialogs are specified as well. The following steps are part of this stage:

· Define user dialogue. This step defines the structure of each dialogue required to support the on-line functions and identifies the navigation requirements, both within the dialogue and between dialogues.
· Define update processes. This is to complete the specification of the database updating required for each event and to define the error handling for each event.
· Define enquiry processes. This is to complete the specification of the database enquiry processing and to define the error handling for each enquiry.

7 Physical Design

· Screenshots
· Prototypes

8 Policies and Tactics
Test Description and Test Plans
Outcome
8.1 Error Codes

9 GLOSSARY