A Comprehensive Guide For Requirements

That’s not technically true… I’d love to spend time with family, eat chocolates and open a small selection of functional, relevant and meaningful gifts along with a stack of Christmas Pudding and brandy butter and maybe user acceptance test a glass or two of Baileys! 

However, as we hurtle along towards the festive season at an astonishing rate, I’d like to blog about requirements in software testing as they are so crucial to getting a good outcome, but so often hard to obtain. 

Requirements which are of good quality and signed off would most likely be high up on the work Christmas list for many in a QA Test capacity as they form such a valuable part of software testing.

Why are requirements so valuable? At a high level, requirements are used to help define what the expectations and needs are of the different groups within a software delivery team or of the targeted end user. They help us to make decisions, to plan to get information on the level of software code and environmental quality. I will cover the benefits in more detail further on.

Requirements help us to determine when things do not look or behave correctly in software, when this happens we are able to raise records to help get clarity or a resolution on what the unexpected findings are. These are often referred to as ‘Bugs’ or ‘Defects’. These defects often go hand in hand with requirements because if there are documented requirements, it will give a baseline of a set of expectations, which can be compared with actual test result data and interpretation of the expected outcomes. If the requirements are unclear, then a defect can often be raised but can effectively turn out to be a user expectation error, or a missed requirement that needs to be handled as a change request. It can be very valuable when these are discussed as it widens the awareness of expectation and gives visibility to other stakeholders about potential issues. Sometimes defects can be found which do not link directly to a requirement. Often a tester will raise an issue that they were not expecting, and it can be something that was discovered along the transaction of functional journey as oppose to the targeted testing of a specific feature of functionality. Huge savings can be made and risks significant reduced if there are good testable requirements available to your testing resources.

• User requirements – these requirements will contain processing flows called user stories, use cases and scenarios which give context to a wide expectation of the functional processing. They will detail the expectations of the targeted and specific user which enables them to perform their role or a specific task for example.
  
  
• Business requirements – typically these outline the key functional expectations of the business users and related onwards business processing targeting intended use primary purpose etc. It can include the client, the supplier, the organisation supporting the client business processing, downstream or back office requirements.
  
  
• System requirements – these will usually be to facilitate the necessary technical elements to enable the functional business and user requirements to be delivered. They might include for example interface requirements, naming conventions, data formats, mandatory fields and lengths etc., system requirements will usually be split into two categories:
  
  
  • 1. Functional requirements - detailing the processes and subsequent resulting expectations that are required.
  • 2. Non-Functional requirements – detailing expectations that help to assess the software behaviour within the test environment. This will consider things like performance response time, usability, scalability, regulatory and security to name a few.

Sometimes if there are savings to be made, there are requirements which relate to a staggered delivery in the future often referred to as Day, Stage or Phase 2.

Fundamentally requirements have a very valuable part to play in the software testing process - they help to provide information on and to identify the following:

• The quality of the software – whether it meets the needs of the business and performs as per the documented requirements and is fit for intended purpose.
• Helps to determine if the software solution is feasible to deliver within the time, scope and budget.
• The unexpected system behaviour – unintended or undesirable consequences and results.
• Missed requirements – often occurs when requirements gathering has been rushed or performed with limited resource and lack of peer review.
• Ambiguity in requirements – we can help identify what exactly is required and also what is not required.
• Error handling – whether appropriate data handshake and send/receipt messaging between systems is adequate to alert the necessary teams in the case of malfunction or interrupted delivery of data flow processing.
• Unintended software use – how the system behaves and what visible indicators there are to both the front-end users and the mid-tier system users and downstream teams.
• Traceability matrix coverage – a grid type method to give quick glance dashboard style information on the key testable areas.
• demonstratable discussion points for ambiguity or complex problem areas in onwards development.
• Prioritisation – making sure the most important area of the development is tested first in case of project slippage and squeezed delivery milestones.
• Planning and forecasting – helps to begin sizing and evaluating resources, effort, elapsed time etc
• A measure of expectation in terms of shared visibility of test results to stakeholders.
• Progress reporting – target against actuals so that stakeholders can track progress and get visibility of blockers.
• Cost control – how much planned versus actual costs are likely to be.
• When to stop - what does done look like – when can we stop testing and how that compares against intended scope?

So, I’ll sign off now and hope that you get all your requirements met and have the very best time during festivities and a prosperous new year!