“Everybody loves a satisfied customer”. Who doesn’t?

Isn’t it this capitalist work everything an exchange? A business owner obtains money and the customer obtains what they want. However, this is not always straightforward.

In the world of software development, if one thing is certain is that nothing is certain. Things are ALWAYS changing. There is always a customer, either your employeer paying for your work, or a end-customer paying you for software. We can face change in two ways, accepting the change and give customers what they want or give them what they need. Very rarely these two are the same. It is the job of software engineers (and some project managers) to define exactly what will be done. This is called Gathering Requirements. There will be a more in-depth look into change for Chapter 3.

Image via Flickr @stavos

I don’t really feel like talking about strange and oddly specific examples of smart dog doors so I’m going to stay more in topic here. In case you wanna read my sarcastic commentary about it, please refer to my earlier post about the same thing here:

https://davidtc2004.wordpress.com/2018/11/21/the-customer-is-not-always-right/

So now, what is a requirement you may ask, the book tells us the following:

“A requirement is a singular need detailing what a particular product or service should be or do. It is most commonly used in a formal sense in systems engineer or software engineering”

Or the tl;dr version is, what your app needs to do correctly (We are in 2019, everything is an app nowadays).

So how do we get requirements, or a list of requirements?

First, we need to talk to the customer to see what they want. Depending on our social and communication skills (sorry introverts), we may also understand what they need right away. Another important piece of info here is that part one is what the software needs to do, the second part is how to do it. Talking with the customer and how listening on how they would use the software we can define a use case. This is a specific scenario based on a specific user action that has a specific outcome. If a specific step within a use case doesn’t work or is not available, we can also define the alternate paths which will help us reach the same goal.

We can have lots of use cases if there’s a complex system to develop, however, there’s a point where it becomes a waste of time. So they should not cover all the edge cases, just the common ones so we can begin creating it as soon as possible.