Requirements Engineering Process Assets

Requirements & Requirements Management

Requirements Engineering Process Assets

By |

High-performance projects have effective processes for all of the requirements engineering components: elicitation, analysis, specification, validation, and management. To facilitate the performance of these processes, every organization needs a collection of appropriate process assets. A process encompasses the actions you take and the deliverables you produce; process assets help the team members perform those processes consistently and effectively. These process assets will help those involved in the project understand the steps they should follow and the work products they’re expected to create.

Table 1 identifies some valuable process assets for requirements engineering. No software process rule book says that you need all of these items, but they will all assist your requirements-related activities. Procedures should be no longer than they need to be to let team members consistently perform the tasks effectively. They need not be separate documents. For instance, an overall requirements management process could include the change control procedure, status tracking procedure, and impact analysis checklist.

Following are brief descriptions of each of these process assets. Many of these are available at http://www.processimpact.com/goodies.shtml. Keep in mind that each project should tailor the organization’s assets to best suit its needs.

Table 1. Key process assets for requirements development and requirements management.

Requirements Development Process Assets

Requirements development process. This process describes how to identify stakeholders, user classes, and product champions in your domain. It should address how to plan the elicitation activities, including selecting appropriate elicitation techniques, identifying participants, and estimating the effort and calendar time required for elicitation. The process describes the various requirements documents and models your project is expected to create and points the reader toward appropriate templates. The requirements development process also should identify the steps the project should perform for requirements analysis and validation.

Requirements allocation procedure. Allocating high-level product requirements to specific subsystems (including people) is necessary when developing systems that include both hardware and software components or complex products that contain multiple software subsystems. Allocation takes place after the system-level requirements are specified and the system architecture has been defined. This procedure describes how to perform these allocations to ensure that functionality is assigned to the appropriate components. It also describes how you will trace allocated requirements back to their parent system requirements and to related requirements in other subsystems.

Requirements prioritization procedure. To sensibly reduce scope or to accommodate added requirements within a fixed schedule, we need to know which planned system capabilities have the lowest priority. I’ve developed a spreadsheet tool for prioritization (at http://www.processimpact.com/goodies.shtml) that incorporates the value provided to the customer, the relative technical risk, and the relative cost of implementation for each feature, use case, or functional requirement.

Vision and scope template. Step 1 for managing the dreaded specter of scope creep is to document the project’s scope someplace, so we can judge whether proposed new requirements are in or out of scope. The vision and scope document is a concise, high-level description of the new product’s business requirements. It delineates what’s in and what’s out, thereby providing a reference for making decisions about requirements priorities and changes.

Use-case template. The use-case template provides a standard way to describe tasks that users need to perform with a software system. A use-case definition includes a brief description of the task, descriptions of alternative behaviors and known exceptions that must be handled, and additional information about the task.

Software requirements specification template. The SRS template provides a structured, consistent way to organize the functional and nonfunctional requirements for whatever product you’re building. Consider adopting more than one template to accommodate the different types or sizes of projects your organization undertakes. This can reduce the frustration that arises when a “one size fits all” template or procedure isn’t suitable for your project.

SRS and use-case defect checklists. Formal inspection of requirements documents is a powerful software quality technique. An inspection defect checklist identifies many of the errors commonly found in requirements documents. Use the checklist during the inspection’s preparation stage to focus your attention on common problem areas.

Requirements Management Process Assets

Requirements management process. This process describes the actions a project team takes to deal with changes, distinguish versions of the requirements documentation, track and report on requirements status, and accumulate traceability information. The process should list the attributes to include for each requirement, such as priority, predicted stability, and planned release number. It should also describe the steps required to approve the SRS and establish the requirements baseline.

Change control process. A practical change control process can reduce the chaos inflicted by endless, uncontrolled requirements changes. The change control change process defines the way that a new requirement or a modification to an existing requirement is proposed, communicated, evaluated, and resolved. A problem-tracking tool facilitates change control, but remember that a tool is not a substitute for a process.

Requirements status tracking procedure. Requirements management includes monitoring and reporting the status of each functional requirement. You’ll need to use a database or a commercial requirements management tool to track the status of the many requirements in a large system. This procedure should also describe the reports you can generate to view the status of the collected requirements at any time.

Change control board charter. The change control board (CCB) is the body of stakeholders that decides which proposed requirements changes to approve, which to reject, and in which product release or iteration each approved change will be incorporated. The CCB charter describes the composition, function, and operating procedures of the CCB. It’s worth taking the time to describe how a group of key decision makers will collaborate.

Requirements change impact analysis checklist and template. Estimating the cost and other impacts of a proposed requirement change is a key step in determining whether to approve the change. Impact analysis helps the CCB make smart decisions. An impact analysis checklist helps you contemplate the possible tasks, side effects, and risks associated with implementing a specific requirement change. An accompanying worksheet provides a simple way to estimate the labor for the tasks.

Requirements traceability matrix template. The requirements traceability matrix lists all the functional requirements, the design components and code modules that address each requirement, and the test cases that verify its correct implementation. The traceability matrix should also identify the parent system requirement, use case, business rule, or other source from which each functional requirement was derived.

Simply passing out a bunch of process documents to your team members is no guarantee of success. Well-meaning improvement leaders sometimes get carried away, creating much more process documentation than they need. Your process materials should be light enough to be unintimidating, practical, and effective—but no lighter.

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.  Karl Wiegers is an independent consultant and not an employee of Jama.  He can be reached at http://www.processimpact.com.  Enjoy these free requirements management resources.

Karl Wiegers
Latest posts by Karl Wiegers (see all)