What is Requirement Analysis in STLC

Requirement analysis is the first step of the Software Testing Life Cycle (STLC) It involves static testing activities that inform, clarify, and define a product’s specific details or requirements. When requirement analysis is complete, the tester should have a clear understanding of what to test.

Why do we need this step?

Requirement analysis in SDLC is an important step. Defects discovered during this step can be the most valuable to a project. For example, imagine you are working on a project for a customer who wants a website where they can sell guitars. The customer is expecting a custom website where they can upload new images and change prices anytime they want. The product manager anticipates a simple website with stock images, and the developer has plans to create a site where writing and uploading code will be required for any changes. Finally, the tester asks – ‘How often will images need to be changed, what payment methods will the customer intend to use, and why don’t we integrate the payment methods they already have an account for?’. While this is a generic example, you can easily understand how asking the right questions at the start of requirement analysis in STLC can save time and money by building the product right the first time.

Assuming or misunderstanding requirements can waste time and money by building a product nobody wants. By analyzing requirements, asking questions, and thinking about the customer’s wants and needs, requirements can become more concrete and lead to a better product. Requirement analysis in STLC is the foundation for the rest of the development and testing processes. This is why analyzing and clarifying the requirements early on is so important.

While considering what you will be testing, it’s also a good time to discuss project risks, such as whether certain aspects are worthwhile risks or are non-testable.

Requirement Analysis vs Test Planning

Requirement analysis can be confused with test planning, the second step in the STLC, because sometimes they coincide or overlap. While considering what to test, you may also start thinking about ways to test. In fact, the more information you acquire about the product, the more analysis you may need to do.

Requirement analysis and test planning are considered separate steps in the STLC because you cannot plan tests without first knowing what you are testing. During requirement analysis, it is necessary to remember that there are both functional and non-functional requirements.

Functional requirements describe ‘what’ the system should do. These requirements are usually written as acceptance criteria in user stories and are specific to an action being performed within the system.

Non-functional requirements describe ‘how well’ the system should act. Sometimes these requirements are vague or even forgotten. They can include issues like performance and load requirements, usability, or accessibility.

Steps for Requirement Analysis in STLC

Step 1 – Inquire

The first step for requirement analysis is to inquire, or ask, “who, what, when, where, and why.” For example:

• Who will you need to contact for information? Who is the product for?
• What is the purpose? What is the existing state of the product? What is the process? What is expected of the test team? What are the milestones?
• When is the MVP due?
• Where and how often are meetings? Where is the test environment?
• Why is this product needed?

Create a list of questions, then work out how you will follow up. For example, you may need to introduce yourself to colleagues who are specific points of contact (POC).

Step 2 – Gather

Now you have some questions, go get the answers. Requirements could be supplied by the customer, a product owner, the project manager, or any other stakeholder. When gathering requirements, make sure you consider what the user expects. For example, if they have requested a new feature, inquire about who would use it and why. Testers should understand the product’s business and technical specifications. Once you know the priorities from a high level, you can begin to dig deeper.

Step 3 – Analyze

Analyzing involves digging through the information gathered and evaluating your understanding of the requirements. This is a suitable time to ask stakeholders questions, start discussions with developers, verify the requirements are complete, and clear up any ambiguities. If you are unsure what questions to ask, a useful method to help you is mind mapping. Mind mapping allows the tester to visualize different outcomes within a project. It can be used again during test planning to achieve better test coverage.

Another method to trigger questions is a data flow diagram. A data flow diagram is a technical document that shows how data moves throughout a system. When you are done with requirement analysis in STLC, you should have a solid understanding of what the customer is asking for and why.

Step 4 – Document

Once you have clarity on the requirements, they need to be documented. Documenting will make the rest of the steps in the STLC much easier. This is because as you begin test planning, you can refer back to your documentation to estimate workloads. They are also helpful as you execute tests because when you are unsure about a result, you can refer back to the requirements documentation for clarity. Remember, you will use the documentation for test planning, so make excellent notes.

Tips for Success in STLC Requirement Analysis

Flexibility – One of the 12 principles of the Agile Manifesto is to welcome changes in requirements. However, when you have spent a lot of time gathering requirements, seeking answers, and planning, it can be quite frustrating when requirements change. But as a professional, all you can do is take a deep breath and move on. Remember to be flexible with changing requirements and adapt to new requests because the goal should be to provide a product that the customer is happy with.

Don’t be afraid to ask questions – Many testers can be intimidated by asking questions, especially those new to a team who have to approach people they don’t know. Don’t let yourself feel like this. Most people want to share their knowledge, and they expect you to come and ask.

Document – Documentation is one of the steps in requirement analysis in STLC, but we need to document other things as well. When requirements change or details are shared, be sure to document who you spoke to and when. This way, if a question arises later, you will have a note to jog your memory.

Question – Practice being a polemicist. Continue asking why until you get the answers you need to do your job properly. Chances are that if you have thought of the question, others have too. But on the other hand, if no one has thought of the question, they probably should have.

Knowledge transfer – This point is specific to projects practicing waterfall techniques. If you are in a position to start testing but haven’t had sufficient preparation or information, then request a knowledge transfer (KT) session. A quick meeting with the developer or product manager can get you up to speed so you know what to test.

Conclusion

Requirement analysis is the first step in the STLC. It is also one of the most critical. By asking the right questions, contacting the right people, and creating an environment where curiosity is encouraged, testers can gain clarity through the requirements. Once these requirements are correctly understood, documentation can occur, which leads to better preparation for the next step, test planning.