Requirements gathering for technology selection

(Blondie’s “One Way or Another” illustrates the challenge of acquisition without requirements.)

When an organization sets out to acquire new technology, they are putting more than resources like time and money on the line. The reality is that “[e]ven when the technology solution is purportedly at hand…technology is not the solution, only part of it.”[1] Organizations must consider how the technology will work within the organizational culture and what its impact on resources will be. However, if selection is done right, existing staff, workflows, and systems will migrate to and integrate with the new technology that will ultimately provide great benefit to their organization, enabling efficiencies and new processes. But if the specific requirements of the organization are not considered, the selection and implementation of new technologies may end up causing headaches, and not actually reaching the envisioned potential. The most successful technology selection occurs through a thoughtful process of requirements gathering so that the organization can communicate and align functional and technical needs with the available systems on the market.

Purchasing a technology must take into consideration a variety of demands: goals, timelines, staffing, costs, technologies, and functions. It is important to scope these demands into a concise set of requirements so the needs are understood by all stakeholders within an organization and to clearly communicate the needs to vendors and suppliers, who can in turn respond to them appropriately. A clear statement of and consensus around need, and a consistent methodology for evaluation of solutions will help an organization objectively compare the variety of options on the market. And, when selecting technologies through an RFP process, providing vendors with set of criteria to respond to ensures that they communicate consistently, even when their costs and services differ. In addition, a set of requirements criteria ensures that responses can be assessed equitably and quantified or scored.

We recommend that an organization develop a few different sets of requirements when selecting a new technology. These should include business, functional, non-functional requirements, as well as illustrative use cases, which together create a matrix of resources that can be cross-referenced and related to one another. This provides a full picture of what an organization needs from a technology.

A. Business Requirements  

The first step in the requirements gathering process is capturing business requirements. Business requirements communicate what an organization needs from a particular technology and what the anticipated goals, outcomes, and benefits are. They will inform and help to shape the other requirements below, which in turn determine how the business needs will be met. The development of a set of business requirements provides an opportunity for stakeholders to understand goals from different parts of the organization, and reach consensus on priorities as a group.

Business requirements can address a variety of concerns including standards compliance, the need to streamline or integrate technologies and workflows or otherwise implement time and cost savings, highlight high-level functionality that the organization would like to see in a technology, and much more. Questions that will draw out information to help formulate a handful of requirements in this category, should consider:

• What is the current state of systems and technology in the organization?
    ○ Where are there challenges that require solutions?
    ○ Where are there opportunities for improvement?
• What does the future state of systems and technology look like?
    ○ How will a new technology impact current challenges and opportunities?

1. Example: Business requirements for a digital asset management system

B. Functional requirements

Functional requirements specify what a system should do. They describe a discrete action or behavior. Often, the list of functional requirements for a technology will be quite long. For example, an RFP recently developed by AVPreserve for an enterprise digital preservation system included 124 functional requirements in categories ranging from Pre-Ingest to Data Management to Exit Strategy. Functional requirements are succinct statements specifying the functionality required of the technology, typically accompanied by a priority ranking (e.g., Mandatory, High, Medium, Low). Functional requirements are testable and demonstrable. They enable vendors to present each function of their existing technology distinctly, ensuring that the selecting organization knows exactly what to expect from the technology options presented to them.

2. Example: Functional Requirements for a Digital Preservation system

C. Use cases

Use cases are lists of actions or event steps (often in a narrative form) that define the interactions between an actor (either a human or a system) and a technology to achieve a goal. They outline, in a series of steps, the way a technology should behave to accomplish a task set forth by the actor. Writing use cases is one method for breaking down a task into discrete actions, which can lead directly to the development of functional requirements to represent the actions that are necessary to achieve the goal of a use case.

A use case is a communication tool—it provides detailed information in a human-friendly way so that all stakeholders understand what a technology should do and how it should work. In this way, use cases provide the context for functional requirements, which on their own, might not be interpreted the way an organization intends.

Because a use case is comprised of many discrete steps, it may have several functional requirements associated with it. An example use case for a digital asset management system and three of its associated functional requirements are below:

3. Example: Use Case and Related Functional Requirements for a DAM system

Use cases help an organization and prospective technology providers understand how the functional requirements work together to answer their needs, and can, through the process of their development, expose functions that are not already accounted for.  

D. Non-functional Requirements

Where functional requirements describe the individual functions that a system should perform, non-functional requirements specify how the system should perform those actions. Non-functional requirements outline technical and performance features, such as response and up-times, as well as usability and reliability. Examples of non-functional requirements include:

• “Return search results with metadata and thumbnail views within five seconds no matter the size of the results set.”
• “The system shall be available 99.99% of the time for any 24-hour period.”

Non-functional requirements are useful in judging whether a system will operate at the speed, performance level, and quality required of the technology.

Technical Requirements

Technical requirements detail any constraints or preferences for the application itself. At AVPreserve, we look at an organization’s technical requirements distinct from other non-functional requirements, although technical requirements are, in effect, a sub-category. Making this distinction highlights the importance of the infrastructure, systems, and tools that a new technology will work within, integrate with, or build upon. By organizing this information separate from other non-functional requirements, we gain a deeper understanding of the environment in which the technology must function. Technical requirements may include information about:

• Software hosting location (e.g., on site, in the cloud)
• Client-side interface and technology (.e.g., Java, web-based)
• Web services (e.g., REST API)
• Authentication (e.g., LDAP)
• Storage (e.g., on site, in the cloud)

Technical requirements may be listed as mandatory or preferred, and more than one option for each category may be offered. For example, an organization may prefer hosting software on site, but may be willing to consider other options (such as a fully SAAS solution). Making all possibilities clear ensures that organizations are investigating all possible options and that vendors understand whether the technology they are offering is a strong match.

E. Evaluation

By creating lists of discrete requirements that have priorities associated with each, an organization can apply scoring mechanisms that allow for objective decision making. At AVPreserve, for example, we assign a priority to each functional requirement and an associated “score” or weighting for that priority level (e.g., Mandatory=4, High=3, Medium=2, Low=1). If the technology can inherently meet the requirement, it is scored based on the priority assigned to the functional requirement. Take, for example, the functional requirement for a digital preservation system “Actively monitor staging area for ingest packages” with the priority of “Mandatory.” If the technology is able to perform this action as part of its core functionality, it is given a score of 4. If it cannot, it is given a score of 0. At the end, all scores for all requirements are added up and an overall score is summed. The higher the score, the better the technology matches the requirements for it.

In some cases, as with software, scores can be assigned not only to priority, but also to whether a function is (a) a core component of a system, or whether (b) integration with other systems is required to achieve the functionality or (c) custom software development is required to build that function into the system. Scored alongside priority, this system analysis provides a more nuanced evaluation of the technology’s features.

4. Summary of functional requirements scores for six competing technologies

A similar scoring methodology can be applied to non-functional and technical requirements. In the end, the scores from each set of requirements can be combined and compared across the various technology options, to objectively identify the most and least relevant solutions.

Conclusion

Providing clear and concise requirements for the technology an organization is selecting not only benefits the organization, but also any vendors that may propose solutions. Requirements help an organization scope what their needs are and to assign priorities to those needs. They can be packaged in a  formal document that staff can use to communicate to decision makers what is necessary to fulfill their job responsibilities, and can help gain financial support to address those needs. Requirements clarify to all stakeholders what they can and cannot expect from a new technology.

For vendors, the objective guidelines provided by well-formed requirements allow them to easily communicate the qualities and characteristics of their technology and how those qualities match the needs of the organization. They minimize subjectivity in decision making by creating methods for qualitative analysis, which leads to informed and confident technology selection.

Requirements gathering has some upfront costs—they can be time intensive and may necessitate input from staff throughout the organization. Ultimately, though, requirements decrease the possibility that money will be spent on inadequate technologies and minimize time wasted on selection by making it easy to quickly identify shortfalls in a product’s capabilities and weed out poor matches. Because the requirements development process requires active participation from all stakeholders (it should definitely not be performed in a vacuum!), it helps generate buy-in, and provides a means for clarifying expected outcomes. For vendors, a clearly defined set of requirements helps them know up front whether their solution makes sense, saving them potentially hundreds (or even thousands) of dollars in the staff time required to develop responses to RFPs, when the fit is not right. And, finally and most importantly, requirements can provide a framework for implementation planning, minimizing surprises from vendors (and organizations) after contracts have been signed, and ensures that technology meets the goals and expectations of the organization.

[1] Kenney, Anne R. and Nancy Y. McGovern. “The Five Organizational Stages of Digital Preservation” from Digital Libraries: A Vision for the 21st Century: A Festschrift in Honor of Wendy Lougee on the Occasion of her Departure from the University of Michigan, Eds. Patricia Hodges, et al. Ann Arbor, MI: Michigan Publishing, University of Michigan Library, 2003. http://dx.doi.org/10.3998/spobooks.bbv9812.0001.001

—Amy Rudersdorf