When it comes to working in Agile development, teams are working together with the customers throughout the software project. They’re constantly communicating, collaborating, and exchanging ideas and suggestions for product improvement. Usually, the customer requests a new software functionality, and together with the agile team, that functionality is converted into a form of a requirement. That requirement must be clear and concise so that everyone can understand what is the purpose.
Out of the requirement, epics and user stories are created to divide the work between the team members. In order for the agile team to clearly define user stories from requirements a technique called requirements engineering is applied.
What is requirements engineering?
Requirements engineering is a method of specifying, creating, and maintaining customer requirements. Agile teams are following this approach to clear out the user stories, add purpose and context to them, consider risk, impacts, and tech debts and identify other missing requirements. The requirements engineering method is applied throughout the whole project lifecycle and in each iteration.
There are 4 main requirements engineering techniques that in Agile, are used pretty often in a less formal approach by all of the team members.
What are the main requirements engineering techniques?
The 4 main requirements engineering techniques are:
Elicitation
Used for acceptance criteria evaluation and clarification, elicitation is a process of finding, understanding, and documenting the user’s requirements and limitations.
Documentation
As the name says it all, documentation is the process of documenting the user’s requests in a form of user stories and acceptance criteria. The documentation should be clear enough using some examples, diagrams, or just natural language.
Validation
When one user story is being defined, different customers can have different suggestions and thoughts on how that should be implemented. Every customer has its own acceptance criteria and the agile team needs to gather their insights and identify any potential conflicts. It’s really important to not forgot some unresolved conflict before the user story is finished being validated.
Management
Even after the user stories were defined and validated, the acceptance criteria were written and concluded, it is still a subject of change because opinions can change or due to some external factors the whole functionality that includes multiple user stories might change. Because of those potential changes, the agile team needs a good approach and management of addressing these changes accordingly.
Using requirements engineering in analyzing user stories
Testers working in an agile testing environment help clarifying requirements along with other members using various approaches like:
- Storyboards
- Personas
- Mappings
- Use Cases
- Diagrams
Storyboards
Using storyboards, the testers can help see the overall context of the user story and the process in the background, assisting with acceptance criteria and user stories, helping with selecting the correct test strategy and approach, and conclude whether a group of similar user stories should be picked up in one iteration since it is likely that those stories will be touched at some point during an iteration due to their similarities.
Personas
Using fictional characters (personas) that will serve as a real user would interact with the system. Using personas can detect ay potential flaws in the system, identify product inconsistencies and discover, create and maintain the acceptance criteria.
Mappings
Mappings are used which have 2 dimensions (axes) that define the user story. The first axis is the one that represents the priority of the user story and the second one represents how sophisticated it is to implement it. Mappings can find the level of risk for each user story, define the scope of the system and prioritize the most basic functionalities.
Use Cases
Using use cases, testers can verify that the user stories are testable and correctly sized, detect any integration points that need to be taken into consideration, understand the communication and relationship between multiple user stories and determine if the user stories need an additional refinement before being validated.
Diagrams
Diagrams can be of various types like class diagrams, UML diagrams, entity-relationship diagrams that can the behavior of the system as well as all of the data flow. The purpose is that we may identify some gaps or flaws in the system functionality.
Conclusion
Requirements engineering can help us with identifying the requirements that come from the customer more easily and the whole journey of creating the requirements, converting it to a user story and acceptance criteria, and then changing its content and purpose for some external reasons can be more manageable and understandable to everyone.
Share This Post
Latest Post
- Test Analyst’s Responsibilities in Risk-Based Testing
- Crucial Aspects Of Superior Test Code Quality
- Streamline Your Cucumber BDD Tests with Gherkin Lint: A Comprehensive Guide
- How to Test Authentication and Authorization with Confidence + Best Tips
- Exploring the Three Scrum Artifacts: Grasping Their Essence and Effective Utilization
