Requirements Development is Key to Successful Software Development Acquisition

By Tom Colangelo

Anyone who keeps up with national news is aware of a recent problematic major website deployment. Media pundits were quick to blame leadership problems. A noted information technology pundit pointed to acquisition and contracting failures and the governments’ inability to “hire” talented contractors. An Inspector General review will undoubtedly identify both functional and leadership problems that led to the ill-prepared roll-out. However, I expect it will also highlight what I perceive to be a more basic problem and something that we should give more attention to: requirements development.

Fundamental to any requirements development process is the documentation of needs. Let’s look at why that’s so important and two processes to achieve it in software development acquisition: the Functional Description and the Software Requirements Specification.

Requirements Dictate Form and Function

Aspiring acquisition professionals and any stakeholder in a major information technology development effort must recognize the importance of the “requirement” and that development of a website is not an Automated Information System (AIS); rather, the website is simply the external face or front office of the AIS. (An AIS is a combination of computer hardware and computer software, data, and/or telecommunications that performs functions such as collecting, processing, storing, transmitting and displaying information.) While its design is important from a user experience perspective, the heart of the AIS is the back office. That is, the computer equipment, software and interfaces that make the AIS work and bring “life” to the website.

The key to development of the AIS requirement, particularly the back office, is the absolute necessity for an accurate and complete Functional Description (FD) and/or Software Requirements Specification (SRS). They are the building blocks of the AIS development project.

Functional Description

The Functional Description (FD) is the customer/proponent’s written documentation of what the AIS must accomplish. It lays out, at a minimum:

• The inputs;
• What must be done with these inputs;
• What other data is required;
• Where that other data is located; and
• The outputs.

It details each transaction in plain English. For example, “When user enters ID and password, search authorized user registry for a match; if a match, allow access. If no match, do not allow access”.

In most cases, only the functional customer can accurately prepare a Functional Description. They are the proponent for the AIS and the people who know, or should know, the statutory, policy, and business drivers behind it. Only they can realistically know and document the inputs needed, the transactions that must take place in the back office, and what the outputs should be. For a system with the complexity of the “website” mentioned above, the proponent of the AIS must call on the proponents or principal stakeholders of all external systems that must interface with the planned AIS and ensure they participate in developing the FD. Development of the FD should precede, and is the basis for, the Software Requirements Specification (SRS).

Software Requirements Specification

The SRS is a project offices’ understanding of a customer/proponent’s system requirements and dependencies prior to any actual design or development work. It enhances and expands the FD and states those functions and capabilities the AIS must provide, as well as stating any required constraints. It does not contain design suggestions, possible solutions or issues, or any other information; it only contains what the development team understands the customer’s system requirements to be. The SRS assures the customer that the development organization understands the requirement and the software behavior necessary to effect it, decomposes the problem into component parts in a logical fashion, serves as an input to the design specification and must contain sufficient detail in the functional system requirements so that a design solution may be devised, and serves as the source document for testing and validation.

The SRS should address the following:

• Interfaces
• Functional capabilities
• Performance levels
• Data structures/elements
• Safety
• Reliability
• Security/privacy
• Quality
• Constraints and limitations.

In my experience, development of a Functional Description is often skipped. The functional customer/proponent may feel it is “too busy” to prepare it or that “It’s an IT function and not our job”. In these cases, the project office or development organization may initiate the Software Requirements Specification based on the general requirement. However, they will require substantially more input from the proponent who may, or may not, devote sufficient time to this effort because they didn’t plan for it. Remember – no one knows the functional details of the requirement better than the functional proponent.

Building Blocks of a Successful Software Acquisition

• An accurate and complete Functional Description is the foundation of a good Software Requirements Specification.
• An accurate and complete SRS is the foundation of subsequent requirements documentation, i.e., the design specification, the statement of work, and other project documents that drive the development of the Automated Information System.
• With an inadequate FD and SRS, the most likely outcome is an over-budget, behind-schedule acquisition, missed deliverable milestones, and a product that may not meet performance requirements. Sound familiar?

What’s your experience with requirements development affecting acquisition outcomes?

Re-posted from the Integrity Matters – Perspectives on Acquisition and Program Management blog.