3 types of requirements when building a GUI-based software

3 types of requirements when building a GUI-based software
Yann Buydens

There are 3 types of requirements when building a GUI-based software:

I’ll illustrate them through the magic of storytelling.

  1. An example

Your are the product manager and the product owner runs into your office screaming (yeah the PO is intense):

“We need to be able to create a pathway”

As the product manager you get to work and write the requirements.

  1.1. The functional requirements

You start writing the functional requirements:

  • The software should allow the user to create a pathway by pressing a pathway creation button on the homepage
    • The pathway isn’t created yet when pressing this button. First he needs to fill in a pathway name.
  • After pressing the pathway creation button, the user should be able to fill in the pathway name
    • The pathway name cannot be blank
    • The pathway name can only contain UNICODE characters
    • The pathway name can be maximum 50 characters
    • The pathway name cannot be the same as the name of an existing pathway
    • An error message should be shown when the user presses “create”
  • After filling a valid pathway name the user should be able to press a confirmation button
  • After pressing confirmation button the user should be redirected to his list of existing pathways (aka. the existing pathways page)
  • … you get the idea

[NOTE: This list can be very long

A couple of things to notice here:

  • I didn’t specify what the copyright will be of the pathway creation button. That falls under the visual requirements because maybe there won’t be any copyright at all. Maybe it will be cute little construction crane 🏗️ (ok probably not but you get my point)
  • I defined key components: 
    • the pathway creation button
    • the confirmation button
    • the existing pathway page
  • I will refer to these key components throughout my requirements ]

1.2. The technical requirements

  • The time between pressing the confirmation button and seeing the list of existing pathways page has to be less than 0.5 seconds 99% of the time

Not a lot of technical requirements to write for this example. 🐆*

It’s unfortunate that we don’t give these requirements the love they deserve. These technical requirements can heavily influence your technical solution and cause problems down the line if the most important technical requirements are not met.

 1.3. The visual requirements

Rough sketch of where the pathway creation button should go on the homepage

[NOTE: We can get away with this level of detail. The developer knows what the layout is of an existing page and knows which standard button components to use because there is a design system im place (I’ll get into design systems in a different blog post).

The most important info right now is where the component should be positioned on the homepage page.]


Rough sketch of the pathway creation overlay when pressing the pathway creation button

Important: that this is an overlay on the homepage. Pressing “X” closes this overlay and you see the homepage again.

  1. Wait why no pixel-perfect designs?

It doesn’t make sense at this point to make pixel-perfect designs. Why? Couple of reasons:

  • You need to give the developer some liberty to pick the most efficient implementation. If the developer picked a good enough implementation you’re good to go. If the implementation needs to be reworked you can do it then. It won’t lead to double work because we are dealing with fine-tuning here. The big visual decisions are already captured in the rough sketches
  • It gives the impression to the developer that he needs to implement the pixel-perfect solution. That’s no good. You want to work iteratively towards a solution. First you implement to 80%. Then you add the remaining 10% with the feedback of your designer or product manager.
  • Go for the pixel-perfect mock-ups when you’re building your design system. The payoff to get your design system pixel-perfect is big because these components are reused everywhere!
  • Finally, it is much more important to create an exhaustive list of functional and technical requirements and to have the UX nailed down because these aspects are the hardest to change if you made a mistake there.

* why the leopard emoji? Because leopards are awesome. Lions are overrated

We can't wait to see what you build

Get access now