ORD, SS, SRS, SDD, DBDD, IRS, IRD.

If that list of acronyms makes sense to you, then congratulations, you're in my field of work. They have recently taken on a more...pressing meaning for me, as for the first time in my professional life I have had to write the things as opposed to just use them to create software systems.

This would not be that bad if my college coursework had actually prepared me for the proper creation of these documents.

My job title is Software Engineer. I am supposed to be able to design and develop software systems. Yet my college coursework was long on developing and short on designing. Out of the many, many hours of credits for programming, only 6 were spent even remotely dealing with design - and even then properly creating a Systems Specification or deriving Requirements from the SS were not really the focus.

So, I have spent hours of hours of OJT learning to build these documents, mainly through trail and error, and I am thankful for a crusty old retired naval officer who is my company's Senior Systems Engineer who is able to provide me feedback on how I'm not doing these things right.

Oh but to see the proverbial red ink all over my documents.

Anyways, I did find a few links online that helped me (or harmed me, the jury's still out on that) and thought I would share them here.

• Writing Software Requirements Specifications
  
• BE Project Guidelines - Writing your System Requirements Specification (SRS)
• A Software Design Specification Template
• Software Requirements Specification - Model Text

Of course those things might not meet your company's needs for an SRS, and the one thing I found is that there are multiple ways of creating these documents. The more important thing is are you going to use Functional Decomposition or Object Oriented Design. And if you are still in college, then I highly suggest you try to find a course where these theories are taught by practical experience rather than book work.