English (UK) 
Magyar 
Deutsch How requirement specification impacts testing
One might assume that with the global IT project experience of the past 20-30 years, no project is started without a well-thought-out, comprehensive, and end-user accepted requirements specification. On the contrary, it’s surprisingly common even today that the development or implementation of IT systems are started or entirely carried out without such documentation.
Business processes meticulously designed and modelled in a standard way, and the relevant functional descriptions guarantee not only the high quality feasibility of the development, but also constitute the foundations for testing.
Without these, projects often go sideways, which leads to counterproductive operation, high costs, poor quality, and dissatisfied users and customers. In this article, we take a closer look at the connection between a high-quality requirements specification and a test suite.
The role of requirement specification
To understand the relationship between requirements and testing, we must first clarify what a requirement specification is. Ideally, this document defines the following aspects of the software to be developed:
- processes
- functionalities
- characteristics
- design elements
- performance parameters
- future user types and their access rights
It’s important to clarify that a requirements specification is a standard business document with an appropriate structure, wording and content. This doesn’t mean that technical requirements cannot be included, but the format encourages to focus on business value and expected business operation rather than technical details.
Documenting software requirements
Standardized, multi-level documentation of requirements is essential for avoiding misunderstandings and deficiencies later. With the current advanced methodologies and tools available, we can choose from several standard requirements specification methodologies. The key is to select and consistently apply planning, analysis, and specification procedures that align with the systems and business processes to be modeled, the level of expertise of the analysts, and the available modeling toolset.
A best practice is to start by defining both end-to-end and internal system processes that the final solution must support. These processes should then be broken down into increasingly detailed steps, guided by the expected business operation.
Once this structure is in place, defining the specific functional requirements for each step becomes much more straightforward. The resulting multi-level architecture - process, step, and function - serves as the frame of the requirements specification, the structure of which makes the clear a thorough consideration and documentation of the requirements unavoidable. Besides functional expectations, it’s equally important to deal with output products and business entities of each process so that all their features that are to be used in the future are captured. Defining user types, authorizations, access rights, and any applicable restrictions is also essential.
Using tools for requirements specification
For the comprehensive execution of the requirements specification process, it’s advisable to use modeling tools and specialized software that
- support the implemented requirements specification methodology,
- help organize information,
and facilitate communication and collaboration among project team members, business experts, and decision-makers.
Creating the requirements specification
If we want to grasp this topic, it’s useful to understand the broad outlines of how a general IT project works. Regardless of the chosen project methodology - whether a traditional structured approach or a more modern agile framework - certain fundamental process steps must always be executed in a specific order.
Once business needs emerge, the sequence of steps is the following:
1. requirements specification,
2. development,
3. testing.
While multiple iterations may run in parallel, so in practice each step is in effect a continuous process, but if we consider a well-defined set of functions (e.g. a sprint), this sequence can be considered constant.
Precise definition of requirements
Both development and testing are based on the same requirements specification. This is why it’s essential that the requirements contained in it are formulated and documented precisely, completely and in a logical context that can be interpreted in relation to each other. Otherwise the project will fail, leaving the customer in a difficult situation.
Modifying the Specifications
It would be ideal if we could fully envision, define, and document the complete functionality of a large enterprise application in the initial, requirements specification phase of a project.
However, reality is far from this ideal.
In practice, projects encounter frequently changing and newly emerging business needs. To accommodate these “new” expectations effectively, we must be flexible in managing modifications to the requirements specification. This requires a well-defined internal change management process and the right tool support that enable effective tracking and managing of changes, informing all business representatives and project team members (e.g. the software quality assurance team), thus ensuring a consistent and error-free project workflow.
How requirement specification impacts testing
One of the most frequently asked - and often most surprising - questions we receive at professional meetings is: On what basis do you write test cases? Interestingly, it’s not the question itself that causes concern, but rather our answer: Based on the requirements specification.
The reason is that, in many cases, the customer doesn’t have a proper requirements specification, which significantly complicates preparation for testing. The most common issues we encounter include:
- lack of specification, or incomplete specification
- the document is outdated and doesn’t reflect modifications made since the system's implementation
- the specification is scattered across multiple files, leading to a lack of centralized documentation and version management
- the original author of the document is no longer available to clarify details
- the document contains obsolete references to other systems or documents
- the enterprise’s modeling or analysis application license has expired, making some data inaccessible
- and so on...
The good news is that if we find ourselves in such a situation, we can immediately reassure the customer that test cases can still be written, a test suite can still be created - even without a proper specification, but it will require significantly more time, effort, and resources than usual. The reason is that the system knowledge and process understanding needed to write test cases must then be gathered from alternative sources.
But what exactly are we gathering, what do we want to read in the specification and why is that the most appropriate document for us?
Developing the test strategy
The first step is to analyze the specification and gather information that applies to the overall testing process. We examine the key processes, the core functionalities of the application, and its fundamental business value. Based on these insights, we start to plan the broad outline of the testing. By assessing the number and complexity of processes and functions, as well as the characteristics of related systems, we develop a test plan that aligns with the project plan and its timeline.
Test suite coverage and scope
As our understanding grows, we aim for comprehensive coverage while also identify process gaps, logical inconsistencies, and business issues. After this, we explore the details of the specification further, focusing on less frequent process variations and edge cases. This approach enables us to build a thorough and precise set of test cases, forming a well-structured test suite.
Extracting test data from the requirements specification
- Once we have a clear understanding of the processes and how the functions operate, we analyze the business entities required for their execution, focusing specifically on their attributes.
- By collecting and organizing these attributes, we build a comprehensive set of test data, the variants.
- We then determine the number of variants needed for each test data set to ensure that the testing cycle can be executed fully and completely.
Requirement specification and test users
The test user in the testing environment corresponds to the end user in a live environment. That’s why, alongside collecting and organizing test cases and test data, we also identify and structure user roles and their access rights to ensure role-based testing that closely mirrors real-world scenarios. Ideally, a role-access rights matrix that clearly outlines user access conditions is a part of or an attachment to the requirements specification. When available, this matrix becomes a valuable addition to the test suite, providing a solid foundation for accurate and comprehensive testing.
Mapping test cases to requirements
If we have successfully created a suitable test suite and the necessary test execution scenarios based on the requirements specification, we load them into a test management application.
It is advisable to choose an application that "recognizes, understands, and manages" the requirements as entities, thereby supporting more precise, business-oriented test metrics.
With this approach, every test case remains linked to a requirement throughout the later phases of testing, ensuring traceability and providing permanent insight into the business coverage of the application's currently functioning features. Naturally, multiple test cases may cover a single requirement in the specification, just as a single test case may correspond to multiple functions. The key is that we will be able to map the results of each test cycle back to the requirements specification and its scope, offering a clear business perspective on the project's current success and the actual usability of the functionalities.
Conclusion and recommendations
Hopefully, this overview has effectively illustrated the strong connection between requirements specification and testing. The success of a project ultimately depends on well-defined processes and requirements, along with their precise administration. This, in turn, enables the seamless execution of subsequent activities, including development and software quality assurance.
If this article has piqued your interest or you would like more information, please feel free to contact us.
