System Design Specification and Review

An SDS takes the System Requirements Specification (SRS) and breaks it down into sections of a puzzle. The puzzle includes the following steps:

Top Level Design

Usually this is a series of diagrams that link sections of the puzzle together. The diagrams show the flow of data and how one module links to another. They do not show detail such as iteration or specifics such as "customer name"

The above process shows the basic process of making a cup of coffee. The process shows a black coffee and a white coffee, but has a very obvious mistake. Can you spot it?

The mistake is no hot water or sugar! A minor point if you want a hot cup of coffee with one sugar and milk.

The above example is a trivial example of how the design process breaks down. Used correctly it becomes a powerful medium to describe what it is the client wants to achieve.

Module Design

Each bubble in the above diagram represents a module. A module is a semi process, something that needs to happen.

In our example, the module "Make a Coffee" breaks down into three minor modules, each being an important process in making a coffee.

Once the system as an entity has been broken down far enough into modules, then these modules can be designed. For example "Milk" cannot be broken down any further and describes clearly what it does. Maybe "Insert Milk" would have been better.

Module Testing Strategy

Once we know the modules and what they do we can design a test strategy for them. For example "Coffee Powder". What happens if we run out of coffee? What happens if there is more than one choice of coffee? These test conditions will ensure that the software developer has adequate conditions in place when developing the software.

Integration Testing Strategy

When all the modules are brought together they need to be tested. For example, what if we have tested the modules individually for one cup of coffee and the system must make many? We need to test that the kettle has enough water for all the coffees we wish to make.

Integration is the connection of more than one module and is a complex operation. The test strategy must ensure that as many problems have been ironed out as possible before a single line of code has been written.

Project Plan

Each module will have a time-scale for completion. The integration and unit testing will also have a time-scale. The designer will know what manpower they have available for the project and so all this information can be used to plan the project.

The project plan should show when a module will be developed based on a project start time and based on preceding modules. For example developing the module "Inserting Coffee" cannot take place until "Get A Cup" is complete otherwise the coffee will spill on the floor.

System Test Strategy

The system test strategy is how the company plans to test the finished article without using live data. For example, if we use actual coffee for our testing then it could become quite expensive. A better solution would be to use a cheaper alternative.

The STS should detail how the system will be tested to mimic the actual live system. This will usually involve copies of test data in a test harness.

Once the SDS has been finished, the client and project peers must review the document. Mistakes found here will be cheaper to fix than if found at a more advanced stage of development.

 top