The publication of my Emerson Exchange presentation on the Emerson web site (see below) reminded me again of the poor state of documentation for SIS. I spent most of this week jetting around the country talking to people about these issues, which we are making very little progress in solving. As more groups with divergent needs get involved in the SIS lifecycle things are getting worse not better as every constituency wants to hang an “ornament” on the SRS “christmas tree”. I think that the recommendations in this presentation need more emphasis than ever. The primary points being:
1. Consider the audience of the spec, and write to them. E.g., if you are preparing a spec that will form the basis of a logic solver purpose – give them all of the information they need, but not extraneous information that don’t use.
2. Avoid duplication. Refer to other documents if necessary. Creating a single SRS document that contains everything is usually a very big mistake.
3. Don’t prepare a safety case. Specifications are meant to convey the requirements of a piece of equipment to others who use the information as the basis for purchase and installation of the equipment. If you feel the need to “prove” you met the requirements of the standard, you can prepare a separate safety case.
4. Don’t put operating instructions into a specification. Information that tells people what to do and how often to do it are operating instructions (e.g., functional test interval). If that information shows up on an equipment spec, you’re sending it to someone who doesn’t need it (i.e., the equipment vendor), and not conveying it to the people who do need it (i.e., the I&E maintenance department).
Hopefully, we’ll be able to get this documentation issue straightened out after a few more years of implementation of SIS in accordance with the standards.