0

After the review of requirements for the last sprint, I was reminded that a revision to the Software Requirements Specification (SRS) Document where we focus more on user requirements would be value added. It would remove many of the requirements that still reference implementation details (e.g. specific folder paths, log filename formatting, internal calculation steps, etc.) and how the application works, and it would focus more on the what is required for the application to do.

We have a Software Detail Design Document that covers many of those details and this change may improve maintainability of documentation. The SRS would refer to the Detail Design as needed, giving the developers the freedom to implement the functionality without triggering an update to the document.

My manager answered to keep in mind though that there are multiple levels of requirements. There are user requirements (or user needs), system level requirements, and the SRS. The SRS in their experience can go into verification of the implementation in detail. Another Software Engineer in the team answered that those details don't belong in the SRS in their experience.

Documentation online consistently directs to specific - not explicit - requirements. The examples I found of SRS Documents didn't go into any implementation details.

Is there a more standard way to determine if a software requirement is specifying implementation details?

2
  • Addressing issues that arise between design and implementation by separating the two shows how this is over design and over thinking. This is a route to unnecessary complexity. I would try a lean agile approach agile where you talk things out. Sep 25, 2022 at 11:18
  • I think that requirement details and implementation details are two separate concepts that are being mixed here. I suggest asking "Is there a more standard way to ensure that functionality that has been implemented is based on software requirements?". The answer is automated tests which fulfill the need for implementations to have specifications. Mar 23, 2023 at 18:40

2 Answers 2

0

Yes, there are some guidelines that can help in determining whether a software requirement is specifying implementation details or not. Here are a few:

  1. Focus on the "what" rather than the "how". A requirement that specifies what the software should do is likely to be a higher-level requirement, whereas a requirement that specifies how the software should do it is likely to be a lower-level requirement that specifies implementation details.

  2. Use the "inverted pyramid" approach to requirements. Start with high-level requirements at the top of the pyramid and drill down to lower-level requirements that specify implementation details. The lower-level requirements should be derived from the higher-level requirements.

  3. Use the "SMART" criteria for requirements. SMART stands for Specific, Measurable, Achievable, Relevant, and Time-bound. A requirement that meets these criteria is more likely to be a high-level requirement that specifies what the software should do, rather than a lower-level requirement that specifies how it should do it.

  4. Use the "gold plating" test. Ask yourself whether a requirement adds value to the user or the system. If it does not, it may be specifying implementation details that are not necessary.

  5. Is the requirement necessary to meet the user's needs? If the requirement is not necessary for the user to achieve their goals, it may be an implementation detail.

  6. Is the requirement verifiable? If the requirement cannot be verified through testing, it may be an implementation detail.

  7. Does the requirement have any performance implications? If the requirement has performance implications, it may be an implementation detail.

  8. Is the requirement related to a specific technology or platform? If the requirement is specific to a technology or platform, it may be an implementation detail.

  9. Is the requirement specified at a low level of detail? If the requirement is specified at a low level of detail, such as specifying specific variable names or function calls, it may be an implementation detail.

These are some general guidelines and questions that can help you determine whether a software requirement is specifying implementation details or not.

0
0

The answer may be in the question. If the requirement takes from the developers the freedom to implement the functionality without triggering an update to the document, then there is too much detail in the specification.

With that in mind, a good requirement can still follow the Characteristics of good requirements (i.e. address only one thing, be fully stated, not contradictory with respect to other specs, comply with traceability, be verifiable, etc.) without locking implementation.

2
  • Welcome to the community. Your answer would be better if you gave more context on the info you linked to. This answer may get flagged and removed as "link only" answers don't provide context and the link can go stale. What about that link is good that you can summarize here? See sqa.stackexchange.com/help/how-to-answer
    – Lee Jensen
    Sep 22, 2022 at 19:41
  • I edited to include a summary of the characteristics in the hyperlink. Thanks for your feedback.
    – OwnDevise
    Sep 23, 2022 at 20:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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