QA Documentation and Requirements 

Requirements are the initial data on the basis of which automated information systems are designed and created. Primary data come from various sources, are characterized by inconsistency, incompleteness, fuzziness, and variability. The requirements are needed, in particular, so that the Developer can determine and agree with the Customer the time and financial prospects of the automation project. Therefore, a significant part of the requirements must be collected and processed in the early stages of creating a system. However, it is possible to collect all the data necessary for implementation at an early stage only in exceptional cases. In practice, the process of collecting, analyzing, and processing requirements is extended in time throughout the entire life cycle of the project, is often non-trivial, and contains many pitfalls.

The requirements extraction stage is considered completed when the requirements meet certain qualitative characteristics.

The requirements determine what software features for a given characteristic the interested parties want to see, i.e. requirements should define: 

  1. What the software should do? Example: Allow the customer to place orders and ensure their delivery;
  2. How reliable should it be? Example: Work 7 days a week, 24 hours a day; 
  3. How comfortable should they be to use? Example: The buyer should easily find the product he needs;
  4. How effective should it be? Example: Support service up to 10000 requests per second; 
  5. How convenient should be his accompaniment? Example: Adding a new type of request to the system should not require more than 3 man-days; 
  6. To what extent it should be portable and replaceable? Example: – The software must run on Linux, Windows XP, and Mc OS X operating systems;

Requirements levels

Generally, there are three levels of requirements: 

  1. At the top level are the so-called business requirements (business requirements). Examples of business requirements: the system must reduce the turnaround time of orders processed at the enterprise by a factor of three. Business requirements are usually formulated by top managers or shareholders of the enterprise.
  2. The next level is the level of user requirements. Example of user requirement: the system should provide interactive means for entering comprehensive information about the order, then fixing the information in the database and routing information about the order to the employee responsible for planning and executing it. User requirements are often poorly structured, duplicated, and contradictory. Therefore, to create a system, the third level is important, in which the formalization of requirements is carried out.
  3. The third level is functional (functional requirements). An example of functional requirements (or simply functions) for working with an electronic order: an order can be created, edited, deleted, and moved from site to site.

Requirements classification

  1. Functional requirements describe what the system does; these are 

requirements for the first component of quality – functionality. These requirements are usually action-oriented (When the user clicks the “Process Order” button, the system saves the order data to the database and determines its status as “Queue for Processing”). 

When defining functional requirements, one should look for a middle ground between a requirement that is too specific and too general and ambiguous. Requirements should remain clear to customers and become clearer to developers.

Functional requirements include: 

1.1. Business requirements. What the system should do from a business point of view. The word “business” in this context is closer to the word “customer”. An example of a business requirement: a promotional site that draws the attention of a specific audience to a specific product of the company.

1.2. User requirements – describe the goals/tasks of the users of the system, which must be achieved/performed by users with the help of the created software system. These requirements are often presented in the form of use cases. In other words, user requirements are what the user can do: register, view certain information, recalculate data according to a certain algorithm, and so on.

1.3. Functional requirements – define the functionality (behavior) of a software system that must be created by developers to enable users to perform their duties within the framework of business requirements and in the context of user requirements. In other words, what will developers do to fulfill user requirements.

1.4. System requirements are also included in the group of Functional requirements. These characteristics can describe the requirements for both hardware (type and frequency of the processor, amount of RAM, hard disk space) and the software environment (operating system, presence of installed system components and services, etc.). Typically, such requirements are compiled by the manufacturer or author of the software. For example, for a game, there may be requirements of this type: a video card – a memory size of 64 MB, DirectX 9.0b compatibility, and the latest drivers. For the site: OS – Windows not lower than XP, IE browsers not lower than 7.0, and so on.

The functional requirements group describes how the system should behave when given certain inputs or conditions. But functional requirements alone are not enough to fully describe the requirements for the system – it is also necessary to take into account the requirements for other components of quality, set by non-functional requirements. In other words, how the system will work and why.

  1. Non-functional requirements, respectively, regulate the internal and external conditions or attributes of the functioning of the system.  

Non-functional requirements include:

2.1. Business rules. They define why the system should work 

exactly as it is written. These may be references to legislation, internal rules of the customer, and other reasons. This section is often overlooked, and it turns out that some system solutions look atypical and not at all obvious. For example, many tobacco and alcohol companies require permanent evidence that people over a certain age are using promotional sites. This business rule (age confirmation) arises at the request of the customer’s ethical committees, although it somewhat contradicts marketing goals and usability requirements. 

2.2. External interfaces. These are not only user interfaces, but also protocols for interacting with other systems. For example, sites are often linked to CRM systems. Features of the interaction protocol “site-CRM” also refer to non-functional requirements.

2.3. Quality attributes. Attributes relate to issues of transparency of interaction with other systems, integrity, sustainability, etc. These characteristics include: 

  • ease and ease of use (usability) 
  • performance 
  • ease of operation and maintenance (maintainability) 
  • reliability and resistance to failures (reliability) 
  • interactions of the system with the outside world (interfaces) 
  • scalability 
  • requirements for user and software interfaces (user and software interface).

2.4. Constraints are statements of conditions that change requirements or sets of requirements, narrowing the choice of possible solutions for their implementation. In particular, these may include performance parameters that affect the choice of implementation and/or deployment platform (protocols, application servers, databases, etc.). Constraints are often based on business rules.

Requirements Identification 

The main goal of identifying requirements in projects is to obtain maximum information about the customer and the specifics of his tasks, clarify the scope of the project, assess possible risks, and form a project team that will be entrusted with a significant part of the upcoming work. Identification and analysis of requirements are carried out mainly on the basis of meetings and interviews with managers and specialists of the customer, and the duration of this stage, depending on the complexity of the tasks and the scale of implementation, can be from several days to several weeks.

The stage of identifying and presenting requirements can be conditionally divided into 4 stages: 

  1. Identification of requirements information collection. 
  2. Primary requirements analysis. 
  3. Requirements documentation. 
  4. Verification of requirements. These stages will be performed, alternating and periodically repeating. This iterative process is the procedure for identifying requirements.

Requirements Sources 

  1. Stakeholders – as a rule, are the first and main source of requirements; 
  2. Documentation – all documents present in the company or related to the legal system of the country/business, are the source of requirements, which most often determines certain project restrictions;
  3. Market/Business Segment – ​​competitive systems of the future product are an indispensable source of requirements. Thanks to the study of analog systems, it is possible to significantly reduce the time to identify requirements. Also, various marketing materials are an indispensable source; 
  4. The customer’s business – the specifics of the customer’s business, monitoring the work of future users, the organization’s business processes – all somehow create an image of the future system and allow you to more accurately determine the needs of the customer, as well as the problems that the future system is designed to solve.

Ways to identify requirements 

  1. Survey – involves a survey of existing and potential users of the product (for example, interviews, questionnaires); 
  2. Observation – implies the observation of the work of users; 
  3. Studying the rules of user work according to existing regulations/legislation, as well as studying existing documents describing the client’s business or an existing product; 
  4. Analysis of the history of using the product according to its technical journals; 
  5. Studying existing products of competitors in the market;
  6. Discussions and brainstorming sessions with users and experts;
  7. Marketing research; 
  8. Modeling – can include both modeling of existing business processes and top-level modeling of a future system. 

Traditional methods of identifying requirements also include the use of interviews and questionnaires, observation, and the study of business documents.