Translate your app idea into software requirements

Published: Aug. 25, 2022

You are a business owner or an aspiring tech entrepreneur. You want to leverage technology to improve your systems. Or you have an idea for a million-dollar app. You have a grand vision for this product/app and how to make it a phenomenal success - all in your head. But unless you get it out on a medium like paper or a document, your idea does not get into a definitive shape. Because ideas keep flowing and evolve during conversations, you might miss out on when to stop ideating and start executing.

So, how do you document these requirements? Having spent a decade transforming ideas into apps, I suggest starting with user stories.

What are user stories?

A user story is just a story - from the end-users perspective on how a particular feature should/will work for them.

The format is,

As a <user_type>, I can <do_this> to <achieve_this>.

For example,

As a registered user, I can log in to the website to see all the latest updates from my friends.

Why is this format effective?

This format describes the type of user, what they want and why. The type of user and what they want - are mandatory sections. However, the why is optional and serves as a justification for why such a feature is required. At times, it defines acceptance criteria and avoids misinterpretation.

For example, consider a user story for a blogging site.

As a blog author, I can create new posts.

The above user story clearly defines two things, an author role and their ability to create a blog post.

But what happens to the newly created post? Is it visible for all, or does an editor review it before publishing?

As a blog author, I can create a new post to submit for review.

The above user story provides more clarity and leads to the subsequent requirement,

As a blog editor, I can review newly created blog posts by authors so that I can publish or reject them.

That further leads into,

As a blog author, I should be notified via email when an editor rejects my blog post.

Thus, these simple sentences (user stories) form a narrative (workflow) and help your team understand the application from multiple end-users perspectives.

A better practice is to list the roles before writing the user stories. Determine the different types of users in your application and list them down. In the blog example, we could list four types of roles.

  1. Site Administrator - Has complete access to the site and manages users and posts.
  2. Blog editor - Can browse, publish or reject posts created by other authors.
  3. Blog author - Can create posts. Cannot publish posts or see posts from other authors.
  4. Visitor - The anonymous website visitor who can read published posts.

Once you have a list of roles, start writing user stories for each.

I have created a spreadsheet template with sample user stories for your use. Click here to download. Please share it with one other person whom it might help.

Last updated: Aug. 25, 2022, 11:34 a.m.