I'm a computer science student at some college out there but i'm a little confused with using the SRS and various diagram such as activity diagram or use-case diagram. I know the objective of the SRS is to minimizes the time and effort required by developers to achieve specific goals and to reduce the development cost as well as the interaction of the system.

May i ask, is it appropriate for someone to use this SRS information such as how the system work and develop a use-case diagram or any other diagram?

I'm a little confused with how the SRS, use-case diagram, activity diagram, etc etc actually interact.

I do understand certain function that is in one particular diagram must be reflected in specific diagram to ensure consistency.

But i can't decipher exactly what should be the same to ensure consistency.

  • 1
    SRS is one kind of document or manual that is used to describe the intended purpose,requirements,software quality attribute of project and nature of software to be developed.it include yield and cost of software.It provide framework that every team in development will flow.Diagram and specification are different thing. SRS is used to specify flow and cost of software.Diagram is used to show interaction with software
    – AjayGohil
    Commented Sep 14, 2020 at 4:15

3 Answers 3


To me, the fundamental objective of the SRS is to tell the software team what the software is supposed to do. This is an alternative to just making it up as you go along (aka "agile").

If you're going object-oriented, then you need to take an object-oriented analysis and design approach. Most likely, the first step is to identify the actors in the SRS and identify the objects (there may only be one at this level).

Then you can develop use cases. That's probably several use case diagrams unless you want a monstrously large diagram.

Later on, you'd break down the objects into packages, then into classes.

Consistency is done by traceability, all the way down. Every software requirement must be addressed by something below it in your design (often a use case, but not always). A "requirements matrix" is often the best way to document that.

In extreme cases (such as safety-critical), you may have to go so far with your requirements traceability that if somebody points to a line in your code and asks "what's that for?", you can trace all the way back up to answer exactly which requirement(s) it is helping to satisfy.

  • Plus one for making it up as you go along (aka "agile"). lol Commented Feb 16, 2017 at 18:26
  • 1
    I seriously recommend that you learn a bit more about agile methods and the motivation behind them. It is definitely not about "making it up as you go along" Commented Feb 16, 2017 at 19:59
  • @FrankPuffer: Actually, it kind of is. That's not necessarily a bad thing, though. Commented Feb 16, 2017 at 20:55
  • @RobertHarvey Only kind of though. You at least want to have a product vision. And the business should know what it wants at the start, more or less. Agility mostly just empowers the business to change its mind, prioritize better, and mitigate risk.
    – svidgen
    Commented Feb 17, 2017 at 0:48

Don't make things more complicated than they are. The SRS is simply a document describing what the software is supposed to do, but not how it is going to do it. It can be plain text but often it makes sense to include diagrams. Often it's a good idea to use standardized UML diagrams like Use Case or Activity. But this is by no means required.


A Software Requirements Specification (SRS) is a tool to aid in communication between stakeholders. It isn't meant to minimize time and effort or reduce costs, aside from helping to facilitate communications. SRS documents describe scope, provide a starting point for building test cases, and give a tangible thing to review and discuss.

IEEE Standard 29148-2011 - ISO/IEC/IEEE International Standard - Systems and software engineering -- Life cycle processes --Requirements engineering is the current standard for structure and content of an SRS. Although much of the discussion is around textual requirements, the standard does recognize other methods of capturing requirements, including visual models. UML (and similar languages or techniques) would be included as visual models. The standard even mentions data flow, control flow, state models, object models, "and many others".

Defining methods and approaches for visual models for software requirements is something that you can get an entire book on.

Personally, some models lend themselves better to requirements engineering than others. In UML, I find that Activity, State, Deployment, and Use Case diagrams tend to lend themselves better to requirements engineering (although I recommend avoiding Use Case diagrams in most cases). This doesn't preclude using other models (Class diagrams, Sequence diagrams), but they will likely be at low fidelity. Also consider UML modes, particularly UML as Sketch, as well as the Agile Modeling techniques.

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.