Design document – HLD & LLD

Here we mainly focus on LLD alone..

Thanks to dinesh for explaining in a clear way..

1) What is design document?

  • The design document gives the main idea and structure of the product that would be developed by developers.

2) What are the different kinds or Types  of design documents ?

  1. High Level Design Document also called as HLD.
  2. Low Level Design Document also called as LLD.

In this article, we will discuss about LLD :

Low Level Design Document:

  1. Low Level Design (LLD) is like detailing the HLD.
  2. It defines the actual logic for each and every component of the system.
  3. Class diagrams with all the methods,Properties,variables and relation between classes comes under LLD.
  4. We can represent LLD of the application in many ways.
  5. Some of them could be : UML (Class diagrams,Interfaces,Sequence diagrams etc), Powerpoint,Screen shots and Pseudo code.
  6. This depends on case to case basis.

3) What is the approach for preparing LLD  or What parameters or points should be considered for preparing LLD ?

  1. Requirements should be understood clearly. Based on the requirements we can come up with LLD. Even for Agile methodology based on the initial requirements we can come with the initial design, but we need to fine tune the design as and when the requirements are clear. We need to refine the LLD till the requirements are freezed.
  2. Identify High level Entities. High level entities are objects, or groups of objects, that constitute major constructs of your design. Good examples of entities are a data access layer, a controller object, a set of business objects, etc…
  3. For each entity, define the low level design: This is where your objects and object relationships are defined.

For each object (or set of objects) define the following:

Usage :

  1. Describe in a paragraph how the object is used and what function it serves.
  2. If an object will interface with an external object or system, it is a good idea to show the interface for the object.
  3. Most importantly, you must again describe your thought process for defining the object as you did.
  4. They don’t have to be verbose, just enough to get the point across.


Controller, Data Access Layer etc.  You can explain what is the controller class does.

Model :

  1. This section should contain the Corresponding classes,methods,Interfaces etc related to each and every high level entity.
  2. Basically supplement of each entity which is listed under .
  3. ‘Identify High level Entities – Point #2′.  E.g. : Controller Class. It should list all the methods,Interfaces,Inherited classes etc related to the Controller class.
  4. In a Nutshell, it is the class diagram depiction  of the Controller.
  5. Depending on the need you can provide the description and the interaction between the components.

Interaction :

  1. This is also a good section for interaction diagrams.
  2. An interaction or Sequence  diagram shows how a set of objects or entities communicate with each other to perform a complex task.

Benefits, assumptions, risks/issues:

  • Make a list of 5-6 top benefits of the design, a list of ALL known risks/issues and a list of ALL assumptions.

Advantages :

  1. A good Low Level Design Document developed will make the program very easy to be developed by developers because if proper analysis is made and the Low Level Design Document is prepared then the code can be developed by developers directly from LLD  with minimal effort of debugging and testing. This helps the development team to give quality product.
  2. Design document will help you in  analyzing  the timeline for each component development. So over all rough estimated time of completion can be calculated in the design documents stage itself. This can be used to compare with the target date set for completion of the project. If the time is greater than target date then unwanted and less important components can be left and may be taken off for next phase of development. Thus on whole good design document helps to deliver quality software product within the timeframe.
  3. It helps us in understanding  the requirements in a crystal clear manner. If there is any gap in the requirements we can get clarified before the development starts.
  4. It minimizes unexpected complications by addressing them before the code is written.

So it is very essential to have a good design document for a software product to b developed on time with good quality.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s