In part one of this series, we discussed integrating a test management tool into your development environment. You set up the users, their roles within the team and their access rights. With that done, our test management tool is set up in a way that allows the best possible workflow for our team.
Now you’re ready to start a new software project. You have a few ideas swirling around in your head, but no focus on what is a viable product. For example, you meet with all of your stakeholders and discover that there isn’t an application to grab all of their favorite types of content and dish it to them in an easy-to-access mobile application. They tell you that they are tired of sifting through the quirky Web browsers on mobile devices. The light bulbs are now starting to go off in your head, so you begin to brainstorm with your stakeholders and team members about what this application requires:
- It needs to have a simple design, so that even a child could use it.
- It needs to work on every mobile platform.
- It needs functionality to pull the right content from the right sources around the Web and present it to the user.
You are starting to envision what the customer wants and this product could have the potential to be a game changer. You sketch up the product with all the key features that make it a unique solution and your team sits down to storyboard this potential product.
You’ve laid down the groundwork, so what’s next? The requirements are starting to become more concrete but you need to capture them somewhere that your team can easily access it, like QAComplete. Capturing the requirements in QAComplete gives you a starting point for your workflow so you can track activities from inception through launch.
From the Requirements tab, start this process by creating a folder for different categories. This could be new folders for functionality and the use cases for your product. Within each category or folder you can add a new requirement.
Adding a new requirement is as simple as clicking on Add New, then entering the title, status, owner and assignee and attaching any documentation that has to do with that specific requirement. If you’d rather, you can also organize our requirements by sprints and releases.
This allows you to organize certain functions that need to be implemented. If the application requires certain certification before we can implement a function, we could have the certification process as a task to be completed first.
Keep the personas in your user stories
When starting to build your requirements it is important to make note of all your stakeholders and how the product should work for them. Developing a set of personas that will be using the features will help to keep the “user” in your user stories. Ideally, you should format your user stories in a way that speaks from the user’s perspective: “As a test engineer, I want to see pass/fail reports for my automated tests because I need to analyze failures.”
Prioritize the requirements
Based on the personas in your user stories, you can prioritize the requirements of your product by identifying user impact. If all of your stakeholders believe that a certain requirement is of high importance, then this functionality should receive a high priority.
Groom your backlog
The market in which your product will be released is bound to evolve over time and so your product, likewise, should evolve. This means changing requirements to meet the ever-changing needs of your stakeholders.
Creating great requirements is the start to creating great products. Using a tool like QAComplete to store and manage those requirements ensures that the whole development team has access to them and can link their ongoing work - like tasks, tests, and defects – back to those requirements.