Software Requirement Specification In The Real World - Tobias Andersen - 2009 08 24
•Download as PPTX, PDF•
6 likes•1,500 views
Software requirements specification in the real world – The good, the bad & the ugly. Why do we need software requirements specification, where does it go wrong (samples), who can do it?
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Software Requirement Specification In The Real World - Tobias Andersen - 2009 08 24
Similar to Software Requirement Specification In The Real World - Tobias Andersen - 2009 08 24 (20)
More from Hello Group
More from Hello Group (11)
Recently uploaded
Recently uploaded (20)
Software Requirement Specification In The Real World - Tobias Andersen - 2009 08 24
- 1. Software requirements specification in the real world – The good, the bad & the ugly By Tobias Andersen
- 2. ? ?
- 3. Definition according to wikipedia... A Software Requirements Specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints).
- 4. Why? Why do we need a SRS...
- 5. At a glance...Where REQUIREMENTS can help
- 6. What often happens... Bad Requirements Bad Assignment
- 7. You cannot build what you do not understand
- 8. No amount of SPIN can replace a quality product
- 9. Starting off wrong, leads to a short life Bad Requirements Bad Execution Bad Longevity Bad Value
- 10. Bad Input leads to Bad output Bad Requirements
- 11. So what is a better way? The SRS lifecycle
- 12. Its not a science Can I do it?
- 13. The Good (Case 1) Project brief: Substitute X resource with Y resource on the clients corporate website.UX have created a ”resource map”, which is located on our internal project server. Projected duration: 1 business day. Estimated rate of success: >75%.
- 14. The Good (case 1) it was a piece of cake. Technical brief: Substitute X resource with Y resource on the clients corporate website at ftp://mysite.com. See sitemap from UX @ {server}project} for further details on the resource-2-page mappings. Actual development time: 1½ business day. Actual rate of success: 100%.
- 16. Projected duration: ½ - 1 business day.
- 18. Actual development time: ½ business day.
- 20. Projected duration: ? business day.
- 22. Actual development time: Just bill the client by the hour. Job nr. is 00911.
Editor's Notes
- Dark arts of Software Requirement Specification. Why do we need it, where does it go wrong (samples), who can do it?
- 3 key points about SRS content according to wikipedia.
- Business processes are complex. (the devil is in the details) Software is rarely the work of a single individual. (teams need to communicate)