In Part I of this series we discussed the importance of having a marketing vision and plan before embarking on your new App project. In Part II of this series we discussed how one would go about reviewing App store guidelines prior to creating your App.
In this part we will take a look at how you might go about writing up the features for your App. You will find that different organisations have different words for requirements, including:
- Functional Requirements
- User Stories
- Epic User Stories
- Use Cases
Don’t worry about the differences between these terms. All you need to think about now is WHAT is it that your App is going to do rather than HOW it is going to do it.
Kick your requirement development off with a brainstorming session. For this session try to stay at a reasonably high level and just throw ideas out there. Get yourself a lot of index cards and a few marker pens. Write each requirement you can think of on a card.
Don’t be surprised if you find you have tens or even hundreds of cards at this point! We are not yet attempting to prioritise them or exclude them from the project (we will do that later). For now we are just trying to get the creative juices flowing at a high level. Try to make the text of each cards read like a “command”. Imagine you are giving an order to someone. What would you say? See the image above for some sensible examples of index cards.
Draw Out Some Screen Sketches
Now for each of your index cards, think about how it might look on the screen. We are still brainstorming here, so use a whiteboard, pencil and paper or some really simple software. If you are going to try software, take a look at Balsamiq. It’s a low-cost, simple piece of software that helps you sketch out rough screen shots.
As A… I Would Like To… So That…
Now it’s time to do some more detailed work. For each of your cards, create one or more usage scenarios such as:
- As a diver, I would like to delete a dive so that I can keep my log book tidy
- As a dive leader, I would like to acquire the location of a dive so I can share it with my dive buddies
Using this three-part statement format we get to work out who your user is, what they want to do and why they want to do it. From the two scenarios above, we can see that our App has at least two types of user (diver and dive leader). We have also potentially identified another new requirement by asking why we want to acquire a location (the new requirement possibly being “Share Location”).
Put all of these scenarios into a document along with the initial requirement card titles and your screen sketches and diagrams.
Iterate Through These Activities
You should find that you are iterating backwards and forwards between these activities as you refine your ideas. You will continually be find new requirements and scenarios and also removing some of them that you decide you don’t really need.
Next: Prioritise Your Requirements
Our next article will provide advice and guidance on prioritising your long list of requirements and getting the best value out of your App.
Nick is the CEO of McKenna Consultants Ltd, based in Harrogate, North Yorkshire, UK. Nick is 1 of only 6 Certified Scrum Coaches in the UK. McKenna Consultants are a professional team of computer programmers delivering the highest quality software specialising in a broad range of technologies for windows, web-based and mobile applications, including apps for the iPhone, iPad, Android and Windows Mobile. McKenna Consultants also deliver Agile coaching, consultancy and training to organisations of all sizes. For more information on the services that Nick and McKenna Consultants provide, please visit: http://www.mckennaconsultants.com/