Our client came to us with a great idea, and we made it into one of our best and most detailed technical specifications. Read our case study about when professional background and deep knowledge of market meets mobile expertise and technical background.

Background

Our client came to us with an idea for a web app for lawyers. His friend recommended Mobindustry as a flexible mobile development partner that could not only create a web application, but also create a technical specification and help with a business strategy.

Our client needed this as he had nothing except an idea and didn’t know how it could be implemented from a technical and business point of view.

In this case study, we’ll show you how our business analyst worked with this client who came to us with a high-level vision for his product.

The challenge

The goal of our business analyst was to extract knowledge from our client, collect it, and create a technical specification. The biggest challenge was creating a technical specification based on an idea but without formalized documents. We didn’t have a less detailed technical specification, wireframes, or existing business processes to work from.

A technical specification is important not only because it makes the development process more organized but also because without a technical specification we can’t provide a precise estimate for a project.

Apart from allowing us to make a detailed estimate, a technical specification has a number of other important functions.

It helps us manage expectations and creates an understanding of the whole product both for the development team and for the client.

A technical specification is also used for quality assurance: a QA engineer uses formal requirements mentioned in the technical specification to create test cases. In this way, a technical specification minimizes risks and allows stakeholders to control the whole development process.

A technical specification is a valuable document that translates an idea into detailed and specific requirements that work as a guide for developers, quality assurance engineers, product owners and project managers

At the first stage, we drew on our client’s vast experience in law practices. Our client is a lawyer with over 20 years of experience, so he knows all the ins and outs of the profession and what problems there are.

We offered to create a technical specification along with wireframes and a design mockup.

The set of features for the initial stage of the project was vague, so we couldn’t tell exactly how much this project would cost.

So we scheduled weekly meetings and started to create the technical specification.

Our solution

The process

The stakeholders who took part in creating the technical specification were:

  • Business analyst
  • Project manager
  • Our client

A lead developer was also involved at the end of the preparation stage. His main objective was to validate the technical specification and estimate the whole project.

We scheduled calls with our client twice a week and discussed every detail, feature by feature. Sometimes, new ideas appeared in the course of discussion.

meeting with a client
We had meetings two or three times a week, where we discussed every feature with our client and offered technical solutions for his ideas

At the start, we determined the target audience for the application and specified what problems the app was going to solve. Our client helped us understand situations the app would be used in, and this was the foundation for defining the app’s features.

Before creating a set of core features, our business analyst also analyzed the market and performed competitor research. This helped us to decide on the preliminary feature set.

After the feature set was ready, we needed to determine how these features would actually work. At this point, we offered our client many different options and considered which one would be best for his idea and for users of the app.

App’s behavior in case of unexpected inputs or errors, security, authentication logic, encrypted data exchange — these are details people without a technological background don’t usually think of

We also chose a technology stack and architecture and formalized the update procedure. Our business analyst offered to include analytics into the app to track its technical and marketing performance. Our client specifically asked us to use common technologies to make the app easier to maintain.

We had to consider lots of issues that people without a technical background usually don’t think of. For example, the app’s behavior in case of unexpected inputs or errors, security, authentication logic, encrypted data exchange, and so on. As this was an app for lawyers, we understood that security was a major issue. All these details had to be thoroughly planned to ease the quality assurance process in the future.

After each meeting, our developers along with our business analyst did research and made a high-level plan that could be discussed at further meetings with the client.

The result

After three months of regular meetings, the technical specification was finally ready. It included 15 parts that described different functional components of the application.

It took much time and effort to create this technical specification because the app ended up being very complex: it has four user roles, and each of them needs its own user scenarios and access level.

For example, this part of the specification document describes the user account management system:

When the technical specification was ready, our business analyst started to create wireframes and our designer started working on the UI of the web application.

It took our business analyst 136 hours of work, including communication, to create the technical specification and wireframes.

The app’s design took 170 hours.

Challenges while working on the technical specification

It was great to write a technical specification with a truly involved client who collaborated with us at each step. This helped us a lot, as we could define the app’s objectives better. The client readily shared his knowledge.

Our collaboration allowed us to avoid some challenges and overcome others.

The first challenge appeared when our business analyst started to describe interconnected features . This was a problem, as it wasn’t possible to define one feature without knowing some basic things that could be determined only during development.

For example, we didn’t know which payment gateway we’d eventually choose, so it was hard to estimate that feature. The developers would have to research each payment gateway and only then could we estimate it properly. But the choice of payment gateway depended on the app architecture. Payment gateway integration in Android or iOS has its own peculiarities, so we needed to consider platforms as well.

That’s why there were several stages of developing the technical specification, during which we validated some features with developers and decided how they should be described.

Another challenge was the constant changes to the technical specification. As our client had a very high-level vision of his product, the requirements naturally changed as we continued to define it. The challenge here was to keep all documentation updated.

Our business analyst ended up with 15 separate documents that made up the whole technical specification, and each time something changed she needed to make changes to all documents.

Thanks to great change management, we were able to keep the whole technical documentation up to date and make sure nothing was lost or forgotten.

What happened next

Our developers validated and estimated the whole project according to the technical specification. For the next step, project estimation, our developers needed to start the project setup.

A project setup is the initial development stage that involves:

  • Designing the app architecture
  • Setting up the backend and repository
  • Setting up the database
  • Researching and selecting tools and technologies

After this stage, it was clear how the development process would go, and our developers provided a final estimate.

But the planned project was too big. It would take almost eight calendar months with two developers (one frontend and one backend) to complete it according to the specification. Our client wanted to test the app on the market as fast as possible, so we decided to pick out certain features for a minimum viable product (MVP) and start with them.

We created a new five-month plan for an MVP and started developing the application according to the new specification.

Conclusion

A technical specification is the most important document for any mobile development project. It requires the involvement of both the client and the development company.

Business analysis136 hours
Design170 hours
Average duration of each communication session1.5 hours
Final estimate 8 months of work by 2 developers
MVP estimate5 months of work by 2 developers

In this case, it took our business analyst 136 hours to create a technical specification that described each step of an eight-month development project. Although creating a technical specification takes time, it’s crucial for a smooth development process.

Our client also spent many hours on communication, defining requirements and getting a clearer understanding of his product. Without this process of creating a specification, he would probably have spent just as much time throughout the development process, as we would have needed to constantly ask him about different aspects of the app’s logic.

Moreover, a technical specification gave our client a clear vision of what he would get in the end as well as control over a project that was developed remotely.

We can’t stress enough how important it is for a client to be involved in a project, especially at the preparation stage. It takes time, but it’s worth it.

Business analysis services

Do you have an app idea? Let us transform it into a detailed technical specification

Get a Free Consultation!
Request Callback

Request Callback

+