By Eugene le Roux, mechanical engineer, one of his regular online articles on general project management principles.
Would you like to guide me in my thinking about writing project requirements?
Eugene le Roux, retired mechanical engineer.
© RACA Journal
If so, let’s consider the following:
They say a requirement must be legal, complete, and consistent. Would the requirement be complete if we cover all the system levels which were agreed upon with the client? For example, a system level up to level 6 (which defines the operator of the system) is a typical requirement.
- Would it make sense to also address the expected lifetime of the product, or service, that must be delivered? For example, a vehicle fleet might have a planned life application of 20 years.
- Would it further make sense to state with what products or services this project must interface, and at which scheduled times, and on which system levels?
Would you not agree that all details covered by the above mentioned, must be consistent among each other. For example, the operator on system level 6 (the user of the system) must be capable of applying the complex system and its software. Or if the expected lifespan of the vehicle is 20 years, the reliability must be qualified to match it (although it must not take 20 years to do so).
Could the requirement of each component be derived from the System Engineering Process (SEP), where the high-level requirement is cascaded down to component level, based on simulation and modelling of the system behaviour? Yes, but to what degree of system detail must the requirement be written?
Could one say that a requirement for a system must be based on system thinking?
This is where I look your way for your well-seasoned experience to guide us.
