So you have this idea of the next big app that wish to develop? Currently, it resides fully in your head, and you must concretize it before actually implementing something meaningful. But how do you know that you are building the right system?

This is where Requirements Engineering comes in to save the day. As the first step of the SDLC, it concerns definining requirements of your application.

This might seem like a boring endeavour at first glance, but I can promise you that it’s an invaluable skill to perfect. Seeing that people work full-time as Requirement Engineers, getting paid big bucks. No doubt that thoughtfully designing a system and its constituent parts becomes ever more important, when AI tools can spit out code faster than your eyes can blink.

Requirements are split up into two parts: Functional and Non-functional requirements. Here is how I like to think about the two:

• Functional: What it must absolutely do, the literal definition of what your app is. The minimal features that must be present.
• Non-functional: Quality attributes that aren’t necessarily vital, but contribute to the overall adoptability of the application. For example: Usability, UI/UX design, reliability, scalability etc

The line is sometimes a bit fuzzy to draw, but a good sanity check would be “is this absolutely crucial, or just a should-have?”. It should be stated that non-functional requirements are still requirements, neglecting them is not a good idea! Context also plays a role, a functional requirement for one app might be deemed non-functional for a different app.

Further, there is often a distinction in who is writing these requirements, since non-functional requirements might require more technical knowledge when dealing with concerns such as UI/UX, reliability and security.

Now, what are some properties of good requirements?

Unambigous, clear language #

A requirement should be concise but also not too vague, seen as this is a communication tool. The goal is to share them with all sorts of stakeholders, some of which have no knowledge or interest in your technobabble.

Here is an example of a poor requirement:
Orders must be stored in a MySQL database running the InnoDB engine

Versus a slightly better one:
Order data such as product, quantity and recipient info must be stored persistently

Including technical implementation details is way too early at this stage. Choosing a specific database implementation is a trade-off that you make after analyzing requirements and finding one that suits the scenario best.

Verifiable #

Another regarded property is verifiability. How do you know if you actually suceeded in implementing a requirement, if there is no reasonable way to measure it?

Something like
The app should feel snappy on launch
is easily beaten by
The homepage should be visible within 250ms of the user opening the app.

Enhancing verifiability also promotes testability, it becomes much clearer which unit tests or integration tests to write, if requirements are made verifiable.

Traceable to needs #

It’s all about needs. Users are needy, so focus on what they actually want instead of what you think that they want. Ask your target audience, conduct interviews, put out surveys, do your research!

This is something I admit to being awful at. It’s so easy to follow your own preconceptions, then wondering why users uninstall your app within 1 hour of using it.

Requirements for our music streaming platform #

It all helps with a bunch of examples, right? For the music streaming platform that we’re building, we start our journey by defining the requirements of the app.

Functional requirements

• The app must stream music content to the user
• There must be persistent storage of users
• Users must be able to log in by inputting their email and password
• A confirmation email must be sent when new users register to the platform
• Users must be able to search and browse new music
• Artists must be able to upload their music content to the platform
• Uploaded tracks must be part of an album or a single
• Users must be able to group together music tracks within playlists
• Music tracks should be categorized by their genre

Non-functional requirements

• The app should have a minimalistic user interface with rounded corners
• The music should start playing within 1 second of the user clicking the play button
• The app must work in cross-platform contexts
• Traffic to and from the platform should be encrypted
• Music content should be authorized only to users who are logged in to the system
• The system should be available even under heavy traffic, above 500 concurrent users

This list is by no means exhaustive. Remember that the SDLC is an iterative process, nothing should be set in stone! Although it undoubtedly helps to have a clear vision when starting out.

Now that we have defined requirements for our system, it’s time to start designing and architecting it. See you in the next blog post!