Requirements; They Can Make or Break a Project

Written by Richard Frederick on November 24, 2009. Posted in Articles.

Every project an organization undertakes has requirements. It doesn’t matter if it’s building hardware solutions, developing software solutions, installing networks, protecting data, or training users – for the project to be a success, knowing what the requirements are is an absolute must.

Requirements exist for virtually any components of a project or task. For example, a project may require specific methods, expertise levels of personnel, or the format of deliverables. This article will discuss the various kinds of information technology requirements, their importance, the different requirement types, the concept of requirements engineering and the process for gathering requirements.

It’s an area that every business analyst is very familiar with but, to paraphrase an old saying, “familiarity sometimes breeds contempt” so it’s well worth taking the time to look back on what requirements are all about and how we’ve been handling them since we first learned about them. Let’s get back to some basics.

What Are Requirements?

The IEEE Standard 1233-1998, IEEE Guide for Developing System Requirements Specifications, defines a well-formed requirement as a statement that:

States system functionality (a Capability)
Can be validated
Must be met or possessed by a system
Solves a customer problem
Achieves a customer objective
Is qualified by measurable Conditions and bounded by Constraints

Specifically, a well-formed requirement should contain:

Capability
Condition(s)
Constraint(s)

According to the Oxford American Dictionary:

Capability as a noun is defined as the capability of doing something; or a power or ability, e.g, “the capability of bringing the best out in people” or “the capability to increase productivity.” However, when used with an adjective, a capability describes a facility on a computer for performing specific tasks, e.g., “the computer has a graphics capability.”

Condition as a noun is defined as the state of something, especially with regard to its appearance, quality, or working order, e.g., “the wiring is in good condition,” or “the bridge is in an extremely dangerous condition.” A condition can also be a state of affairs that must exist or be brought about before something else is possible or permitted, e.g., “for a member to borrow money, three conditions have to be met,” or “all personnel should comply with this policy as a condition of employment,” or “I’ll accept your offer on one condition.”

Constraint as a noun is defined as a limitation or restriction, e.g., “the availability of water is the main constraint on food production” or “time constraints make it impossible to do everything.”

Wherever There are People, There are Problems.

Different institutions are created to solve these unique, large-scale problems: government, healthcare, transportation, telecommunications, etc. These institutions, utilizing a “systems approach” for planning, organizing, and controlling resources, initiate projects to focus on “specific objectives” or components of their problems.

Importance of Requirements

Requirements are the documented needs of a project that are gathered to identify the specific constraints (scope) of each project component and act as the foundation for everything else that occurs in a project.

Project Failure

Requirements are considered by many experts to be the major reason projects do not achieve the triple constraint of “on-time, on-budget, and high quality.” Very few projects do an effective job of identifying and carrying through the project and all the requirements correctly.

Various studies have shown that failure to meet requirements is the biggest problem in projects. Most defects occur during the requirements phase. Project teams need to do a much better job on requirements if they wish to develop quality projects on-time and on-budget.

The Problem

Since the invention of computers, there have been three primary issues to meeting project requirements.

First, the technology learning curve is advancing much faster than the business learning curve. In other words, while technology concepts are changing rapidly, business management concepts have not changed at the same pace.

Second, there is a huge disconnect in the language between business people and technology people. Each group has its own taxonomy (glossary) for how to operate.

Third, because businesses are so reliant on technology, it is more important than ever that the two environments align to insure that the systems being built match the requirements of the business needs.

Alignment

An institution’s ability to efficiently align resources and business activities with strategic objectives can mean the difference between succeeding and just surviving.

The world is cut-throat. To achieve strategic alignment, institutions are “projectizing” their business to monitor performance more closely and make better business decisions about their overall work portfolio.

Governance

Because of errors and omissions on the part of institutions in the public trust, (e.g., government agencies and publicly held corporations) the U.S. Congress has passed legislation to require transparency throughout organizations to eliminate opportunities for fraud.

Transparency is the ability of an institution’s governing body to see through the organization. The way to see through an organization is by documenting – creating a paper-trail – all of the transactions that occur. Today, institutions utilize their information systems and IT departments to insure that the electronic paper-trail exists and is working correctly.

The costs of non-compliance are very large and can include incarceration for the institution’s executives. However, the benefits to be derived from transparency should be the dream of every executive; transparency will bring about the ultimate goal of executives having access to “any data, on any part of the business, from anywhere, and at any time.”

Re-Work

Due to the “time value of money,” all institutions must put their financial resources to work. If there are errors in requirements, they increase the need for re-work and decrease an institution’s operational efficiency. This works against every institution’s goal of managing for value.

Therefore, the earlier requirements problems are found, the less expensive they are to fix. The best time to fix them is when you are involved in gathering, understanding, and documenting them with your stakeholders (who should be the source of your project requirements).

The Challenge

The requirements phase is considered by many experts to be the most difficult part of any project. The hardest requirements problems to fix are those that are omitted.

This really becomes the requirements analyst’s dilemma. The analyst often does not know what questions to ask, and the stakeholder does not know what information the analyst needs. Since the analyst doesn’t ask, the stakeholder doesn’t state requirements.

Types of Requirements

Business Objectives

The overall business goals and guidelines for the project are the business objectives. Business objectives help provide the foundation for a project and are obtained normally from management or from existing company documents. For example: Company XYZ will increase sales domestically by 50 percent within two years.

Business Requirements

Requirements from stakeholders are business requirements. These requirements can include business processes the system needs to support; various constraints such as cost, resources, schedule; and more.

Business requirements often come from managers, although workflow processes (how people do their jobs or should do their job, if you are trying to optimize business processes) will probably come from those actually doing the work or end-users of the system.

Stakeholder Requirements

A stakeholder is anyone with a vested or substantive interest in the project. Stakeholder requirements include the needs of stakeholders both internal and external to the organization. The challenge of any project is to accurately identify all of the stakeholders, and to elicit and understand their needs.

End-User Requirements

Needs from those who will directly or indirectly interact with the system are called end-user requirements. These include requirements for the documentation and user interface, which can be very complex and are often a source of error.

System Requirements

System requirements come from analyzing the business objectives and stakeholder requirements. While business objectives and stakeholder requirements are written in business terms and are from a real-world perspective, system requirements are more rigorous, more formal, and are written in systems (technical) terminology. For example, a stakeholder requirement might refer to “Company XYZ Monthly Sales Report,” while a system requirement might refer to that same thing as “XYZMoSalesRept.doc.”

System requirements are high-level requirements for an entire system. Systems may include subsystems (for example, hardware subsystem, operating subsystem, software subsystem [or subsystems], or network subsystem).

Software Requirements

Software requirements, such as the functionality necessary for operating within a harsh physical environment or the graphical user interface needed between the user and the machine, are detailed, specific requirements written for a software system (or subsystem).

Requirements Engineering

According to the IEEE Software Engineering Body of Knowledge® (SWEBOK®), requirements engineering includes four processes: elicitation, analysis, specification, and validation.

Elicitation

Requirements elicitation is concerned with where project requirements come from and how the analyst can collect them. It is the first stage in building an understanding of the problem the project is required to solve. It is fundamentally a human activity, and is where the stakeholders are identified and relationships established between the project team and the customer. It is variously termed “requirements capture,” “requirements discovery,” and “requirements acquisition.”

One of the fundamental tenets of good project management is good communication between users and the engineers. Before development begins, requirements specialists may form the conduit for this communication. They must mediate between the business domain of the users (and other stakeholders) and the technical world of the engineers.

Analysis

Analysis is the process of:

Detecting and resolving conflicts between requirements
Discovering the bounds of the project and how it must interact with its environment
Elaborating system requirements to derive software requirements

The traditional view of requirements analysis has been that it be reduced to conceptual modeling, using one of a number of analysis methods such as the Structured Analysis or Design Technique (SADT).

While conceptual modeling is important, analysis includes the classification of requirements to help inform trade-offs between requirements (requirements classification) and the process of establishing these trade-offs (requirements negotiation).

It is important to describe requirements precisely enough to allow the requirements to be validated, their implementation to be verified, and their costs to be estimated.

Specification

For most engineering professions, the term specification refers to the assignment of numerical values or limits to a product’s design goals. Typical physical systems have a relatively small number of such values. Typical software has a large number of requirements, and the emphasis is shared between performing the numerical quantification and managing the complexity of interaction among the large number of requirements.

So, in software engineering jargon, “software requirements specification” typically refers to the production of a document, or its electronic equivalent, which can be systematically reviewed, evaluated, and approved.

For complex systems, particularly those involving substantial non-software components, as many as three different types of documents are produced: concept of operations, system requirements, and software requirements.

Validation

The requirements documents may be subject to validation and verification procedures. The requirements may be validated to ensure that the software engineer has understood the requirements. It is also important to verify that a requirements document conforms to company standards, and that it is understandable, consistent, and complete.

Formal notations offer the important advantage of permitting the last two properties to be proven (in a restricted sense, at least). Different stakeholders, including representatives of the customer and developer, should review the document(s).

Requirements documents are subject to the same software configuration management practices as the other deliverables of the software life cycle processes. It is normal to explicitly schedule one or more points in the requirements process where the requirements are validated. The aim is to pick up any problems before resources are committed to addressing the requirements.

Requirements validation is concerned with the process of examining the requirements document to ensure that it defines the right software (that is, the software that the users expect).

Requirements Process

Identify what information is needed. What are the goal(s) and the purpose? Identify who or what is likely to have this information. A coverage matrix, a spreadsheet showing stakeholders and the information needed, can be a useful tool for this step.

Determine effective techniques to get this information from this person or these people. Write out the questions. Even if you are only job-shadowing, you are still observing in order to answer questions.

Obtain the information.
Process the information.
Refine and confirm the information through storyboarding and prototyping.
Write the stakeholder’s requirements document.

Progressive Elaboration

The concept of Progressive Elaboration states that the more we know about something, the better we are able to manage it.

Here is what we know:

Projects begin with “1% of what we know about what WE KNOW,” and “1% of what we know about what WE DON’T KNOW.” HOWEVER, the remaining 98% is “what WE DON’T KNOW about what WE DON’T KNOW” until we begin.

Iteration

Iteration can be considered as “loops around the track” (i.e., how many times should you repeat a process before you are done?) This course will go through the requirements elicitation (and analysis, specification, and validation portions of requirements engineering) sequentially. However, in reality (for large projects, especially), the process is much more iterative. You may need to iterate among the various stakeholders. For example, you may interview the department director, and then, after interviewing her staff, realize you have more questions for her.

You may need to iterate among the processes. For example, you may be writing the requirements specification and realize you omitted an important end-user.

Management

Requirements management is a supporting or infrastructure process that goes on throughout the entire life cycle. Requirements management, or managing requirements, usually involves three major components: Managing change, tracing from stakeholder needs all the way through delivered software, and identifying needed attributes on each requirement – things such as status, author, and priority.

Testing

Requirements are the foundation for testing.

Acceptance Testing

Acceptance testing should be based on stakeholder requirements. System testing is based on system and software requirements. Integration testing (plugging together the parts of the system) is based on architectural or high-level design; and unit or module testing is based on the design specifications (not the code itself).

What are some of the implications?

First, it’s impossible to do effective testing if the front-end documents do not exist or are not well-written. Second, all requirements must be testable.

How do you ensure they are testable?

The best way is to have the tester create the test cases while the requirements documents are in draft mode, nearing completion. If the tester cannot create a valid test case, the requirement is not testable and, therefore, should be rewritten now rather than weeks or months after this requirement was used for analysis, design, and coding, and then fails during testing.

Remember

The earlier you find defects, the cheaper they are to fix. This is one reason to find defects early.

How do you write a testable requirement?

First, requirements should be written in the form “A user shall…” (for stakeholder requirements, substituting any role for “user”), or “The system shall…” (for system and software requirements). Second, measurable terms must be included, such as “The system shall return a prompt within three seconds…,” not, “The system shall return a prompt as quickly as possible.”

Don’t forget to leave your comments below

Richard Frederick, PMP, MCP, MSF is a graduate of Southern Methodist University (SMU) Cox School of Business, a Project Management International (PMI®) certified Project Management Professional (PMP®), a Microsoft® Certified Professional (MCP) and Microsoft Solution Framework (MSF) Practitioner. Richard “Ric” Frederick gained his broad range of experience by treating problems as opportunities and creating innovative solutions. With work in government at the Superconducting Super Collider laboratory, in education with Apple Computer, Inc. and in business with Assured Solutions (his own consulting company), Ric has earned and applied the necessary techniques to achieve both tactical and strategic goals. His efforts to simplify complex issues and turn losing projects into winners have met with outstanding success. Ric, a distinguished speaker and teacher, periodically shares his expert knowledge of industry standard techniques in Program and Project Management Seminars. His insights reveal how to bring order and success to the often-times chaotic program management process.

Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge. Check out the following Global Knowledge courses:

Business Analysis Essentials and Requirements Development and Management

For more information or to register, visit www.globalknowledge.com or call 1-800-COURSES to speak with a sales representative.