User:Halebama/Requirements management

Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements. It administers changes to the agreed requirements, relationships between requirements and dependencies between the requirements document as well as other documents produced during the entire development process of Requirements Engineering. Effective requirements management reduces the expectation gap by keeping all project stakeholders informed about the current state of the requirements throughout the development process. It lets you know where you’re headed, how the trip is going, and when you’ve arrived at your destination.

Overview
The purpose of requirements management is to ensure that an organization documents, verifies, and meets the needs and expectations of its customers and internal or external stakeholders. Requirements management begins with the analysis and elicitation of the objectives and constraints of the organization. It also includes supporting the planning for requirements, integrating requirements, and arranging the requirements for working with the attributes, as well as managing relationships with information against these requirements and handling changes for these.

The traceability thus established is used in managing requirements to report back fulfillment of company and stakeholder interests in terms of compliance, completeness, coverage, and consistency. Traceabilities also support change management as part of requirements management in understanding the impacts of changes through requirements or other related elements (e.g., functional impacts through relations to functional architecture), and facilitating introducing these changes.

Requirements management involves communication between the project team members and stakeholders, and adjustment to requirements changes throughout the course of the project. To prevent one class of requirements from overriding another, constant communication among members of the development team is critical. For example, in software development for internal applications, the business has such strong needs that it may ignore user requirements, or believe that in creating use cases, the user requirements are being taken care of.

Traceability
Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of each requirement and every change made to the requirement should therefore be documented in order to achieve traceability. Even the use of the requirement after the implemented features have been deployed and used should be traceable.

Requirements come from different sources, like the business person ordering the product, the marketing manager and the actual user. These people all have different requirements for the product. Using requirements traceability, an implemented feature can be traced back to the person or group that wanted it during the requirements elicitation. This can, for example, be used during the development process to prioritize the requirement, determining how valuable the requirement is to a specific user. It can also be used after the deployment when user studies show that a feature is not used, to see why it was required in the first place.

Requirements activities
Requirements management is a continuous process throughout the project lifecycle and at each stage in a development process, there are key requirements management activities and methods that are relatable to that phase. Although many development processes may have similar stages with similar deliverables, few are identical. To illustrate, consider a standard five-phase development process with Investigation, Feasibility, Design, Construction and Test, and Release phase.

Investigation
In Investigation stage, the Architectural, Business and User requirements are gathered. These are gathered from the users, business and development team. In each area, similar questions are asked; what are the goals, what are the constraints, what are the current tools or processes in place, and so on. Only when these requirements are well understood can functional requirements be developed.

In the common case, requirements cannot be fully defined at the beginning of the project. Some requirements will change, either because they simply weren’t extracted, or because internal or external forces at work affect the project in mid-cycle.

The deliverable from the Investigation stage is a documentation of the requirements that have been approved by all members of the team. Later, in the thick of development, this documentation will be critical in preventing scope creep or unnecessary changes. As the system develops, each new feature opens a world of new possibilities, so the requirements specification anchors the team to the original vision and permits a controlled discussion of scope change.

While some organizations still use only documents to manage requirements, others manage their requirements baselines using software tools. The requirements of these tools are mainly that they allow requirements to be managed in a database, and usually have functions to automate traceability (e.g., by enforcing the creation or change of certain links upon the creation or change of a requirement), electronic baseline creation, version control, and change management. Usually such tools contain an export function that allows a specification document to be created by exporting the requirements data into a standard document application.

Feasibility
In the Feasibility stage, the costs of the requirements are determined, the project manager and stakeholders must ensure that the project is economically viable. For user requirements, the current cost of work is compared to the projected costs of the new system is in place. These costs include the cost that comes with errors within the current system. It is these costs that usually trigger the need for a new tool to solve those errors.

Other costs include: Business costs, all costs made in operating the business, for some examples “What department has the budget for this?” “What is the expected rate of return on the new product in the marketplace?” “What’s the internal rate of return in reducing costs of training and support if we make a new, easier-to-use system?”

Then there are the Technical costs which are related to software development costs and hardware costs. “Do we have the right people to create the tool?” “Do we need new equipment to support expanded software roles?” This last question is an important type. The team must inquire into whether the newest automated tools will add sufficient processing power to shift some of the burden from the user to the system, in order to save people time.

This a fundamental point about requirements management. A human and a tool form a system, and this realization is especially important if the tool is a computer or a new application on a computer. The human mind excels in parallel processing and interpretation of trends with insufficient data. The CPU excels in serial processing and accurate mathematical computation. The overarching goal of the requirements management effort for a software project would thus be to make sure the work being automated will be assigned to the proper processor. For instance, “Don’t make the human remember where she is in the interface. Make the interface always report the human’s location in the system.” Or “Don’t make the human enter the same data in two screens. Make the system store the data and fill in the second screen as needed.”

The deliverable from the Feasibility stage is the budget and schedule for the project.

Design
Once the costs are accurately determined and the benefits which are expected to be gained are sufficiently large, the project can proceed to the Design stage. In Design, the main requirements management activity is comparing the results of the work in progress against the requirements document to make sure that work is staying in scope. Changes in requirements are part of the design process as it is impossible to completely identify all the requirements during the early phases of the design process. Changes to the requirements can come from all stakeholders in this phase, or from outside forces such as new laws or other legal changes.

The requirements document becomes a critical tool that helps the team make decisions about design changes. To complete the requirements step of the design process, you should write a design brief; a document that holds all of the key information for solving the design problem in one place

Construction and test
In the construction and testing stage, the main activity of requirements management is to make sure that work and cost stay within schedule and budget, and that the emerging tool does in fact meet requirements. A main tool used in this stage is prototype construction and iterative testing. For a software application, the user interface can be created on paper and tested with potential users while the framework of the software is being built. Results of these tests are recorded in a user interface design guide and handed off to the design team when they are ready to develop the interface. The results end up providing an improvement in the workflow of the design team

An important part of the construction and testing stage is verification: This effort verifies that the requirement has been implemented correctly. There are 4 methods of verification: analysis, inspection, testing, and demonstration. Software execution results or through-put on a network test, for example, provides analytical evidence that the requirement has been met. Inspection of vendor documentation or specification sheets also verifies requirements. Actually testing or demonstrating the software in a lab environment also verifies the requirements: a test type of verification will occur when test equipment not normally part of the lab (or system under test) is used. Comprehensive test procedures which outline the steps and their expected results clearly identify what is to be seen as a result of performing the step. After the step or set of steps is completed the last step's expected result will present what has been seen and then identify what requirement or requirements have been verified (identified by number). The requirement number, title and verbiage are tied together in another location in the test document.

During the construction and testing stage the requirements are often adjusted and refined as new insights are gained and as such it remains important to document these changes.

Release
Requirements management does not end with product release. From that point on, the data coming in about the application’s acceptability is gathered and fed into the Investigation phase of the next generation or release. Thus the process begins again.

Requirement change management
A big part of Requirement Management is the ability to adapt to changes. The changes can stem from changes in the environment in which the finished product is envisaged to be used, business changes, regulation changes, errors in the original definition of requirements, limitations in technology, changes in the security environment and so on. The activities of requirements change management include receiving the change requests from the stakeholders, recording the received change requests, analyzing and determining the desirability and process of implementation, implementation of the change request, quality assurance for the implementation and closing the change request. Then the data of change requests will be compiled, analyzed and appropriate metrics are derived and dovetailed into the organizational knowledge repository. One thing to look out for during the entire process is Scope creep, if requirements keep changing and the project manager does not control them, the project gets in danger of becoming too big for its intended purpose.

Tooling
Acquiring a tool to support requirements management is no trivial matter and it needs to be undertaken as part of a broader process improvement initiative. It has long been a perception that a tool, once acquired and installed on a project, can address all of its requirements management-related needs. However, the purchase or development of a tool to support requirements management can be a costly decision. Organizations may get burdened with expensive support contracts, disproportionate effort can get misdirected towards learning to use the tool and configuring it to address particular needs, and inappropriate use that can lead to erroneous decisions. Organizations should follow an incremental process to make decisions about tools to support their particular needs from within the wider context of their development process and tooling. The page List of requirements engineering tools contains an overview of requirement engineering tools and their capabilities, including their support of requirements management.