Stage 3: Design

27 Feb

The third phase in SDLC is Design

In the previous stage, analysis, it addressed what can be done for the new system. So in this phase, design, it will set out how the parts of the system should be implemented in order to fulfil user requirements. Keep remembering that the design phase is all about HOW.

A logical design and a physical design must be created in this stage.

What is the difference between logical design and physical design? Well, logical design outlines what the functions of the system are. Then on the other side, physical design is a plan outlining how the system will be implemented.

Logical information resources include components such as data, processes, inputs and outputs. On the other hand, physical components outline how it will be implemented. The logical design is converted into the physical design.

Some techniques used to describe the system design include flow charts and data flow diagrams.

The steps involved in the design phase are:

  • Choosing DBMS (data base management system)
  • Establishing security standards for the system
  • Interface design (including features which allows users to interact with the system)
  • Data Capture Requirements
  • Standards for printed report production
  • System navigation methods

Some of the key deliverables from the design phase include:

  • Function Specification Document (outlines components such as data, inputs, outputs)
  • Technical Specification Document (including files and programs)
  • Implementation Schedule

It is also important to note that coding does not take place in this stage, it takes place in stage four: implementation. This phase of the SDLC will be discussed in my next blog post.


2 Responses to “Stage 3: Design”

  1. sad111359681 February 28, 2013 at 6:03 pm #

    Very interesting post. I will just add to it by talking a little about what a FSD (Functional Specification Document) is and what it is meant to achieve.

    An FSD is not a high-level business requirements document or a wish-list of stakeholders needs that may or may not be achievable. It is a compact document of those needs into a coherent view of what the system will actually be.

    An FSD informs developers so they know what to make and it is handed to testers so that they know what to test.

    • sad111456588 February 28, 2013 at 8:57 pm #

      thanks for that additional material, very helpful 🙂

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: