Technical Consultation Service

Understanding the business requirements being fulfilled by application development is what we
cover under our consultation and assessment service.

Technical consultation, which is specific to the application's idea.
Cloud Infrastructural consultation for in-house setup.
Technology consultation to decide on the tech stack for the application.

Consultation is followed by a process of rigorous planning to build a strong theoretical foundation
for the further steps of application development.

Planning an Application Development for our clients.

Agile Methodology has proven to be the one of the best approaches to develop a stable application.

Planning an Application using Agile practices ensures :

Simplicity
Quick launch ability
Being market-product fit

At Anuyat, we address planning an application with
five extensive steps –

Defining the scope

02.

Documenting with SRS

03.

Creating high-level user stories

04.

Estimating timelines

05.

Kick-off the application design

Let us paint the picture for you with an example of building an Application for an Online
Rental App.

Step

01 :

Defining the scope

As a business owner, you must have already researched the potential of your idea. The product you wish to develop must solve a particular problem that you may think exists among your target group.

Online Rental App

An online platform for multiple sellers and buyers to rent the new or used stuff.

We add more to your research with our scoping process.

The scope of a product tries to answer a few elementary questions before diving into
building an full-fledged functional product.

Expand to read more on this

Q1. What is the main objective of the business?

This question must have limited answers, probably one or two. This clarity is of utmost importance.

Your Online Rental App can provide n-numbers of advanced features, but we need to limit the app to a single business objective, i.e. Sellers should be able to list the products to sell & buyers should be able to buy those products.

Core business objective: Multiple sellers & buyers can do rental transactions.

That is a good start and a base to build your market-ready product.

Remember: Further efforts will only be made to achieve this single business objective. Any
deviation from this may distort the viability attribute of your customer-centric application.

Q2. Who are your target users?

Again, limit your customer personas to a minimum; we narrow down the audience for your product to build a focused application that caters to the requirement of that group only.

Instead of asking what features they would need in our proposed product, we ask them questions that better understand their pain points.

From here onwards, we will understand this group’s:

Problems, in more detail, for which we are offering the solution.
If a solution is provided, are they willing to pay for it?
Can they refer to other people who may have the same problem?

User Personas

People just shifted to the metro & do not want to buy household stuff.

User Problems

They are always on the move due to their job; hence it is challenging to buy and set up a home every time they make a city shift.

The brainstorming leads to a high-level process flow for the identified users' activities on the platform.

Something like this:

User visits the App
User search for the household item
User finds the seller
User added product for renting, in the cart
User proceeds with checkout
User added shipping & billing information
User completes renting process

Things seem to come out together from hereon, where we can slide into shaping the features that would be part of the application's first phase.

Q3. What should be the features for the first phase of application launch?

We follow the prioritization- matrix to understand what features should make a cut for the first launch and which ones should wait for future iterations.

For our Online Renting App, we can define the “User visits the App” feature into sub-sections:

User visits the App

User search for products in the search box

User browse through the categories & sub-categories

User uses filter options

User select seller's category

User uses review function

We carry on with this schema for the rest of the process flows, and for each of the sub-features, assign a value, based on the following:

How important does the user find it?
Do we expect the feature to be popular?
How much would it impact if we launched the product without this feature?

At the end of the scoping an application process, we are ready with the set of features that are “must-haves” for the first launch of the product.

Step

02 :

Software Requirements Specification (SRS) Preparation

Software Requirements Specification or SRS is our way to lock the MVP features officially on the formal document to make sure everyone involved remains on the same page.
The document has a mix of theoretical discussion and an outline of the discussed features. Generally, an SRS consists of the following elements:
Description of the functional requirements
System requirements
Technical requirements
Constraints
Assumptions
Acceptance criteria

The SRS is shared with our clients for discussion, approvals, and moving to the next exciting level.

This document will act as a blueprint for Anuyat’s development team and the clients.

Expand to read more on this

Preparing an exceptional SRS document

Effort and time go into designing a perfect SRS document. An exceptional SRS document must have all the touchpoints needed for the reference of the application developers and the clients.

Here is what you can expect from a nicely done SRS:

It must maintain the correctness attribute by including the exact identified requirements.
It must exhibit completeness by covering all the functional and non-functional requirements of the client & system.
Take caution while maintaining the consistency of concepts, jargon, & requirements throughout the document.
The unambiguity of an SRS refers to the fact that all the stated requirements must lead to only a single interpretation. Using modelling techniques like ER Diagram is helpful to keep SRS unambiguous.
Designing an SRS must be practiced by keeping a “modifiable quotient” under consideration. Remember, requirements are subjected to modification. Hence, making the SRS flexible to accommodate the changes is highly important.
If a requirement is not verifiable, it is better not to be a part of the SRS. By verifiable, we mean a requirement must be quantified for its functionality, importance, and useability.
The traceability feature is relevant for all the owners and users of the SRS document; designers must be able to locate the requirements for wireframing, developers for coding, and quality analysts to understand "what they need to test the system for".
SRS does not specify the implementation details. This constraint is essential to induce design independence so the designers can have freedom with different design options.
Test cases and plans become easy to generate if the SRS defines the requirements and system expectations in a well-structured manner. This practice portrays the testability attribute of the SRS document.
SRS is undoubtedly a reference document for system designers and developers. Still, it should also address the questions for the end-user, in the language, as simple as one’s mother tongue.

Step

03 :

High-level User Stories

SRS is a compact document that provides a high-level understanding of the system or application to be built. Creating user stories is a more technical part of planning an application.

Anuyat’s SRS document scopes out the user-level details to lay out the blueprint for interactive elements or the actors of the application product.

Let us see how we plan the high-level user stories:

a) Map out the user journey(s)

Identify who is going to interact with the system. Technically, we call them actors of the product.
Identify the story ending, i.e., the end goal of each identified actor and their expectations from the system.
Identify all user-specific actions that must be taken to achieve the identified end goal.

b) “Pain and gain” map for each action

Mention a complete list of user’s actions when using the product/system.
Then, write down the pain points for each identified action.
And finally, make a list of the gains for each action

This defining of user journey helps generate the application's flow, along with focusing on the core value proposition for the target audience.

Step

04 :

Plan the estimated timelines

For a customizable application scope, you would need an expert consultation to understand the approximate cost of building the product and the duration.

Internally, our project management team maintains a sprint document, which contains the detailed structure of the weekly and daily tasks of the project.

The estimated timelines come with a few assumptions and constraints, which are also defined clearly in the SRS document.

Step

05 :

Kickoff the project

After rigorous planning, discussions, and approvals, the application is ready for prototyping and development.

But wait, before we share this document with our design and wireframing experts, there is one more thing to plan – project management.

Anuyat uses modern-day, highly advanced projects and agile task management tools such as Confluence, Asana, Trello, ClickUp, GitScrum, Jira, etc.

These tools help us maintain the team workspace and effectively communicate the progress of the project with stakeholders and clients.

These tools help us maintain the team workspace and effectively communicate the progress of the project with stakeholders and clients.

Planning an application with an MVP approach

The plan for an MVP focuses on the steps that get you closer to “need to have” MVP features rather than “Nice to have” ones.

Anuyat’s MVP scope estimation calculator helps our customers and other users identify the cost and time needed for transforming their idea into an MVP. It is a self-help platform.

As a promise, Anuyat works on “MVP in 90 days” principle - from an idea to a market-product fit, in just 90 days.