Software System Design #002
Collating Business Requirements
Purpose
When designing a software system, clarifying the business requirements should be done first to establish a common understanding between the product manager and the engineer on what the software system restraints and required components will be. This stage of designing a software system is a critical point for determining what you will need to know in later discussions involving the system’s interfaces, data models, and bottlenecks.
Goal
An engineer is primarily responsible for helping the product manager procure a cogent list of business requirements by inquiring into how the product will functions. Avoiding things related to customer market research, pose questions which help elicit the required component interfaces, data modeling, bottlenecks, and third-party software licensing. At the end of this stage, you should have a list of what is and is not a functionality of the minimum viable product.
Business Requirements
Determining the business requirements of the technical system requires knowing every user role interacting with the system, understanding where the system’s scope of responsibility begins and ends, and identifying critical system components which must be performant and resilient
User Roles
First and foremost, be sure to understand every potential type of user that will interact with your system. For example, let’s start with the type or user roles for the most basic website application. At first, the obvious answer is that your website system design has to support anonymous users which means that depending on your business needs you might have an Application Load Balancer with multiple replica web servers that pulls information about your favorite drinks from structured databases:
However, this might not be the entire picture. A website typically allows for an administrator to maintain the website’s content. Consider a scenario where the custom support representative needs the website to have a new image whenever the represented company requests. Instead of SSHing into each web server and uploading a new image to serve, you might have an Administrative User Role that can authenticate with a predetermined service, use an HTTP Post request against an API gateway and upload a new image using a multipart/form-data. For there, you might have the images in your file or object storage be publicly readable.
In summary, designing a software system requires understanding business requirements to ensure that the system accounts for all of the user roles and the permissions those user roles will need.
Scope
Most everyone has heard the cliche where, upon mentioning that you are a developer, an aunt or uncle recommends you build the next Uber. In the same sense, designing a system means protecting the system from scope creep and creating restraints about what a system cannot do. For this reason, I recommend first identifying assumptions that are being made and what functionality is beyond the scope of a system’s first iteration. To avoid boiling the ocean, focus every initial question on the product owner’s understanding of the minimum viable product. Position questions in terms of whether the individual if necessary would choose feature A or B to help with the selection process.
Functionality
Determining the functionality of a software system is perhaps the simplest process, albeit an iterative process that is only completed through trial-and-error. After reasonably defining a broad understanding of the minimum viable product and roadmap for future iterations, ask very specific questions about what what each feature will allow a user can and cannot do.
- Can the user upload images of any size, or do we limit it to a certain size?
- Can users create a profile? If so, what can a user have on their profile?
- Does the user need to refresh to see updates to an article’s content?
Resiliency
For every software system, there will be a collection of business requirements which act as modifiers to the functionality your software system should support, some might call this non-functional requirements. This requirements describe how reliable or performant certain features should behave. Consider the resiliency expectations for a URL Shortening service.
Given I am a user who has created a short URL
When I share this URL with my friends or family
Then I expect the URL to consistently redirect to the original URL
This requirement is par for the course on many software projects, but it can be a rather difficult to address this resiliency functionality. Every stakeholder in a software project would like the software system to be 100% resilient, but this desire often comes into direct conflict with the reality that there are acts-of-god and a lack of budget to support a service that works absolutely. Here an engineer will need to work with a business analyst or product owner to determine how consistent is consistent enough. What is the opportunity cost of a system working with a confidence of 3σ versus 6σ ? For a requirement like this, you are modifying the needs of a core functionality simply by requiring software components for monitoring and measuring your system’s reliability.
Given I am a celebrity with an instagram post using a short URL
When my 5 million instagram followers click the URL
Then I expect all of my followers to be redirected to the original URL
This example shows a realistic user story that your product team expects to support which clearly modifies the type of resiliency your system’s network will need without adding new functionality. That said, this non-functional requirement might require new software components to support which would be unnecessary if the most traffic a single link every expected was only a handful of unique users.
Recommendations
- Remember to be someone that others want to have building their next project. Designing a software system and preparing product specifications is when a software project has the greatest diversity of perspectives and work experience. Before any work is done is also a point in time when a software system is most vulnerable to getting scrapped by a key decision maker.
- Avoid the bias to pigeonholing system designs into patterns where you are a particular expert. If you have a design in mind while identifying business requirements then you might trick yourself into heavy-handing your way into dictating business requirements based off technical convenience.
- Unless interviewing, make sure to ask questions even if you aren’t confident that you can design software system that can support such functionality. Any question that immediately comes to mind when designing the software system for a design will either have no followup or identify a system restraint or necessary software component.
- Even if it is shorthand on a piece of paper, write out the business requirements to ensure none are forgotten when going into later stages. I personally recommend having a shared wiki for any software system where you can document answers to any questions.
- The engineer is always exclusively accountable for ensuring they have the sufficient enough information to proceed to the technical stages of the designing a software system, whether it is an interview or company product. If an answer isn’t sufficient, discuss the business requirement further.
- Another approach that ensures success, whether interviewing or discussing a company project, requires humility. An engineer’s job responsibility usually ends when it comes to synthesizing the customers’ needs into actionable features. This means that an engineer might be taking direction from a customer, a product manager, a customer sales representative, or a COO. Regardless of who is accountable for the product, an engineer is best suited at divorcing themselves from determining customer needs and focusing strictly on addressing the requirements as they are interpreted by one of the aforementioned subject matter experts. The intention of this ensures a health separation of duties which ensures accountability between the individual making the product and the individual servicing customers’ needs with a product.
- Finally, the engineer accountable for designing the software system should expect that they need to turn verbally and visually described functionality into technical requirements. For this reason, take note of every functionality then roughly guess your personal understanding where certain functionality lands in a graph representing complexity vs certainty. In this graph, you should be making the Y axis a subjective measurement of the technical complexity and the X axis a measurement of your certainty on the appropriate technical approach to provide the requested functionality.
In the end, you should share how you have placed all of the functionality on the graph with your engineering and product team. Working together, everyone on the team should run small proof-of-concept experiments that help validate the appropriate technical solution until all of the proposed functionality has either been removed or moved to the far-left side of the graph. At this point, a project manager can weigh the value of particular functionality against the well-defined and studied set of work required before proceeding with prioritizing specific functionality.
Interviews vs Reality
Collating the business requirements for a software system you are responsible to design is a rather different experience than when your are interviewing. The biggest factors in distinguishing how interviews differ would be:
- The time restraint of an interview
- The interviewer will mimic a product or well-known software system
- The interviewer already has a sophisticated understanding of the software system variations that can address the business requirements
In a system design interview, you will unknowingly participate in a well-rehearsed dance with the participant. In reality, an engineer will most likely depart on a jungle expedition with their product stakeholders in search of El Dorado. The key difference here means that you will need to rehearse many system design interviews to know what dance your interviewer will choose, and you need to be keenly in tune with how your interviewer defines the system’s functionality and restraints when describing the business requirements.
Closing Notes
Thanks for reading this article! I’m always willing and interested in hearing from readers what they did and didn’t like about the article. Feel free to leave a comment or ask a question below. In the mean time, I have linked below relevant information on my writings and articles associated with this series.
Next Article
The next article will address how an engineer should approach conversations about scaling their software system, how to propose technical debt budget around bottlenecks, and how to restrict technical requirements to ensure any software system can scale to meet estimated demand:
Software System Design — Scalability
Software System Design Series
For an overview on this series and the motivation behind it, please checkout out series introductory article:
