The benefits of doing a detailed enterprise software requirements analysis

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?

Requirements 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 helps discover unknown requirements before the purchase, rather than during the implementation phase when they cause delays and increase costs.

When gap analyses are done against detailed requirements, software selection risks are reduced with accurate measures of how competing products score against the organization’s 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’t be delays or workarounds during implementation because those limitations are already known and factored into planning.

Spending 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.

How Much Detail?

This, 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.

Bear 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 not 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.

To get a real-world perspective on what is meant by detailed requirements, consider the following:

The software shall be easy to use

This 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.

In 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.

Usability Data Entry

Usability Data Entry Address

Usability Data Entry Currency

Usability Data Entry Date & Time

1. 12 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.
2. 3-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.
3. Date 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:
   • You cannot create an invoice dated more than one month in the past.
   • Dates for certain transactions must be in a range.
   • Dates for past events or completed tasks cannot be in the future.
   • Dates for future events cannot be in the past.
   • A date must be selected from a picklist (to be consistent with business rules)
4. Date 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.
5. Date 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.
6. Date 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.
7. Fractional 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.
8. Month & 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.
9. New transaction default date. The default date for a new transaction can be configured in the system by form. For example, the date on a new transaction could default to:
   • Blank (field is empty)
   • Today
   • Today plus or minus a specified number of days
   • The date of the last transaction entered
   • The date of the last transaction entered with that vendor.
10. Today 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.

Usability Data Entry Numeric

Usability Data Entry Text

The screenshot below shows an example of a software product being rated against usability requirements. Note the bars in the right-most column show the “profile” of how well this software meets these requirements.

 

Wayferry

Wayferry

 

Some 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. Analyzing enterprise software products against detailed requirements accurately measures how well that software fits with an organization’s particular needs. 

The 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.