When developing requirements for purchasing enterprise software, organizations often struggle to decide how much detail to capture. The more detailed requirements are, the more time and money it takes to collect, document and manage them. Is it worth making that upfront investment?\n\n\nRequirements are to software selection as foundations are to a building. Get them wrong and there will be problems. Since detailed requirements must be fleshed out during the software implementation phase anyway, why not capture them early on in the project and use them to your advantage? Developing detailed requirements involves reverse engineering features from competing products. This\u00a0helps discover unknown requirements before the purchase, rather than during the implementation phase when they cause delays and increase costs.\n\n\nWhen gap analyses are done against detailed requirements, software selection risks are reduced with accurate measures of how competing products score against the organization\u2019s needs. Also, measuring the product fit sets realistic expectations for the software. If the decision is made to buy a product knowing that particular features are weak or missing, there won\u2019t be delays or workarounds during implementation because those limitations are already known and factored into planning.\n\n\nSpending time up front to develop detailed requirements pays off handsomely in terms of identifying best-fit software and then reducing implementation risks. Our experience suggests that requirements development is roughly half the total work in an enterprise software selection project.\n\nHow Much Detail?\n\nThis, of course, leads to the question of how much detail should be in the requirements. The answer is to include all requirements that will be implemented. To include them, first capture them and then rate them for importance.\n\n\nBear in mind that when off-the-shelf software is being purchased, requirements are those that could be satisfied by features from any of the potential software products. Any requirement\u00a0not met by at least one of those products will not make any difference to the software selection, although it might cause the scope of the project to be changed.\n\n\nTo get a real-world perspective on what is meant by detailed requirements, consider the following:\n\nThe software shall be easy to use\n\n\nThis usability requirement often appears in RFPs and RFIs. It is written at too high a level to be of any use at all, i.e. there are not enough details. Think about it: What vendor would admit their software is hard to use? The solution is to break this high-level requirement down into detailed requirements that measure ease of use.\n\n\nIn the Wayferry library, we have broken down this high-level requirement into 23 groups containing 165 detailed requirements. Below is an extract from the library to illustrate the concept. It shows data entry usability requirements groups, with the Date & Time group expanded to show 10 detailed requirements.\n\n\nUsability Data Entry\n\n\nUsability Data Entry Address\n\n\nUsability Data Entry Currency\n\n\nUsability Data Entry Date & Time\n\n\n12 and 24-hour time entry. The system should be able to support data entry using both 12-hour times with AM and PM, or 24-hour times, e.g. 18:00 for 6:00 pm.\n3-month calendar. When a calendar is opened to select a date, three months are displayed on the pop-up, and not just one month. The current month is at the center, with last month and next month also showing. A 3-month calendar is especially useful when working near the end of the month, and the user needs a date a few days into the previous or next month. That day is available on the 3-month calendar without the need to click next or previous month buttons.\nDate entry range restriction. The system can restrict date entries to within a range, which reduces errors by preventing invalid dates from being entered. For example:\n\nYou cannot create an invoice dated more than one month in the past.\nDates for certain transactions must be in a range.\nDates for past events or completed tasks cannot be in the future.\nDates for future events cannot be in the past.\nA date must be selected from a picklist (to be consistent with business rules)\n\n\nDate field adjustment. The system allows the user to adjust the date forwards or backwards one day, month or year at a time with something like the + and - keys, or arrow keys. For example, a new transaction is entered in an accounting system. The date field defaults to the last transaction date, and must be changed by a few days. If the date difference is only a few days hitting the + or - key a few times is faster than popping up a calendar and selecting a new date.\nDate field calendar. When in a date field the user should be able to open a pop-up calendar. The calendar should default to the current date, and the user should be able to page back or forward by month and year. This calendar allows the user to pick the date from the calendar, for example, avoiding Saturdays and Sundays or selecting the first Monday in a month. The user should still be able to enter the date via the keyboard.\nDate field direct edit. The system allows the user to type a date directly into a date field. The user is not forced to open a pop-up calendar to change a date. Sometimes the user wants a date a few years in the future or past. Forcing the use of a pop-up calendar can make it tedious to enter this type of date, especially if the user must step through all the months to get to that new date.\nFractional hour format. When entering times, the system should be able to support both fractional hours like 1.5 hours and time format like 1:30. Fractional time format is particularly useful with timesheet type systems.\nMonth & year adjustment buttons. Calendars should have month and year navigation buttons on them: one for moving to last month or year and one for moving to next. For example, there is no need to open a month drop down list, select last month or next month and then click a button to go to that month. This allows the user to move to the last or next month with just one button click. Same applies to a year.\nNew transaction default date.\u00a0The default date for a new transaction can be configured in the system by\u00a0form. For example, the date on a new transaction could default to:\n\nBlank (field is empty)\nToday\nToday plus or minus a specified number of days\nThe date of the last transaction entered\nThe date of the last transaction entered with that vendor.\n\n\nToday button. The calendar contains a button that takes the user to the current day with just one click. For example if the calendar was showing Jan 1, 2014 and today's date was Aug 9 2015, clicking the "Today" button would cause the calendar to show August 2015 with the 9th highlighted.\n\n\nUsability Data Entry Numeric\n\n\nUsability Data Entry Text\n\n\nThe screenshot below shows an example of a software product being rated against usability requirements. Note the bars in the right-most column show the \u201cprofile\u201d of how well this software meets these requirements.\n\n\n\u00a0\n Wayferry \n\nDetailed analysis of a software product\u2019s usability\n\n\nWayferry \n\u00a0\n\nSome people feel this is far too detailed, but that is the wrong approach. What the organization should do is first to capture detailed requirements, and then decide how important they are. Requirements rated as less than important are excluded from the gap analysis. For example, the 3-month calendar requirement above might be critical to an organization with large numbers of monthly manual transactions. To other organizations, it may be of no interest, but both types of organizations should rate it for importance to themselves.\u00a0Analyzing enterprise software products against detailed requirements accurately measures how well that software fits with an organization's particular needs.\u00a0\n\n\nThe outcome of a detailed requirements analysis is that the organization reaps the benefits of selecting best-fit software. No software is perfect, and expectations are aligned with what the product can deliver before the purchase. Knowing product limitations beforehand avoids the costs and delays associated with finding unknown requirements during the implementation phase. This argument makes the case that a detailed requirements analysis is worth the up-front time and money.