DEV Community

Brent Dalling
Brent Dalling

Posted on • Edited on

Wait what? Intro to Decomp.

Hello there! You clicked the link to find out what this was about. Didn't you? A one word title? Crazy! This article is about requirement decomposition in project management.

Decomposition project management is a process of breaking a large, complex project into smaller, more manageable parts. This technique can be used to decompose a project into smaller tasks or to decompose a large product into smaller component parts.
https://monday.com/blog/project-management/decomposition-project-management/

Decomposition in project management is the practice of taking a requirement, feature, or outcome and then breaking it down into smaller and more actionable steps. Chances are that your project manager or senior engineers are already doing this. But, it is a skill that every developer needs. This post will walk through an example scenario and explain each step. You will have a more than basic understanding of decomposition in project management by the end of the post.

A customer wants to build a micro-blogging platform entirely in Node. The platform should handle multiple authors, drafting, and scheduling posts. Login needs to be simple and secure. There needs to be view and like tracking. The platform should permit a simple comment system with no more than 1 level of comments.

Okay. This seems simple enough. We've all built simple blog systems in the past while following sketchy YouTube tutorials with questionable code quality and explanations. We got this! But, we need to break down these features and requirements into more manageable steps.

When approaching this request I would first ask "What is the base functionality?". The answer? Creating posts and displaying those posts to the end user. Okay. Now, what goes into making a post?

  • User can click "new post"
  • User can write content.
  • User can add images and videos
  • User can click publish

Okay! Now we are talking! We have 4 steps that are actionable, manageable, and simple. Each of these can become a step in the SDLC (Software Development Life Cycle). Each of these steps has some sort of complexity that must be handled. But, we derived these steps from "making a post" as a requirement!

Okay, so if we repeat this process for each of the remaining requirements we may get the following.

Authors

  • Permit author invite via dashboard
  • Permit author registration invite code
  • Permit author to CRUD their own information EXCEPT for their role
  • Permit author to delete their own account and transfer their content to another author
  • Permit an author to make updates or co-author a post
  • Record all authors automatically who contribute to an article
  • Permit original author to remove co-authors from article

Drafting / Scheduling / Publishing

  • Permit marking a post as [draft, scheduled, published]
  • If post is "scheduled" then include a date/time field to specify when it should be published
  • Do not show [draft, scheduled] posts to end users

Login

  • Depending on back-end (firebase? pocketbase? custom api?) wire up a simple login flow of: email/password or email / magic link
  • Include 2fa methods of [sms/generator]
  • Logout the user after 10 min of inactivity. But, save their post work before logout if they are currently editing a post.
  • If user can't verify password after 3 attempts send an alert email to sysadmin and user then lock the account.

View and Like tracking

  • include some sort of async JS code to alert the back-end of a view lasting more than 5 seconds. Maybe include mouse tracking so we don't record bots or crawlers.
  • include JS code to alert back-end of a like
  • display views and likes in the admin dashboard
  • display views and likes in the post itself

Comments

  • users can signup for a simple "user" role account which permits: [commenting, liking, saving posts]
  • Comments include username, profilePic, content, createdAt, likeCount
  • Comments can be liked
  • Comments can be reported (this will require back-end code to handle the report)
  • Comments can be shared (provide direct link to the comment)
  • Comments will NOT support [images/videos, rich formatting, HTML]

--
And, just like that, we have a simple list of tasks from our request. However, there are still more actionable items to be found in here. Try to find the steps that I missed and include them in the comments. Let's practice the technique and find those missing steps. hint: every feature has a ton of back-end requirements or related requirements that are missing.

If you liked this article please bookmark it, like it, and share it! I'll be writing more basics articles in the near future with interactive examples!

Top comments (0)