Requirements Gathering: 10 Best Practices for Simulation Project Success

In product development, a requirement is a physical or functional need that a particular design must fulfill. It defines the gap that a necessary or desired capability, feature or characteristic will bridge to provide value and usefulness to the stakeholders, be they users, customers organization, etc.

Requirements are used both at the start of a project (“here’s what this needs to do”) and at the end, as part of the verification process (“does it actually do what we need it to?”).

Because of this, the quality of the requirements gathering phase is critical to the success of a project — a strong house requires a strong foundation. For a simulation project to be successful, the very first requirement is to define its goals and needs fully, so that no time is wasted on non-essentials. This may seem obvious, but vague discussions can lead to requirements that that turn out to be incomplete or worse, misleading.

Getting Started

The best way to gather requirements is to engage in a formal process, with documentation that invokes review and sign-off by all the stakeholders in the project. Set a clear definition of the scope of the project – and ensure everyone agrees to it! This makes it much easier to turn down the costly “wouldn’t it be nice if…” requests that inevitably appear midway through design and implementation.

  • A summary description: Are you building a driver trainer, or studying the geometry of proposed suspension designs with a driver in the loop? It’s important to define the project correctly, since this will indicate the area in which the bulk of the efforts will be invested. In the above driver trainer example, a basic suspension simulation is probably enough; time and effort will be better placed on building training scenarios instead.
  • A list of key objectives: These are the high-level goals that must be achieved for the project to be considered a success. For example, “simulator will include a 6DOF motion platform,” or “simulated area will cover at least 1km2.” Be honest here, and include only the true key objectives.
  • A full description of the intended simulator hardware: Itemising available computers, displays, controls, etc., will help avoid optimization issues later on. Note that for some projects, the hardware will be decided upon only once the requirements are set, specifically to meet them – that’s okay too.
  • Constraints: If there are any known constraints, they should be listed here as well. Is a first iteration required in time for a trade show, or a high level meeting with critical stakeholders? Is the project using a new technology? Must the simulator be easily moved?

All that said, once you’ve laid the foundations, successful project completion depends on the execution of a number of best practices.

10 Best Practices to Follow for Project Success

Clear and stable requirements definition will give any project an increased chance of success.

  1. Involve all stakeholders from the start. The project should begin and end with them. Consult the end users and subject matter experts if possible, and not just the people who will be signing the check.
  2. The requirements document should be fairly stable. Requirements are written by humans and are thus subject to ambiguity, incompleteness, and inconsistency. Clarifying them early typically cost orders of magnitude less than when these same issues are found later in product development. Note that in Agile methods, elaborating details may be done on a just-in-time basis, but the high-level, baseline requirements should still be set at the start!
  3. Be clear, concise, and avoid jargon if possible. Requirements are a means of communication between the stakeholders. They should be easy to understand by normal users and developers alike, so technical jargon, acronyms and other obscure references should be avoided. A common way to document a requirement is stating, in plain text, what the system must do. For example: “The simulation must include three different loads for the crane to lift.” Other methods involve use cases and user stories.
  4. Make sure requirements are measurable. They should be based on objective facts, not opinions, and have only a single possible interpretation. Vague definitions, adjectives (“the simulated vehicle should look cool”) and other subjective formulations must be avoided, as well as negative statements. This also helps make sure that no requirement contradicts another.
  5. Requirements are not solutions! The stakeholders should explain the end results that they seek and the needs they have, not how to get there. For any requirement that calls for a specific technical feature or implementation, you need to understand why the request is being made – otherwise it is suspect. There may be an easier way to answer the need that is unknown to the stakeholders. Identify problems and needs before attempting to solve them.
  6. All requirements must be verifiable. They must be written down in a way that ensures they can be tested, inspected, reviewed, verified, etc. Avoid words like “always” or “never” (since proving this would involve an infinite testing cycle!). Requirements should have clear success criteria, and be realistic, both in time and scope. Don’t hesitate to present them back to the stakeholders to confirm your understanding. This should be done before the project starts since changes become much more difficult once work has begun.
  7. Never make an assumption about what the customer wants. Including a force-feedback steering wheel is obvious for a driving sim? Maybe the client has budget and space restrictions, and needs joystick controls instead. It pays to ask! Never be afraid to go back and ask additional questions if there is any doubt.
  8. Each requirement should address one need. If your requirement contains a conjunction (“do this and that”), it can probably be broken down into two separate ones. Having single-purpose requirements makes it possible to create functional mockups or prototypes along the way. You don’t need the full, final environment and scenarios to test drive a vehicle model, for example. This can prevent nasty surprises when using complex or cutting-edge technology, especially considering their potential for teething problems.
  9. All requirements should be prioritized. No plan survives contact with reality. You may not have time to do everything, so what is critical to the success of the project? What could be done later, or not at all? For example, having proper hydraulic systems response would be a “must have” in a heavy machinery simulation, but being able to easily modify the logo on the vehicle’s door? Not so much.
  10. Document, document, document. Everything should be written down in a place that every stakeholder can access. All requirements must be fully stated in one location with no missing information. This can help you avoid confusion and recriminations later.

What are your tips for project success? Do you have any lessons learned to share? Drop us a line to let us know, and we’ll share in a future blog post. You can also discuss the issue with other simulation users on the Vortex Studio Community Forum.