Software Requirement Specification and diagrams

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.