Ian Sommerville and Pete Sawyer in “Requirements Engineering: A Good Practice Guide” described, over 15 years ago, the method of assessing and improving requirements engineering processes. It is based on the identification of good practices, activities that are desirable elements of the model process of requirements engineering. The authors tried to cover the entirety of requirements engineering. In my opinion, these good practices do not lose their relevance. They concern the following areas:
- specification document,
- acquiring requirements,
- analysis and negotiation of requirements,
- describing requirements,
- system modeling,
- verification of requirements,
- requirements management,
- critical systems.
However, taking into account the criteria of complexity and costs of introducing good practices, the division of practices into three groups according to the level has been separated:
- basic practices
- intermediate practices
- advanced practices
Good practices form the basis for assessing the level of maturity of the requirements engineering processes in the organization. I have described the scope of these good practices within the above defined areas.
Requirements management – basic good
Document of requirements specification
Define the standard structure of the document. The document of requirements should have a standardized structure in a given organization. This is to facilitate and accelerate readers’ familiarization with the document due to the knowledge of the structure and distribution of content.
Explain how to use the document. The specification document should include a section explaining how the document is used by different groups of addressees. Individual sections should be listed, which will make it easier for them to get up to date with the content of the document.
Attach a summary of the requirements. The specification document should contain a chapter summarizing the assumptions of the system and presenting its basic requirements. This allows readers to get a wider view of the system and allows referring to later defined requirements and speeds up their search.
Refer to business analysis. The specification document should include a chapter justifying the need to build the system and referring to the purposes of the organization for which it is intended. This helps in justifying the occurrence of certain requirements and allows you to assess changes made to the requirements in relation to the organization’s goals.
Define specialized terms. The document should include a dictionary of specialized terms and system-specific terms. This helps to avoid terminological misunderstandings among both authors and readers. It also widens the circle of potential readers.
Take care of the structure of the document. The document should have a clear and clear structure allowing to limit the time needed to review the document and find information therein. This increases the overall effectiveness of people using the document. It is recommended, among others using wide margins, consistent headings, lists and bullets, and diagrams instead of verbal descriptions.
Help the reader find information. To speed up the use of a document throughout the course of the project, it should contain an index and table of contents, tables, drawings, etc. This helps considerably in finding the information you need and increases the productivity of its users.
Make the document easy to change. The document should be easy to change for its users and should not require reconstruction and re-distribution in its entirety. This should be ensured both in the manner of writing and publication. This limits the costs resulting from distribution and delays.
Evaluate the feasibility of the system. The system feasibility assessment should be carried out before acquiring the requirements, in order to assess the feasibility and feasibility of the system implementation and determine its cost-effectiveness. It may turn out that the system does not meet these conditions and its implementation carries a high risk of failure.
Be sensitive to organizational and political factors. Organization-specific and strategic factors can influence the process of acquiring requirements. Their identification can help to highlight important sources of requirements and the system requirements themselves.
Identify the shareholders of the system and consult them. Shareholders are all people involved in creating the system and those who benefit in the future. Identifying these people can help in acquiring the requirements by revealing their potential sources.
Store the sources of requirements. The sources of requirements determine the connection with the information on the basis of which the requirement was obtained. The source may be system shareholders, correspondence, quality standards, technical documentation and others. The storage of sources speeds up the consultation once the requirements change.
Define the operating environment. Defining the operating environment, i.e. the target hardware and software platform, but also other systems that communicate and use the system being built, allows to limit the reproduction of these conditions in tests, moreover, allows disclosure of requirements imposed by external systems.
Use business goals when acquiring requirements. Business goals are abstract and general goals for the system being built, required to satisfy the client. Fulfilling them is the basic condition for the usability of the system and is the basis for specifying requirements.
Analysis and negotiation of requirements
Define system boundaries. System limits are defined by a limited set of system requirements. Separate from them the requirements of processes related to the system and others that are outside the scope of the system. This eliminates confusion in the subsequent process of requirements analysis.
Use checklists to analyze requirements. The checklist should contain questions to check the problems encountered in the previous experience of requirements analysis. Verifying each requirement with such a list prevents mistakes and speeds up the process of requirements analysis.
Share the negotiating support software. The process of analyzing and negotiating requirements should be supported by, for example, electronic mail and electronic bulletin boards or even conference and group support systems. The goal is to ensure a continuous dialogue between shareholders and analysts to avoid misunderstandings, while reducing meeting costs.
Plan conflict management and resolution. In each project, conflicts between requirements should be expected and should be prepared in advance by planning negotiation meetings with the shareholders of the system in order to reach compromises. Such meetings shorten the time of the requirements analysis phase.
Give priorities to your requirements. Analyzes and negotiations should prioritize the requirements according to their validity for shareholders and for the success of the system as a whole. In this way, the most important requirements can be distinguished and the negotiations focused on them.
Define templates for describing requirements. A detailed description of the requirements should be built using a standard template containing a place for all relevant information. Requirements are easier to read and to acquire. The avoidance of important information is avoided.
Use a simple and accurate language. If a word description is used, it should be expressed in simple and accurate language with the exception of complicated sentences and unclear vocabulary. This facilitates quick reading and understanding of requirements and reduces costs.
Use diagrams in the right way. The diagrams should be included in the description of the requirement to express structural information, links between elements of the description or to describe the sequences of events. They are easier and faster to understand than a verbal description. They can also be reused in the future.
Complete the word description of the requirements with other descriptions. Some requirements are best described using mathematical equations, design notations, or even programming languages. However, such a description should not replace, but only supplement the verbal description, making it more strict.
Develop complementary system models. In order not to complicate the system model, it is better to divide it into smaller models presenting its various aspects. This forces the analysis taking into account these various aspects, reveals omissions and facilitates communication with shareholders representing a given point of view on the system.
Model the system’s surroundings. To better understand the requirements, it is good to model the system’s environment, i.e. other systems that communicate with the one being built. This forces specifying the method of this communication and indicates the possibilities of using external systems. It also helps readers understand the relationship with assisted business processes.
Model the architecture of the system. Model architecture should always be modeled, showing how the system is divided into subsystems and how the communication between subsystems runs. This helps in the division of requirements and identification of often problematic requirements for several subsystems.
Check if the document complies with your standard. Before the requirement document is distributed, it should be checked for compliance with the accepted document standard. This saves time for people later viewing, because they can concentrate on the substantive side of the document.
Organize a formal review of requirements. System requirements should be regularly reviewed by a designated group of people. They meet to discuss problems related to requirements and set ways to deal with them. Such a meeting should focus on the problems themselves and not on the responsibility for them.
Use multidisciplinary teams to review the requirements. For the review of requirements, teams composed of representatives of various groups of shareholders and experts are the best. This provides a variety of viewpoints as well as the accuracy and versatility of the requirements review. Shareholders feel involved in the requirements specification process and more open to changes.
Define checklists for requirements. Checklists allow you to organize the verification of requirements and focus the attention of the reviewers on the most critical attributes of the requirements. They also allow the implementation of inexperienced persons, e.g end users in the verification process.
Assign identifiers to requirements. Give identifiers or numbers to your requirements so that they can be easily referenced from other parts of the requirements specification or other documents. This supports the tracking process of change propagation and makes it easier to use tools that automate requirements management.
Define requirements management rules. Requirements management rules should define the goals and procedures of this process and standards to follow. They indicate to those involved in the project what and how it should be performed. In this way it becomes independent from of individual knowledge.
Define the propagation tracking rules. A part of the requirements management rules should provide information on the scope and method of tracking change propagation. They should contain information on how to find links between requirements and between requirements and design, documentation, etc. They affect quality and cost control and facilitate changes in the system.
Keep the change propagation tracking guide. An addition to the requirements specification document should be the change propagation tracking guide. It contains information about the applied tracking rules and the information about requirements associations and other elements. Collecting this information in one place facilitates changes and updates and speeds up access to them.
Create a checklist for security requirements. A checklist specific to the field of system application should be drawn up to check the completeness of the requirements specification. If security and reliability are important, this list should also focus on these attributes. In this way you can avoid bypassing the system’s essential requirements.
Involve external people in the process of approving requirements. You should always include external experts, not involved in the acquisition and negotiation of requirements, in the process of approving requirements for critical systems. They bring a fresh point of view and have no prejudices taken from previous phases.
Requirements management – intermediate good practices
Look for the limitations imposed by the domain of the problem. The domain of the system being built often imposes additional requirements, they result from the applicable requirements, regulations and field restrictions. The system must take them into account and meet them. Gathering these restrictions can be useful when building a different system in the same domain.
Keep the reasons for the requirements. The justification of the requirement summarizes the reasons for specifying the requirement and explains the addressed problem and how to resolve it. The justification accelerates the understanding of the requirement and helps to assess the impact of the change has a requirement.
Collect requirements from many points of view. An important element for acquiring the requirements is the identification of viewpoints for the system. Such endpoints can be shared by end users, managers or system domain restrictions. Identifying them helps in categorizing requirements and finding important ones.
Prototype hard to understand requirements. The prototype is a demonstration of system operation built to identify the requirements of the shareholders of the system. This is particularly important in the case of unclear and difficult-to-define requirements regarding, for example, the user interface.
Use usage scenarios. The scenario is a record of an exemplary user interaction with the system. It indicates the users’ expectations as to the system. This allows for easier acquisition of requirements and desired functionality from users.
Define operational processes. Computer systems are usually designed to support certain processes taking place in organizations. It is therefore necessary to define these processes to better understand the system being built. This leads to easier identification of shareholders and the requirements themselves.
Analysis and negotiation of requirements
Classify requirements using a multi-dimensional approach. It is recommended to classify requirements to find related links between them. It’s best to use many categorization methods in parallel. This method is called multidimensional. This allows you to find similarities and conflicts between requirements and helps in tracking the propagation of changes and finding missing requirements.
Use the interaction matrix to detect overlapping requirements and conflicts. The matrix of interaction has requirements in rows and columns, and intersections between data in two requirements. It can be a conflict, a meshing or a lack of connection. This matrix forces the analysis of relationships between all requirements and is a good object to negotiate requirements.
Specify the requirements quantitatively. As far as possible, requirements (usually non-functional) should contain specific, measurable values of the attributes described. It provides precise information for contractors and is the basis for system acceptance tests.
Use object-oriented methods to model the system. Object-oriented methods is a set of notations, guidelines and rules for defining the system model. Such defined models can be a complement to the specification of requirements, standardize the documentation of models and facilitate the transition to the system’s design.
Use the data dictionary. All names used in system models should be placed in the dictionary along with a description and other information. This allows you to set common nomenclature, especially in multi-person teams, and supports tracking change propagation.
Document the links between the requirements of stakeholders and the system. The link between the word description of the requirements obtained from stakeholders and the detailed models specifying the system should always be documented. This makes it easier to track propagation of changes and check models and related requirements.
Construct a prototype for the animation of requirements. Create a system prototype to demonstrate the acquired requirements and obtain their acceptance by system stakeholders or change hints. The prototype helps shareholders visualize requirements and prevents ambiguities in requirements.
Write a sketch of the user’s manual. On the basis of the system specification, write a sketchy user’s manual describing all aspects of the functionality, taking into account the assumptions concerning the user interface. This helps to reveal possible problems with the use of the system.
Suggest tests for requirements. For each requirement, propose one or more tests to check if the system meets the requirement. It often reveals missing information in the requirements and also helps in designing and planning the right system tests.
Use a database to manage requirements. It is recommended to use a database to store requirements in place of a paper form. This database is easier to maintain, update and search, and maintain information about connections. Many people can access and update simultaneously.
Define change management rules. Clear rules should be defined for proposing, analyzing and accepting changes in requirements. After considering the change, a new version of the given requirement is created. Defining these rules gives stakeholders a mechanism to make corrections, while taking into account and planning related costs.
Identify global system requirements. Global system requirements define the essential and desirable features of the system as a whole. They are not associated with a module or subsystem. They are also therefore the most expensive to change and require consultation with all shareholders. Their knowledge allows you to predict and plan the steps required for changes.
Identify and analyze the threats. A threat is a system condition that can lead to an accident. In the case of critical systems, it is required to collect threats, their possible causes and consequences. This is the first step in providing security for such systems.
Provide security requirements with threat analysis. On the basis of hazard analysis, functional requirements for avoiding or limiting the consequences of accidents should always be introduced. Proceeding in accordance with these rules significantly increases the security of the system.
Check functional requirements for safety requirements. Constantly check functional requirements, do not affect the emergence of new threats and whether there are no conflicts with security requirements. This is to improve the security of the system and find conflicts of requirements.
Requirements management – advanced good practices
Use the same requirements repeatedly. It is recommended, as far as possible, to use or modify any other projects, similar or covering the same field of application, that were obtained during construction. This saves you the cost and time to rediscover your requirements and avoids previous errors. Reusing the requirements may lead to using, for example, an existing code.
Assign risk to requirements. It is recommended to conduct a risk analysis for each requirement or their groups. This analysis determines the probability and type of problems, effects and remedies. This discloses requirements that need change to reduce this risk or specify more specifically.
Develop a verbal paraphrase of the system. If you use formal or graphic notation to present the system model, also convert it into a description in natural language. It saves time of the system’s shareholders who verify this model and does not impose knowledge of the notation.
Identify fleeting requirements. Fleeting requirements should be distinguished, i.e. the most susceptible to changes. If possible, it is necessary to predict what kind of changes this may be. Their separation affects the planning and design of the system to reduce these risks.
Store rejected requirements. Keep a list of requirements that have been rejected during the analysis and negotiation phase and why. It often happens that they are proposed again in a later time. Their storage can reduce the cost of re-analysis.
Specify the system using formal methods. Formal methods use a mathematical record and established syntax and rules. Critical parts of the system should be specified in such a way as to avoid ambiguity and use the possibility of proving the correctness of the implementation.
Collect error descriptions. Information and details on errors that have occurred in previously delivered systems should be collected. This reveals mistakes that have occurred earlier and helps to avoid them in the future.
Draw conclusions from the experience of errors. Using the error information collected, check the functional requirements and search for potential threats based on past experience to avoid similar situations.
Take care of the safety culture in the organization. A security culture means that everyone in the organization is aware of the role that security plays and feels responsible. It is easier to improve the processes have been used so far.