Requirements source

I define a requirements source as the origin from which I derive a requirement. For example, a stakeholder, a document, an existing system, or an observation can provide that origin. In practice, I identify origins early during elicitation and document them clearly. This way, I can trace each requirement back to where it came from.

For example, during an interview a time traveler tells me that her colleague usually performs an action I asked about. In addition, she refers to time travel process documentation. Consequently, two potential origins appear at once. Then, I ask for the colleague’s name and for details about the document. After the interview, I check my source register. If the colleague or the document already appears there, I mark them as confirmed. If not, I add them as new candidates. Thus, one lead often points to the next, and I still expect new leads late in the project.

I use two approaches to find requirements sources. First, I use pragmatic identification and rely on experience to list likely stakeholders, documents, and systems quickly. However, I do not stop there. Second, I use a systematic method. I define criteria for what counts as relevant and run a targeted search. For instance, I apply the snowball principle and ask each identified contact for more people, systems, or documents. Moreover, I define elicitation objectives that focus specifically on finding origins, not only on collecting needs. As a result, the broad goal of “find what matters” turns into concrete tasks.

I group origins into three main types. First, stakeholders such as users, managers, and external partners. Second, documents such as policies, process manuals, and legacy specifications. Third, systems such as current software, hardware, and integrated services. In addition, I inspect processes and events around the system, and I use organizational charts and logs when they help. For each elicitation task, I define what “good enough” looks like. For example, when I search for users, I require a name, a role, and contact data.

Missing a relevant origin creates risk. Incomplete inputs lead to incomplete requirements, which can reduce user acceptance, delay approvals, or overlook legacy behavior. Therefore, I review the source register regularly, re-check relevance, and retire obsolete entries to keep the repository accurate.

In practice, I work in a repeatable cycle. I ask interviewees for names and references, update the register, expand it with the snowball principle, and repeat throughout the project. Thus, I maintain a current and complete set of requirements sources. As a result, I improve traceability and strengthen the overall quality of the requirements set.