Discovery phase. How AlvariumSoft does it.

                                                                                        General info
Very often people who are going to order some software services may hear such words “Let’s start with a discovery phase” and don’t know exactly what it means and why the development should be started with it instead of the development of the core functionality. Here are many questions, discussions, opinions, and practices. So, let’s break this topic down and discuss what a discovery phase is, why it is important and worthwhile.

Looking ahead, many things are dependent on SDLC (software development life cycle). There are many of them, it’s a topic of another article, that is why we’re going to consider the most popular from them in order to make this topic wider having included as many details as possible to provide our clients with the information and make the understanding about software development more structured and simpler for them.

In order to give a right vector to the project, the idea a client has come up with should be described, investigated, discussed and written. This means the idea should be reflected in gathered and written requirements in full. This way the project should be well performed. There are many ways to reach this goal. We’re going to tell you how we usually do it.

Many people expect to work with a Fixed bid model and consider that all requirements are clear and there is nothing complicated. Sure, in case we are talking about a one-page website it works, but anyway, there are also many details there. In case we talk about different web applications with user roles, logic and algorithms inside, it requires to invest 2 - 4 weeks for gathering requirements in order to deliver the product that must be fit to client's expectations and vision. And it's 100% necessary in case there is a goal to do something by a created application. 

 

                                                                          Discovery phase details
AlvariumSoft starts with creating project boundaries. As the first step should be totally defined business requirements, a business analytic should define all business requirements. The main reason a project is going to be developed should be clear, and contain hidden needs figured out, because they affect the final result. Let’s consider several examples:

- “I want to create a web application in order to sell cinema tickets over the USA from all cinemas in order to have a good traffic to sell advertisement inside”;

- “I want to create an online marketplace for handmade clothes selling to monetize it charging a commission from each internal buying”;

- “I want to create an app to help users sending email chains in order to sell monthly subscription for using app’s services”.

It’s the main thing and a development process shouldn’t proceed without it. If that happened when defining business requirements was missed and a client comes to ask to proceed with development for an already existing project and there is no necessary architecture inside or technologies are not fit, there is a risk to redo the whole app to implement business requirements.

After defining business goals we define key functional requirements. Speaking of simple words it’s discussing what an application should do and how. The most valuable things are hidden under the functional requirements because even if a functional requirement is clear, there are many ways to realize it and many dynamics of his work. It’s important because a client may have a different opinion and if nobody asked about it, it makes trouble during the delivery of a developed functionality when it doesn't match a client's expectations.

                                                                        User stories approach
We prefer to create user stories with acceptance criteria, where all details are broken down and allow us and a client to imagine how it's going to work. Each user story has several use-cases, which state what and how it should be developed,  and how it should work. 

It gives many advantages like:
 - developers know what they should do and don't spend time for additional discussions; 
 - a project manager is aware of tasks, plans, and terms when a particular functionality should be delivered;
 - QA engineer has criteria and scenarios to test;
 - a client has a guarantee to receive the project that totally fits his requirements and expectations.

So, as you can see there are much more details besides a development that affect the final results.