The Importance of Requirements in Low-Code Development

Do I really need requirements for Low-Code?

No matter your background, there’s a good chance you’ve seen requirements before: giant exhaustive lists of features, fields, and formats attached to any large IT project, an indelible record of all things that the new system must ultimately accomplish. This is probably the furthest thing you’re imagining from easy, lightweight, low-code development, but hear me out: Requirements are still critical in low-code.

The difference is that in low-code, we’re able to bring requirements back to basics, to get them more in line with what they were invented for: to help organize and store your design decisions, locking them in to free up your time and your mental bandwidth.

Building a system can be taxing.

You need to remember everything that a piece of information has been used for in the past, and everything it might be used for in the future, in order not to undo your own work or make tomorrow’s work harder. Even for a simple system, this can be a huge web of connections to think about constantly.

Further, every ridge and valley on this information landscape can be successfully navigated with multiple routes over the course of your design, which may conflict with or complement each other in ways that aren’t often apparent at the outset. If you’re coming into low-code from outside a traditional development environment, to say that this can be intimidating constitutes outrageous understatement, and you should not let anyone convince you otherwise.

Define What You Aren’t Working On

Here’s the big key that should change how you look at requirements, especially in low-code: requirements aren’t there to define what you’re working on. They’re there to define what you aren’t working on.

Requirements exist to relieve you of the burden of constantly thinking about every other part of your system at all times. They break up every facet of the need into discrete parts that you can figure out individually; that you can group together by shared dependencies.

Good requirements give you the reassurance that you no longer have to keep some portion of your brainpower paying a coordination tax. They build trust between you and your own project. They mean the systems-thinking is already done and documented, and you, as the developer, are free; liberated of that quagmire and ready to simply solve the users’ needs one by one.

No tangles; no decoding;
just pure, rocket-fueled development.

But gassing up that rocket requires more than just having a great spreadsheet. It requires a trust in the process on the part of everyone involved which can be best achieved with truly honest and open requirements-gathering. Stakeholders need to feel heard and understood. The requirements need to clearly and convincingly speak to their needs.

What makes a good requirement?

With traditional project planning, you’d document requirements from several different perspectives, then bring them together slowly as the project plan comes together. But we’re talking about Citizen Development in a Low-Code environment, this will often be a Business Analyst or a savvy end-user doing the work themselves and putting together tools to make their jobs easier. The last thing we want is to weigh them down with excessive systematization, but the truth is that we still need an information-dense way to communicate needs.

Bridge the Gap with User Stories.

User Stories are a style of requirement that focuses on what a specific person in a system wants or needs by describing the need in a narrative form. A user story can be as simple as, “As an applicant, I want to know when an application I’ve submitted is due in the next week, so that I can submit it before the deadline.”

If you’re used to traditional requirements, this may sound wishy-washy to you, but consider that it already contains everything we need to develop this feature, and it’s packaged in an easy-to-understand narrative form that will make it much easier to avoid mission-creep. This story contains all three major elements that we’ll need to build:

• Who we are serving
• What we are providing

and most importantly:

• Why they need it

With all three of these in place, we can very easily define success regarding this need. This provides the flexibility to fulfill the need in different ways without inadvertently drifting away from the original intent. The core goal remains clear.

Including the “why”

Including the “Why” in such a plainly written form is the secret sauce that brings low-code to life. It guides you toward the big picture and prevents you from developing in a circle. It provides a clear condition of success for the story and gives you all the pieces you need to paint a bright line around who you’re serving and what you’re giving them. The stakeholder and the value provided are defined up-front in a digestible form, giving your developer a goal, rather than instructions. This unlocks creativity and encourages stakeholder collaboration. A stakeholder can read a user story in plain language and that makes them feel heard, which engages them further with the process.

By building with user stories and a lot of transparency, you’ll often find that stakeholders start brainstorming right along with developers, and in the low-code space, that’s the first step toward jumping in and making their own apps. A well-crafted user story becomes equal parts requirement and deliverable, transforming power users into Citizen Developers.

Get started with the Citizen Development here!

Or if you want to see a low-code application development platform in action: