Every good software engineer knows that you need to have a design for your software before you start building it. A low-level design document comes after you’ve already gathered requirements and created a high level design diagram, reviewed and revised it, and had it approved by your team. Technically you can create it before your HLD is done being reviewed, but I would caution against it because you may end up putting in some big changes to your high level diagram after review!
In this post we’ll cover:
- Low Level Design (LLD) for Software Engineering Questions
- Low Level Design Questions for Data Manipulation
- Low Level Design Questions for Interfacing
- What Goes into a Low Level Design Document for Software?
- What Does a Low Level Design Document Look Like?
As I’ve mentioned multiple times before such as in my article about why programming is easy but software engineering is hard and my article about learning the tools for engineering, we’ve got to ask the right questions.
Low Level Design (LLD) for Software Engineering Questions
The Low-Level Design Document is quite similar to the High Level Design Document. They are both design documents after all. The difference lies in their focus. The HLD is focused on the functionality and data structure of a software. The LLD is focused on the data manipulation and internal interfaces (internal APIs) of a software. I’m going to make a note here about the differences between functions and modules. In the HLD I mention modules/libraries a lot, in this post, we’re more focused on functions. Functions make up modules, but sometimes modules are just one function.
Low Level Design Questions for Data Manipulation
Whereas High Level Design is concerned with data organization and structure, Low Level Design hones in on what we actually do with the data. An LLD will help us determine which functions or modules need access to what data. Here are some questions we should ask to move us towards our goal of organizing data manipulation within our software design.
- Which functions take in what data?
- Which functions create information?
- Where does each instance of data start for one run?
- Which functions need information from outside the module to run?
- Where does each instance of data end up for one run?
Like I said in the High Level Design post, these aren’t the only questions you want to ask. These are enough to start off, and as you get the answers to these questions, there will be more questions that come up. Usually those will be around “why” you want to do x, y, or z with some data. For more information, check out Discover, Design, Deliver – the Blueprint for Building Software.
Low Level Design Questions for Interfacing
Other than data manipulation, the other question the LLD addresses is about how we want modules and functions to interface. As we’ve already covered in the post about what APIs are, interfaces are essentially contracts between programs. For the purposes of Low Level Designs, interfaces tell us what goes into the function and what comes out of the function. Having this information is important to know so we can make sure our data manipulation is correct. With these goals in mind, let’s take a look at some of the questions we should be asking to determine how our functions will interface.
- Which functions help us perform which actions?
- Where will each endpoint (external API) be called and what information will it have?
- Which functions will we need to execute endpoint API calls?
- When will each function be needed in our workflow?
- How will the function access the data it needs?
As above, these are not a comprehensive set of questions, but rather a set of starter questions. Other considerations include how we’d like to structure data encapsulation and storage. We should have many of those questions answered already, but it’s good to go back over them. One of the main things to consider when looking at how we should structure our interfaces is the extensibility of the interfaces – how easy is it going to be to add new functionality with these interfaces?
What Goes into a Low Level Design Document for Software?
High Level Design Documents are like blueprints, Low Level Design Documents are like architectural models. The LLD should start to give you an idea of what the software will look like when it’s fully built. With a Low Level Design Document, you should basically have all the functions for the software functionality down. Note that this diagram will only include the actual functionality of the software. Some modules like helper functions, utility functions, and constant files aren’t included yet.
Other than descriptors of what we want the functions to do and the answers to our questions above, we’ll also need a Low Level Design Diagram in our Low Level Design Document. The LLD Diagram looks pretty much exactly the same as the High Level Design Diagram except there should be descriptors of what information each module or function needs. For more complex designs, you’ll also want to add notes along the lines which the data moves.
What does a Low Level Design Diagram Look Like?
Further Reading
- Build Your Own AI Text Summarizer in Python
- Slicing Python Strings
- Neural Network Code from Scratch in Python
- Fast Track Your Junior to Senior Software Promotions
- What is the Difference Between an Interface and an Abstract Class?
I run this site to help you and others like you find cool projects and practice software skills. If this is helpful for you and you enjoy your ad free site, please help fund this site by donating below! If you can’t donate right now, please think of us next time.
