06 functional requirements


Published on

Published in: Technology, Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

06 functional requirements

  1. 1. Functional requirements
  2. 2. A requirement isa one-sentence statement of acapability of the software
  3. 3. Taken together, all therequirements should definethe software completely
  4. 4. They are foundational sothey must be of the highestquality¡  Remember how expensive it is to have poor requirements:
  5. 5. How do you write qualityfunctional requirements?Lets take a look at some characteristics on thefollowing pages¡ Correct ¡ Modifiable¡ Feasible ¡ Complete¡ Necessary ¡ Verifiable¡ Prioritized ¡ Consistent¡ Unambiguous ¡ Traceable
  6. 6. They must becorrectEach requirementmust accuratelydescribe thefunctionality to bedelivered
  7. 7. They must be feasible¡  It must be possible to implement each requirement within the known capabilities and limitations of the system and its environment.
  8. 8. They must be necessaryEach requirement should document something thecustomers really need or something that is requiredfor conformance to an external requirement, anexternal interface, or a standard.
  9. 9. They must be prioritized ¡  Assign an implementation priority to each requirement, feature, or use case to indicate how essential it is to include it in a particular product release.
  10. 10. They must beunambiguousThe reader of a requirementstatement should be able todraw only one interpretation ofit.
  11. 11. They must be verifiable ¡  See whether you can devise tests or use other verification approaches, such as inspection or demonstration, to determine whether each requirement is properly implemented in the product.
  12. 12. They must be completeNo requirements ornecessary informationshould be missing.
  13. 13. They must be consistent¡  Consistent requirements do not conflict with other software requirements or with higher level (system or business) requirements.
  14. 14. They must bemodifiableYou must be able to revise thespec when necessary and keepa history of changes made
  15. 15. They must be traceable¡  You should be able to link each software requirement to its source, which could be a higher-level system requirement, a use case, or a voice-of-the-customer statement.
  16. 16. Lets review some requirements together¡  as
  17. 17. What could be improvedwith this statement?The product shall providestatus messages atregular intervals not lessthan every 60 seconds.
  18. 18. A suggested improvementmight be …¡  The Background Task Manager shall display status messages in the user interface at intervals of 60 plus or minus 10 seconds.¡  If background task processing is progressing normally, the percentage of the background task processing that has been completed shall be displayed.
  19. 19. What could be improvedwith this statement?The product shall switchbetween displaying andhiding non-printingcharacters instantaneously.
  20. 20. A suggested improvementmight be …The user shall be able totoggle between displayingand hiding all HTML markuptags in the document beingedited with the activation ofa specific triggeringcondition.
  21. 21. What could be improvedwith this statement?The HTML Parser shallproduce an HTMLmarkup error reportwhich allows quickresolution of errors whenused by HTML novices.
  22. 22. A suggested improvementmight be …The HTML Parser shall producean error report that contains theline number and text of anyHTML errors found in the parsedfile and a description of eacherror found. If no errors arefound, the error report shall notbe produced.
  23. 23. What could be improvedwith this statement?Charge numbers shouldbe validated on-lineagainst the mastercorporate chargenumber list, if possible.
  24. 24. A suggested improvementmight be …The system shall validate thecharge number enteredagainst the on-line mastercorporate charge number list. Ifthe charge number is not foundon the list, an error messageshall be displayed and theorder shall not be accepted.
  25. 25. Guidelines for Writing QualityRequirements¡  Here are a few guidelines to keep in mind as you document software requirements: ¡  Keep sentences and paragraphs short. ¡  Use the active voice. Use proper grammar, spelling, and punctuation. ¡  Use terms consistently and define them in a glossary or data dictionary. ¡  To see if a requirement statement is sufficiently well defined, read it from the developerʼ’s perspective. Mentally add the phrase, "call me when youʼ’re done" to the end of the requirement and see if that makes you nervous. In other words, would you need additional clarification to understand the requirement well enough to design and implement it? If so, that requirement should be elaborated before proceeding with construction. ¡  Avoid long narrative paragraphs that contain multiple requirements. A helpful granularity guideline is to write individually testable requirements. If you can think of a small number of related tests to verify correct implementation of a requirement, it is probably written at the right level of detail. If you envision many different kinds of tests, perhaps several requirements have been lumped together and should be separated.
  26. 26. Guidelines for Writing QualityRequirements ¡  Watch out for multiple requirements that have been aggregated into a single statement. Conjunctions like "and" and "or" in a requirement suggest that several requirements have been combined. Never use "and/or" in a requirement statement. ¡  Write requirements at a consistent level of detail throughout the document. I have seen requirements specifications that varied widely in their scope. For example, "A valid color code shall be R for red" and "A valid color code shall be G for green" might be split out as separate requirements, while "The product shall respond to editing directives entered by voice" describes an entire subsystem, not a single functional requirement. ¡  Avoid stating requirements redundantly. While including the same requirement in multiple places may make the document easier to read, it also makes maintenance of the document more difficult. The multiple instances of the requirement all have to be updated at the same time, lest an inconsistency creep in.
  27. 27. Conclusion¡  Functional requirements are short statements that say what the system must be able to do¡  Taken together they define the entire capability of the system¡  It is critical that functional requirements are high quality¡  They should be: ¡ Feasible ¡ Verifiable ¡ Correct ¡ Prioritized ¡ Consistent ¡ Unambiguous ¡ Modifiable ¡ Traceable