SOFTWARE ACQUISITION GOLD PRACTICE

MANAGE REQUIREMENTS

FOCUS AREA: REQUIREMENTS - Change Management

 

 

Definition and Summary:  The process of eliciting, documenting, organizing, and tracking changing requirements and communicating this information across the project team to ensure that iterative and unanticipated changes are maintained throughout the project lifecycle.

 

Requirements management is premised on accepting several key assumptions as reality and planning for them:

·                Most software efforts are increasing in size and complexity and thus require an iterative (or evolutionary) development approach.

·                Requirements will, in fact, change over the life of the project due to changes in technology, user needs and the environment

·                Requirements emerge as knowledge is obtained during development

·                Requirements drive the verification and test process

 

Requirements Management (RM) seeks to reduce the risk of cost and schedule overruns by establishing a way to control the continuing definition of requirements as changes occur and unforeseen needs arise and as knowledge is gained during development, in contrast to more traditional development approaches where requirements were documented (often without involvement of the developer) prior to any development activities and frozen for the life of the effort.  The successful implementation of RM depends on having flexible contract scenarios that require the establishment of a process to manage requirements (in lieu of rigid pre-defined specifications) that addresses specification, change control and traceability, and identifies what stakeholders must be involved in the various activities of the process throughout the life cycle.

 

Some benefits attributed to an effective requirements management process are:

·          Documented agreement on exactly what the software is supposed to do

·          Improved quality of requirements

·          Better alignment with program or business goals

·          Reduced time to market

·          Projects completed on schedule

·          Optimized Return-On-Investment (ROI)

·          More effective use of human resources

·          Fostering a cooperative low-stress development environment

·          Creation of requirements components that can be reused within a product line

·          Verification that user needs have been implemented and adequately tested

·          Verification that no “extra” behaviors have been added that do not relate to a requirement

Description of the practice:

 

Summary DESCRIPTION

The scope of requirements management (RM) is increasing as we migrate from the traditional waterfall development model to an evolutionary development approach.  In some scenarios, RM now encompasses all aspects of requirements development.  Primarily RM involves eliciting, documenting, organizing, and tracking changing requirements and communicating this information across the project team to ensure that iterative and unanticipated changes are maintained throughout the project lifecycle and that stakeholders maintain a shared vision.  RM is the glue that enables the requirements engineering processes to be effective as the project progresses.  It begins with establishing positive relationships among success-critical stakeholders and continues throughout the life of the project.  It is premised on accepting that requirements will, in fact, change.  As the need for change arises, it is important to apply the same processes that were applied in the creation of the initial requirements.  RM is focused on guiding a project in developing and tracking the requirements for successive releases of the software (development spirals) when the evolutionary development model is used.

Key Processes of Requirements Engineering

The essential activities and key practices of RM are:

§        Understand the relationships among key stakeholders and involve them in the requirements engineering process

§        Identify requirements change – Recognizing the need for a requirements change is one of the most challenging aspects of project development, and can significantly impact the project.

§        Manage the changes to requirements – Establish and use formal procedures of requirements engineering to ensure that issues are addressed and the appropriate specification and communication occurs.

§        Identify and track requirements attributes – This provides objective data for better decision making.

§        Trace requirements – Maintain an information path from source to implementation. 

 

DetailED description

Throughout this document the “Manage Requirements” practice and the “Requirements Management (RM) “process are considered to be synonymous.  While addressing the process as a whole, we will identify key practices within the process that may contribute to a successful implementation.

RM is the process of eliciting, documenting, organizing, and tracking changing requirements and communicating this information across the project team to ensure that iterative and unanticipated changes are maintained throughout the project lifecycle.  It is premised on accepting these key assumptions as reality and planning for them:

§         Most software efforts are increasing in size and complexity and thus require an iterative (or evolutionary) development approach

§         Requirements will, in fact, change over the life of the project due to changes in technology, user needs and the environment

§         Requirements emerge as knowledge is obtained during development

§         Requirements drive the verification and test process

 

A widely accepted interpretation of RM is illustrated in Figure 1.  The software effort is segmented into a series of deliveries (releases), each with more functionality added, resulting in the evolution of the envisioned product over time.  However, detailed planning and requirements development focuses on each release.

Figure 1:  The Role of Requirements Management in Evolutionary Development

 

The scope of RM is evolving as we migrate from traditional sequential software development models to the currently recommended evolutionary acquisition models.  Table 1 identifies some observations of the two approaches with respect to requirements.  They differ not in the “what”, but in the “who” is doing it, and “when” is it being done.  Figure 2 illustrates the scope of RM from a traditional development approach while Figure 3 addresses the scope of RM from a modern engineering perspective, specifically positioning RM as a subset of a broader requirements engineering (RE) discipline comprised of several requirements-related processes.  

Although the traditional approach is characterized here for comparison purposes, it is no longer the recommended approach because the size and complexity of software efforts demands an approach that is more responsive to change.

These two approaches are characterized as follows in Table 2, but there are some key differences to remember.

§        The evolutionary approach involves all success-critical stakeholders in the requirements engineering process working together to develop requirements, while in the traditional approach does not.

§        In the traditional approach, requirements are essentially dictated to the developer, while in the evolutionary approach stakeholders (acquirers, customers, users and developers) work together to develop a shared vision. 

Table 1:   Observations of Traditional and Evolutionary Development Approaches

Traditional Development Approach

Evolutionary Development Approach

Acquirer develops requirements independent from Developer. The acquirer may follow an iterative cycle of elicitation, analysis, specification, and validation until the requirements document is determined to be complete, but this is without interaction with the developer. Minimal dialogue occurs between developer and acquirer regarding requirements.  The acquirer essentially dictates requirements to the developer by referencing the requirements specifications to contractual agreements. Requirements attributes are maintained within the requirements document. Requirements development can be a lengthy process – sometimes taking longer  than producing the software [Reifer, 2000] Requirements are essentially frozen prior to any development. Requirements management is essentially viewed as document management, maintaining the requirements documents over the life of the project, including the requirements traceability matrix. For large systems, attempts are made to define all the requirements for the entire system before any design or development activity occurs.

All stakeholders are involved in developing requirements – not just the acquirer.  Developers often participate in the elicitation, analysis, specification and validation processes for the initial requirements as well as for requirements changes. Stakeholders work together to develop, refine and prioritize requirements for each phase (release) of the effort through negotiation, and accept that requirements will change. Planned dialogue occurs between the RM process and other RE processes (and their stakeholders) throughout the product life cycle. Developer must demonstrate a capability to manage requirements changes. Requirements repositories (tool based) are used to maintain attributes and generate requirements documents on demand. Contracts reference broad functional capabilities or performance requirements rather than specific requirements specifications. Large complex systems are decomposed into smaller more manageable projects, where each project constitutes a release or phase of development, and requirements are refined and a baseline established for that release.  Development occurs for that release while requirements development is in progress for future releases. Prototypes and executable architectures are used to validate requirements for a planned release or spiral.

Figure 2: Traditional Development Approach

In traditional development environments the general perception is that the acquirer develops the requirements to a sufficient level of detail and then attaches/references the requirements document(s) in contractual agreements with developers.  Developers are responsible for meeting the requirements as defined.  The requirements are essentially frozen.  There is little opportunity for dialogue among the stakeholders once the document is approved.  There is essentially a wall (communication barrier) between developer and acquirer.  The developer is expected (and contractually obligated) to deliver the software as specified in the requirements document.  In theory, this scenario is ideal but in practice the process deteriorates as projects grow larger and more complex, along with the increased demand for better, cheaper, software delivered faster.  Changes in the environment, the technology, and the knowledge acquired during development trigger a need for requirements change, but the only avenue for making the change is through a contract modification.

In contrast to the traditional approach, the engineering perspective summarized in Figure 3 places RM at the hub of requirements engineering.  Although the focus of RM is on managing changes to requirements, it is the glue that ties the other requirements processes together over time, and maintains the focus on the overriding goals of the initiative.  RM establishes and maintains the necessary communications among stakeholders in addition to its primary functions of (1) controlling requirements changes, (2) managing requirements attributes for better decision making, and (3) establishing and maintaining traceability throughout the life of the project.  RM is about formalizing the focus of the project to ensure that the resulting software product satisfies the needs and expectations of the users and/or customers.

 

Figure 3: Key Processes of Requirements Engineering

Some sources in the literature contend that RM is the “oversight” process for all of requirements engineering, while other sources see RM as a process, isolated from requirements definition and validation, that clearly begins when the initial set of requirements are baselined, and then continues for the life of the project.  In reality, the scope of RM for you depends on many things: the organizational culture, the development environment, the relationships among stakeholders, and the size and complexity of the effort.

It is important to address the scope of RM in relation to the other processes of requirements engineering (RE).  A detailed description of each of these processes is beyond the scope of this document, but a summary is provided in the following paragraphs.  Most of the content of these paragraphs is derived from the Software Engineering Body of Knowledge [SWEBOK, 2001].

Requirements Elicitation

Requirements elicitation is the starting point for a project, the first stage in building an understanding of the problem that the software is supposed to solve.  It is essentially a human activity and is where stakeholders are identified and relationships established between the acquirer, customer, user, and developer.  This process is typically performed by a requirements engineer (or team) with appropriate experience and skill in implementing elicitation techniques.

Elicitation seeks to discover all of potential sources of requirements including:

§         Goals – The overall high-level objectives that the system needs to satisfy

§         Domain knowledge – Sufficient knowledge of the domain is necessary in order to allow the requirements engineer to infer tacit knowledge that may not be specifically articulated by the stakeholders

§         Stakeholders – Multiple stakeholders typically have differing viewpoints which must be weighed and managed to avoid conflicting requirements, or an inappropriate bias toward a particular stakeholder view

§         Operational environment – Not addressing requirements derived from the operational environment can severely impact feasibility, cost, and design choices

§         Organizational environment – Impact of the structure, culture, and internal policies of the organizations involved needs to be assessed in determining requirements

§         Law/Regulations – In many cases regulation drives or constrains what is possible

Elicitation Techniques

Requirements sources rarely have explicit requirements detailed to a level appropriate for making design decisions.  The requirements must be derived as a result of interacting with stakeholders and reviewing other sources, and getting concurrence from stakeholders about how well the statements represent their thoughts.  It is a difficult and labor intensive task, regardless of who is doing it, and irrespective of the software development approach.  Techniques include:

§         Interviews

§         Scenarios

§         Prototypes

§         Facilitated meetings

§         Observations

 

The requirements engineer must translate the information coming from the various sources into requirements statements representing a hierarchy of levels, and organized according to a scenario that makes sense for the project.  Typically this results in a requirements document.

In some environments elicitation may be on-going as new phases of a software effort are planned.

 

Requirements Analysis

The main objectives of Requirements Analysis (RA) are:

§         To detect and resolve requirements conflicts

§         To discover the bounds of the system and how it interacts with its environment

 

Analysis generates requirements attributes that are used to manage the project thereafter.  Analysis activities include:

§         Classifying requirements – Grouping requirements into logical entities for planning, reporting, and tracking.  Classification can be done on a number of dimensions including source, type, priority , risk, scope, volatility.

§         Prioritizing requirements – Establishing the relative importance and risk of each requirement, and specifying an implementation priority

§         Conceptual modeling – To aid in understanding the problem.  Some types of models typically used are data and control flow charts, state models, event traces, user interactions, and object models.

§         Architectural design and requirements allocation – Deriving architecture of the solution and allocating requirements to subsystems (assigning responsibility for satisfying requirements to subsystems).

§         Requirements negotiation – Another name for conflict resolution.  Addresses problems with requirements where conflicts occur between stakeholders wanting incompatible features, or conflicts between requirements and resources, or between capabilities and constraints.

It is important to note that these activities are not sequential and do not always precede requirements specification.  Conceptual modeling may occur as part of design activities after a set of requirements have been approved, in addition to its use for reaching a common understanding of the requirements.  Architectural design typically follows specification as well, but in some environments these activities are used to assess the feasibility of the requirement and provide the data necessary to support negotiation.  Some would argue that conceptual modeling and architecture design address “how” rather than “what” and, therefore, are not really part of requirements engineering.  In some sources in the literature requirements negotiation is viewed as part of the validation process, and in other sources it is viewed as part of the requirements management process.  The manner in which these activities are grouped is not significant, but performing the activities is vital.

 

Requirements Specification

Specification is concerned with how to preserve and communicate the current agreement of stakeholders about requirements.  Requirements must be documented and the documents maintained over the life of the project.  This is the most fundamental precondition for successful implementation.  Recent studies [Hofmann, 2001] show that successful projects typically allocate from 15 to 30 percent of project resources for requirements engineering activities.  Depending on the environment and the scope of the effort, there may be a need for several documents, addressing various levels of requirements.  Document names may vary.  Typically, a document (often called the Concept of Operations (ConOps)) describes the results or output from the requirements elicitation process, or the stakeholders’ initial perspective of the proposed capability, and another document (often called the Software Requirements Specification (SRS)) contains the detailed requirements that are needed to drive the design.  Many of the requirements at this level are derived from the higher level requirements in the ConOps or comparable sources.

In some environments specification languages are selected to make the requirements precise and consistent.  Requirements statements are replaced by models and/or prototypes that allow users to directly experience the interpretation of their expectations.  Such models help to clarify the actual requirements and, in turn, can be used to generate design and code.

Key practices of this process are:

§         Uniquely identify each specific requirement to make referencing them easier

§         Strive for the minimum possible number of documents to minimize maintenance as the project progresses

§         Establish a single source for requirement storage (each requirement is stored once in a single place and can be referenced many times).  This repository may be a master document, or it may be a database from which the necessary documents can be generated. The larger the project, the greater the need for a tool to support requirements specification.

§         Follow a standard or recommended guide for adopting a structure for the document.

§         Adhere to standard rules for writing good requirements statements

§         Assess and improve document quality, since it can drastically affect the quality of the resulting software product.  This is also addressed under the requirements validation process.

 

Documenting requirements forces issues of clarity and priority to surface and reduces the variation in interpretation of requirements thus bringing the stakeholders to a common ground.  However, if the document is not used, once written, then the process is of little value.  Care must be taken to ensure that the document (or structural counterpart) remains readable and accessible to the team throughout the life of the project, and that its structure supports its use in the specific development environment.  Often, projects under schedule pressure neglect to maintain the requirements document as changes occur because the task is perceived as less important than other development tasks.  In a very short time, the document becomes obsolete and useless because it no longer reflects the real requirements.  It is important to understand that changes will occur and plan an efficient update process at the start of the project.  For large projects or projects with more than 100 detailed requirements, it is a labor intensive, time consuming task to maintain documents without the support of requirements tools.  Most successful projects resort to maintaining requirements in a repository and generating document updates automatically from the repository.  Making decisions about such maintenance is an important function of requirements management, and project management in general.

 

Requirements Validation

The goal of requirements validation is to seek out and correct problems before resources are committed to implementing the requirements.  It is concerned with examining the requirements to certify that they meet the stakeholders’ intentions, and to ensure that they define the right system, the essence of the agreement and understandings between developer and acquirer about what to build, in a manner that ensures a common understanding across the project team and among the stakeholders.  Validation addresses specific requirements and the requirements collection as a whole.

Validation should not be confused with verification.  Verification occurs after requirements have been accepted, and determines whether the work products conform to the allocated requirements, not whether the requirements are in fact correct.

Key activities of requirements validation are:

§         Conduct requirements reviews to validate that requirements are correct, unambiguous, complete, consistent, ranked for importance, verifiable (testable), modifiable, and traceable.  Review teams should include end user representatives and customer representatives, in addition to the developer participants.  Use quality checklists as an aid to the review process.

§         Use prototyping to validate requirements. Prototypes demonstrate assumptions and actual understandings and can alert the team to mismatches between the written requirement and the interpretation carried forward in the prototype

§         Validate the conceptual models developed during analysis

§         Plan how each requirement will be verified (establish acceptance tests)

 

Requirements Management

Having briefly addressed each of these requirements engineering processes, the case can now be made that Requirements Management (RM) touches all of them, and they in turn provide information needed for RM.  Figure 3 contains two way communication arrows between RM and each of the four other processes that constitute requirements engineering to signify that as events occur that may trigger requirements changes, the management process must revisit each of the other four processes in order to adequately determine the impact of the candidate requirement on the existing effort.

RM is about ensuring that the software continues to meet the expectations of the acquirer and/or user.  The requirements document needs to always accurately reflect those expectations as changes occur in order to communicate those changes to the development team and ensure that a shared vision is maintained among stakeholders.

RM, therefore, needs to elicit new requirements that arise from changing expectations, new regulations, or other sources of change.  RM needs to analyze the impact of those changes on the project.  Conflicts need to be addressed and changes actually negotiated and validated before such requirements are added to the baseline.

The RM process applies formal change control practices to requirements and brings the artifacts of requirements engineering under configuration management (CM).  Thus, there is a tight coupling between RM and CM processes and tools used on the project.  They must be compatible.

Who is responsible for Requirements Management?

The developer has primary responsibility for RM, but the acquirer has final approval on requirements changes, just as they approved the initial requirements.  Within the developer organization there is typically a requirements engineer role (sometimes filled by the project manager, technical lead, or software architect, or a composite team) that is responsible for RM. This person (or team) works closely with the configuration management team because requirements artifacts and attributes have to be managed in much the same way as source code and design artifacts.  RE demands a high level of skill. Project Managers should ensure that the RE team is comprised of experienced and well-trained people.

The literature documents that the most difficult, and yet most important, task of RM is identifying the need for a requirements change.  Things that should be addressed as requirements changes are often overlooked and have significant consequences to the project in terms of schedule and cost when the issue is not discovered or addressed until the coding or testing phase of a project. On the other extreme, high requirements volatility can severely diminish the likelihood of a successful implementation if some degree of control is not used.  This volatility is a significant risk factor and should be managed as such.

Key practices of Requirements Management:

Identify and understand stakeholder relationships:  There are four key stakeholder groups whose relationships impact RM. In this context the terms are defined as follows:   

Acquirer – The organization (s) responsible for acquiring the software, by establishing contracts with one or more developers.

Customer –The organization(s) that are providing the funding, or in essence purchasing the product or service

User - The collection of individuals, groups, or organizations that will actually use the software product or service.

Developer –The organization(s), or team of individuals, responsible for developing or maintaining custom software, or integrating COTS-based software to provide a solution.

Figures 4 and 5 illustrate key relationships that may exist among stakeholders that have an impact on requirements engineering.

Figure 4-a represents the one end of the relationship spectrum where all stakeholders are within the same organization and communication occurs in the natural course of operations.  A common vocabulary may already exist.  The developer is also a user.  In this scenario, size and complexity of the application are the major reasons for documenting requirements and having a formal change control process in place.

Figure 4:  Mutliple Stakeholders within Common Boundaries

Figure 4-b represents the relationships in a typical COTS development environment.  End users for the most part are not directly involved in the process.  It is market driven.  Sales people often represent the end user.  Although funding is internal, marketing people and technical people do not have a common vocabulary, nor is their motivation the same.  In this environment, negotiating what requirements will be implemented for a specific release is critical to project success.

Figure 4-c is a scenario that represents many government software and system efforts.  The acquirer contracts with one or more developers to deliver a desired capability or solution.  The project may be constrained by the nature of the contractual relationship, by requirements to interface with or be compatible with legacy systems, by government regulations, and by domain-related issues.  Stakeholders have varying, and sometimes conflicting, motives.  In this scenario it is extremely important to focus on a common vocabulary, and to identify where domain knowledge impacts assumptions about requirements.  The developer should plan how to get the key stakeholders involved and keep them involved throughout the effort.

Figure 5:   Stakeholders within Separate Boundaries

 

Figure 5-a is a scenario comprised of stakeholder relationships that are both internal and external; some funding comes from within the acquiring organization, some from other sources; some users are part of the acquiring organization while others are not; external developers are working side-by-side with in-house technical people.  This is typically evident on research projects where the deliverables are not necessarily known.  The biggest challenge in this type of environment is probably getting people to recognize that requirements do in fact exist and need to be identified and delineated.

Figure 5-b illustrates the scenario that is often prevalent for very large projects/programs such as weapon systems programs.  Stakeholders are from distinct organizations, each with their own perceptions, language, and motivations.  The critical activity for RM in this scenario is to establish and maintain communications (denoted by the arrows) among these diverse stakeholders.  More resources may be needed for requirements engineering in this case.  Also, it becomes more important to use a requirements management tool for timely updating and reporting of requirements changes.

Take responsibility for requirement management:

The project needs to take responsibility for RM regardless of the stakeholder situation.  If the project is constrained by tight contractual obligations that, in essence, freeze the requirements, it behooves the developer to communicate any issues involving requirements early on to build a relationship of trust with the acquirer by providing solid data to support requirements negotiation.  The developer needs to do requirements analysis even if it has already been done by the acquirer.

Establish a shared vocabulary:

Take time early in the project to discuss terminology and gain an understanding of what the acquirer and developer really mean when they use key terms.  Agree on common usage.  Be flexible.  You may need to adjust your language to accommodate the customer or end user.

Plan and manage the specification process:

The developer should get involved in the specification process and ensure that a requirements document is established, whether or not it is a contract deliverable.  In many cases the requirements presented at the time of contract award are not sufficient to drive design.  Typically, further analysis and validation is necessary in order to create a document that is sufficiently detailed to drive the design process.

The final, most detailed requirements are typically contained in a document called a requirements specification.  This document usually contains other information that provides the rationale (why) for the requirements and other explanatory information.

This is especially important for projects that focus on software maintenance, since change requests may be in conflict with the functions of the existing system.

Note that “documented” means written down or recorded.  It does not restrict the specification to a hard copy manual or book.  Requirements entered into a database, or some other requirements tool (where they can be referenced consistently and are accessible to the team), are acceptable forms of specification.

Validate requirements changes:

Perform your own validation of any requirements document provided by the acquirer at the time of contract award.

Good requirements specifications have the following characteristics:

§         Lack of ambiguity – There is only one possible interpretation for each requirement statement

§         Conciseness – Minimal number of words used, and presented in a distinct visual form (not embedded in a paragraph of explanatory information)

§         Completeness – The specification contains all requirements known to date

§         Consistency – There are no conflicting requirements

§         Traces to origins – The source/origin of each requirement is identified.  It may have evolved from a more general requirement, result from a conversation with a user, result from adoption of a standard, or adhering to a new regulation.

§         Absence of design – The statements specify “what”, not “how”.  “How” is part of design.  In some circumstances, however, there are design constraints such as use of a particular operating system or COTS product is required that should be included in the specification.

§         Organized into logical meaningful groups

Establish and follow a change control process:

Since stakeholders should be involved in the change control process, it is important to discuss the process early on and ensure that the roles and responsibilities of the stakeholders are clearly delineated and understood by all.  Change control is closely coupled with configuration management.  It makes sense to establish a process that can integrate with or interface with existing CM tools used on the project.

Establish and maintain key requirements attributes:

Identify the key items of information that are important for tracking the project, and making decisions as the project progresses.  At a minimum, maintain the following:

§         Unique identifier for each specific requirement

§         Type  - Logical grouping or categories that make sense for the project

§         Priority – Implementation priority relative to other requirements or a planned release (High, Med., Low)

§         Source – Origin of the requirement

§         Relationship to other requirements

§         Risk – Assessment of the risk to the project  due to the difficulty or complexity of this requirement, or its volatility

Other attributes may be identified as you progress.  It is important to choose a tool/method for tracking attributes that is sufficiently flexible to accommodate adding other attributes during the project.

For large projects support tools will be needed to track requirements and their attributes.  Here are some suggestions:

§         Establish a requirements database as a repository for requirements and their attributes

§         Store each requirement once in one place.  Reference as needed.

§         Generate requirements documents as needed from the requirements repository

§         Allow stakeholders direct selected views into the database

§         Identify and track the impact of requirements changes in terms of risk to the project

Trace requirements:

Tracing is essentially documenting the path from origin thru implementation. When trace information is maintained it provides valuable data to assist the analyst in assessing the impact to the software of changing the requirement  and vice versa.

§         Trace each requirement backward to its source or origin and forward to the downstream products which it impacts

§         Verify that the trace is accurate upon completion of each major phase

§         Verify that no requirements have been overlooked or accidentally omitted

§         Establish the trace for new candidate requirements to determine their impact as preparation for the approval or negotiation process

§         Use a requirements management tool that provides this described level of traceability

 

Characteristics of implementation:

 

Summary characteristics

Enabling Practices:           Link to Requirements Management Interrelationships Diagram

Enabled Practices:            Link to Requirements Management Interrelationships Diagram

Impact Areas:                      Quality, Risk, Technical Performance

Life Cycle Phase:               Throughout the project or program life-cycle

Scope/Authority:                Project-level

Applicability:                       Acquisition; development

Use Indicators:                   High task complexity; high number of individual disciplines involved; software-intensive acquisitions

Use Inhibitors:                    None indicated

Appropriate Programs:    Software-intensive acquisitions, maintenance or operational projects

Inappropriate Programs: Small, single product

Barriers:                               Political/cultural issues (turf, responsibility, accountability); rigid contractual agreements that freeze requirements; no access to users; inadequate resources allocated to requirements engineering

Facilitators:                          Strong leadership; RM tools; flexible contracts; iterative development approach; resources and budget allocated to requirements engineering

 

ANTICIPATED BENEFITS OF IMPLEMENTATION:

 

Successful implementation of the RM practice can result in:

§         Meeting user/customer expectations - The principal benefit derived from effective requirements management is the receipt of a product or service that adds value for the end user/customer due to a better understanding of their needs and expectations.

§         Reduced cost over the project life - Better understanding results in fewer design and construction errors, thereby lowering or eliminating costs associated with rework.

                     Improved accuracy of cost and schedule estimates for future projects - As the effectiveness of the requirements management process improves and the rework associated with faulty requirements decreases, there will be a corresponding increase in the accuracy of estimates of total life cycle cost and schedule.

§         Reduced risk – Risk associated with requirements is addressed early, often resulting in negotiating requirements trade-offs that, in turn, minimize the risk of project failure or schedule slippage.

 

Detailed characteristics

 

Key Characteristics of the “Manage Requirements” Gold Practice

Characteristic	Comments
Essential for large/complex projects	§      One high level customer requirement may translate to more than 100 detailed software requirements. Large projects have thousands of requirements. §      Interrelationships among requirements must be communicated to the development team §      RM focus is necessary to verify that requirements have in fact been met
Premised on the reality of change	§      The acquirer organization culture accepts the reality that requirements will change, and that not all requirements can be known at the start of a project §      Stakeholders realize that new requirements will emerge as knowledge is gained during development
Requirements traceability must be done	§      Sources of requirements are also the sources of requirements changes.  Backward traceability to the requirement source facilitates the identification of requirements changes.  For example, when requirement specifies compliance with a standard, if the standard changes, then the software needs to be analyzed in light of the new standard. §      Forward traceability to the downstream products that satisfy the requirement provides the data needed to more accurately estimate the impact of a requirements change
Requires skilled, experienced, trained staff	§      RM is not an administrative (paperwork) function.  It is a highly technical function and is one of the most difficult tasks of software development. §      Using skilled people ensures greater accuracy of the requirements, and more efficient (and cost effective) use of resources §      While the Project Manager (Developer) is responsible for implementing RM, it cannot be viewed as an isolated task that can be checked off as complete.  Its success depends on involving the stakeholders.
Requires a substantial allocation of budget	§      Successful projects have allocated from 10 to 30 percent of the budget for requirements engineering activities across the project life cycle.
Continues throughout the project	§      RM should be implemented throughout the life cycle of the project.  Ideally, it begins at project inception and ends with project closeout. §      RM is integral to other requirements engineering functions such as requirements elicitation, analysis, specification, and validation.  It should not be isolated from them. It may encompass them. §      The bulk of RM occurs early in the project because of all the initial planning, establishing attributes, and tracing that must be done, but it continues throughout the project to address changing requirements  and satisfying requirements
Works best when supported with tools	§      The larger or more distributed the project is, the more sophisticated the support tool needs to be.  For small projects, spreadsheets and simple databases developed in house will work, but for large projects, requirements engineering tools that integrate and/or interface with configuration management  tools are necessary. §      Tool users need to be trained in tool use in order for it to really help

 

RELATIONSHIPS TO OTHER PRACTICES:

 

The Figure below represents a high-level process architecture for the subject practice, depicting the nature of the influences on the practice (describing how othesr practices might relate to this practice). These statements are based on definitions of specific “best practices” found in the literature and the notion that the successful implementation of practices may “influence” (or are influenced by) the ability to successfully implement other practices. A brief description of these influences is included in the table below. The arrangement of the statements in the figure and the subsequent table does not imply any particular order or sequence in which they should be addressed.

Process Architecture for the "Manage Requirements" Gold Practice

 

Summary of Relationship Factors

INPUTS TO THE PRACTICE
Assess the impact of the software environment	The environment can have a positive or negative impact on managing requirements.  Organizations with a process focus are also likely to be concerned with process improvement and seeking a level of process maturity as defined by the Capability Maturity Model (CMM) for Software.  Conducting Independent Expert Reviews (IERs) and Software Capability Evaluations (SCEs) assesses the requirements engineering process.  This environment embraces requirements management as a necessary and important part of the development process.  Also, when a structured development method (iterative processes) is required, it accommodates prioritizing and allocating requirements to various iterations and, therefore, provides the structure and motivation for successful implementation of requirements management.  The Architecture-First Approach addresses establishing executable architectures to help validate requirements and verify a solution before resources are committed to full production.  This practice looks at alternative solutions at the architecture level, and it focuses on high-level requirements.  While it has a positive impact on the project as a whole, managing requirements in this scenario can be somewhat different than managing requirements in a traditional environment.
Determine how acquisition factors will affect RM	In this context, acquisition factors are those factors relating to the contracting process, and its basis.  RM is about ensuring that customer/user needs and expectations are met throughout the life of the project.  The contracting scenario may severely constrain RM or enhance it.  The acquisition process provides the motivation for the contactor to deliver a quality product on time and within budget.  When lowest bid is the primary element of source selection, combined with little consideration of requirements engineering, the chances for success are limited.  On the other hand, acquisition practices such as Use of Past Performance, Best Value Awards, and Performance based Specifications set the stage for requirements engineering and increase the likelihood of requirements management contributing to the success of the project.  Acquisition Process Improvement considers the full life cycle of a project or program and addresses alignment of the acquisition process with the goals of the program to ensure long term success.  Thus, it creates contract scenarios that can optimize the value of the requirements management practice to the project.
Investigate potential sources of requirements	Requirements elicitation involves investigating, and in some cases revisiting, potential sources of requirements.  There are many techniques for identifying or deriving requirements and changes.  The Commercial Specifications and Standards/Open Systems Approach addresses key practices that should be followed when the project is based on the open systems approach.  The selected standards drive requirements, but the standards are evolving, thus triggering changes to requirements over the life of the project.  If your project involves commercial off-the-shelf (COTS) software or non-developmental items (NDI), the need to Leverage COTS/NDI, combined with changes to COTS technology, is a continuing source of requirements change and must be managed accordingly.  A need to Ensure Interoperability also triggers changes in interoperability requirements across the life cycle of the project, as the need arises to be interoperable with new systems and/or the desired level of interoperability increases.  Integrated product teams (IPTs), that function as part of an Integrated Product and Process Development (IPPD) environment are a rich source of requirements, but the requirements engineering process is still necessary to elicit the specific requirements from this source.  IPPD facilitates RM by bringing the key stakeholders together and providing a good forum for communication.  The Goal-Question-Metric (GQM) practice is an excellent technique for identifying requirements, as well as establishing the metrics that will be later used to assess the success of implementation.
Accept the realities of change	RM is premised on accepting as fact that requirements changes will occur over the project life.  Several other Gold Practices focus on specific types of change.  Plan for Technology Insertion addresses how to preserve or improve the capability and affordability of a software system as technology changes and triggers requirements changes.  Requirements Trade-Offs/Negotiations is part of requirements engineering that occurs across the life of the project, as change requests emerge.  This practice is an important part of RM because it is used to control “requirements creep”.  RM often attaches a risk attribute to each requirement, which is used for decision-making about the priority of implementation.  When a Formal Risk Management process is used at the project level, identifying the risk or volatility of a requirement is a natural activity.  Often a project schedule and cost estimate is based on some assumptions of reuse.  When care is taken to Assess Reuse Risks and Costs, the results of such analysis provide more accurate data estimating the resources needed to complete specific requirements, and the associated risks.  Maintaining a Life-Cycle Business Case for a software system provides the justification and goals for the software.  Often the business goals change over time, necessitating requirements changes in order to ensure alignment and continuing value of the software.
Choose the right tools	Requirements drive design and testing.  Thus, it is critically important to communicate requirements changes accurately and in a timely manner.  For all but very small projects (less than 100 specific requirements), tools are necessary to support the process. In selecting tools for requirements management, consider how they must integrate with other aspects of the project and other tools.  Configuration Management addresses management and control of all project artifacts, including the artifacts of requirements engineering (requirements documents and change requests).  Model Based Testing (MBT) is about automatically generating test procedures and test cases using models of system requirements.  Consider how your RM tool might integrate with, or allow MBT, without duplicating efforts to specify requirements.  Capture Artifacts in Rigorous Model Based Notation is a practice that develops models that can be used to expedite and improve the accuracy of other aspects of project development such as design, code and testing.  It is supported by modeling tools.  In adopting this modeling approach, it is important to choose one or more tools that work together to address both the modeling effort and the requirements management effort.
OUTPUTS FROM THE PRACTICE
Monitor and report project progress	The goal of RM is to verify that customer/user needs and expectations are being met.  This should be the overall goal of the project as well.  The requirements attributes, tracked as part of the RM process, provide substantive data for monitoring and reporting project progress.  The Track Earned Value practice estimates what portion of the budget is needed for each task and then tracks the value earned for task completion as a measure of progress. RM tracks the resources estimated for each requirement.  This estimating often provides the starting point for allocating earned value to the associated tasks.  Establish Clear Goals and Decision Points is a practice that is performed early in the project, but the decision points are then used to review progress and achievement and determine the future direction of the program.  RM provides the data and the focus for the reviews, making the decision points more meaningful.  Program-Wide Visibility of Progress vs. Plan focuses on the value to the project that results from everyone knowing exactly where the project stands.  RM contributes to this practice by providing the requirements attributes data, and by emphasizing the requirements focus.
Assess requirements implementation	RM provides data to support Quantitative Progress Measurement and Statistical Process Control.  Also, the traceability of requirements to downstream products supports Demonstration-Based Reviews where design trade-offs are addressed and architectural defects eliminated early.
Establish appropriate communication about requirements	RM involves continuous communication among stakeholders about requirements both prior to and during development.  It is important for the project to provide the appropriate resources and experienced staff for RM to ensure the optimum value of the communication.  People-Aware Management Accountability addresses the allocation of appropriate staff and financial resources to requirements engineering.  Formal Inspections are applied to requirements artifacts to ensure quality of the product prior to its release for its intended use.  This is often a peer review process.

 

 

RESOURCES:

 

§         Websites

¡         International Council of Systems Engineers (INCOSE) Requirements Working Group website – addresses requirements management, requirements analysis, and requirements engineering methodology

      http://www.incose.org/practice/techactivities/semanagement/rwg.aspx

¡         Managing Requirements

      http://www.jiludwig.com/

¡         Requirements Engineering Support Process - California Health & Human Services Agency Data Center (HHSADC). Although this site specifically addresses the needs of the HHSADC, it is an excellent reference for requirements engineering in general, with many links to standards and other references. 
http://www.bestpractices.cahwnet.gov/ProjectOfficeFunctions.aspx?fid=12&pid=0

¡         Software Program Managers Network (SPMN) web site for 16 Critical Software Practices for Performance-based Management.  One of the key practices is “Manage and trace requirements”.

      http://www.spmn.com/16CSP.html#requirements

¡         Software Program Manager’s Network Lessons Learned pages (1998)

http://www.spmn.com/lessons.html#four

¡         Successful Delivery Toolkit, Office of Government Commerce (OGC), United Kingdom, has a section dedicated to requirements management

    http://www.ogc.gov.uk/sdtoolkit/reference/deliverylifecycle/reqments_mgmt.htm

 

§         Tools And Methods

There are a multitude of methods and tools that may be useful in implementing and improving the effectiveness of requirements management.  The first table in this list contains tool surveys that are being updated continually.  The second table identifies some specific tool sources.  Note that the brief descriptions of the tools presented in the second table are extracted from material published on the vendor web sites and may have a marketing flavor.

 

[The fact that a tool or tool vendor is listed (or not listed) here does not constitute an evaluation or endorsement of the product or vendor by the DACS.  These are simply links to tools currently available relative to the subject practice.]

Requirements Tool Surveys and Assessments

Survey Name	Description and URL
INCOSE  Survey of Requirements Management Tools	The INCOSE Requirements Management Working Group (RMWG), developed a set of requirements for RM tools, and has surveyed the tool vendors asking them how they felt they stacked up against the requirements.  Actual vendor responses are presented in the survey and results are updated frequently (most recent updates are from 2002). http://www.paper-review.com/tools/rms/read.php
RM Tool Market Survey, February 2000	Although the tool information may be somewhat outdated by now, this reference is included because it contains a comprehensive list of requirements for RM tools, developed by a Process Action Team within the California Health and Human Services Agency Data Center (HHSDC).  Requirements are categorized and prioritized according to the needs of that organization.  Most of the tools assessed have updated versions which may have more capabilities. http://www.goldpractices.com/practices/rto/RM_Tool_Market_Survey.pdf
RM Tools: A Quantitative Assessment,  Virginia Tech.,2003	This document provides an assessment of tool capabilities relative to RM, in addition to listing available tools. http://eprints.cs.vt.edu:8000/archive/00000658/01/RM_Tools.pdf

 

Requirements Engineering Tools

Tool Name & Vendor	Description and URL
Telelogic DOORS	A multi-platform, enterprise-wide system designed to capture, link, trace, analyze and manage changes to information to ensure a project's compliance to specified requirements and standards. http://www.telelogic.com/products/doorsers/doors/
AnalystPro by Goda	A tool with the capability to perform most functions associated with requirements management.  http://www.analysttool.com/
Focalpoint Requirements Management  Tool	Provides support for all work with requirements, from collecting to handling, prioritization, planning, follow-up and testing. http://www.focalpointus.com/products/sol/requ.htm
Rational (now partnered with IBM)	Provides a suite of tools that can be used for requirements development and management, and visual modeling tools that can be used to represent an architecture. http://www-306.ibm.com/software/rational/offerings/reqanalysis.html
TrueReq by TrueReq, Inc	Designed to facilitate collaboration and increase communication, TRUEreq is a web-based product lifecycle management (PLM) application.  With TRUEreq, development teams can manage requirements internally and/or across distributed organizations, helping your company build successful, timely and cost-effective products. http://www.truereq.com/
Catalyze by SteelTrace, Inc.	The Catalyze suite of products provides an approach for organizations to quickly and easily capture business and system requirements, bridging the business-technical divide.  The vendor claims that Catalyze yields a 40% per project ROI involving minimal deployment time. Unlike traditional Requirements Management tools, Catalyze takes a more structured view of requirements, breaking them into Functional (in the form of a use case-like storyboard structure of main flow, alternative flows etc.) and Non-functional requirements (qualities and constraints). http://steeltrace.com/products_catalyze_suite.htm
Livespecs Software, Inc.	Provides techniques for writing clear requirements. http://www.livespecs.com/
UGS Corp. Teamcenter Requirements	Teamcenter Requirements delivers product requirements to all of the entitled users who participate in your product lifecycle.  It brings your customers directly into your extended enterprise and reflects their concerns from the start of your product lifecycle to its conclusion. http://www.ugs.com/products/teamcenter/sol_prod/requirements/

 

§         Experts And Contact Points

 

¡         Walker Royce, Vice President and General Manager at Rational Software Corporation, has led Rational in developing the Rational Unified Process for requirements.

      See http://rational.com/

  

¡         Karl Wiegers, Principal Consultant with Process Impact of Portland, Oregon, has authored several books and articles on requirements engineering, and more specifically requirements management.

kwiegers@acm.org

      http://www.processimpact.com/bio.shtml

 

¡         Donald Reifer, Reifer Consultants, Inc., is one of the leading figures in the field of software engineering and management with over 30 years of progressive experience in both industry and government.

P.O. Box 4046
Torrance, Ca 90510-4046
Phone: (310) 530-4493
Fax: (310) 530-4297
info@reifer.com

 

§         Training

In the interest of keeping the document manageable, the following types of training have not been included:

§         Pure consulting services

§         Training courses primarily based/offered outside of the continental US.

§         Courses focused on broader areas with requirements engineering as a component

§         Tool–specific training courses

Many of the vendors offer a virtual classroom alternative to the traditional classroom training, and many also offer on-site training opportunities.  Click on the links provided to get this type of information.

Training Opportunities

Vendor	Course Description and URL
Advanced Managerial Services, Inc.	AMS142 - Requirements Management:  An In Depth View This 2-day seminar is for experienced Project Managers and Business Analysts who wish to acquaint themselves with all aspects of requirements, from concept through closeout.  Participants will learn practices for requirements management, including proper selection of tools and techniques for specific types of projects.   Stakeholder management and evaluation techniques to verify requirements early in the project life cycle will be key focal areas of this course. http://www.amsconsulting.com/OLreqsindepth.htm
Beggs-Heidt	Requirements Management Rapid Adoption Program This training service features facilitated workshops and mentoring activities that 'jump start' your team's ability to elicit, document, and trace requirements through the project life-cycle.  The workshops and activities focus on five requirements disciplines. http://www.beggsheidt.com/programs/requirements.asp
Borland	Training:  Karl Wiegers' "In Search of Excellent Requirements" The 1-day course focuses on defining and managing requirements in the context of an application development lifecycle.  A series of integrated requirement specification exercises illustrate the progression of an idea from concept to code. http://www.borland.com/services/training/courses/pdf/ WW_TI_Karl_Wiegers_InSearchOfBetterRequirements.pdf
Cardinal	Requirements Management with Use Cases This 1-day seminar provides an overview of requirements management using the Use Case technique. The first part of the seminar demonstrates, by example, the key artifacts involved in Requirements Management.  The second part of the seminar describes an effective process to effectively write and manage requirements, with an interactive activity that focuses specifically on use case development. http://www.cardinalsolutions.com/Training/Master_Course_Guide.pdf
Carolla Development, Inc.	Requirements Management: Collection, Analysis, and Validation: 2-day course Through a combination of group projects and lecture, students gain an understanding of how to elicit, analyze, and manage requirements to realistically speed time to market and to reduce cycle times and expense. http://www.carolla.com/C1203Q.htm
CDI Education Corp.	Requirements Management: A Key to Project Success This 3-day course addresses: ·         Applying a requirements management process to a project life cycle ·         Developing and gaining agreement on requirements that meet specific business objectives ·         Identifying formal and informal techniques to manage customer relationships within the requirements management process ·         Implementing a change management process to control scope creep http://www.cdilearn.com/corporate/outlines.nsf/weboutlines/PM84?OpenDocument& VLP=Project%20Management&VLP=CDI
Compliance Automation, Inc.	SIN 874-4 Training Services under a GSA Contract CAI provides a suite of training services that cover writing and managing requirements across a project life cycle. http://www.complianceautomation.com/GSA/training.htm
Construx	Requirements Boot Camp This 3-day course presents practical techniques for exploring user needs, capturing requirements, controlling changes, and building highly satisfactory software.  It explains how leading edge companies use requirements engineering to support successful software projects.  Through a mix of lecture, discussion and exercises, attendees will learn many useful requirements engineering practices. http://www.construx.com/training/courses/RealWorldReqs3Day.php
Dashcourses Inc.	Requirements Management & Use Cases This 2-day course is an introduction to management of requirements in software projects. http://dashcourses.com/courses/OOP/RMaUC.shtml
Defense Finance Accounting Service, 1997	Systems Modification Scenario Requirements Management Training Class: This briefing focuses on RM in an environment where existing systems are being maintained and updated. http://www.dfas.mil/technology/pal/spipgmdc/spi-educ/rm.ppt
Ennis Information Age Services	Usability Training: Requirements Management A 2-day course that defines the process for managing requirements from elicitation through implementation. http://www.eias.ie/aaa/usability_training_requirements_management.htm#1
ESI International	Requirements Management : A Key to Project Success This course takes the experienced project manager beyond the basics of all aspects of requirements, from concept through closeout.  Participants will learn up-to-date practices for requirements management, including proper selection of tools and techniques for specific types of projects http://www.esi-intl.com/Register/course.asp?coursecode=PMC-CVG
Global Knowledge	Requirements Development and Management This 4-day course provides the necessary foundation and understanding for developing effective requirements, moving from business objectives, through business and end-user requirements, through system and software requirements.  The course provides a logical, generic methodology for the requirements process, as well as needed skills to perform effective interviews and group workshops. http://www.globalknowledge.com/training/course.asp?pageid=9&courseid=8107 &catid=408&methodid=c&country=United+States&translation=English
IBM	REQ480: Mastering Requirements Management with Use Cases Provides three days of training in requirements management and use-case modeling techniques. http://www-306.ibm.com/services/learning/ites.wss/us/en? pageType=course_description&courseCode=RR611
Iconmedialab	Unique Requirements Discipline (focusing on the Rational Unified Process) A set of training courses that goes far beyond basic use case instruction.  You will examine advanced issues such as defining complex business rules, selecting a use case style (informal, formal, or essential), specifying steps and data, and handling iteration and concurrency. http://training.iconmedialab.us/requirements.php
InferData	Mastering Use Cases and Requirements Management This 3-day course provides practical, hands on training for roles involved in writing use cases and supplementary specifications.  The course begins with the context of requirements in the development process, explores best practices of requirements management, and teaches participants how to write high quality use cases and supplementary specifications. http://www.inferdata.com/training/ooad/manageReqs.html
Integrated Chipware	Customized courses in requirements management ranging from a few hours to a few days. http://www.chipware.com/content/rtm/trn_ov.PDF
Integrated Computer Engineering	1 Day Course – Requirements Management This course examines key elements of the Software Requirements Management program and identifies pitfalls where many programs have failed.  It presents the techniques that have proved successful in real-world programs, methods for implementing them and strategies for determining if the techniques are being effectively implemented. http://www.iceincusa.com/training_reqmts.htm
International Institute for Learning	Requirements Management e-learning course conducted over four 3-hour sessions as part of an Advanced Project Management Certificate Poor requirements definition and lack of adequate change control procedures to requirements and scope are the primary contributors to project difficulty and failure.  This workshop will provide you with the knowledge, tools and techniques required to minimize or avoid these pitfalls. http://www.iil.com/str_link_all_results.asp?select_cartid=537&ld=APMC
Learning Tree	Identifying and Confirming User Requirements In a case study-based series of workshops you will learn how to ·            Implement a step-by-step business and user requirements development methodology ·            Write well-formed and accurate requirements within the IEEE framework ·            Elicit and organize requirements information to set and manage stakeholder expectations ·            Analyze and derive requirements to keep the project focused on the desired results ·            Develop requirements documentation to accurately target the problem domain ·            Apply techniques to thoroughly validate, confirm and manage project requirements http://www.learningtree.com/courses/315.htm
Numbersix	Offers training and momentum services in requirements management http://www.numbersix.com/v3/solutions/trainingmomentum2.html
Object Knowledge	Requirements Modeling & Analysis with Use Cases This 3-day workshop will provide your team with the practical skills necessary to effectively and efficiently capture, model and analyze user-centric requirements with Use Cases. http://www.objectknowledge.com/Requirements_Modeling_Analysis_main.htm
PESG, Inc.	Training for Better Requirements A series of  seminars and curriculum components offered at various times and places throughout the USA, addressing critical aspects of effective requirements definition, requirements validation, requirements management and key soft skills for requirements scenarios http://www.pesg.com/requirementstraining/
Process Focus Management	Requirements Management Training This is a three-day workshop designed to help you manage constantly changing software requirements.  Specifically geared toward getting to CMMI level 2. http://www.processfm.com/requirements.html
Process Improvement Associates	Requirements Management This course provides a comprehensive view of the requirements management process, from customer requirements to final acceptance testing.  We present a step-by-step approach, emphasizing best-practices, methods, and tools currently used by world-class organizations. http://www.processimprovement.com/courses/RM.htm
Project Management Leadership Group	Requirements Management This 1-day course will prepare students to conduct effective requirements planning sessions and to be able to control scope and configuration changes throughout the lifecycle of the project. http://www.pmlg.com/requirementsmanagement.shtml
Software Productivity Center, Inc.	In Search of Excellent Requirements This two-day workshop, based on Karl Wiegers' book Software Requirements (Microsoft Press 1999), will provide attendees with a tool-kit of practices, reinforced with practice sessions and group discussions, which immediately can be used to improve the quality of requirements development and management in any organization. http://www.spc.ca/training/public/requmnts.htm
Software Productivity Consortium	Introduction to a Disciplined Requirements Process This 3-day course provides a foundation in sound requirements principles which can help reduce the risk of project overrun or failure.  The strategic purposes of the course are to: §         Provide an introductory level foundation in sound requirements principles §         Help organizations (primarily Level 1) establish a disciplined requirements process §         Help organizations (primarily Level 2) seeking to improve their existing requirements process The tactical purpose of the course is to provide a generic requirements process that an organization can tailor for use. http://www.software.org/pub/training/course.asp?id=1140
TeraQuest	Requirements Management Workshop This workshop provides a foundation for building a requirements management capability that is compliant with the maturity models of the SEI.  The course begins with an in-depth study of the Requirements Management key process area (KPA) of the CMM framework. http://www.teraquest.com/training/courses/Requirements%20Mgt%20Workshop.pdf
TriReme International, LTD	Requirements Engineering 2-day course in requirements engineering, with a focus on Universal Modeling Language (UML) http://www.trireme.com/custom_solutions/training/courses/requirements_engineering_syllabus.html
Web Age Solutions, Inc.	WA1105 Requirements Management and Use Cases   This 2-day course is an introduction to management of requirements in software projects.  It starts by introducing the concepts and is ideal for someone who is going to be involved in the requirements management phase of a software project. http://www.webagesolutions.com/training/oop/wa1105/

 

 

§         Bibliography

 

APPENDICES

 

DEFINITIONS:

 

Requirements Management

The process of eliciting, documenting, organizing, and tracking changing requirements and communicating this information across the project team to ensure that iterative and unanticipated changes are maintained throughout the project lifecycle[Davis, 1999]

Monitoring status and controlling changes to the requirements baseline.  Primary elements are change control and traceability.  It begins when a requirements baseline has been set and continues through development, maintenance and operations, ending when the system is retired or the project closed out. [CA HHSADC, 2003]                                          

Spans the whole software life cycle.  Fundamentally addresses change management and the maintenance of requirements in a state that accurately mirrors the software to be, or that has been built.  [SWEBOK, 2001]

The process of controlling the content and scope of a system through its requirements;  Includes creation and management of the baseline, change and version control of requirements, and traceability of requirements to implementation and verification. [CA HHSADC, 2003]

The planning and controlling of the requirements elicitation, specification, analysis and verification activities [Sud, 2003]

 

Ensures that changes to requirements are reflected in project plans, activities, and work products.  This cycle of changes may impact all the other Engineering process areas; thus requirements management is a dynamic and often recursive sequence of events.   Establishment and maintenance of the Requirements Management process area is fundamental to a controlled and disciplined engineering design process. [CMU/SEI-2002-TR-012]

 

 

SOURCES (Origins of the Practice):

 

Although defining requirements has existed as part of the software life cycle since the 70s, the focus on managing requirements did not develop until the mid 90s when the Software Program Managers Network identified it as one of their 16 critical practices.  [SPMN, 1998]

 

RECOMMENDING SOURCES:

[This section identifies segments from specific DoD, industry, or academic sources that recommend, specify or otherwise support adoption of the subject practice either directly, or as part of a broader best practice initiative, or a practice with a different name.]

§        Interim Defense Acquisition Guidebook, 30 October 2002 [INTERIM 2002]

Although it does not specifically use the term manage requirements, it essentially directs that activities be done that are comparable to managing requirements.

§        Capability Maturity Model Integration (CMMI), Version 1.1, Software Engineering Institute, CMU/SEI-2002-TR-011, TR-012, March 2002[CMU/SEI-2002-TR-011], [CMU/SEI-2002-TR-012] 

The CMMI identifies requirements management as a key process area (KPA) that must be achieved by organizations desiring to be certified at level 2 on the 5-level CMM scale.

 

§       GAO Report on Defense Acquisitions, March 2004 [GAO, 2004]

The consensus of this report was that stronger management practices are needed to improve DoD’s software-intensive weapons programs. The report goes on to state that the success (quality software product, on time and within budget) of leading software companies is attributable to creating a manageable evolutionary development environment, using disciplined processes, and useful metrics such as earned value. A great deal of management attention is placed on the requirements-setting phase because missing, vague, or changing requirements tend to be the major cause of poor software development outcomes.

 

GLOSSARY:

 

CASE STUDIES from the literature:

Software Requirements: When Theory Meets Practice
by Suresh Subramanian and Philip Wong, PRTM

Published as a feature article in Software Business Online, April 2004

http://www.softwarebusinessonline.com/newsletter2_april04.htm

Description:

This case study illustrates how one software organization achieved significant improvements in software product development costs and effectiveness by putting in place key business process elements that tie together proven requirements techniques.  For the company's 200-person software organization, the Requirements Definition and Management (RDM) process took about six months to develop and pilot. While the full launch of the new process is still underway, initial results have been promising:

Results:

§         Less development churn, reflected in a 30% decrease in change controls

§         Estimated annual cost savings of $200,000 per product release

§         Additional intangible benefits-products that better meet client needs, closer involvement of internal and external stakeholders in product development

 

Requirements Engineering as a Success Factor in Software Projects

By Hubert F. Hoffman, General Motors, and  Franz Lehner, University of Regensburg, IEEE Software, July/August 2001

 

Description:

Getting requirements right might be the single most important and difficult part of a software project.  This study was conducted to identify the RE practices that clearly contribute to software project success.  It investigated team knowledge, allocated resources, and deployed RE processes. Fifteen RE teams from 9 development organizations in the telecommunications and baking industries participated in the study.  Targeted projects were recently released critical business applications.  On average, the projects finished in 16.5 months with an expended effort of 120 person-months.

Results:

Successful projects have the right combination of knowledge, resources, and process.  Best practices resulting from the study are as follows:

 

Focus Area	Best Practice	Benefit
Knowledge	§     Involve customers and users throughout RE §     Identify and consult all likely sources of requirements §     Assign skilled project managers and team members to RE activities	§     Better understanding of “real needs” §     Improved requirements coverage §     More predictable performance
Resources	§     Allocate 15 to 30 percent of total project effort to RE activities §     Provide specification templates and examples §     Maintain good relationships among stakeholders	§     Maintain high-quality specification throughout the project §     Improved quality of specification §     Better satisfy customer needs
Process	§     Prioritize requirements §     Develop complementary models together with prototypes §     Maintain a traceability matrix §     Use peer reviews, scenarios, and walk-throughs to validate and verify requirements	§     Focus attention on the most important customer needs §     Eliminates specification ambiguities and inconsistencies §     Explicit link between requirements and work products §     More accurate specification and higher customer satisfaction