1

Over several years, a company developed a multi-disciplinary (firmware, software, hardware) product. No SRS (Software Requirements Specification) was ever written. A prospective customer now wants a SRS.

Any ideas how to approach writing one? Read the code? Write a user manual and convert it into requirements?

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
Mr. T.
  • 127
  • 2
  • [Sharing your research helps everyone](https://softwareengineering.meta.stackexchange.com/questions/6559/why-is-research-important). Tell us what you've tried and why it didn't meet your needs. This demonstrates that you've taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see [ask] – gnat Oct 23 '19 at 08:33
  • Do you have any kind of record of what the software developers were asked to develop? This could even be something like a ticket system. – Bart van Ingen Schenau Oct 23 '19 at 08:34

2 Answers2

3

The end-user isn't interested in the source code. There's no need to go down into the weeds like that. They are interested in the product as a whole.

Ask yourself "what does the product do?" Working with someone who knows it well, find all the things it does, and write a requirement or two for each thing.

Wherever possible, requirements should be testable. Consider how you will demonstrate that the product does what the requirement says it does. Test "by inspection" should only be a last resort.

If you are specifically after a software requirements document, then you need to work out the overall requirements first, and that should tell you what the software needs to do.

Simon B
  • 9,167
  • 4
  • 26
  • 33
2

I would question why a customer is asking for a Software Requirements Specification to be written for existing software. Requirements are typically used to drive design and test - you create a design that satisfies the requirements and then use tests that trace to the requirements to confirm that the design actually does satisfy the requirements.

For existing software (or any kind of off-the-shelf purchased products), I'd recommend a Software Design Description (SDD) of some kind. Tests - especially those written in BDD style - can describe the characteristics (functional and some quality attributes) of the software system in a way that can be understood by stakeholders. This can serve as one part of an SDD, with appropriate graphical, tabular, and textual models serving as another component. The level of detail greatly depends on the type of product you are making and the agreements and relationships with the clients who receive the documentation.

If an SDD isn't appropriate or suitable, you would have to work with the customer to understand exactly what concerns they are trying to alleviate and work with them to find the best ways to address them. That may mean reverse engineering a SRS from an SDD or the code or a running system.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • 1
    Thomas, in an FDA regulated environment, when you are purchasing software to be used within "the quality system", you still have to have a full documentation set for purchased software. Typically, you ask a vendor for their user and functional requirements documentation to stand in place of writing your own for their system. – HardCode Nov 20 '19 at 20:22
  • 1
    @HardCode None of my customers have had an issue accepting a functional specification in the form of BDD tests, test summary reports that detail the testing performed on every release, and generating their own URS. The vendor is not required to provide all of the documentation, but the regulated entity is required to have the full set. Where each piece comes from is not specified. – Thomas Owens Nov 20 '19 at 21:08