Press "Enter" to skip to content

Commutee functional requirements

When you want to create an application, first, you have to know what this app will do. That’s a pretty important thing to know. You may know technology, know how to use it, how the user interface will look like, how data will be stored, but if you don’t know what this app have to do, you won’t be able to make it. An application must have some use cases so that users would use it for something. But wait, we know what will Commutee do, it will find me a route from here to where I want to get to, right? Yes and no. That is a general idea, but we need more than that to even start thinking about the implementation.

To correctly design and create software, we must know exactly what this software is supposed to do. We can’t use a general idea like above and just start writing. The "let’s code and we will see" approach most of the time doesn’t work well. Sooner or later it bites back. Changing requirements are the worst enemy of the software development. They are unavoidable, but whenever we can, we need to thoroughly analyze everything we know at this exact moment and try to design our app with all these requirements in mind.

So let’s start with few general use cases for the Commutee:

  1. Show a timetable for a bus/tram/train
  2. Find a route

What? only two? you may ask. Yes, there are only two general use cases. Either we want to find some kind of route between few locations or we want to know when a bus arrives at a bus stop. Those two are a really broad, but simple requirements. In my opinion, it’s good to start with something so broad, as these two,  and refine it later into more specific use cases.

Show a timetable

This one is a pretty simple, we have few options here:

  1. Show a timetable for a specific line at specific bus stop with an ability to set a different day than today
  2. Show a timetable for all the lines at current bus stop with an ability to set a different day than today
  3. Show the time of arrival of the next bus at the current bus stop

But how does it translate to implementation? Let’s think about it.

Show a timetable for a specific line at specific bus stop with an ability to set a different day than today

We want to show a timetable for a specific line – that means that first, we have to select a bus line somehow, some kind of search by name, a selection from a list? The same goes for selecting a bus stop, we have to find it somehow. We can try to find it by a street address or name. But that’s not enough, as several bus stops may have the same name, but different numbers for different directions. User somehow has to select the correct one.

As you see, something as simple as displaying a timetable may get complicated quickly when you think about it a bit more. Now, let’s move on to the main functionality of Commutee.

Find a route

Finding a route also consists of a few cases. Let’s write them down.

  1. Find a route from current location to specified destination
  2. Find a route from specified location to another specified destination
  3. Find a route between any number of locations (at least 2) in desired order
  4. Find a route from current location to a specified destination with arrival at desired time.
  5. Find a route from a specified location at desired time to another specified destination.
  6. Find a route from a specified location to another specified destination with arrival at desired time.
  7. Find a route between any number of locations (at least 2) in desired order with desired arrival times at each of the locations.

There are even more because we can specify locations in several ways:

  1. use GPS
  2. select a point on a map
  3. search for an address
  4. search for or select a bus stop

We can add a few more options:

  1. Select the fastest route or the most comfortable route (fewer changes)
  2. Select a desired type of transport (trams, buses, trains, subway)

As you see, finding a route is not so simple. There are many possible combinations of user requirements for finding a route.

What’s next?

As you see, it got a bit more complicated, especially that finding a route has many additional options that affect a result. But now we know what will be the input for finding a route or displaying a timetable. Now I can start thinking about how to write a backend service. Having in mind all these requirements makes it easier and more effective because it lowers the possibility of bad surprises, for example, discovering that some kind of query requires a huge change in our data model and this often means – rewriting a big part of an application.

 


Also published on Medium.