When considering new\u00a0enterprise software, it is usually a good idea to start with an evaluation even if the outcome is a decision to build the software yourself. See my\u00a0previous article: Why most enterprise software projects should start with an evaluation. This article considers using features from existing products to inspire the writing of requirements for either buying or building software. We conclude by mentioning several tools to manage those requirements.\nRequirements for buying software\nThink of the requirements for a new home: you can either buy an existing house or build a new one. Requirements for the former are far simpler than the latter which needs things like architectural diagrams and so on.\nIt\u2019s the same with enterprise software: Requirements for buying software are simpler and at a higher level than those used for building software. In the former case, requirements are used to select one product from several existing candidates. In the latter case, they describe how the new software should function. Typically requirements for selecting software describe the desired functionality only, and not how that functionality is implemented.\nRequirements for building software\nThe chief difference between requirements for buying vs. building software is one of detail. Requirements for building software should describe how that software will function in enough detail so the software can be written to perform as expected.\nMany things in life are like painting a house. The more thorough the preparation, the better the outcome. Software is no exception, and this led to the traditional waterfall model for developing requirements. However, waterfall is too difficult and too slow for the business.\nAgile emerged as a response to these problems and, in part, relies on frequent incremental releases being verified by business users. But this runs into a difficulty: what happens when users don\u2019t know what they want? Steve Jobs once said: \u201cA lot of times, people don't know what they want until you show it to them.\u201d So if the users don\u2019t know what they want, you may be relying on analysts and developers. But what happens when nobody on the team has the vision or inspiration to give software development the direction it needs?\nThis is where examining multiple products that could potentially solve your problem, and rewriting their features as requirements delivers so much value. Typically this is done when buying software, but it also works when building software. By reverse engineering features into requirements across dozens of products, you are harvesting inspirations and ideas from perhaps hundreds of developers to show users what they might want. All that brainpower presented to users can truly amplify inspiration in ways never thought possible.\nReturning to the example of buying a home, if you have ever watched a house hunting show like Escape to the Country on the BBC, you can see how looking at houses helps people refine their requirements. Sometimes they end up falling in love with something very different from their initial specification. It is precisely the same with software: it is the looking at requirements reverse engineered from the features of potential products that can\u00a0help your organization discover those \u00a0\u201cunknown unknowns.\u201d\nOf course, enterprise software is a lot more complicated than a house, often needing thousands of requirements. Spreadsheets don\u2019t cut it; you need the right tools to manage these large numbers of requirements.\nRequirements management tools\nThe reasons behind selection or development decisions can get lost with time or people leaving a company. If you know why something was designed in a particular way, you have the power to change it with minimal risk. It is when you don\u2019t know why things are done that way, and you change them that you run a considerable risk. Documenting detailed requirements preserves corporate knowledge and context. Managing large collections of requirements needs the right tool, depending on where the requirements will be used. For example:\n\nWhen purchasing software, Wayferry has a free app that captures requirements and does the subsequent gap analysis. In any enterprise evaluation, there are always a significant number of requirements that belong to multiple groups.\nA more comprehensive requirements management tool for purchasing software is SelectHub. Each stakeholder can rate requirements for importance to themselves, allowing them to compare different products from their perspectives. Also, SelectHub supports online discussions for each requirement, allowing the \u201cwhy\u201d to be captured. Active user participation in requirements development builds user buy-in, which helps ensure the ultimate success of the software.\nWhen it comes to requirements for managing implementations that are extensively configured or building new software from scratch, see tools like Blueprint. When you code, be it configuration or from scratch, you will need far more extensive testing than if you had purchased the software. A great feature of Blueprint is the ability to generate scenario test cases\u00a0automatically. Also, Blueprint can go beyond the purchasing decision into deployment and manage the full life cycle of the software.\n\nWrapping it up\nThe key takeaway is that by reverse engineering requirements from potential products, you can harvest inspiration from hundreds of developers. If, after doing the gap analysis, you decide to build rather than to buy, you can amplify the detail in those requirements you have already gathered. The technique of reverse engineering requirements allowed your organization to discover the "unknown unknowns" and provided a\u00a0head start in developing applications that can deliver great business value. And that business value is something that gets noticed in the C-Suite.