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 defining traditional requirements is equally important. The quality of the requirements documentation can result in the difference between a successful product launch and various high-dollar mistakes.
The purpose of developing new software is to create a business solution that either reduces overhead or creates new revenue—in other words, it either saves money or makes money. Why is it, then, that most software projects start out with good intentions but end up failing or going way over budget? The answer is simple—poor requirements. The process of gathering and defining requirements is designed to prevent such problems by clearly and effectively documenting the many details of a project before any development occurs. Attempting to reduce errors is a key component in any project plan, and software projects are no different.
Imagine for a moment that you planned your first home. You designed it from the ground up and you are very proud of your accomplishment. Now, imagine discovering that you never properly analyzed the amount of concrete needed to support the size of the house. Here you are with a new home, presumably ready to move in, and you find out the foundation is faulty. How much is it going to cost you to fix this problem? We don’t automatically know the answer to this question, but we can assume it is going to be very expensive. This is an example of a situation in which the requirements-gathering process was flawed. If you had spent more time analyzing the size and weight of the house in relation to the amount of concrete needed, you might have been able to prevent this problem before the first nail was hammered.
This situation is much the same in many Fortune 500 companies today. Despite incredible advances in software and hardware over the last 40 years, many companies still spend tens of millions of dollars annually to correct software development bugs and defects that often do not surface until well after the design phase is completed. There is nothing more frustrating in a software development project than discovering a bug or a defect that could have been prevented if the front-end research had clearly and adequately communicated the necessary specifications earlier in the process. The loss of money and time spent by design teams often causes projects to end up over budget and to exceed scheduled time allowances—causing launch delays and, in some cases, the scrapping of an entire project. Well-researched, well-defined, and well-documented requirements are critically important in preventing these kinds of calamities.
Issues with Traditional Textual Requirements
For years, traditional software requirements have been produced in textual form—written by analysts and administrative assistants through sessions held with business stakeholders. This process classically produces many pages of typed specifications and notes that add up to volumes of requirements that have to be waded through as the team progresses with the actual programming work. Traditional textual requirements alone, although necessary for documentation purposes, are fraught with issues that can have an impact on the success of the overall project.
The mass of paperwork, for example, is often too much to digest for the stakeholders who need to buy into a project. Executives who hold the purse strings for a project rarely have the time to wade through the pages of requirements that spell out what the program will do for them. The sheer mass of documentation also often hides unnecessary requirements or prevents readers from recognizing that a requirement might be missing. Different interpretations of requirements or differences in writing styles can often lead to misunderstandings and debates over the intent of a particular requirement and what its manifestation will be in the final product. The scope of a project can shift slightly when the requirements are interpreted incorrectly, resulting in an end product that looks different from that which the designer envisioned. These issues and more can have a profound financial and scheduling impact on a software development project.
Stakeholder Buy-in
One of the most challenging things with defining textual software requirements is obtaining stakeholder buy-in. Most stakeholders don’t read—or have time to read—the requirements. This is understandable, considering that most average-size software applications can generate hundreds of pages of textual requirements. Executives that control the money and make the decisions regarding the life expectancy of a project would need many more hours in their day if they tried to read and understand all of the software requirements for each project that they oversee.
One example is a recent project at OneSpring that included over 1,500 features. Picture us sitting with the stakeholders and the project team members trying to obtain buy-off on the requirements. During our first hour-long session, we made it through only ten features. This is only one example among the hundreds out there that reinforce the difficulty of reviewing projects with clients using a review of traditional software requirements.
In addition to just reading requirements, these executives also have to visualize what the requirements are describing and how they impact other areas of the organization. It is difficult to visualize the interrelatedness of the requirements, however, when faced with a mountain of textual documentation. Most individuals are visual rather than textual. This simply means that it is easier to decipher an image of something as opposed to reading about it—hence the saying, “A picture is worth a thousand words.”
Scope Creep
Scope creep is a problem by which stakeholders continue to add requirements to a project even after sign-off on requirements has occurred. This is an ever present issue that plagues many software projects and can lead to massive delays and budget overuns. The presence of a formal methodology can help prevent this from happening, but it is almost impossible to eliminate it altogether.
Unnecessary Requirements
It is very easy to slip requirements into a software project. The sheer scope and breadth of a long list of requirements makes it easy for stakeholders to slip additional requirements into the document without much notice. The focus of any project should be restricted to high-need requirements, rather than bells and whistles—at least at first.
Different Interpretations
Another problem with textual requirements is that the written word can be easily misinterpreted. Reading a list of 500 requirements and trying to visualize what the requirements are identifying easily opens the door for misinterpretation. It is the job of the business analyst to make sure that all requirements are interpreted correctly by all team members. The problem with this is that business analysts are human, and can also misinterpret information in written form.
Different Writing Styles
A fair number of projects have several individuals working on defining requirements, which opens up the issue of different writing styles. This could range from how requirements are actually defined to subtle nuances in writing style. This can also contributes to misunderstandings over what the requirements are intended to accomplish.
Maintaining Requirements
Maintaining a large number of textual requirements can be a daunting task in itself. There are tools in the market that can help facilitate this, but they are only as good as the amount of human attention that is paid to making sure the requirements are up-to-date. It is very easy to forget to update requirements, because updates are generally written down in meetings, in a notebook, or on a notepad during a phone conversation and then transferred to the master list later. This gap between writing the change down and manually changing the requirement is the difference where missed or misinterpreted requirements can occur.
Ambiguous or Lost Requirements
This is tied directly to maintaining requirements in that requirements can be lost or opened up for interpretation. For example, a stakeholder says “I want to be able to log into the system.” That simple statement opens up a great many topics for discussion. Should the login be single sign-on? Does the user have to register first before they log in or will they already have an account? These are just a couple questions that would have to be asked. A junior business analyst may not be experienced enough to know what questions to ask, or may miss the finer points of the questions they ask. Because of the sea of requirements that sometimes threaten to overtake some projects, it can be extremely easy to miss critical requirements. This usually comes to light after the software is launched and a client is reviewing the application.
It is very easy to get bogged down in the weeds with requirements. Many projects last months at a time and it can become increasingly difficult to discern the trees from the forest during lengthy projects.
This list of issues can create cost overruns, exploded schedules, or just annoying delays and misunderstandings. With such a long knock-list of concerns, are there any advantages to continuing to use a traditional requirements-gathering process? There is newer technology that offers an exciting alternative with many more benefits than the older, more problematic requirements-gathering activities.
Modern Software Requirements: Software Simulation
How many of you have found yourselves with an idea and no simple way to visualize it? Not so long ago, we would have taken the traditional approach of hiring a team of business analysts to document our new idea. The typical timeline would include numerous meetings talking about the product concepts, with a lot of note-taking by the team of analysts. Once the analysts felt they had fully captured your vision, they would have packed up the bus and headed out to craft a 300-page Microsoft Word document or something similar. In other words, we paid for the pounds of paper the consultants generated. After a few months, the lead analyst would reappear with a slick presentation and several copies of the 300-page document, and tell us that our product lies somewhere within those 300 pages. Although this approach has worked for many years, it is fraught with errors, ambiguity, and always a missed concept that leads to countless dollars spent in project rework.
Software simulation provides us with a viable alternative to traditional requirements with many fringe benefits. Software simulation is the process of visually defining a website, desktop application, portal, or any other product that contains a user interface. Simulations allow business analysts, product managers, and user-experience professionals to create compelling interactions without ever writing a single line of code.
The real power lies in the simulation’s ability to mimic (or simulate) actual data interactions. A business analyst, for example, can rapidly visualize what a user login screen [see Figure 1.0] or registration page will look like and how it will function when users log into the site and view recent activity. It is easy to visualize the scope of the intended final project early in the design phase with a simulation, as compared to the final product. The final product is created by programmers using requirements that are generated through the simulation process, resulting in a website that is extremely close to the original simulation without the budget overruns and schedule extensions that are classically inherent in traditional software projects.
The ability of non-technical professionals to create such feature-rich simulations in a relatively short timeframe allow project stakeholders to envision what the final product will resemble once it is developed. This negates the need for people who are not intimately involved in the details of a project to wade through reams of paper documentation—the visual representation of what the program or product will do can save hours of development time and often reduce development budgets by preventing rework in later stages of the project.
The benefits of simulating software rather than using the traditional documentation process are vast. This exciting activity is impacting businesses today in a number of ways, including the following:
- Allows users to visualize ideas instantly (Business Stakeholders, Developers, Architects, etc)
- Reduces time to market for most products
- Eliminates requirement ambiguity
- Reduces project rework
- Mitigates project risks
- Allows for early training
- Provides the ability to perform usability testing earlier in the process
In addition to the benefits listed above, many simulation products allow for robust requirements management. This provides a 1-to-1 correlation between the visual imagery created in the simulation and the necessary textual annotations that accompany the visual interactions.
OneSpring was created to harness the power of new technology in requirements management and software design. Our background with traditional requirements definition provided us with countless years of experience developing textual requirements (i.e., use cases). Hours spent cleaning up the results of documentation and design errors had provided us with a burning ambition to find and market a solution that could save our team and our clients many hours of development time. As a result, many of our consultants at OneSpring have moved away from traditional requirements definition and have adopted a methodology of starting all our projects in a simulation tool such as iRise or Axure.
The increased benefits of software simulation are slowly becoming a standard in many companies across the industry. As I have introduced in this paper, the most notable benefits are fewer defects and reduced development time. As most companies in the business of creating and developing software know, these benefits can add up to millions of dollars in savings and hundreds of hours in recovered time, resulting in much more successful projects and happier customers.
As a result of the new global economy, U.S. companies now must compete on a much larger scale with companies from around the world. The need to produce products faster and more efficiently has never been stronger. As a result of companies such as OneSpring, who are pushing the advantages of simulation over the old traditional requirements-gathering process, simulation is slowly creeping into the software development lifecycle of more and more companies and organizations. As exposure to it expands, so will its impact on the industry at large.
