Archivists can use several elicitation techniques to gather requirements for their projects. These methods, ranging from document analysis to in-depth interviews, provide ideas for needed projects.

The Importance of Face Time

There are several ways to elicit requirements for your projects. The most common method is face-to-face meetings to gather information about stakeholder needs. If your archival project involves several departments, hold meetings with representatives from each faction to discuss their needs. These meetings identify necessities and also assist in obtaining buy-in from the attending department members. You may want to hold separate meetings for different audiences, such as the reference team and the IT department.

Users Sometimes Don’t Know What They Want

Requirements do not have to come directly from people. I’ve learned while working as a lone arranger and an archival consultant that many stakeholders and clients may not know or be able to articulate their requirements. Sometimes, requirements emerge indirectly based upon research, reviewing existing documents, and studying other data.

Many Ways to Uncover What’s Needed

Interviewing users can help identify the processes they use and the functions they require. A structured approach helps provide the necessary information. For example, the first series of interviews could document fundamental requirements while the second round could review and refine them.

Surveys or questionnaires can provide useful information to help you gather your requirements. You will want to design the questionnaire carefully and determine whether you want to ask open- or closed-ended questions. One challenge is making sure you are not leading people’s responses but allowing them to tell you what is important.

You may also need to employ some of the following techniques:

• Comparative analysis: Be alert to the ways in which other organizations are being innovative.
• Document analysis: Study the existing documentation to determine questions to ask.
• Focus groups: Work with a gathering of five to ten people; solicit their suggestions and assess requirements.
• Forecasting: Focus on trend analysis as a basis for predicting future needs and expectations.
• Interface analysis: Examine interfaces with your technical stakeholders to understand how the system interacts with other systems, hardware, and users.
• Interviews: Ask questions of your interviewees to explore and understand the answers that will shape your requirements.
• Observation: Watch users perform tasks to get an insight into an organization’s operations.
• Prototyping: Develop a model of the project so users can envision what the solution will look like.
• Requirements workshops: Also called facilitated work sessions or Joint Application Development (JAD) sessions, this technique gathers team members in highly structured meetings.
• Reverse engineering: See how a product is built by taking it apart. With software, this approach means examining the code.
• Surveys: Use these appraisals to elicit requirements from stakeholders and to understand user needs or desires.

Leverage Existing Materials

There are also elicitation tools for gathering requirements from existing materials, such as document analysis, interface analysis, or reverse engineering. These techniques are not meant to stand alone. They should be combined in a way that is most useful for your project. They should also be iterative. You will never receive all the information at once. You may start with a critical mass of data to begin analyzing and determining the requirements; then you can return to your stakeholders to get more information that clarifies and expands upon your findings. 

Try Recycling and Prototyping

Consider reusing existing requirements. If you are working on a project similar to one performed in the past, you can use existing requirements as a foundation for your current project. This approach reduces effort, and you may be able to improve on the previous solution based on past feedback.

For software applications, creating a prototype can encourage creative ideas and help users explain what they need. A prototype is a rough model used to test an idea. Built early in the development phase of the project, it provides insight into how an application will look, feel, and work. Prototypes are used to gather and document requirements, and, after feedback, gain additional requirements.

The prototype, or even a rough draft of the requirements, can act as a straw man for stakeholders to critique. Users can use the draft as a tool to better articulate their needs. By stating what they do not need, stakeholders show what they are seeking in the project.

Uncovering Assumptions

As the project evolves, you may discover implied requirements that were never documented. You may also find infeasible requirements given existing project parameters. Additionally, extraneous requirements may be identified.

The requirements baseline for an archival project is the standard agreement that pending change requests are measured against. Its purpose is to fend off defects and poor quality, as well as the small, undocumented changes to the project scope—collectively called scope creep. When stakeholders sign off on the requirements scope, they agree that these identified needs will serve as the baseline for the project, and these items are mandatory for project acceptance.