I have to write a System Requirements Specification for an upcoming project and it is the first time that I draft such a document. In my case we are creating a smartphone App which will have a basic application and a couple of well defined sub-modules that can be acquired.

I am now asking myself how to handle such a case in a SRS: Should I write different SRS for the sub-modules or should I keep all in the same document? Some of the sub-modules will exist from the launch of the app, some will be defined and coded at a later time.

1 Answer 1


I associate a set of requirements (in whatever format) with a releasable entity. So, my question would be: Are these submodules going to be independently released from the application?

If you are developing libraries or reusable components that you want to design, build, and version independently for traceability, then each component will need its own set of requirements. If you're using a requirements management tool, that could be just assigning a label or tag or some other kind of attribute to each requirement so they can be managed independently or in conjunction with others. If you're using documents, then separate documents would be the way to go.

However, if your sub-modules are simply logical pieces of code that are not independently built and released, then there's no need to split up your requirements at once. The overhead of managing multiple requirements sources is not necessary.

There are also two caveats here:

At a system level, you could make the argument that it doesn't matter what your underlying architecture is. The requirements are capturing what the system does without regard to how it's implemented. The set of requirements are levied against your system and it's a design decision on how to realize those requirements.

Planning for reuse too early is generally wasteful. If your implementation is only going to be used in one or two applications, then rewriting the implementation is usually safer. There's added complexity in making a robust, reusable component and you don't typically see value until at least 3, if not more, instances of reuse of the component. By that time, it may make more sense to refactor and extract.

My recommendation would be to start with one set of requirements. However, by appropriately labeling them and allocating them, you can be prepared to refactor your requirements. I would recommend using at least a spreadsheet application to manage requirements over a word processor, since there are some inherent sorting, filtering, and data analysis features that can make it easy to manage requirements over a long term project.

  • Thanks for the advise, I will consider that!
    – Mark
    Commented Jun 26, 2019 at 8:38

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.