Software Engineering Srs Code And Asks
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. It isn't meant to minimize time and effort or reduce costs, aside from helping to facilitate communications. 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.A Software Requirements Specification (SRS) is a tool to aid in communication between stakeholders. Every software requirement must be addressed by something below it in your design (often a use case, but not always).
Also consider UML modes, particularly UML as Sketch, as well as the Agile Modeling techniques. This doesn't preclude using other models (Class diagrams, Sequence diagrams), but they will likely be at low fidelity. 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). 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. UML (and similar languages or techniques) would be included as visual models.
0 kommentar(er)
