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.
Best Answer
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.