Monday 15th of March 2010

SDS - System Design Specification

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ... Posted on: July 15th, 2008 by admin

Now that you have chosen a company to design the SDS, whether you have given the entire project is irrelevant. The SDS is a unique project in its own right.

An SDS takes the 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 with another but 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. Clearly 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 not a cup with milk and coffee powder.

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 are important processes 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 there is a problem. 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 represent a time-scale for completion. The integration and unit testing will represent 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 be spilt 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 way to go maybe 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, then the document must be reviewed by the client and project peers internally by the company. Mistakes found here will be cheaper to fix than if found at a more advanced stage of development.

    Related posts

Leave a Reply

You must be logged in to post a comment.

Headlines

Feeds