I define a method as the systematic application of one technique or a set of techniques to reach an objective or to create a work product. First, a method gives me a clear path. Then, it breaks work into steps. Next, it tells me which techniques to apply. Therefore, I reduce ad hoc decisions. Moreover, I can repeat the process. Consequently, I improve predictability.
In requirements engineering, I treat a method as a structured sequence of elicitation, analysis, specification, validation, and management activities. For example, I can follow a method that bundles interviews, workshops, and prototyping. Furthermore, I can choose another method that relies on pairwise comparisons to set priorities. Specifically, the Analytic Hierarchy Process (AHP) uses pairwise comparisons. In AHP, I compare two requirements at a time. Then, I decide which one is more important and by how much. However, I must compare every pair. As a result, for n requirements I create n(n-1)/2 comparisons. This grows fast. Consequently, I plan for significant effort. Nevertheless, AHP gives me a consistency ratio. Thus, I measure how reliable the evaluations are. Therefore, I can detect and reduce evaluator errors. Finally, a tool or an expert can compute the final priorities for me.
I choose methods based on constraints and goals. For instance, I select agile-oriented methods when I need fast feedback and flexible scope. Conversely, I select plan-driven methods when I need detailed upfront requirements. In addition, I often tailor a method to the project. For example, I combine agile practices like Scrum, XP, or Kanban with formal techniques such as GQM or AHP. Moreover, I plan more than one elicitation activity. Thus, I capture different stakeholder views. Similarly, I mix techniques within the same method to cover multiple needs. Therefore, I increase the chance to discover hidden requirements.
I focus on practical aspects when I apply a method. First, I assess organizational culture and structure. For example, I check how decisions travel across departments. Then, I adjust contact points and invitations for leadership. Next, I consider who will evaluate and who will use tools. Also, I estimate effort and cost. For example, I calculate the number of pairwise comparisons if I plan to use AHP. Furthermore, I prepare clear scales and guidelines for evaluators. As a result, I improve consistency and reduce rework.
I highlight strengths and weaknesses. On the positive side, a method gives me repeatable steps, measurable outcomes, and a known effort. In addition, it helps me balance trade-offs and align stakeholders. On the negative side, a method can require significant planning and effort. Also, some methods need training or tooling. Therefore, I weigh benefits against costs before I adopt a method.
In practice, I follow process patterns and proven recipes. Consequently, I avoid reinventing the wheel. Nevertheless, I remain flexible. Accordingly, I tailor or hybridize methods when needed. In summary, I use methods to turn techniques into outcomes. Therefore, I achieve objectives with clarity, control, and measurable quality.