- Followings a series of intense brainstormings, a fairly well defined project should be picked-up. From there, a 'Black Box' approach is used to look at the targetted system from its most general point of view. A set of high level requirements should be clearly defined such as:
- motivations behind the creation of the system
- list all INPUTS
- list all OUPUTS
- desired transfer function(s) between Inputs/Outputs
- desired performance(s) (with accepted tolerances)
- discuss on robustness, sensitivity, variability.
- Keep in mind that each requirement is expected to be tested during the validation process
- Specifications should be seen as the driving forces of the project. Everything afterward is supposed to deal with how to fulfill them. It helps to keep focus on what has to be achieved. On the other hand, specifications should not be seen as a document written in the stone, it is a piece of information that should always be challenged and reviewed as the knowledge about the project increases.
- This step should be applied to parts, Devices and Systems.
The expected output of the specifications is a table listing all the previously defined requirements. The document should try not to be too wordy, it has to go straight to the point.
A standardized way of presenting should be defined so that it will be easier to browse through all the different components of the systems.
Once more, this list of requirements should match the future testing document.
- A Wiki-table is great as it can be easily standardized. The version system of the wiki will also help a lot to track changes in specifications as the project evolves.