When working on relatively small projects, but a software requirement specification document is necessary, is it a standard to include said document on version control systems or is it managed differently. Note I'm talking about standards

  • Version control standards are still evolving. I've read articles where apparently some are dumping entire VMs with development environments in them to avoid loosing the toolset that can compile the software. Perhaps worrying about standards is the wrong way to look at this, instead you should ask if you gain by doing so. Existing tools would make it easy to spot differences in new versions, for instance.
    – John O
    Apr 7 '15 at 20:54
  • @JohnO: I once worked at a place where we officially had to use StarTeam as our VCS, but one group preferred SourceSafe. Their solution was to periodically check the entire SourceSafe repository into StarTeam as a blob. Technically compliant with policy, but . . . :) Apr 7 '15 at 20:58
  • @RandallCook Where I work, we have 3 VCS, and few if any standards. 3 years after we officially switched to git, I still have to dig things out of svn occasionally, supposing they were checked in in the first place. And then there is SCM Harvest, which Wikipedia says dates back to the late 1970s. But all of this is ok because we have 3 ticketing systems and 3 IDEs too. I want to cry.
    – John O
    Apr 7 '15 at 21:42

Yes and no. Version control is about just that: control of revisions of assets, be they source code text files, images, or even documentation. While software engineers usually put source code and graphical assets (once they receive them) under version control, graphical assets and standards documents are often prepared by non-engineers. In my experience, these people rarely work under version control (though it could be argued that they should).

Another reason why requirements specifications are not often under version control is that they are often not text files (Word documents, spreadsheets, or Google documents are common) and thus versions cannot be compared easily by many version control systems. Yes, modern word processors can intelligently compare different revisions, but sometimes that feature cannot be invoked by the version control system.

In spite of this, there is a natural tendency for people to understand the importance of preserving old versions, and I have seen various ad hoc methods used by non-engineers, like adding revision numbers or dates to the filenames, for instance.

You ask about standards, and I know of no commonly-applied official standards requiring which assets need to be under version control and which do not. This is a managerial and organizational choice, and it varies from place to place. Some enterprises have clear policy around this, using in-house or externally-defined guidelines, or special software tools, others do not.


Although I agree with most of Randall Cook's answer, I would like to add some additional things.

Your requirements should be under configuration management and be controlled in some way. That is, you should be able to associate a given set of requirements (perhaps captured in a SRS document or a collection of user stories or a database or some other format) to a given software version. For any given software version, you'd probably want to know what the requirements, design, implementation (source code), test cases (test code, scripts, manual procedures), and perhaps even test results are. This aspect of configuration management is called "configuration identification".

One aspect of configuration management is version control. However, how you implement version control could be different depending on the type of artifact. Source code could be kept in tools that are well-suited to managing software (which is usually text files) - tools like Subversion or git. However, different tools may be necessary to properly version other artifacts. Requirements management tools, such as DOORS, often have change management workflows and support the versioning of requirements. For documents, a content management system may allow you to track versions as well.

As far as standards go, there are standards for configuration management, there are many, some active and some withdrawn or superseded - ANSI, ISO, IEEE, the US Department of Defense, industry specific practices for a number of different industries, and so on. How applicable they are to you depends on a various factors - contractual or regulatory obligations, project size and type, industry, to name a few big ones. They may provide guidance and a starting point for tailoring. Ultimately, though, it's up to the development organization to define a process that is suitable for their needs.

  • Great points, @Thomas. +1 Apr 9 '15 at 19:52
  • @RandallCook If you want to take anything from mine and make a single mega answer, feel free to. Hopefully yours would get accepted and stuck to the top and there would be credit in it to this answer. (Also, +1 on your answer for providing 95% of what I would have said).
    – Thomas Owens
    Apr 10 '15 at 13:51
  • Very generous of you, @Thomas. Well, you're a moderator, so if you want me to do it to make a better site, I am happy to do so. Otherwise, having our two answers mention each other is satisfactory for me. Apr 11 '15 at 0:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.