Methodology

I define methodology as the systematic study and application of methods in a field. First, I see it as a way to select methods. Second, I see it as a way to apply methods. Third, I see it as a way to evaluate methods. In short, I treat methodology as a set of methods used in combination to solve a problem.

Moreover, I use methodology to structure my work. For example, I choose templates to document requirements. In addition, I use model-based notations to express goals and relations. For instance, I draw AND/OR trees when I need to show subgoals and alternatives. Thus, I show that all subgoals must hold with AND. Likewise, I show that at least one subgoal must hold with OR. Therefore, AND/OR trees help me link detailed goals with higher-level goals.

Furthermore, I apply goal-oriented languages when requirements include non-functional needs. For example, I use GRL to model goals and to reason about trade-offs. Also, I apply KAOS when I want to derive clear requirements from goal models. In addition, I use the i* framework when I model organizations or socio-technical systems. As a result, I create models that show actors, dependencies, and rationales. Consequently, I trace requirements back to stakeholder goals and reasons.

I choose notation based on context. If I work on systems engineering, I often use SysML block definition diagrams. Meanwhile, if I work in agile projects, I prefer lighter artifacts. For example, I use user stories and iterative prototypes. Likewise, I adopt Scrum ceremonies such as refinement, planning, and sprint review to incorporate formal review ideas in the agile flow. Therefore, I blend rigorous inspections with agile practice when needed.

When I review requirements, I pick a review method that fits the risk level. For low risk, I use walkthroughs. For high risk, I use inspections. Moreover, I select inspectors from peers, business, users, and experts. Then, I ask them to check the work product against standards and objectives. Also, I prepare checklists and individual reviews before the meeting. As a result, the inspection yields a clear list of defects and actions.

In addition, I use exploratory techniques to validate requirements early. For example, I run prototyping sessions. First, I build a throwaway prototype to test ideas quickly. Second, I run an evolutionary prototype when I plan to extend the same artifact. Then, I invite stakeholders to use the prototype. Afterward, I collect their feedback. Consequently, I discover usability issues and missing requirements early. Therefore, prototyping supports incremental and design-thinking approaches.

I advise selecting a methodology by weighing goals, risks, team skills, and constraints. For instance, if safety matters, I pick formal inspections and rigorous documentation. However, if time to market matters, I pick iterative delivery and MVPs. Also, I mix methods. For example, I combine goal models for rationale and prototypes for user feedback. Thus, I ensure traceability and validation at the same time.

Finally, I stress that methodology is not fixed. Instead, I adapt it. Moreover, I measure outcomes and refine my method set. Therefore, I improve my process step by step. In conclusion, I treat methodology as a living combination of methods. Consequently, I stay effective, transparent, and aligned with stakeholder needs.