How do you adapt your requirements gathering process to different types of complex systems?

2 Choose the right techniques

When you know the system type, you can select the most suitable techniques to obtain requirements from varied sources such as users, customers, domain experts, and system components. Depending on the system type, you may need to employ different techniques to capture different aspects of the requirements, such as functional, non-functional, quality, user experience, and ethical requirements. For example, interviews and surveys are useful for obtaining information from users and customers about their needs, preferences, expectations, and satisfaction with the system. Observation and ethnography are helpful for understanding the context, culture, and behavior of users and customers in their natural environment. Workshops and brainstorming are advantageous for generating ideas and solutions with stakeholders and domain experts as well as validating and prioritizing requirements. Prototyping and testing enable creating and evaluating mock-ups or prototypes of the system with users and customers as well as identifying and resolving issues and feedback. Analysis and modeling are beneficial for describing and specifying the structure, behavior, and interactions of the system components in addition to verifying and validating requirements. You may need to combine or modify different techniques to suit the specific system type as well as available resources and constraints.

3 Document the requirements

After gathering the requirements, it's essential to document them in a clear, consistent, and traceable way. Doing so will help you communicate them to the development team and other stakeholders, as well as monitor and manage their changes and dependencies. Depending on the system type, different formats and languages may be necessary to document different aspects of the requirements, such as text, diagrams, models, scenarios, or stories. Natural language is the simplest and most common way to document requirements using plain text; however, it can also be ambiguous, inconsistent, or incomplete. Structured language is a more formal and precise way to document requirements using predefined syntax and semantics (e.g., logic, mathematics, or XML). Graphical language is a more visual and intuitive way to document requirements using symbols and diagrams (e.g., UML, BPMN, or ERD). Executable language is a more dynamic and interactive way to document requirements using code or scripts that can be run or tested (e.g., SQL, Python, or Cucumber). Different formats and languages may be necessary for different types of requirements or stakeholders in order to ensure compatibility and interoperability with the system components.

4 Review and refine the requirements

Finally, you need to review and refine the requirements throughout the development process to ensure they are complete, consistent, accurate, and feasible; this will help you avoid errors, conflicts, gaps, and changes that can affect system quality and performance. Depending on the system type, you may need to use different methods and criteria to review and refine different aspects of the requirements. Analysis is a method of checking for logical consistency, completeness, and correctness; testing is a method of checking for functional consistency, usability, and reliability; inspection is a method of checking for quality consistency, clarity, and compliance; and evaluation is a method of checking for value consistency, relevance, and satisfaction. You may need to use different methods and criteria for different types of requirements or stakeholders in order to adapt to changing needs and expectations. By following these four steps you can ensure that your requirements gathering process is suitable for complex systems and meets the needs and expectations of your users and customers.