Requirements management

Requirements management is the science and art of gathering and managing user, business, technical, functional requirements, and process requirements within a product development project. The project could be for a new consumer product, a web site, a system or a software application. In all these cases, the five classes of requirements should be represented. If they are not, the project will suffer user or consumer rejection to some degree. (From here, we'll say 'user' for simplicity. But the rules apply even if the tool is a new type of hammer rather than a software application.)

Introduction Starts

There are several classes of requirements.

Users' requirements list the tasks and goals of the user or consumer. User requirements are intended to make the tool or product easier to use, faster, less error prone, and even a bit fun. User requirements are separated from other requirements to provide clarity and a focus on user experience. Under obsolete requirements classifications the inclusion of user requirements in other requirements has resulted in poor user experiences and, in extreme cases, the rejection of the application or product.

Business requirements list the goals of the business. At the highest level, these goals are to increase revenue, decrease costs, improve data management, increase knowledge transfer, improve efficiency, and so on. For example, an internal software application is made only when someone in the business recognizes a need for a better-than-current system or process and implements a project to fill that need.

Functional requirements specify the specific transformations of inputs to outputs that the system or software is required to perform. Functional requirements are usually derived from the user and business requirements

Non-functional requirements (aka,technical requirements) specify the qualities that the product must possess. Non-functional requirements are things such as security, compatibility with existing systems, performance requirements, etc. The non-functional requirements include answers to the question "How well" the system must perform the functional requirements (how fast, how accurate, how reliable, how user-friendly, how precise, etc.). The non-functional requirements are often called the "illities" because many of them address such qualities as scalability, reliability, availability, survivability, usability, teachability, maintainability, etc.

Process requirements specify the limitations on the development processes, methods, techniques that are allowed to be used in the construction of the target system or software. In a product manufacturing example, some process requirements would be manufacturing requirements, or the conditions, processes, materials, and tools required to get the product from the design board to the shipping dock.

With those definitions in mind, we can see that requirements management is all about balance, communication, and adjustment along the way. The key to successful requirements management is balance. To prevent one class of requirements from over-riding 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.

Typically, however, use cases describe a desired set of actions and fail to take into account whether those actions are reasonable given the user’s environment, skill level, preferred task execution style, ergonomic or physiological conditions, and other such “human” conditions. Thus, tracking user requirements as a separate class helps ensure that user needs do not get ignored.

Stages of development

At each stage in a development process, there are key requirements management activities and methods. Suppose that a standard five-phase development process is used. Let’s call these stages Investigation, Feasibility, Design, Construction and Test, and Release.

Investigation

In Investigation, the first three classes of requirements are gathered from the users, from the business, and from the 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.

A caveat is required here: no matter how hard a team tries, 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 work affect the project in mid-cycle. Thus, the team members must agree at the outset that a prime condition for success is flexibility in thinking and operation.

The deliverable from the Analysis stage is a requirements document that has been approved by all members of the team. Later, in the thick of development, this document 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 many organizations still use only documents to manage requirements, others manage their requirements baselines using software tools. These tools allow requirements to be managed in a database, and usually have functions to automate traceability (e.g., by allowing electronic links to be created between parent and child requirements, or between test cases and requirements); 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, costs of the requirements are determined. For user requirements, the current cost of work is compared to the future projected costs once the new system is in place. Questions such as these are asked: “What are data entry errors costing us now?” Or “What is the cost of scrap due to operator error with the current interface?” Actually, the need for the new tool is often recognized as these questions come to the attention of financial people in the organization.

Business costs would include, “What department has the budget for this?” “What is the expected rate of return on the new product in the market place?” “What’s the internal rate of return in reducing costs of training and support if we make a new, easier-to-use system?”

Technical costs 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.

The question also points out 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 processing. The overarching goal of the requirements management effort for a software project would thus be to make sure the work being automated gets assigned to the proper processor. For instance, “Don’t make the human remember where she is in the interface. Make the interface report the human’s location in the system at all times.” 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

Assuming that costs are accurately determined and benefits 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 design against the requirements document to make sure that work is staying in scope.

Again, flexibility is paramount to success. Here’s a classic story of scope change in mid-stream that actually worked well. Ford auto designers in the early ‘80s were expecting gasoline prices to hit $3.18 per gallon by the end of the decade. Midway through the design of the Ford Taurus, prices had centered to around $1.50 a gallon. The design team decided they could build a larger, more comfortable, and more powerful car if the gas prices stayed low, so they redesigned the car. The Taurus launch set nationwide sales records when the new car came out, primarily because it was so roomy and comfortable to drive.

In most cases, however, departing from the original requirements to that degree does not work. So the requirements document becomes a critical tool that helps the team make decisions about design changes.

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. This saves their time and makes their jobs much easier.

Release

You might think that requirements management ends on product release, but that’s not entirely accurate. 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.

Tools

Requirements Management tools can be split up into hosted and non-hosted tools. The traditional non-hosted tools include Borland® Caliber® Analyst, Telelogic's DOORS, IBM's Requisite Pro,Geensys's REQTIFY, TechnoSolutions TopTeam, or Accord's ReMa or Goda Software's Analyst Real Team System (ARTS). They are software that is installed and implemented in a local environment. Some of these tools allow local or global team collaboration.

However, hosted tools such as GatherSpace.com don't require a business to purchase or install any software. It operates as a SAAS (software as a service) where the purchaser/user uses the software through their browser.

Another tool that assists businesses undertake Requirements Management is the Bi-Directional Requirements Gathering Mesh Topology developed by Nathan Hill in the late 1990s. This tool helps organizations define and build relationships between areas of their businesses to ensure all engineering requirements are accurately captured and mapped to business processes.

Relevant Links:

Incose Requirements Tools Survey

Modeling Languages

The system engineering modeling language SysML incorporates a requirements diagram allowing the developer to graphically organize, manage, and trace requirements.