Software Requirement Specification In The Real World - Tobias Andersen - 2009 08 24

1,995 views

Published on

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?

Published in: Technology, Business
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,995
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
159
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • 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)
  • Software Requirement Specification In The Real World - Tobias Andersen - 2009 08 24

    1. 1. Software requirements specification in the real world – The good, the bad & the ugly<br />By Tobias Andersen <br />
    2. 2. ?<br />?<br />
    3. 3. Definition according to wikipedia...<br />A Software Requirements Specification (SRS) is a complete description of the behavior of the system to be developed. <br />It includes a set of use cases that describe all the interactions the users will have with the software. <br />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).<br />
    4. 4. Why?<br />Why do we need a SRS...<br />
    5. 5. At a glance...Where REQUIREMENTS can help<br />
    6. 6. What often happens...<br />Bad Requirements<br />Bad Assignment<br />
    7. 7. You cannot build what you do not understand<br />
    8. 8. No amount of SPIN can replace a quality product<br />
    9. 9. Starting off wrong, leads to a short life<br />Bad Requirements<br />Bad Execution<br />Bad Longevity<br />Bad Value<br />
    10. 10. Bad Input leads to Bad output<br />Bad Requirements<br />
    11. 11. So what is a better way?<br />The SRS lifecycle<br />
    12. 12. Its not a science<br />Can I do it?<br />
    13. 13. The Good (Case 1)<br />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.<br />Projected duration: 1 business day.<br />Estimated rate of success: &gt;75%.<br />
    14. 14. The Good (case 1) it was a piece of cake.<br />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.<br />Actual development time: 1½ business day.<br />Actual rate of success: 100%.<br />
    15. 15. The BAD (case 2)<br /><ul><li>Project brief: Substitute X resource with the document we uploaded last month to our clients corporate website.
    16. 16. Projected duration: ½ - 1 business day.
    17. 17. Estimated rate of success: 75% <> 50%.</li></li></ul><li>The Bad (case 2) we got lucky...<br /><ul><li>Technical brief: Substitute X resource with its predecessor (unknown document, ask Claus he worked on it a month ago) on the clients corporate website at ftp://mysite.com.See sitemap from UX @ server}{project} for further details on the resource-2-page mappings.
    18. 18. Actual development time: ½ business day.
    19. 19. Actual rate of success: 50%.</li></li></ul><li>The UGLY (case 3) it’s not a science, it’s black magic<br /><ul><li>Project brief: Hi Tobias. ”Your account manager asked me to forward you this email discussion that describes our change requests. If you have any questions feel free to contact me (p.s: I might be busy, but leave a message and I will get back to you ASAP.). Have a nice day!  ”
    20. 20. Projected duration: ? business day.
    21. 21. Estimated rate of success: <25%.</li></li></ul><li>The Ugly (case 3) not even the Beauty could love this Beast<br /><ul><li>Technical brief: Read this email thread and do the needful!
    22. 22. Actual development time: Just bill the client by the hour. Job nr. is 00911.
    23. 23. Actual rate of success: 0%.</li></li></ul><li>What have we learned<br /><ul><li>A well-crafted SRS document mitigates risk.
    24. 24. SRS does not have to be 50 page documents. It can be something as simple as a set of use cases defining the clients needs.</li></li></ul><li>How to convert the Ugly into the Good<br /><ul><li>When in doubt ask your client. If they don’t know, chances are you don’t need to know.
    25. 25. Express your needs in a form that a 5 year old could understand!</li></li></ul><li>Good Input enables Beautiful output<br />

    ×