What do you do next after creating an SRS?

Question

Having gone through the IEEE standard document (IEEE 830-1998) on what a Software Requirements Specification should contain I'm now looking for guidance on the next steps following the creation of an SRS

As I believe it an SRS is designed to ensure that the development team and customer are on the same page when it comes to figuring out the functionality and scope of the project. What I'd like to do now is go from this document and write up how to implement the project for the development team.

Essentially I'm looking for the next step after completing an SRS. I realise that broadly this is "implement the project", but how do you convert an SRS into something a developer can use? i.e. How do they know what tests need to be written?

Answer 1

If you were following a sequential process, the next step would likely be to design the product. There are different tools and notations that can be used for this, but if your process is expecting documents as outputs or evidence of completion, the document artifact would be a Software Design Description (SDD). IEEE Std 1016 IEEE STandard for Information Technology - Systems Design - Software Design Descriptions provides the outline for such a document. The latest revision of this document was published in 2009.

The standard does not mandate any specific design tools or methods, but Table 1 does provide examples of design languages that may be used to satisfy each of the viewpoints presented in the document, which range from various UML diagrams to IDEF models to IDL to decision tables. Additional examples of what may be expected are captured in the text of this standard.

Note that design is often an iterative process. The SDD format is designed to capture both high level (architectural) and low level (detail) design. In an iterative process, this would be a living document, especially the lower level detail design sections.

In my experiences, while the design and development team is off creating the SDD (and perhaps prototyping or even implementing some of the framework for the project), the SRS is also used by the test team to develop acceptance tests for the software. These are the requirements-based tests that will be used at the end of implementation to assert that the software meets the intended functionality. The development team will, throughout the design process, concurrently be working on the unit and integration level tests (perhaps in coordination with the test teams).

Answer 2

I agree with Thomas. I'd only add that in my experience, after the design is finished, the next step is to share the design with the stakeholders. This design is supposed to demonstrate HOW the system is going to implement the WHAT to do expressed in the SRS. Sharing the design with the stakeholders will give them the opportunity to pinpoint possible misunderstanding, which gives you the opportunity to fix them before you start the implementation stage.

It depends, of course, on the complexity of the requirements. Also, the project could be stopped at this point if the design suggests an implementation that goes over budget.