GPM First
Chapter 5 of Requirements Management (978-1-4094-5137-2) by Mario Kossman

The RM Process

 

Chapter Summary

This chapter describes in detail a generic approach to RM that is both knowledge-driven and process-driven. It is intended for the development of complex or highly complex systems in a wide range of business contexts. This means that for simple systems, many of the proposed activities will be much less time-consuming and the needed tools to support the process and manage the created data may not have to be as sophisticated, since the data volumes for simple systems can be expected to be significantly lower.

Overview

The RM process as described in this chapter is a generic process that has to be instantiated – depending on the particular context and its complexity – at one or several layers of development, possibly within a complex extended enterprise. The process can be applied to a wide range of business and not-for-profit contexts alike. The purpose of the RM process is to establish all requirements of any relevant type for the particular context; and to keep them up-to-date over time.

The RM process consists of a number of workflows and their activities that are potentially concurrent and iterative. A process is an organized set of workflows and related activities which transform inputs into outputs. Process descriptions or models are essential to be able to reuse and continuously improve knowledge in general, and this applies also to the RM process itself.

A workflow consists of a number of related activities, which are integrated components of one or several workflows. Both workflows and their related activities can be conducted concurrently with a number of different stakeholders. This reflects reality insofar as the RM process is not usually a strictly sequential, one-off process with all needed participants just waiting for the requirements manager to turn up. In real life, people are not always available and many iterations and concurrent loops may be necessary throughout the relevant parts of the extended enterprise.

Also, the RM process does not suddenly stop at an early stage of the system development, but it continues, although usually at a much lower level, throughout the entire life cycle of a program or system. This is important because whenever a change of an existing system is needed, we have to be able to analyze the impacts of the change and systematically control the preparation and implementation of this change.

The output of the generic RM process is a new or updated set of validated requirements. The subject of these requirements, as well as their level of granularity and detail, will depend on the purpose and organization of the team or the individual for which the generic RM process is instantiated. The resulting requirements will specify aspects of a program, project or system in a given context.

Figure 5.1 provides a high-level overview of the generic RM process. The light bulb represents some new idea or significant change in a particular context, which leads you to develop new requirements – for instance, the intended launch of a new aircraft development program, or the extension of a secondary school building complex.

The two main parts of the RM process are the Requirements Development (RD) process and the Requirements Change Management (RCM) process. RD is the process of developing requirements. It can be subdivided into a number of potentially concurrent and iterative phases: Elicitation, Analysis and Negotiation, Documentation and Validation. The output of this process is a new set of validated requirements.

RCM is the process of managing changes to requirements over the entire life cycle of the program or system. The principal RCM activities are change control and change impact assessment. RCM requires traceability information to be recorded, that is, specific links among requirements, the sources of requirements, the system design, and planned actions and evidence of validation and verification activities. The output of this process is an updated set of validated requirements.

 
Figure 5.1 High-level overview of the generic RM process

graphics/fig5_1.jpg

Figure 5.2 provides a more detailed view of the generic RM process, showing the four steps of the RM process. This is not to say that these steps take place one after the other, strictly sequentially, and only once. Rather, as was mentioned above, the generic RM process usually takes place in an iterative and concurrent manner due to certain circumstances in a given context.

These circumstances may be that the involved relevant stakeholders and domain experts are not available as and when needed following the RM process. Also, required information such as higher level input requirements or the outcomes of a simulation or technology research study may not be available when needed, while following the process. As a result, specific parts of the RM process may have to be conducted with different participants at different moments in time, or they will have to be revisited or repeated, once the required information becomes available.

At the same time, there may not be time to wait at each stage until you can complete every workflow exhaustively. Rather, the person conducting the RM process may be forced to continue the process as far as possible, knowingly and intentionally allowing certain gaps in the needed information, until this information becomes available. However, care must be taken not to risk significant corrective rework.

For example, if a relevant stakeholder is not available for three weeks, you could already elicit and capture the needed information from all other identified relevant stakeholders and domain experts, and then go through the same workflows and activities with him when he is available again.

 
Figure 5.2 The four steps of the generic RM process

graphics/fig5_2.jpg

The RM process has to allow for the above circumstances, and needs to be sufficiently flexible and reliable to cope with them because this reflects reality.

In the following, all four steps will be explained in detail, discussing each of the corresponding workflows. For each workflow, all needed activities as well as their inputs and outputs will be described, stating the involvement of participants where applicable. Also, references will be made to suitable techniques and tools that can support these workflows and activities as appropriate. These techniques and tools are described in more detail in Chapter 6, and a mapping from the RM process workflows that will be described in this chapter to the recommended techniques and tools that can best support them is provided in Appendix G.

Requirements Development

The RD process is subdivided into three steps: ‘Step 1 – Explore the context’, ‘Step 2 – identify the needs’, and ‘Step 3 – Establish the requirements’. Although these three steps are potentially iterative and concurrent, they can only be finalized or closed one after the other in their sequential order. For example, you cannot consider that you have a complete set of requirements before you have finished elaborating all underlying needs.

As you go through the steps of the RD process, it is of utmost importance to record relevant traceability information and to keep this information under an appropriate form of configuration management.

For example, if you develop a requirement based on a higher level of input requirements, you should immediately establish the link between both requirements, or if you are not working in a requirements database yet you should at least record the source reference. It only takes a moment to establish this traceability while you still work on the requirement, because then you exactly know where the source or related information is located. It takes much longer and is prone to errors if someone else or even you have to establish this traceability later.

It is almost certain that you will need the relevant traceability information later on, because it tremendously facilitates the analysis and validation activities, and it is also the necessary basis for the RCM process once the requirements have been established for the first time. This is so because the recorded traceability information enables change impact analyses.

Furthermore, you should aim to complete each step with the appropriate involvement of all identified relevant stakeholders and domain experts before you start the next step in order to keep corrective rework to a minimum. On the other hand, if a particular relevant stakeholder is on a holiday for two weeks, you should not stop all activities until he returns. The RM process described in this section explicitly allows for the flexibility that is required in such cases.

A summary checklist of the entire RD process is provided in Appendix B.

Step 1 – Explore the Context

The first step consists of the following three workflows: (1) ‘identify and review relevant documentation’, (2) ‘identify and map stakeholders’ and (3) ‘Elicit and capture relevant context information’. The latter workflow needs direct involvement of relevant stakeholders and domain experts, as marked in Figure 5.3 (a symbol of a person is used and the workflow is written in bold font).

 
Figure 5.3 Explore the context

graphics/fig5_3.jpg

RD Workflow 1.1 – Identify and Review Relevant Documentation

The first workflow is about finding out what existing documentation and similar sources are relevant for the current context and available and reviewing them in order to have a good overview and understanding of this specific context – even before talking in detail to any stakeholders.

This is important since you need stakeholder involvement in the RM process, and you do not want to put them off by wasting their time. Asking them obvious questions that you could have easily answered yourself by reading the corresponding procedural document, which may be available on the company’s intranet, may seriously annoy them. You should make sure that you use their precious time as effectively as possible, adding the greatest value to the RM process.

Table 5.1 displays the activities of this workflow, as well as their inputs and outputs. There is no intended participant involvement, other than asking the people around you for the right places to find the documentation you are looking for. Hence, no participants are marked in the table.

 
Table 5.1 Identify and review relevant documentation

graphics/tab5_1.jpg

The relevant documentation you need to identify and review, if available, is likely to consist of procedural documents, specific regulation and legislation, standards, studies and publications, lessons learned and identified good practice, requirements from previous projects or programs, as well as your input requirements that may have already been established by your current stakeholders.

All such relevant documentation should be referenced by you, and the main information you deem relevant should be summarized, or in some cases the document stored for later use. For example, you could save a previous requirements document from a similar project in a dedicated working folder for your current project.

Remember that the aim here is not to spend a lot of time going through all possible types of documents that may have something to do with your current project in detail. Rather you should try to see this workflow as an opportunity to save time for you and the participants in the RM process, by not ‘re-inventing the wheel’, where there is already something useful documented.

Maybe there are some informal customer expectations available from customer focus groups or in service support reports; or you are participating in a bidding process based on a set of input requirements. Any such information is of course very useful to review before we actually take our stakeholders’ time.

Just a few words on input requirements that your stakeholders may already have established for you, when you start developing your own requirements at your level. In principle, input requirements can come via two routes: (1) relevant stakeholders can propose the allocation of specific requirements to you (‘push’ principle) and (2) you can contact identified relevant stakeholders and proactively ‘trawl’ for requirements (‘pull’ principle).

In the first case, you should review the requirements proposed for allocation and either agree with the proposed allocation, or where necessary negotiate with the relevant stakeholder to reach an agreement. This may be necessary if you do not understand a requirement, if you think it is not relevant for you, that is, if you suspect a wrong allocation, or if a requirement is not of good quality and needs reformulating. Early negotiation of input requirements leads to a better understanding of these, and an early identification of mis-allocations, problems and risks, as well as constraints from other teams.

In the second case, you may have to proactively contact specific relevant stakeholders and ask them for your input requirements – or even elicit the input requirements with them, if they have not been able to formulate and allocate any input requirements to you yet, for whatever reason. In this case, just follow the relevant parts of this RM process. And remember that it is in your best interests to have good input requirements, even if it may not be your direct responsibility to produce them. It is time well spent and your help will certainly be appreciated by your stakeholder.

When reusing existing requirements from previous projects or programs, you should take care to analyze every single requirement (to be reused) for relevance, necessity, need for adaptation to the new context, and its source. Also, you need to decide how the reused requirement can be updated if the original requirement (in a different context) is changed, or if this does not matter.

This workflow can be effectively enhanced by brainstorming and mind mapping techniques, which can be supported by mind mapping and spreadsheet tools.

RD Workflow 1.2 – Identify and Map Stakeholders

This workflow is about finding out and recording with whom we need to talk so as to be able to develop our requirements. Stakeholders are individuals, groups or organizations who will be affected in some way by the development, sale, delivery, support, operational use or disposal of a system to be developed, and therefore have a direct or indirect influence on the system requirements.

They include end-users of the system, clients who are paying for the system, managers and others involved in the organizational processes influenced by the system, engineers responsible for the system development and maintenance, customers of the organization who will use the system to provide some services, external bodies such as regulators or certification authorities, and so on.

Those stakeholders out of the many possible stakeholders that have been declared to be the official stakeholders within a given project or program are the relevant stakeholders. They usually have to validate the requirements and sign them off.

Domain experts, on the other hand, may be stakeholders, or unconcerned who might not even be part of the project or program in question, but who have some relevant expertise or experience in the field at hand. They are often overlooked and not considered in order to save time, or because they are simply forgotten. Yet, in many cases, they actually have significant inputs to contribute. Table 5.2 displays the activities of this workflow, indicating their inputs and outputs.

 
Table 5.2 Identify and map stakeholders

graphics/tab5_2.jpg

Based on the previously recorded, relevant key information, and perhaps recommendations by people you talk to, this workflow can be undertaken in isolation, without any formal participants.

This said, in practice the stakeholder map is usually initiated alone, but then, during discussions with some of the identified stakeholders, you will often identify additional stakeholders that you may wish to add to your stakeholder map. This tends to be the case especially for domain experts, since they will not necessarily be stated in any relevant program documentation because they may not be part of the program in question.

The resulting stakeholder map may have to be updated later on in the process when you come across any additional recommendations of relevant stakeholders or domain experts by the people you are meeting, and occasionally when identified stakeholders leave their position and are replaced.

As with the previous workflow, this workflow can be effectively enhanced by brainstorming and mind mapping techniques, which are supported by mind mapping and spreadsheet tools.

RD Workflow 1.3 – Elicit and Capture Relevant Context Information

This workflow is about meeting relevant people, who either will have to validate or sign off your requirements later on (relevant stakeholders), or can contribute to your work of eliciting and capturing relevant domain knowledge or information (domain experts).

This workflow is very important because it helps you achieve the necessary foundation for a complete and consistent set of requirements in the end, and also to obtain the buy-in of the people who have to sign off your requirements later on by having them participate in the process of developing the requirements and offering them intermediate opportunities to have an influence on this process. Table 5.3 displays the activities of this workflow, indicating the involvement of the participants, as well as inputs and outputs of all activities.

 
Table 5.3 Elicit and capture relevant context information

graphics/tab5_3.jpg

Short meetings of one to two hours should be scheduled with all identified relevant stakeholders and domain experts individually. Try to schedule these meetings in the light of the participants’ availability and convenience, taking into consideration any local customs and preferences.

Some may wish to have their meeting jointly with other stakeholders you wish to invite, or in fact people you had not previously identified. If specifically requested, this is fine and should be accommodated for, but in general it is very helpful to have individual meetings so that undivided attention can be given to each participant.

These meetings must be well prepared beforehand by using and visualizing the context information that could be obtained previously, for example, from the existing context documentation.

During the meetings, this initially prepared and any subsequently captured context information can be shown to other participants, who can then comment and confirm it or contradict it, and help you improve the structure of the information. You should keep a record of who contributed which part of the information, and who disagreed with what others had said, and for what reasons.

As you go about eliciting the domain knowledge on which you will base your requirements later in the process, you should make use of any relevant or helpful types of modeling, simulation, and analyses. Also, it is often at this stage that you may become aware of additional people you might want to speak to. This may be the case when already identified stakeholders recommend during your discussions with them that you should ask specific other domain experts regarding certain relevant aspects.

This workflow can be effectively enhanced by techniques such as brainstorming, mind mapping, diagramming user interactions, functional analysis, safety analysis, why-why-analysis, scenario analysis, use case analysis, and walkthrough. It is recommended that these techniques be supported by mind mapping, spreadsheet and modeling tools.

Step 2 – Identify the needs

The second step consists of the following three workflows: (1) ‘Derive needs’, (2) ‘Analyze and update needs’ and (3) ‘Validate needs’. The last workflow requires direct involvement of relevant stakeholders and domain experts, as marked in Figure 5.4.

 
Figure 5.4 Identify the needs

graphics/fig5_4.jpg

All workflows of Step 2 can be greatly enhanced by using mind mapping techniques and a dedicated mind mapping tool.

RD Workflow 2.1 – Derive needs

This workflow is about translating all the information and knowledge you have captured regarding your problem context into one coherent set of high-level needs. If you have explored the problem context using a mind map, you will have captured and structured different sorts of concerns, business process aspects, actors, scenarios, functions, use cases, and other relevant models that have some impact on your problem space. This structured yet ‘messy’ information is of different levels of granularity and detail. Therefore it has to be used to formulate a list of high-level needs that summarize the entire ‘problem space’, for which you ultimately want to find one or several alternative solutions that satisfy your needs.

This workflow is important because it makes explicit the underlying external and internal needs that are to be satisfied. Table 5.4 displays the activities of this workflow, including their inputs and outputs.

 
Table 5.4 Derive needs

graphics/tab5_4.jpg

Establishing traceability from the needs into the domain knowledge from which you have derived them is essential, because this greatly facilitates the analysis and validation of your needs in the short term, and enables the continued use and efficient reuse of the domain knowledge in the longer term.

Each such need has one or several relevant stakeholders and possibly domain experts associated with it, namely the ones who originally gave you the captured problem space information, based on which you have derived the need.

Needs can address one or several constraints on a new system to be developed, or the project or program that is conducted to develop the new system, or any capabilities or characteristics of the new system in general. However, needs are not detailed requirements yet but rather high-level statements. This means that they are likely to be very vague, not easily measurable, and they are usually open regarding any possible solutions.

Needs can be considered to be the formalized summary of the ‘problem space’ before entering into the ‘solution space’ by developing the goals and later requirements. This solution space (defined by the goals and requirements) specifies the ‘allowable space’ in which alternative solutions can be identified that will satisfy the derived needs.

It is good practice to go through the entire context information that was previously captured, create one need per major topic, and link from that need to the parts of the context knowledge from which the need was derived. You have completed the workflow when (1) you have covered the entire context knowledge that was captured, (2) you are happy with the formulation of each individual need and (3) each need is linked to where it originated from in the problem space.

Therefore it can be said that one key aspect of this workflow is the establishment of traceability within the problem space that can later be used for analysis and validation purposes at the need, goal and requirement levels.

RD Workflow 2.2 – Analyze and Update Needs

This workflow is about making sure that the established list of high-level needs are of good quality in terms of their correctness, completeness and consistency. All should be traceable, there should be no overlapping or partly duplicated needs, and any conflicts have to be identified and resolved.

This is very important because the list of needs will be the basis for the development of goal hierarchies and later requirements that will specify the solution space. Also, both the analysis and any necessary corrections of the derived needs will take considerably less effort and time, and therefore cost less if it is done at this early stage, as opposed to identifying problems later when the goals or even requirements have already been formulated. Table 5.5 displays the activities of this workflow, including their inputs and outputs.

 
Table 5.5 Analyze and update needs

graphics/tab5_5.jpg

First, each of the needs has to be reviewed individually, whether it is well expressed, that is, clear and understandable, and linked to its origin in the captured context knowledge. Then, the entire set of needs has to be reviewed in its entirety to ensure that the list is complete, of a comparable level of granularity and detail, and free of conflicts. Any identified conflicts will be recorded and duplications removed from the set of needs.

RD Workflow 2.3 – Validate Needs

This workflow is about having your relevant stakeholders validate the first intermediate outcome of your requirements development efforts. By validating the list of needs, they will give their agreement that you have established a complete and consistent high-level summary of the problems to be solved.

This is important because it gives you the confidence that you are on the right track, even if there may be some corrections to do at this stage. Also, the workflow contributes to the buy-in of the relevant stakeholders, because they are given the opportunity to validate this intermediate outcome of your requirements work. Table 5.6 displays the activities of this workflow including their inputs and outputs, as well as the involvement of other participants.

 
Table 5.6 Validate needs

graphics/tab5_6.jpg

Once the list of needs has been analyzed and updated as necessary, the relevant stakeholders are invited to individual sessions where you should talk them through their needs in detail in order to get their feedback. They should also be given the opportunity to look at the other needs of which they are not themselves the relevant stakeholders. This will help increase the confidence that the set of needs is in fact consistent.

Alternatively, this validation can also be driven via video or telephone conference, or even via email. For globally dispersed teams, this may be the most economical way in the light of limited travel budgets. However, you have to be confident that the relevant stakeholders fully understand what you have done and agree with your outcomes, before they validate the needs you have derived.

Step 3 – Establish the Requirements

The third step consists of the following six workflows: (1) ‘Create goal hierarchies’, (2) ‘Analyze and update goal hierarchies’, (3) ‘Validate goal hierarchies’, (4) ‘Write requirements’, (5) ‘Analyze and update requirements’ and (6) ‘Validate requirements’. The third and sixth workflows need direct involvement of relevant stakeholders and domain experts, as marked in Figure 5.5.

 
Figure 5.5 Establish the requirements

graphics/fig5_5.jpg

RD Workflow 3.1 – Create Goal Hierarchies

The first workflow of Step 3 is about determining for each validated need how this need can be best satisfied. By building goal hierarchies you can sometimes prepare quite complex graphs of goals and sub-goals that are of increasing level of detail, until you arrive at root goals. The latter are quite detailed goals that you think should not be further broken down into sub-goals. The assumption is that if all root goals of one need are met, then this need can be considered as satisfied.

This workflow is important because it leads from the list of identified high-level needs to a much more detailed level of concrete root goals that can subsequently be used as the basis to write corresponding requirements. Table 5.7 displays the activities of this workflow, as well as their inputs and outputs.

 
Table 5.7 Create goal hierarchies

graphics/tab5_7.jpg

The creation of goal hierarchies before even starting to write requirements is quite an important concept, because it takes much less time to create, analyze and update goals that are not very formal in nature, as opposed to much more detailed requirements.

Furthermore, it is easier at this stage to identify and resolve conflicts, remove duplications and increase consistency. Figure 5.6 shows a generic goal hierarchy that was created for an identified need.

For example, if one of the validated needs was the following:

The Aircraft needs to be perceived as setting a new standard in passenger comfort during all operational flight phases.

 

 
Figure 5.6 A generic goal hierarchy

graphics/fig5_6.jpg

Then, some of the first level goals in the associated goal hierarchy for this need could be:

  • Reduce cabin noise levels.

  • Reduce fuel particles in the cabin air.

  • Increase legroom.

  • Make available flexible lighting.

  • Use surface materials that promote feelings of well-being when touched.

  • Provide sufficient seat width for obese passengers.

  • Provide sufficient length of seat belt for obese passengers.

  • Enable complete retraction of arm rests into the seat.

 

These goals would have to be further broken down, if needed with the help of domain experts and using modeling where helpful, until you arrive at a very detailed and quantifiable level that can then be used as the basis for writing your requirements later on in the RM process.

For instance, regarding the first goal ‘Reduce cabin noise levels’ it would have to be explored and decided what noise levels are actually perceived to be acceptable per operational phase, and in the light of competitors’ products, so that the goal contributes to the achievement of the underlying need.

Even in cases where it seems hard to quantify, there is always a way around it. For instance, focus group meetings or questionnaires can be used with sample groups of passengers in order to measure certain perceptions. Also, a number of other analyses can be used very effectively to identify during which operational phases, in which use cases or scenarios certain goals are valid, as opposed to being valid all the time. Often, domain experts would make a decision based on their own professional judgement, and this may be as good a concrete and measurable value as you will get.

The completeness and consistency of goals and (later in the process) requirements is practically impossible to achieve for complex systems. The important thing is to get to a sufficient level of completeness and consistency, based on multiple analyses from many viewpoints and in the light of the experience of all participants in the process.

This workflow can be effectively enhanced by mind mapping techniques, plus diagramming user interactions, functional analysis, safety analyses, why-why analysis, scenario analysis, use case analysis and walkthrough techniques. Also traceability has to be established between the goal hierarchies that were created and their multiple sources such as models or studies. These techniques are best supported by dedicated mind mapping, modeling and spreadsheet tools.

RD Workflow 3.2 – Analyze and Update Goal Hierarchies

This workflow is about making sure that the established goal hierarchies are of good quality in terms of their correctness, completeness and consistency. Any duplications of goals have to be eliminated, and conflicts identified and resolved.

This is very important because the requirements will be based on the identified root goals within each goal hierarchy. Also, both analysis and any necessary corrections of the established goals will take considerably less effort and time and therefore cost less at this stage, as opposed to identifying problems later, when the requirements have already been formulated. Table 5.8 displays the activities of this workflow, as well as their inputs and outputs.

 
Table 5.8 Analyze and update goal hierarchies

graphics/tab5_8.jpg

Each of the goals and sub-goals in all goal hierarchies for all validated needs has to be analyzed or reviewed individually to see whether it is well expressed, that is, clear and understandable. Then all goal hierarchies have to be analyzed or reviewed one by one, to check that they are correct, complete and consistent. In particular, the question has to be asked whether all identified root goals together, if achieved, actually satisfy the underlying need. Finally, it has to be made sure that all needs have been covered in that way, and that duplications and conflicts between goals from different goal hierarchies have been identified and addressed.

This workflow can be effectively enhanced by mind mapping techniques that are supported by mind mapping and spreadsheet tools.

RD Workflow 3.3 – Validate Goal Hierarchies

This workflow is about having your relevant stakeholders validate the second key intermediate outcome of your requirements development efforts. By validating the goal hierarchies for the identified needs that they have already validated, they will give their agreement to the way you propose that each need could be satisfied, and the green light that the requirements can now be formulated based on the identified root goals. Table 5.9 displays the activities of this workflow, including their inputs and outputs, as well as the involvement of participants.

 
Table 5.9 Validate goal hierarchies

graphics/tab5_9.jpg

This is important because it gives you the confidence that you are on the right track, even if there may be some corrections to do at this stage. In addition to that, this workflow strongly contributes to the buy-in of the relevant stakeholders, because they are given the opportunity to validate the outcome of your requirements work at another key stage on the way towards completing the requirements. This will also greatly facilitate the validation of the requirements later on.

Once all goal hierarchies have been analyzed and updated as needed, the relevant stakeholders are invited to individual sessions, where you should talk them through the developed goal hierarchies in detail in order to get their feedback. They should also be given the opportunity to look at the other goal hierarchies of which they are not themselves the relevant stakeholders. This will help increase the confidence that the set of goal hierarchies is in fact consistent, or at least identify any issues that had been overlooked despite the previous analyses or reviews.

Alternatively, this validation can also be driven via video or telephone conference, or even via email; as for global teams, this may be the most economical way in the light of limited travel budgets. However, as mentioned before, you have to be confident that the relevant stakeholders fully understand what you have done and agree with your outcomes, before they validate the goals that you have developed with their help.

Just as the previous workflow, this workflow can be effectively enhanced by mind mapping techniques that are supported by mind mapping and spreadsheet tools.

RD Workflow 3.4 – Write Requirements

This workflow is about actually writing your requirements and completing any additional information in the form of attributes and links; based on the work previously performed, or in direct response to input requirements that are allocated to you directly by a stakeholder or customer. Also, in some cases you may be able to reuse existing requirements from similar contexts, in which case you still need to make sure that these requirements are well written and contain all the information you need for your specific context.

This is important because the resulting set of requirements, be they newly written or reused, will become the basis for your work, or for your contract with a supplier or customer. Whatever it is that will be developed based on these requirements will be wrong if the requirements are wrong. Therefore this workflow is crucial. Table 5.10 displays the activities of this workflow, including their inputs and outputs.

In larger organizations and/or for highly complex systems, requirements would usually be managed in a dedicated requirements database that is supported by a suitable software tool and reflects a common data-model. Such a requirements database enables the participants in the RM process to manage all requirements individually as objects, including any related information in terms of attributes and possibly links to related objects that are also stored within the requirements database.

The following criteria will both help writing good requirements in the first place, and facilitate the analysis of requirements prior to their validation. The criteria are divided into two levels, that is, the individual requirements level and the set of requirements level.

The former level is about producing high-quality individual requirements, whereas the latter level is about complete and consistent sets of requirements, for example, in the form of high-quality requirements documents. The criteria for both levels are summarized in Appendices E and F respectively.

 
Table 5.10 Write requirements

graphics/tab5_10.jpg

Check that each individual requirement is:

  • necessary

  • attainable

  • clear and unambiguous

  • verifiable

  • not premature design

  • complete

 

Each requirement has to be necessary, that is, there has to be an identified stakeholder with an underlying, justified need. A requirement will have a certain priority, which can change over time. But even low priority requirements have to be necessary in the sense that they have to be stated. Think about what would be the worst that could happen if you left the requirement out.

Each requirement has to be realistic and achievable in terms of the laws of physics and domain experience. Technical feasibility as well as budget and schedule constraints should be considered, but they should not prevent you from stating challenging requirements. Often, in the beginning of a new development program for a highly complex system, the needed technologies to satisfy some of the requirements will not be available yet. If something is required it has to be stated as a requirement, even if we cannot satisfy it yet. At least this helps to make that very fact explicit.

Requirements, in particular the requirement statements, have to be clear and unambiguous in order to avoid misunderstandings. They shall be kept as simple as possible, show relevant punctuation, consist of only one sentence per requirement statement (and only one requirement per sentence), avoid noun clusters and use tabular layout where appropriate.

For each requirement you should think about how the design, and later the product should be verified, so that you can decide whether you consider that the requirement has been satisfied. Therefore each requirement has to be formulated in a way that it is verifiable; and you should have proposed means of design and product verification in the corresponding attributes of the requirement.

The requirement should never constrain the solution space more than necessary at its level. Solutions should only be imposed by means of requirements if this is really a necessary constraint, for example if a stakeholder explicitly needs a detailed specific solution.

Each requirement has to contain all needed statement components, mandatory attribute information and links or references in line with the established requirements data-model. You may wish to write individual requirement statements split into their components following the structure shown in Table 5.11, and fill in every component that is relevant for a given requirement.

 
Table 5.11 Parsing requirement statements into components (adapted from Halligan, 2010) [26]

Component

Example

Actor

Any single fuel pump

Condition(s) for action

on ground

Action

shall be replaceable

Constraint(s) of action

by one ‘level 2’ maintainer

Object of action

-

Refinement / source of object

without having to drain the tank

Refinement / destination of action

within 20 minutes

Other

-

Table 5.12 shows a number of example requirement statements from the aerospace context related to an aircraft, a program, a training module, an aircraft subsystem, and an aircraft structure component.

 
Table 5.12 Example requirement statements

The MZV aircraft, with the extended range option package, shall be able to carry xx passengers over a distance of YYYYY km.

The MZV program shall define NRC and RC targets for all MZV aircraft variants and standard option packages by Maturity Gate XY.

The MZV training for flight crews of the MZV aircraft (all variants and standard option packages) shall take the following number of days:

  • 5 days if not qualified for MZV company aircraft,

  • 2 days if qualified for MZV aircraft family,

  • 1 day if qualified for MZV aircraft.

 

The Air Conditioning System shall regulate hot air temperature discharge by a closed control loop based on bypass air modulation.

The Air Conditioning System shall achieve the mix of hot and cold air by means of a valve.

The Air Conditioning System shall make sure that the valve is in the full closed position in case of failure.

The Load Management System shall compute the optimum load positioning taking into account the following criteria:

  • Characteristics of load items,

  • Air delivery sequence,

  • Any load restrictions, when operated from the manual work station.

 

The Vertical Tail Plane, during landing and take-off on a 90-ft wide runway, shall sustain a crosswind component of:

  • 35 kts for a braking coefficient > 0.4

  • 15 kts for a braking coefficient 0.25 < × < 0.4

 

As a general rule, no requirement should be repeated if it has already been expressed somewhere else in the requirements database, in order to avoid unnecessary costs without adding value. You should refer to the source of such a requirement (using a ‘source’ attribute) if the requirement in question is not in a requirements database, or directly link to it if it is. Only in some special cases it may be necessary to repeat a requirement, for example, where complete sets of requirements have to be passed to suppliers (in the form of a document) that do not have access to the original requirement in question. However, never should a requirement be repeated in the same requirements document.

If identical requirements are used in a number of requirements databases and linking among them is not enabled, these requirements can be mirrored, that is, copied into other databases to allow for local traceability within these other requirements databases. This is often the case when requirements are developed outside the requirements database using specific methodologies, and subsequently managed within the database, or within the extended enterprise between a customer company and a supplier company.

For example, the customer company may manage a requirements document in their requirements database for a given project, and these requirements will be copied into the supplier’s requirements database; so that they can link from their own more detailed requirements and other related information to the copy of the customer requirements.

Table 5.13 provides a selection of useful requirement attributes. In order to ensure consistency and reusability of requirements and their associated information, a common data model would normally be implemented in the requirements database.

For instance, some attributes may offer a selection of pre-defined values to pick from: for example, the requirement status may offer the values of ‘proposed’, ‘analyzed’ and ‘deleted’. This is necessary in order to analyze the status of the requirements work within the entire requirements database.

 
Table 5.13 A selection of useful requirement attributes

Attribute

Comment

Unique id

Each requirement must have a unique identifier.

Created by

The author of the requirement.

Object type

In some requirements database systems the distinction is made between requirements and other objects that are managed.

Requirement statement

The requirement statement is the core of the textual requirement. it formulates what is actually required.

Rationale

The reason or justification for a requirement. Often this information contains the experience and know-how of the author of the requirement.

Owner

The owner of a requirement is not the stakeholder of the requirement, but the person in charge of its development and management. For example, the owner would drive the validation of his requirement by the designated relevant stakeholder.

Stakeholder

The relevant stakeholder(s) should be stated in this attribute, that is, the designated stakeholder(s).

Requirement type

This attribute would let you select from a set of established categories of requirements, for example, ‘functional’ versus ‘non-functional’ requirements with a number of subcategories; or ‘product’ versus ‘enabling product’ versus ‘process’ requirements.

Scenario

Reference number of the scenario during which the requirement is necessary.

Use case

Reference number of the use cases during which the requirement is necessary.

Function

Reference number of applicable functions from the identified functional tree (functional requirements only).

Fit criterion

Criterion that needs to be given in order to consider the requirement as being satisfied by the design and/or the system to be developed.

Version

This attribute contains version information such as which requirement component was changed, when, and due to what decision.

Priority

for example: ‘key’, ‘secondary’, and ‘unimportant’; ‘order winners’, ‘qualifiers’, and ‘less important’; or ‘essential’, ‘important’, and ‘nice to have’.

Additional information

Here, any additional information of relevance can be stored and managed. This should facilitate the understanding of the requirement by any reader.

Assumption

Any major assumptions on which the requirement is based should be stated here. by linking this kind of information to project or program risks, risk management can be greatly enhanced. If such an assumption does not hold true, all concerned requirements can be immediately identified via the established traceability, and analyzed for any impacts.

Source

If a requirement is directly based on a source document that cannot be linked to from the requirements database, the source reference should be given in this attribute.

Requirement status

This attribute describes the status of the requirement, for example, ‘proposed’, ‘analyzed’, ‘deleted’.

Means of requirements validation

The intended means of validation of the requirement can be stated in this attribute, for example, ‘review’, ‘simulation’, ‘study’, ‘demonstration’.

Requirements validation status

For instance ‘to be validated’, ‘validated’, ‘not validated’ (that is, validation failed in current state).

Requirements approval status

In some cases, some higher authority in the company needs to approve each requirement. pre-defined values of this attribute may be ‘to be approved’, ‘approved’, ‘not approved’ (that is, approval not given in current state).

Means of design verification

The intended means of design verification against the requirement can be stated in this attribute, for example, ‘review’, ‘simulation’, ‘study’, ‘demonstration’.

Design verification status

For instance ‘to be verified’, ‘verified’, ‘not verified’ (that is, design verification failed in current state).

Means of product verification

The intended means of product verification against the requirement can be stated in this attribute, for example, ‘review’, ‘demonstration’, ‘test’.

Product verification status

For instance ‘to be verified’, ‘verified’, ‘not verified’ (that is, product verification failed in current state).

Allocation

The information regarding the proposed allocation of the requirement to another team or part of system architecture can be managed in this attribute.

In addition to these attributes, each requirement should be linked to its source if the source or reference information to the source is kept in the same requirements database. If not, the source attribute should be populated with the reference or a hyperlink to the source information.

A scenario describes an operational or other life cycle context, during which a system is required to show a specific behavior or have a specific characteristic or quality, whereas a use case describes one or several related and purposeful interactions between a human person or an external system (or element thereof) with the system of interest.

Exploring the different relevant scenarios and use cases during the development of a new system, usually as part of the requirements development process, helps to limit appropriately the validity of individual requirements, and contributes to ensuring the overall completeness of the requirements.

For example, a coast-guard surveillance aircraft system will have to operate in a number of operational scenarios, in each of which different things may be required. Similarly, the support personnel on ground will have certain use cases of how specific roles have to interact with the system, for example to refuel the aircraft or maintain it. It is important to know what the system is required to do in all relevant scenarios and use cases.

By applying both scenario and use case considerations to the development of requirements, significant benefits can be achieved: (1) certain requirements are cheaper to implement in the design of the system if they are only valid in particular scenarios or use cases, (2) the resulting set of requirements is more likely to be complete and (3) the identified scenarios and use cases will be helpful to plan and conduct the related V&V activities.

Traceability is key to being able to exploit the information that is generated and managed during the RM process. Traceability means the ability to trace related information objects such as sources of requirements, requirements and V&V data, for example by means of links or traceability matrices, in order to enable different types of analyses and the controlled reuse of these information objects.

Forward requirements traceability means the traceability from sources of requirements towards the resulting requirements. Backwards requirements traceability means the traceability from the requirements back to their sources.

Traceability can be further enriched by introducing different types of links and also relationships between several links.

In many cases, you will need a self-contained requirements document that is easily readable and understandable and that covers all necessary context information. The contained requirements should be structured in such a way within the requirements document that it facilitates a supplier’s understanding of what is required. Table 5.14 offers a possible structure of a requirements document.

 
Table 5.14 A requirements document template

Chapter/sub-chapter

Comments

1. Context description

This first part of the document gives an overall introduction and addresses the intended context of the system to be developed at high-level.

1.1 Purpose of the system

High-level description of the overall purpose of the system to be developed.

1.2 Served system

This section of the document should contain a context diagram that identifies the boundaries of the served system, its components, actors, data flows, and so on.

1.3 Stakeholders

Including relevant stakeholder, domain experts, users, customers, clients, and so on.

1.4 Cultural and political aspects

Any particular aspects that have to be taken into account in general.

1.5 Strategy aspects

For example, a general preference to use Cots versus bespoke solution components.

1.6 Assumptions

High-level assumptions that are likely to have a major influence on the system development project/program, the system development process, or the system itself.

1.7 Open issues

Any significant open issues that have to be taken into account.

1.8 Glossary and definitions

The project/program terminology needs to be defined here to avoid misunderstandings.

2. Project/program constraints

This second part of the document addresses overall constraints on the project/program in terms of process requirements, that is, how the system has to be developed.

2.1 P&PM process requirements

How the project/program has to be managed.

2.2 SE process requirements

How the system has to be developed.

2.3 Procurement process requirements

How any procurement activities have to be conducted, for example regarding sub-components.

3. System requirements

This third part of the document addresses the requirements that the system itself has to satisfy, that is, what the system has to be able to deliver.

3.1 Scope of the system

Detailed definition of what exactly is in the scope of the system to be developed.

3.2 Operational scenarios

What are the operational scenarios in which the system is intended to be used?

3.3 Use cases

What are the use cases in which the system is intended to be used?

3.4 Functional tree

Representation of the identified functional tree, containing all functions that the system will have to fulfil in order to be used in its intended context.

3.5 Functional requirements

Derived from the functional tree and possibly allocations of functions to already known parts of the system’s architecture.

3.6 Performance requirements

Specific performance aspects are addressed here, for example range or speed of the system.

3.7 Human machine interface (HMI) requirements

Human machine interfaces, formerly known as man machine interfaces (MMI), address the human user interfaces within systems, for example graphical user interfaces (GUIs).

3.8 Usability requirements

Specifying how the system has to be usable depending on the identified scenarios and use cases, and external circumstances.

3.9 inter-operability requirements

Specifying how the system needs to be able to interact with other systems.

3.10 Interface requirements

Specific technical interface requirements in terms of geometrical, electric, mechanical, pneumatic, hydraulic, service, data or information, and process interfaces.

3.11 Cost requirements

Covering both non-recurring costs (for example, development related) and recurring costs (for example, production related) throughout the entire life cycle of the system.

3.12 Weight requirements

Addressing all weight requirements in all identified operational scenarios, including corresponding allowable weight limits, for example maximum take-off weight of an aircraft.

3.13 Maintainability requirements

Covering all relevant maintainability aspects of the system to be developed.

3.14 Data integrity requirements

In terms of data loss, data corruption and data theft.

3.15 Security requirements

All relevant security aspects the system has to incorporate are specified in this section.

3.16 Documentation requirements

Specifying how the system has to be documented, and how documentation has to be maintained throughout its life cycle.

3.17 Legal requirements

Any legal issues are addressed here as needed, for example safety or environmental protection related requirements such as the ban of certain materials or maximum noise levels.

A requirements document, that is, a set of requirements shall be:

  • complete

  • consistent

  • non-redundant

  • structured

  • validated

  • approved

 

All necessary requirements from all identified relevant stakeholders have to be present, and should have been analyzed. All defined categories of requirements should have been considered, and all identified scenarios, functions and use cases should have been taken into account.

No two requirements should be in direct conflict. Any such conflicts should have been identified, addressed and resolved by means of negotiation with the concerned relevant stakeholders. If this is not possible, the conflict has to be flagged up and a decision will have to be made at the relevant escalation level.

Each requirement should be expressed only once in the document or set of requirements. There should be no duplications, either full or partial duplications. Full duplications should lead to one of the duplicated requirements being deleted. Partial duplications are harder to spot and can often be resolved by combining concerned requirements.

There should be a clear structure within the requirements document. This structure can be based on one or several of the following criteria: system architecture, requirements type, work breakdown structure, project or program schedule, operational functions, system features, as well as identified scenarios and/or use cases. A good document structure is helpful because it facilitates the document’s readability and analysis for completeness and consistency.

All requirements contained in the document have to be validated by the identified, relevant stakeholders. The owner or author of the document would have driven this validation process, and demonstrated to all relevant stakeholders that both at the individual requirements level and at the set of requirements level all quality criteria have been met. The formal validation confirms that the relevant stakeholders agree that the requirements are correct, consistent and complete.

In many cases, a designated manager or commercial representative will have to formally approve a requirements document. In such cases, the approver will have made sure that all quality criteria are met for the entire document before signing it off. Documents can also be approved in cases where not all requirements have been validated yet, for example to release a draft requirements document to a supplier or risk sharing partner. However, the contained requirements would be marked accordingly, that is, the validation status attribute would indicate that specific requirements have not been validated yet.

This workflow can be effectively enhanced by mind mapping, traceability establishment and analysis, as well as requirements quality analysis techniques. These should be supported by dedicated mind mapping or spreadsheet, object management, and requirements quality analysis tools.

RD Workflow 3.5 – Analyze and Update Requirements

This workflow is about analyzing and, if needed, updating the requirements that were newly written or reused, and structured into a comprehensive set during the previous workflow, in the light of the validated needs and their goal hierarchies.

The same quality criteria that were described previously and had to be applied when writing or reusing, and structuring the requirements are used again to ensure that the resulting requirements are of high quality.

This is important because it is easy to get carried away by the details of the requirements as you write them or compile them. Although the quality criteria should have already been observed when preparing the requirements, it is always good to check your work after you have done it.

It is also necessary to prepare the validation of the requirements by the relevant stakeholders. Being able to demonstrate to your relevant stakeholders that you have properly analyzed the requirements will facilitate the validation because it increases their confidence that the requirements are in fact of good quality. Table 5.15 displays the activities of this workflow, including their inputs and outputs, as well as the involvement of other participants.

The applicable quality criteria were described in the previous workflow, both at the individual requirement level and the set of requirements level. Appendices D and E provide a summary of these criteria.

When correcting any identified quality issues with the requirements, it is essential to resolve any conflicts with the concerned relevant stakeholders prior to entering the validation workflow. The last thing you want is having a large validation meeting with numerous stakeholders fighting about requirement conflicts they have only discovered during the meeting.

This workflow can be effectively enhanced by traceability analysis, requirements quality analysis and mind mapping techniques. These should be supported by dedicated object management, requirements quality analysis, and mind mapping or spreadsheet tools.

 
Table 5.15 Analyze and update requirements

graphics/tab5_15.jpg

RD Workflow 3.6 – Validate Requirements

This final workflow of the requirements development process is about obtaining the formal agreement of your relevant stakeholders that their identified needs are appropriately expressed in your set of requirements and that they consider the requirements to be of good quality in terms of their correctness, consistency and completeness.

This is important because all subsequent development work or purchasing efforts will be based on these validated requirements. Table 5.16 displays the activities of this workflow indicating the involvement of other participants, as well as the inputs and outputs of each activity.

All relevant stakeholders should be given the opportunity to look at the entire set of requirements prior to any validation meeting, not just at those of which they are directly the stakeholder. Traditionally, you would invite all relevant stakeholders to one formal meeting during which you would jointly go through the entire set of requirements, demonstrating the outcomes of your quality analyses if needed.

However, the validation can also be driven via video or telephone conference, or even via email. In some cases, especially in geographically dispersed teams, this may be the most economical way in the light of limited travel budgets. Still, in any case you have to be confident that the relevant stakeholders fully understand what you have done and agree with your outcomes, before they validate the requirements you have developed.

 
Table 5.16 Validate requirements

graphics/tab5_16.jpg

All relevant stakeholders should validate those requirements for which they are the designated stakeholder only, but in the context of the other requirements within the set of requirements.

If you decide not to organize one stakeholder validation meeting, because it would take too long to find a suitable time slot for all concerned, or some of the relevant stakeholders are temporarily unavailable, you may prefer to drive the validation of your requirements with the relevant stakeholders individually, or in ‘partial’ validation meetings with only some of the relevant stakeholders participating at the time.

This workflow can be effectively enhanced by traceability analysis, requirements quality analysis, and mind mapping techniques – in terms of enabling the ‘on demand’ demonstration of evidence that sufficient analysis was carried out, and has led to updates of requirements as appropriate. These techniques have to be supported by object management, requirements quality analysis, and mind mapping or spreadsheet tools, so that the ‘on demand’ demonstration of evidence is possible.

Requirements Change Management

Once a new set of validated requirements has been established, this set needs to be kept up-to-date throughout the entire life cycle of the program, project, or system at hand. Step 4 of the RM process addresses this need.

There are many different factors for requirements change, both external and internal. For example, these might be changes in the market, in customer behavior or in their own business processes. Alternatively the company’s internal production process might have changed, or new legislation was ratified that influences our required system characteristics.

Not being able to change our requirements in a flexible yet controlled and systematic manner would bear the risk of losing competitive advantage at best, or may even lead to project failure.

Therefore, a stringent change process has to be in place to enable systematic and controlled change of our requirements and also to avoid uncontrolled requirements creep and mutation. The importance of change impact analyses that are based upon the available traceability information cannot be emphasized too much.

A summary checklist of the entire RCM process is provided in Appendix C.

Step 4 – Manage Requirements Change

The fourth step consists of the following six workflows: (1) ‘identify the need for change’, (2) ‘Analyze the impacts of the identified need for change’, (3) ‘Prepare the proposed change’, (4) ‘Analyze the impacts of the proposed change’, (5) ‘Agree the proposed change’ and (6) ‘Implement the agreed change’. The fifth workflow needs direct involvement of relevant stakeholders and domain experts, as marked in Figure 5.7.

RCM Workflow 4.1 – Identify the Need for Change

The first RCM workflow is about finding out that a requirements change is needed, or more accurately, whether a requirements change is needed. It is important that any such need be identified as soon as possible in order not to lose time, and to keep the costs that are caused by such a change as low as possible.

 
Figure 5.7 Manage requirements change

graphics/fig5_7.jpg

Not losing time is important for two main reasons. First, there are presumably people working on the basis of your requirements, for example finding and implementing a design solution that satisfies your requirements. If at least one of your requirements is wrong, that is, it needs to be changed, these people are working towards a partly wrong basis, thereby wasting time and money, until your requirements have been updated as appropriate.

Second, if it takes you a long time to update your requirements, this time will not be available for the recipients of your requirements to develop a new solution or find a new existing solution that satisfies your updated requirements. For example, this could mean that they may be forced to pick an existing, conventional solution due to the lack of time, instead of going for a more innovative solution that takes more time to develop. Table 5.17 displays the activities of this workflow, including their inputs and outputs.

You should make sure that you regularly check for any relevant requirements change notification from your relevant stakeholders or their organizations. This may be in the form of ‘engineering change proposals’ or ‘requirement change notes’, or in fact much less formal, with your customer sending you a letter that he wishes to make a change, depending on the specific context.

Also, within your own domain, you should keep your eyes open as to whether there are any changes in the domain knowledge or relevant regulation and legislation that may require changes of your requirements.

 
Table 5.17 Identify the need for change

graphics/tab5_17.jpg

In any case, it is worthwhile keeping communication channels open with all identified relevant stakeholders and domain experts. Furthermore, automatic triggers could be put in place that allow you to be informed if certain events happen that may entail the need for change at your level. For instance, the last point could be realized by regularly scanning the reports of relevant change control board meetings whose outcomes may include changes of requirements that potentially have an impact on your area.

This workflow is greatly enhanced by traceability analysis techniques that are supported by an object management tool.

RCM Workflow 4.2 – Analyze the Impacts of the Identified need for Change

The second RCM workflow is about identifying the likely impacts of the identified need for requirements change at your level. Impacted requirements have to be identified; and it has to be established whether any of these will have to be changed in order to be in line with the identified need for change. Any such need for change has to be categorized to be able to make sound decisions on where the change has to be addressed most urgently.

This workflow is important because it helps in providing a clear picture on the impacts of the identified need for change on your own level, that is, your requirements. It will help you to know which of your requirements are impacted by the identified need for change, which of them will have to be changed and how urgently, as well as of what type the expected changes of your requirements would be. Table 5.18 displays the activities of this workflow, including their inputs and outputs respectively.

 
Table 5.18 Analyze the impacts of the identified need for change

graphics/tab5_18.jpg

Possible ways of how your impacted requirements may have to be changed in order to accommodate the identified change elsewhere are the following: modifying requirement statements, modifying the information contained in related requirement attributes, deleting existing links, creating new links, creating new requirements that are now needed, or deleting existing requirements that are no longer needed.

Whatever change of your impacted requirements is needed, it is good practice to keep a history of what was done, when, by whom and why. For example, if you decide that one of your existing requirements should be deleted in the light of an approved change proposal that will lead to a change of one of your input requirements, then your decision to delete your requirement should be documented with a reference to the underlying change proposal. This documented history information should just cover sufficient information, not in too much detail or the activity will soon keep you from doing your ‘real’ work.

Most commercial RM tools provide automatic history functionalities that track what information was entered, modified, deleted and linked, when and by which user, so that only reference information or other justification information needs to be entered manually.

Categories of the needed change of your own requirements could be expressed in terms of the urgency at which you have to respond to the underlying changes that are impacting your requirements; the severity of this impact; or the type of change that is needed.

This workflow can be effectively enhanced by traceability analysis and mind mapping techniques that should be supported by object management and mind mapping tools respectively.

RCM Workflow 4.3 – Prepare the Proposed Change

The next workflow is about preparing a proposed change of one or several of your requirements in response to the identified need for change, when applicable. This means that you should propose an update of your requirements, as you think it would best accommodate the identified need for change. This is important because you will have to get your stakeholders’ ‘buy-in’. They need to be happy with these changes, and will most probably have to formally agree with the changes you propose. Table 5.19 displays the activities of this workflow with their inputs and outputs.

After detailed consideration of all necessary changes to your requirements, you should prepare these changes in order to propose them to the relevant stakeholders, who will usually have to agree with your proposal before you can implement your proposed changes. In larger projects or programs, there will be a dedicated requirements change process in place, in which case you will have to apply this process in order to communicate your proposed changes of your own requirements.

The same quality criteria for ‘writing good requirements’ apply for any such proposed changes. It goes without saying that the proposed changes have to be analyzed in the light of the remaining set of requirements at your level. There is a great danger in updating some of your requirements, but no longer looking at the remaining set of requirements. The previously described analyses at both the individual requirement level and the set of requirements level have to be carried out again in the light of the proposed changes.

As with the previous workflow, this workflow can be effectively enhanced by traceability analysis and mind mapping techniques that are supported by object management and mind mapping tools.

 
Table 5.19 Prepare the proposed change

graphics/tab5_19.jpg

RCM Workflow 4.4 – Analyze the Impacts of the Proposed Change

This workflow is about finding out what impacts the proposed changes of your requirements would have. This is important to know because if you wish your stakeholders to agree with your proposed changes they also need to know what impacts you expect these changes will have on the current situation. Such impacts may be related to system performance, project costs and/or schedule. Table 5.20 displays the activities of this workflow, as well as their inputs and outputs.

If a dedicated requirements change process was used to communicate the proposed change of your requirements, you will also receive feedback from the parties that are impacted by your proposed changes, that is, the recipients of your own requirements, be they internal or external to your organization. Any such feedback will be helpful in completing the picture with the expected budget and schedule implications of the proposed changes.

As with the two previous workflows, this workflow can be greatly enhanced by traceability analysis and mind mapping techniques that are supported by object management and mind mapping tools.

 
Table 5.20 Analyze the impacts of the proposed change

graphics/tab5_20.jpg

RCM Workflow 4.5 – Agree the Proposed Changes

This workflow is about obtaining the agreement of your relevant stakeholders with the requirements changes that you propose. This agreement may be subject to a number of prior changes to your proposal. The outcomes of your change impact analysis from the previous workflow will help you to provide the relevant stakeholders with a good picture of what the proposed requirements change will entail. In fact, this agreement of the proposed changes by the relevant stakeholders corresponds to the validation described in the requirements development process.

The workflow is important because it will bring about the new requirements baseline. Table 5.21 displays the activities of this workflow including their inputs and outputs, and indicating the involvement of other participants.

 
Table 5.21 Agree the proposed changes

graphics/tab5_21.jpg

Traceability analysis, mind mapping, and presenting techniques are essential to facilitate this workflow. These techniques ought to be supported by dedicated object management, mind mapping and presentation tools.

RCM Workflow 4.6 – Implement the Agreed Changes

The last RCM workflow is about implementing the validated and agreed changes to your requirements in a controlled manner, and communicating them to the people that depend on your requirements, that is, the recipients of your requirements. These recipients will consider your requirements as their input requirements and they will have linked some of their own requirements to your requirements as the source or justification of their requirements. Alternatively they may have produced some design solution or product to meet your requirements.

Therefore it is important to communicate any changes you have implemented (without delay) to these recipients of your requirements. They need to know as early as possible what was changed and why, so that they can start in turn their own change process, as appropriate. Table 5.22 displays the activities of this workflow, including their inputs and outputs.

 
Table 5.22 Implement the agreed changes

graphics/tab5_22.jpg

This workflow can be greatly enhanced by traceability analysis, mind mapping, presenting, and reporting techniques. These should be supported by the appropriate object management, mind mapping, presentation and text editor tools respectively.

Submit your own content for publication

Submit content