{"id":635,"date":"2018-11-25T07:13:31","date_gmt":"2018-11-25T07:13:31","guid":{"rendered":"http:\/\/www.creativesparksolutions.com\/blog\/?p=635"},"modified":"2019-09-13T04:43:56","modified_gmt":"2019-09-13T04:43:56","slug":"how-to-create-a-requirements-document-for-your-mobile-app-steps-and-tips","status":"publish","type":"post","link":"http:\/\/www.creativesparksolutions.com\/blog\/how-to-create-a-requirements-document-for-your-mobile-app-steps-and-tips\/","title":{"rendered":"How to create a requirements document for your Mobile App ? (Steps and Tips)"},"content":{"rendered":"

Mobile App Development is slightly more tricky business than developing a website. The budgets for a mobile app, the effort required and the coordination involved – all are much higher.
\nFor all these reasons, App Development has to be planned well by the owner or company which is getting it developed. One of the important steps in this process is creating a requirements document for your Mobile App.<\/p>\n

It is avoidable to simply call up a mobile application development company and say – ‘Hey Guys, we need an app like Paytm ?’ or ‘Hey guys, can you create the next Ola Cabs \/ Uber app for us ?’<\/p>\n

Sure, Apps like Paytm or Ola Cabs are possible – but they took years of development time, changes, iterations. Not to mention thousands and maybe lakhs of man-hours and loads of functionality which you may never need, or may wish to differentiate from. And for all of these, the features and requirements must have been clearly planned, documented and evolved over months and years<\/p>\n

And if you don’t wish to develop the next Clone app – it is even more important to make a requirements document<\/strong>.<\/p>\n

So let’s look at what a Requirement document is and how it’s created.<\/p>\n

\"Requirements<\/div><\/div>\n

Steps to Create a Requirement Document for your Mobile App<\/h3>\n

Step 1: Research on your App idea and Technologies available<\/h4>\n
This is the first important step. Before you build something, you need to know what is already there in the market, the problems with these existing apps \/ solutions and pain points of Users (which hopefully your App will solve). You can research on competitors online, simply download these apps and go through the features and flow. Think about the functionality which you feel the App is missing. Your research should be geared to analyze if: a) There is a market for your app which is not being served fully b) There is a business model where you can end up making money from the app. (or whether it suits some business purpose of your company)<\/p>\n

This is something called as a ‘Feasibility Study’ which you can undertake. <\/p>\n

And yes; even if you are not a techie, you should have some basic idea of the technologies available in the market for your App.

\nFor example: if you send in your requirements and the vendor suggests iOS Native + Android Native vs. Hybrid Technology, it may be good to know what exactly these terms mean. If the app development company suggests a technology or platform, it would be nice to know enough to ask them a few questions like: ‘Why is this suggested?’ , ‘Pros and Cons’ etc.
\n<\/div><\/div><\/div>\n

<\/div>\n

Step 2: Discuss and Decide on the flow of your App<\/h4>\n
\nPlease discuss with your partners , stakeholders and finalize the user journey through the App. The User Journey or User story is basically how the user will enter the app, exit the app, perform various functions. Each function has it’s own story or Journey. Yes, this will change a few times with improvements, suggestions incorporated at later stages; But you should have a base-line Flow before you send your requirements to any App developer. This helps a development company provide an accurate effort and cost estimate, reducing your project’s risk.
\n<\/div><\/div><\/div>\n
\n\"Creating<\/div><\/div>\n<\/div>\n
<\/div>\n

Step 3: Identify Features of Existing Mobile Apps<\/h4>\n
\nIt is crucial to check out what features and screen flow competing Apps have in the market. Or Just go through Apps which you like and pick out features which may be relevant for you. Download these apps and check out various features. Take screenshots of screens having features which you like. List down things which you don’t like. Check specially how user friendly the app is (Example: Auto reading OTP when it is sent, Social Login, Seeking Location). Another aspect you can focus on is how they’ve tried to personalize the app.<\/p>\n

For example – if yours is a Moving \/ Shipping App you can check out how various apps are providing tracking functionality, how they process your order, calculate the charges etc.
\n<\/div><\/div><\/div>\n

<\/div>\n

Step 4: Prioritize the Features of your App in Phases<\/h4>\n
\nIf the Mobile App is ambitious in scope it makes sense to divide the features into those required immediately, those which are good to have and those having low priority. Features can also be divided in Phases with important ones released on launch and other’s gradually. Your requirement document should mention the phase-wise requirement if this is the case. At this point you will probably have put the features and requirements in a rough list so now you can divide the list depending on your priorities. You should check this with all the stakeholders to get an idea of what the whole team thinks.<\/p>\n

If your app is a clone, what happens to the requirements document?<\/strong>
\nAgreed, that if your app is a clone or majorly uses pre-existing features, your requirement document need not be that detailed and may not need Sketches or wire-frames. But you should still document the following: Which features are copied, minor changes in features, forsaken features if any.<\/p>\n

<\/div>
<\/div><\/div>\n<\/div><\/div><\/div>\n
<\/div>\n

Step 5: Create Wireframes , User Screen Sketches for your Mobile App<\/h4>\n
\n\"Example
\n<\/div><\/div><\/div>\n
\n
\nWireframes, Sketches are really helpful to an App development company. If they are able to visualize through sketches and wireframes on even a word document, the user flow that your app has; it makes it easy for them to estimate efforts and costs. With wireframes \/ sketches it is easier to estimate complexity and no. of screens. In a mobile project if the effort requirement is not clear, there can be delays, disputes and whole project may spiral out of control. In worse case scenario your product may not be created in timely manner or project may even get shelved.<\/p>\n

Yes, proper screens etc. can be created later once the project is awarded, but some sketches using something as simple as MS Word Drawing or any design tool is sufficient. Even snapshot of a sketched screen on piece of paper is fine. Only exception to this can be if it is proper clone of a similar app and the requirement document simply mentions screen or flow differences.
\n<\/div><\/div><\/div>\n

<\/div>\n

Step 6: Choose a Requirements Template or create one with the following sections<\/h4>\n
\nIn above steps, you have done all the groundwork required for creating a requirements document. Now you actually create one using an Online Template or making one. A basic Template will be sufficient for many of the apps.<\/p>\n
Typical sections of a Mobile App Requirements document<\/h5>\n