Systems Engineering Editing and Proofreading Services

A system is specified, built and delivered exactly as required, and the people who have to use it find that it does not fit how they work. Every requirement was met. The requirements were written by people reasoning about a system rather than about a shift, a crew, a route or a bad night, and no document ever described what the thing would actually be like to operate. That description had a name and a place in the process, and it was skipped because it produces no requirements of its own.

We edit what systems engineers produce — concept of operations documents and operational scenarios, stakeholder requirement specifications, system and subsystem requirement documents, requirement verification and traceability documentation, interface requirement specifications, system architecture descriptions and trade studies, verification and validation plans, integration and test strategies, human factors and operator workload documentation, system safety and hazard tracking documentation, configuration management and baseline documentation, and transition, training and support planning documents. Our editors work on the document that describes the system as it will be lived with.

The concept of operations is the document that decides whether a delivered system is usable, and it is the one most often written after the requirements it was supposed to generate. Its purpose is to describe the system from the point of view of the people who will operate, maintain and depend on it, in their language, before anyone has committed to a solution. We write these so it is organised around scenarios rather than functions — a normal shift, a busy period, a handover, a degraded day, an emergency, a maintenance window — because functions are what a system has and scenarios are what people experience; so each scenario names who is present, what they know, what they are doing simultaneously and what they will not have time to do, since a system requiring an operator's full attention during the one event when they have none has already failed; so the current way of working is described honestly, including the workarounds, as those workarounds encode real constraints and a system that eliminates them without replacing what they did will be worked around again; so the boundary is drawn around what the system will not do and who picks that up; so operational, maintenance and support staff are each given their own scenarios rather than being folded into a single user; and so it is written to be read by those people and confirmed by them, in language free of the acronyms the requirements will later need. Systems whose ConOps was written properly are recognisable on delivery.

Everything you send is treated in confidence, including requirements, designs and programme information. We are editors rather than systems engineers or human factors specialists, and we offer no view on requirements, architecture or operational design. What we can do is make the document that describes the lived system readable by the people who will live with it.