Jason Moccia, OneSpring Managing Partner and Co-Founder examines how traditional software development has always required a long requirements-gathering phase at the beginning of a project that if not handled correctly, can often result in schedule delays and costly budget overruns that have a significant impact on the project itself. Software visualization can streamline that process and prevent many of the errors and delays that are common when using traditional methods.
Scaling API-first – The story of a global engineering organization
The Software Requirements Struggle
1. CONCEPTS
by OneSpring LLC
w w w . o n e s p r i n g . n e t
July 6, 2007
The Software Requirements Struggle
Traditional versus Modern Requirements
By Jason Moccia
Executive Summary
Traditional software development has always required a long requirements-gathering phase at the beginning of a
project that, if not handled correctly, can often result in schedule delays and costly budget overruns that have a
significant impact on the project itself. Software simulation can streamline that process and prevent many of the errors
and delays that are common when using traditional methods. This paper details the requirements-gathering
mechanism and how simulation is breaking into the mainstream as a time-and cost-saving method of helping clients
design software projects with a minimum of error and hassle.
Traditional Software Requirements
Most of us in the software industry are familiar with the concept of requirements and the traditional process of defining
requirements for software development projects. In the world of software development, requirements are the blueprints
the development team uses to create software. Requirements identify the specific functions that a software program is
expected to carry out as a person or system interacts with it. In more concrete terms, requirements identify the
building blocks that are used to create software applications, and the processes that each facet of the software will
invoke as it is used or implemented in an environment.
The importance of requirements can be reflected in research performed by The Standish Group which found that 28
percent of software projects are completed on-time and on-budget. The cause of this atonishing number does not fall
on requirements alone, but it certainly has a profound impact. In addition, OneSpring estimates that most companies
that produce software spend at least 30 percent of their software budget on the requirements definition process alone.
In most development projects, this can add up to a rather large sum of money very quickly. What many industry
professionals also know is that the traditional requirement-gathering and defining process rarely creates a good
enough snapshot of the product to prevent budget overruns and lost man hours that result from poorly
communicated specifications in the early stages of a project.
Most companies that create software in its various forms write their requirements in basic text format—
often using programs like Microsoft Word. The degree of detail in these documents varies in direct relation to the
complexity of the project and the environment in which the project is being developed. Some projects can have
hundreds of pages of documentation and many hierarchical levels that can get very confusing if not written clearly.
The main problem with lengthy textual specifications, however, is that no one likes to read them, nor do many people
have the amount of time it takes to thoroughly understand them.
Written requirements are widely recognized and understood as the first step in software design across the
industry. In fact, some companies create vision documents that outline the scope of the final product and give developers
an overall goal to shoot for, and then create a software requirements specification (SRS) or a functional specification that
outlines the detailed requirements. These documents are usually cumbersome to put together and difficult to
understand and interpret.
Communicating Concepts and Ideas Effectively
The process of gathering requirements is one of the most disorganized areas of most software development projects,
and as a result, is often the most misunderstood. The process begins when someone—often an executive or manager
in a company—identifies an area of the business that could benefit from the potential implementation of a new
software solution or the enhancement of an existing software application. When an idea is presented to the powers
that be in the organization and approved for development, a decision is then made to either build a custom
application or purchase a boxed solution. Regardless of the outcome of that decision, the process of gathering and