© 2010 Ugur Akinci
Sometimes technical writers confuse software requirements specifications for system specifications. While in certain cases they may prove to be the same, they are different in nature for a very simple reason: a system may include more than a software component. There are countless systems which comprise of software AND hardware AND networking AND etc. components. That’s why system specs cannot be assumed to be one and the same as software (or hardware) specs.
So how do we as technical writers differentiate between these two specs and how do we write them?
It’s best to illustrate it with a concrete example.
Let’s say that System Requirements Specification of an integrated security camera system require the following functionality:
“The system shall take and safely store full-color 300 dpi resolution 6″x9″ JPG images of the Casino game room 20 times a minute, 24 hours a day.”
You now need to “partition” this requirement and spell out its implications for the software, hardware, and networking subsystems that make up the total integrated security system.
For example, your related Software Requirements Specification should read (just an example):
“The SafeGuard software shall trigger the camera 20 times a minute, 24 hours a day, to take pictures of the Casino game room and store the images in BU relational database with redundant backup.”
The corresponding Hardware Requirements Specification should read (just an example):
“The CCTV camera Mohawk 34B7 shall be able to take full-color 300 dpi resolution 6″x9″ JPG images when prompted by the SafeGuard software and then send it to BU relational database for storage.”
You might even have a Networking Requirements Specification that reads:
“C1 network shall transfer full-color 300 dpi resolution 6″x9″ JPG images through RS485 wiring between CCTV camera Mohawk 34B7 and DB facility where images are stored in BU relational database. The network shall support 32 cameras, 16 simultaneous users and 1 Terabyte of data load per day.”
More often than not these conceptually separate specs are thrown together and written in one “design document” or “spec document.” But as a professional technical communicator you should be aware of the analytical differences between different kinds of specs and how they work together. The larger and more complicated a project gets, the more troubles you’ll avoid by keeping such specs separate.
Did you like this post? Can we improve it in any way? What do you think? Please feel free to share your mind…
nice explanation!!!