7
Requirements Management
Requirements are the basis for the design and testing of each of the systems, subsystems, equipment, components and software. It is therefore essential to define clear and testable, non-ambiguous and non-contradictory requirements. In a system-of-systems, the number of requirements is usually huge (several thousand or even several tens of thousands). The requirements must therefore be identified in a unique way, linked to the functionalities and the components (systems and subsystems, equipment, etc.), and serve as a basis for both the developments and the tests which will demonstrate their proper implementation. The number of requirements and their changes over time justify the use of requirements management and processing tools. It is also recommended in ISO/IEC/IEEE29148 (2018).
In the context of this chapter, we will use the term “requirement” to represent what is required as development; in Agile parlance we will speak more of epics (Epic), characteristics (Feature) or User Story. The concept is similar, and the applicable rules and practices are identical.
7.1. Requirements documents
In a system-of-systems, the technical and functional requirements can be present in several documents, with various levels of granularity. The standard (ISO/IEC/IEEE29148 2018) proposes:
– business requirements specification (BRS);
– stakeholder requirements specification (StRS);
– system requirements specification (SyRS);
– software requirements specification (SRS);
– system operational concept (OpsCon).
There are other documents that may contain applicable requirements including:
– contractual documents;
– applicable standards;
– architectural documents;
– vision and scope documents;
– use cases, features and epics in Agile environments.
In a system-of-systems, we must also identify the reliability, availability and capability requirements related to the missions that the system-of-systems must achieve. For example, a system-of-systems in charge of the defense of a carrier battle group will have to manage end-to-end (E2E) missions with objectives of reliability (can it really be 100?), availability (can it really be 100%?) and reaction times (depending on the capacity and speed of the threats), which will have to be studied according to the architecture and the different nodes of this system-of-systems. This will involve identifying the resources to be used, their behaviors – including for Legacy-type systems – which will be involved in the responses to these E2E missions.
We will therefore have both quality requirements, and also architectural, engineering, capability and capacity constraints, which will be added following the various system-of-systems objective planning meetings.
7.2. Qualities of requirements
The quality of requirements is an important element to take into account, especially since the requirements are at the origin of approximately 20% of the total anomalies in the software.
During our experience, we have certainly encountered requirements that were:
– Pious wishes: for example, “the application will manage the users”, without indicating the management activities to be envisaged, neither as attributes associated with the users, nor the level of security to be implemented to protect the personal information stored.
– Contradictory, especially given the large number of requirements in a system-of-systems: for example, “the aircraft must take off for ASW missions with two torpedoes” and elsewhere “the aircraft must carry out ASW missions at maximum range with a torpedo”; how many torpedoes must the aircraft carry for ASW missions (one or two) at maximum range?
– Non-testable: for example, “the application must be faster than the previous version”, without indicating the volume of transactions or simultaneous users, nor the level of reduction to be achieved.
– Not achievable, or not achievable in an economically profitable way: for example, “the application must be available 24/7 without interruption”; this implies that the corrections, patches or developments cannot generate any interruption, and that the production must consider a duplication of servers and a hot backup in case a server is down (plus continuous power supplies for servers, network equipment, etc.).
– Frequently modified: for example, “response time must be 2 seconds”, a few days later “response time must be 1 second”, then “in this case the response time can be 4 seconds”, etc., which can lead to significant architectural modifications (load balancing, simultaneity of processes, etc.).
– Incorrectly distributed to the people or groups who need them: for example, developers are always informed of the requirements that they have to translate into code, while this is not always the case for testers. Testing teams, primarily for SIT and UAT testing, and related systems teams were not always notified of the changes that are being implemented.
We realize that the costs associated with defects in requirements quickly become enormous if they are not detected quickly: development and tests rely on these requirements to design their deliverables and the late correction of requirements – after the developments have begun – will involve considerable effort.
One way to ensure the quality of the requirements is to carry out reviews (formal or informal) of these requirements and to ensure the level of detail defined for each one. A requirement from a higher level (e.g. Feature or Epic) must define the needs at this higher level and not the solutions or draft solutions envisaged for the lower level(s). More information can be obtained in Freedman and Weinberg (1990), and in Wiegers (2010).
In the case of Agile development, requirements can be defined – and reviewed formally or informally – as the project progresses in the form of Epics, Features or User Stories. The level of granularity of these requirements ranges from the most general to the most detailed.
7.3. Good practices in requirements management
Standard ISO/IEC/IEEE29148 (2018) and Wiegers (2013) identify the following good practices associated with requirements engineering.
– elicitation;
– analysis;
– specification;
– approval and validation;
– requirements management;
– awareness;
– project management.
Actions and best practices associated with requirements management need to be addressed.
7.3.1. Elicitation
In the context of requirements elicitation, that is, the gathering of requirements from various stakeholders, we have:
– define the vision and scope in order to inform all project stakeholders, and define the limits and contents of each iteration;
– identify the classes of users and their characteristics, and their frequency of use of the system-of-systems;
– select the product champions for each class of user, in order to have a referent for each class who can make decisions on behalf of this class of users;
– create focus groups with representative users in order to collect information on the desired or expected uses of the system-of-systems;
– identify user requirements with user representatives, highlighting each requirement and representing them in the form of Use Cases, User Stories, Scenarios, etc.;
– identify system events and their responses, including external events to internal events. Periodic signals or interfaces – or even their absence – may have to generate alerts and/or the implementation of degraded procedures within the system-of-systems;
– hold interviews and elicitation working groups in order to allow the interaction between analysts and users;
– observe users performing their work in order to create flow diagrams, and identify interactions and decisions that could go unnoticed;
– distribute questionnaires and analyze the answers provided;
– perform document analyses, including documents from competitors (e.g. marketing brochures, user manuals, etc.) in order to identify the necessary, desired or unused functionalities;
– examine reports of anomalies or problems reported by the field;
– reuse existing requirements.
7.3.2. Analysis
Requirements analysis requires:
– modeling the application environment to identify limits and interfaces;
– creation of technical prototypes and user interfaces;
– analyzing whether the requirements are feasible or not;
– prioritization of the requirements (or Features, User Stories etc.);
– creation of data dictionary to facilitate shared understanding;
– modeling requirements to reveal inconsistencies, gaps or superfluous requirements; models can be data flow diagrams, identity and relationship diagrams, context diagrams, state and transition diagrams, state and transition tables, decision trees, etc.;
– analysis of interfaces with external components, products or systems;
– allocation of requirements to subsystems.
7.3.3. Specifications
When we begin to specify requirements, we will have to:
– adopt templates for requirements (e.g. Vision and Scope, Use Case, SRS, etc.) in order to have a consistent structure for recording and grouping information related to requirements;
– identify the origin of the requirements in order to identify the stakeholders at the origin of the requirement and those impacted by the requirement;
– uniquely identify each requirement by a robust naming convention, allowing the addition, modification and deletion of requirements over time;
– record business rules, company policies, applicable standards, etc; business rules should be stored in a separate document because they exist beyond the project;
– specify non-functional requirements to identify the non-functional quality characteristics to be tested.
7.3.4. Approval and validation
Requirements should be testable and validated. For this, we will need to:
– review requirements, for example, through peer reviews or inspections;
– test the requirements and design the tests that will demonstrate that the requirement is – or is not – satisfied;
– define the acceptance criteria desired by users;
– simulate requirements, for example, via prototyping tools.
7.3.5. Requirements management
Requirements management interacts with other management processes such as configuration management and version control processes by:
– establishing a change control and monitoring process covering proposals for change in requirements, their analysis and their resolution (acceptance or rejection);
– performing change impact analyses, in order to help the CCB to make correct decisions for the business;
– establishing baselines and version control of requirement sets. These baselines will include approved requirements, typically for a specific release or iteration;
– making sure to keep the history of changes, in order to facilitate the return to a previous version of requirements;
– tracking the status and state of each requirement (e.g. proposed, approved, implemented or verified), in order to measure the evolution during the project;
– dealing with concerns and exchanges on requirements so as not to forget any; – using a requirements traceability matrix to identify the component(s),
product(s) or system(s) impacted by each requirement; requirements management tools are essential for creating such a matrix;
– using a requirements management tool.
7.3.6. Requirements and business knowledge management
Requirements management also interacts with business knowledge management, among other things, to:
– train business analysts;
– educate stakeholders about the requirements;
– educate developers about the application domain;
– define a requirements engineering process;
– create a glossary.
7.3.7. Requirements and project management
Requirements management, of course, interacts with and is impacted by project management processes:
– the selection of appropriate life cycle and design according to the types of projects and degrees of uncertainty related to the requirements;
– planning the approach to requirements, how they will be identified, analyzed, developed and validated (or rejected) throughout the project;
– the estimation of the efforts related to the requirements (obtaining, refining, etc.) and what are the factors that will influence the duration of realization – and testing – of the requirements;
– the definition of plans based on requirements, for example, by assigning sets of requirements to PI (Product Increment), components, products or systems and achievement milestones;
– the identification of decision-makers linked to the requirements, in order to resolve conflicts linked to business decisions external to the system-of-systems in progress;
– renegotiation of project implications when requirements change; this involves communicating to the project (both customer and supplier) if it is impossible to meet deadlines or the level of quality if changes in requirements make these objectives unattainable;
– requirements risk management, in order to avoid the impact of unanticipated risks on the project;
– requirements effort tracking, in order to provide better requirements workload estimates for subsequent projects as part of continuous improvements;
– review of past lessons learned even from other projects.
7.4. Levels of requirements
The level of granularity of the requirements will vary depending on the document where these requirements will be defined. If we refer to the requirements documents, we can clearly see that the requirements of the “Vision and Perimeter” document will be of a much higher level than those which will be in the SRS (Software Requirements Specifications) document. This is an advantage of sequential design methodologies over Agile methodologies.
In Agile projects, the requirements will start with a limited level of detail (e.g. during PI Planning) then will be more and more detailed – in the Product Backlog, then the Sprint Backlog – before becoming extremely detailed when they will be made. It is this level of detail that will make it possible to design the test cases necessary for the verification and validation of the requirement.
It is the responsibility of each team to define the appropriate form and level of detail for each of the requirements. In the context of systems-of-systems, regulatory constraints require the use of paper documents or tools.
7.5. Completeness of requirements
When a component, product, system or system-of-systems is defined, very often only the “functional” requirements are described. We saw earlier that there are many quality characteristics – other than functional characteristics – that need to be taken into account: resource use, security and performance come to mind, but each quality characteristic can influence user experience in a system-of-systems. It will therefore be necessary to ensure a minimum level of quality for each quality characteristic.
We therefore recommend including each quality characteristic in the risk analyses and providing at least one test case to ensure the level of completeness achieved. From there, it will be easy – with traceability from these non-functional requirements – to ensure a minimum level of quality for these requirements.
7.5.1. Management of TBDs and TBCs
It is almost certain that our requirements will be – partially – incomplete. It is recommended to note these incompletenesses by a flag [TBDnn] or [TBCnn], where nn is a sequence number. TBD is the acronym for To Be Defined and TBC is the acronym for To Be Confirmed. It is important to note the TBDs (and TBCs) and their number in a document in order to follow their resolution, to identify the persons responsible for the resolution of these concerns and their expected date of resolution. Periodic monitoring of this document will allow us to ensure that these TBDs and TBCs disappear before these requirements are met, thereby eliminating ambiguities and uncertainties.
7.5.2. Avoiding incompleteness
It is not possible to ensure with certainty that all requirements have been identified. However, some solutions exist to limit this risk:
– focus requirements elicitation on user tasks rather than system functionality;
– model the requirements and analyze these models;
– use state and transition diagrams and tables to identify missing states or transitions;
– identify symmetrical operations;
– identify incomplete requirements;
– analyze complex logics and ensure that each combination is processed;
– identify exceptional exceptions and combinations;
– identify functionalities or datasets kept for compatibility reasons, but which are no longer relevant.
7.6. Requirements and agility
Sequential development methods involve exhaustively defining all project requirements and then waiting for them to be fulfilled. The upstream workload is significant and any modification of requirements (e.g. in order to meet a change in business needs) sometimes leads to very heavy impact analysis.
Agile methods mitigate these constraints by grouping requirements into development iterations – sprints – comprising a smaller number of requirements, and by having stronger and more frequent interaction with customer representatives (e.g. sponsors, etc.) to detail the requirements, in User Stories, as they are carried out.
Requirements activities in Agile projects are basically the same as in sequential projects. Impact analyses and other activities related to the rewriting – and retesting – of requirements already carried out to adapt them to new requirements will take more time than on a sequential project where they do not have to exist.
It is therefore illusory to think that at the level of the whole project, the workload related to the requirements is less in an Agile project than in a sequential project. Similarly, it will be necessary, for any evolution of requirement or User Story, to apply to these evolutions the rules applicable to sequential requirements.
7.7. Requirements issues
In his book, Donald Firesmith (2014) identified other problematic elements related to the requirements:
– ambiguous requirements, often due to the use of ambiguous words, jargon or acronyms, misuse of words such as “should”, “shall”, “could”, etc., the association of numerical values without defining units of measurement, or the use of synonyms or close synonyms;
– obsolete requirements, for example when requirements are modified and are not officially approved, or are not stored in the requirements repository;
– missing requirements, for example, those on non-functional characteristics (performance, security, response time, robustness, usability, etc.), on data, interfaces or the absence of specification of behavior during non-operational phases (initialization, degraded mode, training or simulation, shutdown phase);
– incorrect requirements, for example when they do not specify triggers, preconditions or post-conditions, quantitative limits or mandatory behaviors (e.g. returning data, sending command or exception messages, etc.);
– unstable requirements that are frequently modified, with additions, modifications or deletion of requirements (frequent for Agile developments);
– improperly derived requirements, where requirements from one level simply carry forward requirements from a higher level, resulting in the design and execution of tests with no added value, or the allocation of tests to multiple components of the system-of-systems architecture;
– lack of verification methods, leading to inconsistencies and/or assumptions about when and how a requirement should be verified (e.g. through reviews or inspections instead of functional testing), which generates the use of ineffective and/or inefficient verification/validation methods.