Return to Archive Runtime - The Software Outsourcing Newsletter for Executives and Investors from Accelerance and Steve Mezak The Requirements Of Good Product Requirements Just a couple of items before the main topic of this issue of "Runtime". I heard back from a few of you after the last issue about hiring a Core Technical Team to manage outsourced product development. All strongly confirmed the approach as a way to track progress of on-time product completion and quality. One subscriber mentioned a different approach used by large companies with a strong market presence. They use outsourced development without any managing team, technical or otherwise. The justification is, "Why hire a person in the US when you can hire three engineers offshore for the same money." Instead, a high level specification is sent to the offshore team and programming begins immediately. What comes back is not a perfect product. It may have an awkward user interface and missing and broken features. However, the cost of additional revisions is so low, a core technical team is deemed unnecessary. Dominating the market enables the bigger companies to take this approach maximizing the use of offshore resources without damaging the customer relationship too badly. My experience is that startups rarely have this luxury. If your startup has a truly innovative product, addressing a huge, pent up market demand, you may get away with releasing a poorly implemented product. Netscape and Ebay, circa 1995, come to mind. But early customers are precious to most startups. You must work carefully to make an excellent first impression. Employing a core technical team enables you to pay close attention to customer requirements and to safeguard the product development process. How should you, or your core technical team, specify the requirements of your product? Software engineers have dealt with this question for several decades now. There are a number of answers involving techniques and styles. There is no one correct answer. It is difficult to define a single approach that covers all possible software systems. Consequently, specifying product requirements often seems like a nebulous process. However, there are specific items that should always be in your product requirements. I divide the overall product definition process into the creation of two documents - a Marketing Requirements Document (MRD) and a Functional Design Specification. Some people combine the two and consider "Requirements" as one big document that covers marketing issues as well as a relatively complete description of product functionality. Or marketing issues are ignored and the document jumps right into the details of product features. More on this later. Separating the process into two steps is useful. There are important marketing issues that should be addressed in the MRD. Do not distract yourself with the gory details of your product's functionality at this point. Sometimes the MRD is only considered a definition of the product and renamed a PRD for Product Requirements Document. In this case more emphasis is placed on product functionality and it is easy to skip the marketing issues that may be critical in defining a new product. For example, one startup I know was very focused on product features and the founding team designed a system without consideration of potential partners in the marketplace. Specifically, the system had a sophisticated approach to capturing information about shipments sent out by customers of the system. Later, after most of the system was built, they realized that much of the functionality could have been implemented with an interface to FedEx and UPS systems that had many more features to begin with. Furthermore, an alliance with one of these big companies would have been more important than any set of features the founders could have dreamed up. On the other hand, an MRD can be heavily weighted towards the size and texture of your market. Your opportunity may be the product weaknesses of multiple competitors. The MRD can describe market situation and how these weaknesses will be overcome. Your MRD describes how your product will achieve a significant market share. It may go so far as to prioritize features in terms of ability to gain market share. Another startup I know created a detailed comparison of product features in matrix form. They used this for customer presentations. Of course, the startup's column had the most checkmarks next to the feature descriptions. Sometimes, they had checkmarks in entire categories of features their competitors had neglected to implement. Internally, this was a tremendous tool to motivate the developers and to describe what the product needed to do. "If we don't have this feature in the next release, we won't be any better than Brand X!" How you write your MRD depends on what you consider your most important innovation. Is the product by itself so new and cool, that customers will beat a path to your door? If so, a feature-centered MRD may be sufficient. Or will you need to include specific features your competitors do not have? Is your innovation the use of a different sales channel that works only if your product is easily self-installed by the customer? Requirements like these must be in your MRD. The MRD describes "What" the product MUST include and not "How" it is implemented. The "How" is described in the Functional Design Specification. Some people also recommend that the MRD specify measurable criteria to determine if the product has delivered a solution to the problem you originally set out to solve. This is useful in a product with a large number of requirements. In a startup, your initial product may not be so complex. There are multiple formats of MRD to choose from. There are several standards that cover requirements: IEEE Std 1220-1998 - IEEE Standard For Application And Management Of The Systems Engineering Process ANSI/IEEE Std-830-1984 - IEEE/ANSI Guide to Software Requirements Specifications These standards cover the specification and design of large systems and are heavily influenced by the defense industry. Standards like these are usually overkill for most startups. Personally, it annoys me when documents like these say "This page intentionally left blank." At a startup, you don't want to waste the paper. Here are the major sections I think need to be in an MRD for most software startups: Introduction or Executive Summary - describing the purpose of the product or problem it solves, the market opportunity, and a general plan for product releases and revenue. The introduction describes a vision of success achieved after the product is released. Functional Requirements - the major features and functions that must be in the product. It can include a definition of user roles and high level use cases. Performance - describes the required speed of the product in terms of number of users, page views per second, etc. Also includes the disk space & memory requirements or restrictions of the product. Technology - requirements such as system architecture, databases and computer languages. It can be combined with Environment in some MRDs. Hardware - supported computers, network equipment, etc. Environment & Integration - describes the software environment or context in where the product will be used. Usually this means specifying sources of data the product must tap and other existing software packages the product must integrate with. Optional sections you may include in your MRD: Market Opportunity - market size, segments and competitor & partner information Schedule Requirements - if your product must be released for an industry show, customer specified date or other date that defines your window of market opportunity Assumptions & Dependencies - covers dependence on other companies products or your own technical breakthroughs. Glossary - define the specific terms unique to your product category that may not be familiar to the development team, investors and other stakeholders. It is critical to not get hung up in an overly formal process when it comes to requirements and specifications. Requirements will change. They will evolve. You must not churn in your efforts to create an MRD. I recommend setting a time limit on the process. For many startups, the process of creating a useful MRD should take no longer than a week or two. Most of your writing time should be spent in creating a Functional Design Specification after the MRD step is completed. The FDS contains more detailed uses cases, a sketch of your user interface, definition of internal objects used to model information in your product, and many other details. I will discuss creation of an excellent Functional Design Specification in upcoming issues of "Runtime" Vision Resources Are you wondering how you will select an expert offshore team to develop your software? Use the Accelerance Vision Resources(sm) outsourced vendor selection service and cut the time of your vendor selection process by as much as 90%. Vision Resources leverages members of the Accelerance's 17 teams in 14 countries around the world. Click here to learn more about Vision Resources Accelerance, Inc. delivers impartial & expert strategies and services for risk-free outsourcing of your software development. Visit our web site at www.Accelerance.com   Until next time, Steve Mezak Accelerance, Inc. Risk-Free Outsourcing www.Accelerance.com 213 Garcia Avenue Half Moon Bay, CA 94019 1-650-712-8990 Contact me by email (c) 2005 Accelerance, Inc. All rights reserved. You are free to use material from the "Runtime" eZine in whole or in part, as long as you include complete attribution, including live web site link. Please also notify me where the material will appear. The attribution should read: "By Steve Mezak, CEO of Accelerance, Inc. Please visit the Accelerance web site at http://www.Accelerance.com for more information and resources on outsourcing and creating great software products."