ABCs of Requirements Engineering

A strong requirements engineering discipline is critical to the success of an application. Poor discipline can lead to cancelled projects, significant cost overruns, and inadequate release deliverables. Configuration management (CM) plays a role in many of the requirements areas by providing version control and change control processes that can help in implementing a successful requirements engineering practice.

Areas of Focus for Requirements Engineering

In the requirements engineering space, there is often a focus on just requirements management. However, in order to manage requirements, they must be effectively elicited, documented, and approved. These steps will lead to a more effective process of managing change to requirements and will enable the ability to trace to and from requirements. This section will walk us through the areas of requirements engineering. As we pass through these areas, the support CM provides will be introduced. 

·       Eliciting requirements:This is the most critical area of requirements engineering. If requirements are not articulated, there is no chance for a successful release. This area revolves around two key facets.

·       Selecting a technique: The first facet of eliciting requirements focuses on selecting a requirements elicitation technique (or techniques) that can help best articulate the requirements. There is no one technique that is best for all projects, so it is important to investigate the various techniques and select the one (or more) that is best for the release of the application.

This is the step that helps define the language that will be used to discuss the requirements amongst the team and the structure that is used to articulate the requirements. The application owner (with input from analysts) should select a technique. Once a technique is selected, consider providing training to educate those that must contribute too or work with the requirements.

There are numerous requirements elicitation techniques. Some techniques include use cases, interviewing, (executable) prototyping, process-flow, modeling, mockups (paper prototyping), and brainstorming. Often times, if the language (or technique) is not defined, people start describing the requirements from the technique they are most comfortable. This is akin to beginning the development phase without a defined coding language and allowing the developers to use the development language or technique in which they are most comfortable. The end-result can be disastrous. While not to the same extent, a lack of a defined technique can slow down the requirements elicitation process and produce less clear requirements.

·       Holding appropriate elicitation sessions:The second facet of eliciting requirements focuses on the ensuring that the requirements elicitation sessions are productive. When approaching the requirements elicitation sessions, consideration should be given to the types of requirements that need to be captured, who should attend these sessions, and holding enough sessions to ensure there is adequate time to identify requirements.

·       Including the requirements category:Give thought to the category of requirements that should be identified. By listing the requirements categories, this can help avoid missing whole sections of requirements such as security related requirements. Some examples of the category of requirements are user requirements, system requirements, performance requirements, and security requirements.

·       Identifying participants:To determine who should attend the requirements elicitation sessions, identify the people who can best identify requirements. From a customer perspective, obviously include an appropriate number of customers. Customers that are paying the most may have more representation or have more weight in the requirements they solicit. Consider inviting marketing folks since they will have insight as to what the potential customers are looking for. You should also have systems representatives (lead developers and testers) so that technology related requirements are included.

·       Holding enough sessions: You may have sessions for one or more groups of people depending on the size and type of participants. You may consider having a requirements session for external customers, another for internal customers and marketing, and yet another for the systems folks. Another approach is to include all folks in the sessions to generate a better understanding of requirements across participant types. Typically, several requirements elicitation sessions are needed to extract requirements and hone them so they are somewhat concise and clear. 

Documenting Requirements

There are four key facets to documenting requirements. This includes getting to clear and concise requirements, estimating effort per requirement, prioritizing each requirement, and utilizing the right tool then template to store the requirements. 

·       Getting to clear requirements:The first facet to documenting requirements is to ensure that each requirement is unambiguous, concise, verifiable, complete, consistent, traceable, and have a unique identifier. Establishing a unique identifier can be as simple as number that is incremented upwards for each new requirement. The unique identifier is applied to each requirement. This also establishes the groundwork for enabling traceability. Without an easy to identify unique identifier, it is difficult to enable tracing to and from the requirements. The ability to ensure that requirements are unambiguous, concise, verifiable, complete and consistent relies heavily on the requirements skills and experience of those facilitating and documenting the requirements. Experience has found that having test personnel review the requirements is a good way to get the requirements into a less ambiguous, more concise, and verifiable level. This is because testers have the responsibility to test the requirement so they must really understand the requirements and ensure it can be verified (e.g., tested).

·       Estimating requirement effort: The second facet to documenting requirements focuses on estimating the effort of each requirement. This is typically the job of a business or system analyst (e.g., someone who has project estimation skills) who reviews each requirement, identifies what items are impacted, estimates the effort of each impacted item (includes design, development, and testing effort), then calculates the total effort. This data will be useful in helping prioritize requirements and identify which requirements should form the requirements baseline for a release.

·       Prioritizing requirements: The third facet to documenting requirements focuses on prioritizing the requirements. This is where either the customer and/or application owner prioritize the requirements to understand the relative importance. Consider establishing a priority grid with definitions for “priority 1,” “priority 2,” and so on. This can be a challenging task since it seems to be human nature to make most requirements a “priority 1.” If this becomes the case then either establish a “priority 1 high,” “priority 1 medium,” and “priority 1 low” or rank the requirements that are “priority 1”.

·       Utilizing the right requirements tool, then template:The fourth facet to documenting requirements focuses on selecting and utilizing an appropriate requirements tool so that the requirements can be more easily reviewed and managed. You can either use an automated vendor requirements tool or a manual spreadsheet. For smaller projects, you may find a template in spreadsheet tool may be adequate for your needs. If you have a more complex or large project, an automated vendor tool can be a wise choice. The advantages of an automated requirements tool is that it allows numerous fields or attributes per requirement (e.g., priority, requirement category, etc.) and it can provide a history of the requirements and what has changed. If traceability is important, select a requirements tool that provides an automated mechanism for traceability. If an automated requirements tools is being considered, perform a tool evaluation that focuses on identifying the needs for a Requirements tool. Once the tool choice is made, create the requirements list template(s) within the tool. Ensure it includes the fields or attributes (e.g., unique identifier, priority, requirement category, version number, etc.) that will be assigned to each requirement.

    CM support:  Because requirements change (much like code does), it is important to apply a form of version control as an attribute or field, whether in an automated   

    requirements tool or manually in a spreadsheet. Every time a requirement changes, the version number for that requirement should increment to reflect this change. Note:

    versioning of a requirement can be one of the criteria used to select an automated vendor requirements tool.

Approving Requirements

There are three key facets for getting requirements approved. They are identifying the right folks to establish and approve the requirements baseline, determining which requirements goes into the release, and approving the requirements. 

·       Establish an application-level change control board (CCB): The first facet for approving requirements focuses on establishing a change control board (CCB) at the application level. Those assigned to the CCB should be considered stakeholders of the application and are empowered to establish requirements baselines per release and approve or reject new requirements or changes to existing requirements across the application lifecycle. This may include, but not limited to the application owner (product manager), test manager, development manager, and customer representative (this may be marketing).

CM support:  The CCB is a key element of configuration management. The CCB, like the CM discipline, focuses on the importance of managing and controlling change.

·       Determine requirements of releases: The second facet of approving requirements focuses on allocating requirements to the releases of an application based on the priority and estimated effort of the requirements. This is the task of the application-level CCB. Their first goal is establishing a baseline of requirements for the latest release (then subsequent releases). The ability to determine if the requirements are attainable in a release is based on the requirements estimates given along with the estimated effort of the bug fixes and other changes being included in a release. Otherwise, several of the requirements (or bug fixes) may need to be deferred to subsequent releases (whether a major, minor, or patch release).

·       Approve the requirements baseline for a release: The third facet focuses on approving the set of requirements to establish a requirements baseline for a given release. This again is the task for the application-level CCB. They will review the set of requirements, ensure the estimates of effort align with the schedule, and then approve the set of requirements to establish the contents for a release. This becomes the requirements baseline for a release and changes will be managed too it at the project level.

CM support: Approving the baseline is a change control board (CCB) task, which is a key element of configuration management.

Management of Requirements

Requirements Management refers to managing changes to an approved requirements baseline for a release. There are four key facets to managing a requirement. They are to establish a requirements management (RM) process, establish a project-level CCB, establish a CCB Conduct Guidelines, and implement the RM process. 

·       Establish a requirements management process:  The first facet of managing requirements is to establish an RM process. Typical steps in an RM process include:

1.       Change request get submitted

2.       Change gets analyzed for impact and effort

3.       Change gets reviewed and ruled on (accept, reject, etc.) by the CCB

4.       Change gets assigned to a change agent

5.       Change agent makes change

6.       Change gets validated

7.       Change request gets closed

All changes are discussed in relation to the requirements baseline (e.g., the set of approved requirements for a particular release).

As part of step 1, a change request form (CRF) should be created to capture all pertinent information about a change. In addition, you may wish to automate the change request form using a change management or incident tracking tool. If so, ensure a proper tool evaluation occurs.

CM Support: The RM process is effectively a CM change control process but specifically for the requirements baseline.

Note: For details about establishing a change control process (including process example), visit the book, “Software Configuration Management Implementation Roadmap,” Chapter 4, section 6.2. “Develop an SCM Change Control Process.”

·       Establish a project-level change control board (CCB):The second facet of managing requirements is to establish a CCB at the project level. This CCB should be made up of key project representatives who are empowered to make project decisions that focus on the impact of the change to the release schedule and quality of the release deliverables. This typically includes the project manager, test lead, developer lead, CM lead, and customer representative (e.g., marketing or actual customer). These folks should be trained in the established requirements management process mentioned above.

Often times within a project release, new requirements are uncovered and it must be determined if they should go into the current release or be deferred to a subsequent release. If the recommendation is to defer it to a subsequent release, then the change request should be sent to the application-level CCB for their ruling.

CM support: The change control board (CCB) is a key element of configuration management. The CCB, like the CM discipline focuses on the importance of managing and controlling change.

·       Establish the CCB conduct guidelines: The third facet of managing requirements is to establish a CCB conduct guidelines. These guidelines provide rules to help objectify the CCB process in order to more effectively and efficiently rule on each change. It will include determining the CCB meeting logistics, CCB meeting process, CCB voting privileges, Voting approval method and waiving policy. This guideline should be established and reviewed with the CCB members.

Note: For more details about the CCB Conduct Guidelines (and example template), visit the book, “Software Configuration Management Implementation Roadmap”, Chapter 4, section 6.2.1 “Prepare Change Control Board (CCB) Conduct Guidelines”.

·       Implement the requirements management process: The fourth facet of managing requirements is to implement the requirements management (RM) process for use on an on-going basis. Review the requirements management process, the change request form (CRF), and the CCB conduct guidelines with all CCB members. Per the CCB conduct guidelines, set up periodic CCB meetings or hold them when change requests come in. Rule on the changes per the RM process and CCB conduct guidelines. Post the results of the CCB meeting to all impacted personnel. On occasion, validate that the RM process is being used to determine if changes are being objectively processed in a timely manner. 

Traceability of Requirements

Traceability may be defined as the relationship between requirements and the downstream items (e.g., code, test cases, etc.) that realize the requirements. The main benefit of establishing traceability between requirements, code, and test items is that it ensures that only what is required is being developed and everything that is developed is actually tested. This reduces the gap of missing requirements in the finished product and reduces the chance of releasing code that has been untested.

There are two key facets to traceability. The first is that all traceable items must be uniquely identified and controlled. The second is that all links between traceable items must be identified, established, and maintained. It should be noted that traceability tends to be an advanced practice in the requirements arena since it effectively crosses thru design, coding, and into test and is challenging to implement. The first challenge is the effort involved may be high compared to the perceived and real benefit of establishing traceability. The second challenge is that traceability cannot be implemented on an ad-hoc basis, but must be implemented as a program across the application lifecycle. Otherwise, the benefits will not be realized.

·       Uniquely identify all requirements, code, and test cases: The first facet to traceability is that all traceable items that will be traced to and from must be uniquely identified and version controlled. Therefore, in order to perform valid traceability, the team must have requirements that are unique, have a requirements identifier (ID), and be versioned. Also, all code and test items (e.g., test cases, test scripts, etc.) must be uniquely identified and should be version controlled to make the items easier to identify and manage. 

·       Create traceable links to establish a traceable relationship path: The second facet to traceability is that once items are uniquely identified and controlled, links must be established and maintained between traceable items. The links established between a requirement and its downstream items form the traceable relationship path. Once the traceable relationship path is established, it is easier to ensure that requirements are being developed and fully tested. Below is an example of five traceable relationship paths.   

CM support:  If traceability is desired between requirements, code, and test scripts, then code and test items should be version controlled in a CM repository. For more advanced and automated traceability, an integration between a configuration management tool and the requirements tool may be advantageous. That way, all configuration items (code, test scripts, etc.) that support the requirements can be versioned, easily identified, and have links (e.g., hyperlinks) amongst those in the traceable relationship path.

Summary
Many times, application teams reduce the requirements engineering effort on a release due to a perceived short-term time-to-market gain. While a project may appear to improve its schedule up front by spending less time in the requirements phase, it ends up spending more money in cost-overruns because it was not clear what it was building causing key functionality to be missed, nor clear on what it should be testing causing large sections of untested functionality being released. This affects not only the current release, but also subsequent releases of the application.

For an application to have successful releases and avoid cost overruns, a requirements engineering practice must be in place. This process should include the ability to elicit requirements, document requirements, approve and baseline requirements, manage the requirements after approval, and trace from the requirements thru test. CM can help develop a solid requirements engineering practice by providing version control and change control processes. These CM processes can be tailored to fit the needs of requirements engineering which will lead to a more successful application lifecycle and releases therein.

References

1. Chapter 4: “Establish an SCM Infrastructure for an Application” from “Software Configuration Management Implementation Roadmap” by Mario E. Moreira, 2004, Wiley, Ltd. Publishing

2. “Effective Requirements Practices” by Ralph R. Young, 2001, Addison-Wesley

3. “An Analysis of the Requirements Traceability Problem” by Orlena C.Z. Gotel & Anthony C.W. Finkelstein, Imperial College of Science, Technology, & Medicine, Department of Computing. http://www.cs.ucl.ac.uk/staff/A.Finkelstein/papers/rtprob.pdf