In my last post, I talked about how people often have trouble briefing their developers and specifying what they want their app to do. This week, I thought I’d share the basics of defining your web platform or mobile app. In “biz” speak, this is really your product definition and in “tech” speak, these are called “business requirements” and they represent a documented version of your product and what you want a developer to build.

Defining your product (aka writing requirements) for apps is actually a skill. It takes practice to think about what your product should do and how to explain it to someone. You need to translate your high-level idea into something concrete and tangible so that it instructs a developer on what you want.  

As the person that has the idea and the person that owns the business, you’re going to need to know your product inside and out. I’ve found that this is often a hard thing for newcomers, as they don’t know to drill down to that next level of detail.  

There are a few steps to creating a full set of requirements for your product, which will take a while to explain (I’ve identified eight of them in my requirements writing course). So in this post, I’m going to jump straight the end to show you what a requirements looks like. This is what you want to get to.

If offering a solution (your app) to a person is all about solving their problems or helping them to achieve their goals (more on this another time), then when you define your product, you need to focus on three things:

1. What is it that you want someone to do?
2. Who is going to be doing this “thing”?
3. Why will they want to do it?

A “user story” is a handy way of pulling this all together in a single sentence:

This amazing sentence is called a “high-level requirement”. It’s giving the reader an overview of a specific thing (or “function”) that needs to be supported in your app.

Seems simple right?! Well, here’s where it gets a bit complicated. Your user story could include a very big activity – in which case, you’ll want to break your user story down into a bunch of little user stories. For example, imagine you were building a travel-booking website, one of your user stories might be:

This user story covers quite a lot of ground – what reports do you want to view? What do you need to manage in your business? From this user story, you might actually create some other, more detailed, user stories:

Can you notice the difference between the first user story and the next two? Look at how specific the second two are. Writing requirements this way forces you to be as descriptive as possible and also to think about what you really want.

The important thing here is to make sure you’ve covered the whole breadth of what you want your product to do. If you miss something here, it may end up costing you more money, as what you ask the developer to do all of a sudden becomes a lot larger.

As I mentioned in my tips article the other week, try and keep your product as small as possible. This will reduce the complexity in your project and ultimately the cost and time it takes to build. It’s always easier to improve on something that has already been built.

Your requirements aren't done yet! From your high-level requirement, you need to break it down even further into detailed requirements. This means that you need to provide a bit more information about it. The kinds of things that you need to consider are:

• What data do you want to capture, store or retrieve?
• How will users complete a particular tasks?
• What are your users trying to accomplish? 
• Are there different scenarios that might occur as a task is being performed?
• What are some of the assumptions, prerequisites and dependencies that apply to the task?
• Are there different rules that should be applied by the app?
• Will there be things that you might want the app to do in the future?

 If you take our reporting examples, some of the detail might include the fields that you want to see on the report. Other things that you might consider are:

• How do you want the data to be sorted?
• Do you want to be able to filter the data? (e.g. by type of room? by date range?)
• Do you want to see an average price across all bookings? Maybe by room type?
• What other information do you want to see? (e.g. how many rooms have not been sold?)

In addition to the user story above, the detailed requirement for the booking report by property might also say:

These are the kinds of things that you’ll want to think about and document. You have to do this for every high-level requirement that you have, so there will be a lot to do!

The key is to get you really thinking about what you want. Don’t worry about getting all the detail down in the first pass. There’s a good chance that as you write one requirement, you’ll remember something for another requirement. You may create, combine or delete high-level requirements as you flush out the detailed ones. In the whole process of defining your product, you’ll probably go back and forth several times until you feel like you’ve got it all sussed out. You want your requirements to be as complete as they can be, but chances are you’ll miss some of the details. That’s ok too as your developers should pick them up when they review your requirements.  

As you can see, it takes quite a lot of work to define your product. Even if your app will only have one or two functions, you still need to have a detailed understanding of what you want your product to do. As the person that owns the idea, people will look to you for guidance. The clearer that you can be about your product, the easier it will be to develop your app.

 So, to summarise – in order to define your product, you have to write both high-level and detailed requirements for each of the things that you want your app to do. These requirements will inform your developers on what you want to build. It’s important for you to have a detailed view of your product to ensure its success.  

There are some more tips on writing requirements in my article the other week, so if you haven’t read that one, head over there now to check it out.

NOTE: for those of you that understand what agile is, I understand that some of the detail would normally get flushed out during a sprint. However, I feel that people new to building apps should take the time to write detailed requirements upfront so that they can better understanding what their product will do and so that they can appreciate all of the decisions that need to be made to build it.    

* When you sign up for a discovery session, we'll also add you to our mailing list so you can receive emails from us (with your consent). These emails will include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. You may also receive follow-up emails in relation to this session. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you.To view our privacy policy, click here.