What techniques can help you gather complete and accurate requirements in systems engineering?

Design thinking can really help here: consider the stakeholders, including various kinds of users and operators, maintenance and operational personnel. Then understand in clear and practical terms what they actually do, what they are accountable for, what information they need at any given point and how they use it to take action.

Stakeholder 'needs' is unfortunately broadly misunderstood. Simply asking users/stakeholders what they need/want will mostly lead to 'faster horses,' using a Henry Ford analogy. Instead, understand what they want/need to achieve; understand their desired outcomes. In the Henry Ford analogy, their desired outcomes ('needs') can be phrased as: to go from point A to point B; within x time, with y people, safely, comfortably, etc... the solution/design choices will include faster horses, cars, hyperloop tech, or teleporters (driving tech evolution in the future). Then, it becomes a cost/benefit analyses and a risk evaluation based on the users' mission/use cases and the $/maturity of the technology, etc.

Develop a CONOPS involving all stakeholders. Given the system define the requirements engineering program, which includes: Requirement engineering considerations: Development of effective requirements Derived requirements Requirements testing Requirements development Requirements compliance Requirements revision Requirements traceability Requirement documentation Requirement language Redundant requirements Inductive and deductive requirements Associated standards and codes

In meinen Arbeitsalltag habe ich h?ufig erlebt, dass die Stakeholder Analyse nicht durchgeführt worden ist und sich direkt auf die Modellierung technischer Anforderungen gestürzt worden ist. Das Problem hierbei: Man startet die Entwicklung ohne überhaupt verstanden zu haben was Kunden, Anwender und viele mehr für Erwartungen an das Produkt haben. Neben all den Erwartungen die ein Produkt erfüllen soll haben sie ebenfalls die Chance den Zielkorridor zu verkleinern indem sie unn?tiges Ausklammern. Ein abschlie?ender Faktor ist das Vertrauen das sie durch gezielte Kommunikation und einbeziehen in den Entwicklungsprozess zu ihren Stakeholdern aufbauen k?nnen.

In my career, mediating objects have always served me well. To have something, a prototype, an intentionally thought provoking rendering, or something unachievable sparks stakeholders to express requirements that they would otherwise have been unable to express, but nonetheless expect or desire. In general, I advocate a plethora of methods to capture all possible facets.

When it comes down to complex systems thinking, almost everything around a physical, procedural or logical system can be modeled. The key is knowing how to break your system down into functional blocks or subsystems that can be modeled. It doesn't matter if you are using simulations, mathematical models, physical models of any of this but its also important to understand model ownership, interactions, boundaries and data in/out .. if you don't have a deliberate plan with it comes to your requirements modeling you are likely to end up with Garbage in / Garbage out...

There are the super fancy methods, and then there is the quick and dirty $100 method. For customer requirements, ask your customer to allocate $100 to the requirements (the amount can be adjusted to fit your product, if you are for example developing airplanes). Make sure to have a selection of customers that represent your target group, that goes without saying right?

I advocate comprehensive requirement models for traceability. We need to get rid of document based requirements management! For full traceability, requirement models should be integrated with all design domains: requirements, systems, technical, test. After all, requirements cannot be broken down without context. If you are really good, you get your process domain in the same model to capture traceability to you process requirements.

Requirements traceability ensures a holistic end-to-end view of actionable requirements consumable by the necessary stakeholders. It allows the architects and project managers to visualize where gaps exist and whether necessary verification and validation tests have been implemented. Easier impact analysis is also one of the major benefits of requirements traceability.

In a project in which the solution is complex, cross domain and encompasses multiple systems integrated together, it could be useful to ensure all requirements are captured comprehensively, by performing a Scenario Requirement Analysis. Step through various scenarios in which you expect the system to be operating in, and specify the performance parameters the integrated system is expected to achieve. The specific requirements for each system, is then a consequence of these system-level performance parameters. Have all stakeholders contribute and acknowledge their parts in this Scenario Requirement definition, which then becomes the starting point for all design and requirement considerations, including tradeoffs.

Before starting stakeholder analysis, it’s important to understand the scope of the project. This would inform the engineer of what requirements are acceptable in requirements development.