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?

  • 1
    Welcome to PMSE, James. I'm tempted to close this as "too broad," as how to create a complete project plan is a subject that fills whole books. Please narrow your question to something specific that can be answered in a couple of paragraphs. – Todd A. Jacobs Jan 24 '15 at 15:58
  • Thanks CodeGnome. I was hoping that the questions could be answered in a couple of paragraphs as I'm only looking for the next steps not a full project plan. Basically, "What comes next after an SRS?". I'll update the question. – James Pudney Jan 26 '15 at 6:09

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).


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.

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.