What Is The Difference In Collectinf Requirements For Website Development And Mobilw App Development

Requirement Analysis Techniques

Requirement analysis techniques play a very important role in any of your web or mobile app development project's success. Are you properly analyzing the requirements before you/your team start working on the web app?

Do you know why most mid to large scale projects fail or are delayed? It's because of the faulty or improper requirement analysis techniques for the web app. I have faced failure for two of the projects that cost me double time to develop.

Time is money when we are talking in the context of the I.T field. These two projects helped me develop a requirement analysis techniques that are effective for web application development of any kind. While OOD is out of our scope for this article but I'll cover it soon in the other article.

This article is divided into three core sections. The first two consist of the details that you should consider gathering. While the third one is an additional step that you might want to include while working with large scale applications.

Functional Requirements.
Non-functional Requirements.
FURPS Requirements.

This article is for you if you are seeking for a practical guide on how you should analyze and log the project requirements. I wouldn't be talking about the ideal and theoretical Software Engineering ways of requirement analysis techniques.

In my honest opinion, gone are the days when you fully analyze the requirements, develop, and ship the project. In the time of the Agile development approach, you can't expect your client not to change the business rule or fraction of requirements while you are working on it.

I will try my best to suggest some practical requirement analysis techniques that will help you analyze requirements easily in a small time frame and an iterative procedure that will ensure your project's success.

Functional Requirements [What the app will do?]:

functional requirements requirement analysis techniques

This might be the heart of requirement analysis techniques. You might want to thoroughly understand the functional requirements your client has for the project even before sending the price quote. How would you quote for something before even knowing what functionality is required and how much time and effort you may need to address them?

How to Analyze?

The beginners fall short with functional requirement gathering. They generally try to collect all the information at once and look for the technical ways to address those needs. Don't you think it's quite early to start working on the project after having a brief requirement overview? How much information(in-depth) do you think you can collect in a few(2 or 3) meetings?

I would rather focus on collecting the core idea or functionality the client is looking for. If you dive a little deeper, you will see there is a problem which he/she wants to solve with the project. Ideally, I would understand the problem first.

After getting a good idea of the problem, I would focus on the very core functionality that the client is proposing to solve the problem. No fancy features or things come into the picture just yet. Simply the problem and functionality that addresses the problem.

This should be the area where you focus the most. The success of your project development relies on how efficiently your solution is helping your client solve the core problem. Those extra UI effects, animations, reporting features, and other bells and whistles make no sense if your solution isn't solving the problem properly.

02 Non-Functional Requirements [What else you want it to do?]:

non-functional requirements requirement analysis techniques

Non-functional requirements are those who don't really affect the core problem you are solving with the application. But they are pretty important to your client. Here are some of the non-functional requirements I give place into my requirement analysis techniques.

Legal Aspects:

If I am working on the eCommerce web application development, I would ask the client about the compliance certificate he/she might need. Who will get them, and How they need to be integrated? If there are transactions attached to the web application, what about the return policy? Who will provide the privacy, cookie, and return policy?

Performance:

Sometimes, clients have performance concerns that the web app should load under X seconds. The app should work with the mobile device. They should be able to bare X number of concurrent requests and so on. All the performance-related queries and doubts should be cleared in this phase.

Support:

What kind of support does the client need? How would you be able to provide the support? What will be included in the support and the fees for the support? It may sound small, but it's one of the essential requirement analysis techniques to build better trust and relationship with your client.

Security:

What are the security requirements? What security standards need to be followed? How to opt for the SSL certification? What do other security compliance certificates the client need, and who will provide them? Make the security an integral part of your requirement gathering techniques.

UI Preference:

If you are working on a client/customer-facing web application then your client might have some design, color, and typography preference. Make sure you include them in your requirement gathering techniques as well. It will help you create the design next to his/her preference. Using a UI framework will help you save quite a good amount of time. Bootstrap is a trending responsive web design framework. Learn more about what bootstrap is and how to use it.

03 FURPS [Do you consider this as well?]:

furp requirements requirement analysis techniques

This is a completely optional step. And if you are not dealing with a large and very sophisticated system, I would recommend you to skip this. The FURPS is the abbreviation of Functional, Usability, Reliability, Performance, Supportability requirements. Let's take a close look at it.

Functional Requirement:

Any extra features or the provisioned features the client might want. Any such feature that might change your application's architecture is worth noting here. In common practice, there might not be such features that change the article of your project because you might have covered them in the most primary functional requirement analysis.

Usability Requirements:

Consider what help, documentation, and tutorial the client needs? Who will provide these? How do they need to show up in the web application? Who will train the client or the client's staff on how to use this application. Make sure you cover them all.

Reliability Requirements:

Failure of software or hardware resources can happen. While working with critical web applications, make sure to have provision for them as well. You can have a strategy of multiple hosting, load backing, and failovers. It will help you make sure the web app and data would not get affected in case of a web server failure. Discuss the acceptable failure aid.

Performance Requirements:

Not all web applications are of the same nature. They need different server resources and infrastructure based on what functionality they need to perform. I would highly recommend you include performance in your requirement analysis techniques while dealing with the large and complex system. When it comes to web infrastructure, consider the hardware resource scalability, optimizing the hosting environment, optimize server operating system(if needed), and CDN services.

Supportability Requirements:

Documentation, support, and training/tutorials might be part of the complex web application you will be developing. There are chances that the web app you are building will have public API, you might need to develop the documentation for it. You need a very clear strategy for support and training. Consider adding all these supportability points into your requirement analysis techniques for large and complex systems.

How to Progress Further?

After the analysis, I generally start working on either wireframing or prototyping. If the project is large and complex enough, I will do the wireframing. This helps me discuss and showcase the project's overall design structure with the client. It's very easy to change the design structure in the wireframing phase than the final HTML, CSS based designs. I use pen and paper for wireframing.

If you have an excellent graphic designer in the team and you guys are struggling to convert them into web design, we are offering PSD to Bootstrap Conversion at a very affordable price. We will help you move forward without you needing to think or worry about web designing.

No matter where I start meaning wireframing or prototyping, I start working on the core modules that solve the problem. These are the first building blocks of our application.

Once the wireframing phase cleared, I started working on the design prototype. This prototype helps me decide and confirm the colors, typography, and overall visual design. No backend coding or database. Just the front-end design prototype. I use Photoshop or SketchApp or Adobe XD for creating the design prototype.

Please don't make that develop everything at one time and shipping the final product at the end method. You know it's the best strategy to either fail or take twice the development time for a moderately large to large web applications.

The Modular Approach:

If agile is not the right strategy for your project, at least stick to the modular development and delivery. Start with the core modules. Develop them and ship them. You will have a pretty fast development, deployment, and feedback cycle going on for your project!

There might not be any surprise to your client as well, they will have something to test every week. They would know what is being developed and how the project is taking place. They would be able to provide immediate feedback on the core and most fundamental modules that solves their business problem.

This approach will help you accommodate newly introduced business logic or some customization requests that may need some architectural component changes. Yes, it's very much possible to accommodate such needs with modular development.

And finally, don't get very much stressed about all the requirements as long as you understand the core problem. Because you already have logged (in paper or digital document) the complete application requirements. Once you complete the core part of your application, you will definitely have a better picture of what should be the next requirement and how to address them!

If you are not sure, give a modular development approach a serious shot. Include it in your requirement analysis techniques and development methodology. You will love it.

Conclusion:

A proper requirement analysis kind of guarantees you the successful project execution. This article explains some of the worth noting requirement analysis techniques you may consider applying while working on mid to large scale projects. The modular development approach is also worth considering in case you are not using the Agile method. Feel free to comment in case of any doubts or queries.