Discovery phase. How AlvariumSoft does it.
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.
We also create use cases for each user story. It provides our management and developers with a common understanding of how it’s going to work in detail. It also shows conditions where defined algorithms should work. The developer who works on a task should only concentrate on code creation instead of defining conditions, details, etc which unfocuses the developer. In case of coding more-less big projects it saves much time and budget for our clients simultaneously increasing results for clients to receive what they really expect.
Here is a use case example of "Reset password" functionality
Precondition - a user has an account and is logged in
- a user should have an ability to put his email into the field;
- a user should click to the button reset;
- a user should receive a warning if the email is not matched with registered email;
- a user should be able to change the email and the email letter with a new password should be sent to the email box;
- a user should receive a new password and log in using it;
Alternative scenario 1
- a user should have an ability to skip this stage and move to another page inside his account.
Writing such documentation we deliver to the client more accurate results than working without it, just discussing from time to time what should be done.
The most valuable part of gathering requirements and simultaneously a competitive advantage is prototyping. In a nutshell, it's creating a user interface of an application based on provided requirements using Figma prototyping functionality. It’s a mockup creation that is going to be linked and become a clickable prototype. It allows reflecting some client's vision concerning user interface, yeah, we in AlvariumSoft make prototypes colorful instead of black and white dry draws, and it gives an opportunity to use Figma's functionality of linking pages. And when screens have links between each other we just need to launch the prototype and we can surf between pages like a traditional website in the network. This way we can check a user journey and think about the logic and app's working. A client can also play with it and feel if it is what he needs or not.
Here is how it looks
We always try to visualize what should be developed in the future. Because in case we see that something needs to be redone we do it easy and it takes just a little time. Because the next flow is UX/UI design and having such a prototype as described above we increase the level of accuracy incarnating a client's idea. So, a UX/UI designer has particular logic that an app follows and the designer concentrates to make it as convenient as possible instead of defining project boundaries and translating lots of client's wishes to clean information that's going to be implemented.
Speaking simpler, we do something more than just writing many strings of requirements. We provide our clients with added values to be different and stand out from other vendors and supply more accurate products.
In general, our clients appreciate the results that we have after a discovery phase is conducted. This stage is very important and allows us to have a look at the project before starting development.
Summarizing the advantages are:
- saving client's time and budget;
- defining what exactly should be done;
- defining project boundaries;
- creation of the clickable prototyping;
- user stories and use cases creation.
We hope this information will be useful for you and bring you different benefits.
How useful was this post?
AlvariumSoft Receives 2020 Top Software award
Thousand Ways of creating UX/UI design
Nowadays marketplaces are very popular among users. It's comfortable to find thing you need in several clicks. We've prepared information that may be useful for you.
“We are thrilled to have been chosen as one of the leading software development providers in Ukraine!” – Andriy Petrenko, CEO