www.qbi.in
www.qbi.in
www.qbi.in
www.qbi.in
www.qbi.in
www.qbi.in
www.qbi.in
–   Company wide same document structure is followed–   Easy to Read–   Easy to do Quality Checks–   Suits your requiremen...
–   Different Readers the document is aimed at–   Specific Sections of interest to a particular audience–   Document Depen...
– Glossaries are integral to Requirement Documents– You can prepare a common glossary for your domain and  utilize it afte...
– Standard Notations allow you to remain consistent– Examples: UML 2.0 , BPMN 2.0                                         ...
www.qbi.in
www.qbi.in
www.qbi.in
www.qbi.in
www.qbi.in
www.qbi.in
1.   Correct            6. Verifiable2.   Unambiguous        7. Modifiable3.   Complete           8. Traceable4.   Consist...
• Correct: every requirement given in SRS is a  requirement of the software• Unambiguous: every requirement has exactly on...
• Ranked importance: essential vs. desirable• Verifiable: for each requirement there must be a  “finite cost-effective” me...
• Introduction  – Purpose     • delineate purpose of SRS     • intended audience for SRS  – Scope     • identify software ...
• Introduction (continued)  – Definitions/acronyms/abbreviations  – References     • list documents referenced by name and...
• Overall description  – Product perspective (related products?)     • block diagram     • constraints        – system int...
• Overall description (continued)  – Product perspective     • constraints        – communications interfaces             ...
• Overall description (continued)  – Product functions     • summary of major functions sw will perform  – Intended user c...
• Overall description (continued)  – Constraints (limitations of developer options)     • regulatory policies     • hardwa...
• Overall description (continued)  – Assumptions and dependencies     • e.g. specific OS available on HW  – Apportioning o...
• Specific requirements  – External interfaces  – Functions  – Performance requirements  – Logical database requirements  ...
• Specific requirements (continued)  – Software system attributes     •   Reliability     •   Availability     •   Securit...
• Specific requirements (continued)  – Organizing the specific requirements     •   System mode     •   User class     •  ...
• Supporting Information  – Table of contents  – Index  – Appendixes                           www.qbi.in
www.qbi.in
Upcoming SlideShare
Loading in...5
×

Requirements Documentation

1,902

Published on

This presentation covers Requirements Documentation for IT Projects

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

No Downloads
Views
Total Views
1,902
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Transcript of "Requirements Documentation"

  1. 1. www.qbi.in
  2. 2. www.qbi.in
  3. 3. www.qbi.in
  4. 4. www.qbi.in
  5. 5. www.qbi.in
  6. 6. www.qbi.in
  7. 7. www.qbi.in
  8. 8. – Company wide same document structure is followed– Easy to Read– Easy to do Quality Checks– Suits your requirements www.qbi.in
  9. 9. – Different Readers the document is aimed at– Specific Sections of interest to a particular audience– Document Dependencies– Technical background if any to suit the requirements www.qbi.in
  10. 10. – Glossaries are integral to Requirement Documents– You can prepare a common glossary for your domain and utilize it after making suitable amendments for the project www.qbi.in
  11. 11. – Standard Notations allow you to remain consistent– Examples: UML 2.0 , BPMN 2.0 www.qbi.in
  12. 12. www.qbi.in
  13. 13. www.qbi.in
  14. 14. www.qbi.in
  15. 15. www.qbi.in
  16. 16. www.qbi.in
  17. 17. www.qbi.in
  18. 18. 1. Correct 6. Verifiable2. Unambiguous 7. Modifiable3. Complete 8. Traceable4. Consistent5. Ranked for importance and/or stability www.qbi.in
  19. 19. • Correct: every requirement given in SRS is a requirement of the software• Unambiguous: every requirement has exactly one interpretation• Complete: includes all functional, performance, design, external interface requirements; definition of the response of the software to all inputs (valid and invalid)• Consistent: internal consistency www.qbi.in
  20. 20. • Ranked importance: essential vs. desirable• Verifiable: for each requirement there must be a “finite cost-effective” method to verify process with which a person or machine can check that the software product meets the requirement.”• Modifiable: SRS must be structured to permit effective modifications (e.g. don’t be redundant, keep requirements separate)• Traceable: origin of each requirement is clear. www.qbi.in
  21. 21. • Introduction – Purpose • delineate purpose of SRS • intended audience for SRS – Scope • identify software to be produced by name • explain what sw will (not) do • describe application of sw (benefits, objectives) www.qbi.in
  22. 22. • Introduction (continued) – Definitions/acronyms/abbreviations – References • list documents referenced by name and source – Overview • brief description of rest of SRS • organization of SRS www.qbi.in
  23. 23. • Overall description – Product perspective (related products?) • block diagram • constraints – system interfaces » identify functionality that fulfills each system requirement – user interfaces – hardware interfaces – software interfaces » how sw interacts with supporting software (purpose, message content and format) www.qbi.in
  24. 24. • Overall description (continued) – Product perspective • constraints – communications interfaces » network protocols – memory » requirements/limits on primary and secondary memory – operations » modes of operation » interactive vs. unattended operation » backup & recovery – site adaptation requirement www.qbi.in
  25. 25. • Overall description (continued) – Product functions • summary of major functions sw will perform – Intended user characteristics • educational level • experience • technical expertise www.qbi.in
  26. 26. • Overall description (continued) – Constraints (limitations of developer options) • regulatory policies • hardware limitations interfaces to other applications • parallel operation • audit functions • reliability requirements • criticality of the application • safety and security considerations www.qbi.in
  27. 27. • Overall description (continued) – Assumptions and dependencies • e.g. specific OS available on HW – Apportioning of requirements • requirements that may be delayed to future versions www.qbi.in
  28. 28. • Specific requirements – External interfaces – Functions – Performance requirements – Logical database requirements – Design constraints • Standards compliance www.qbi.in
  29. 29. • Specific requirements (continued) – Software system attributes • Reliability • Availability • Security • Maintainability • Portability www.qbi.in
  30. 30. • Specific requirements (continued) – Organizing the specific requirements • System mode • User class • Objects • Feature • Stimulus • Response • Functional hierarchy – Additional comments www.qbi.in
  31. 31. • Supporting Information – Table of contents – Index – Appendixes www.qbi.in
  32. 32. www.qbi.in

×