1. INFO 627Lecture #71 Requirements Engineering and Management INFO 627 Requirements Quality and Specification Methods Glenn Booker

2. INFO 627Lecture #72 Ambiguity and Specificity  The right level of detail for requirements is the desired “sweet spot”  Too little detail can result in vague requirements  Too much detail removes design creativity and wastes time  Goal is to be understood correctly

3. INFO 627Lecture #73 Light Box Example  In the text’s light box example, the requirements state: If either of the lights burns out, the remaining bulb shall flash every 1 second  Does this mean the remaining light flashes briefly every second? Or does it flash on for one second, off for one second, etc.? Even this simple case has many interpretations

4. INFO 627Lecture #74 Finding the Sweet Spot Ambiguity Understand- ability The Sweet Spot Too obtuse Too preciseToo vague Gibberish

5. INFO 627Lecture #75 No, I wanted  … a Bud Light!  Be careful what you ask for, or you might get something completely different than intended  Another silly example is to imagine the possible ways to respond to the requirement to “bring me a rock”

6. INFO 627Lecture #76 Mary Had a Little Lamb  A cute example is from looking up various interpretations of the nursery rhyme “Mary had a little lamb”  Assuming we know who Mary is, and “a little” is clear (though one could dispute “little” easily!), play with possible interpretations of “had” and “lamb”

7. INFO 627Lecture #77 “Had” Could Mean  Held in possession as property  Acquired  Accepted in marriage  Was marked or characterized by  Was held in a position of disadvantage or certain defeat  Was tricked  Gave birth to  Partook of (ate)  Was bribed by

8. INFO 627Lecture #78 “Lamb” Could Mean  A young sheep, especially one less than one year old or without permanent teeth  A young antelope  A gentle or weak person  A dear or pet  A person easily cheated or deceived  The flesh of lamb used as food

9. INFO 627Lecture #79 Conclusion?  So “Mary had a little lamb” could mean: Mary had a pet young sheep Mary gave birth to an antelope Mary was tricked by a gentle or weak person Mary ate a person who was easily fooled or deceived Mary was bribed by a young sheep Mary married the flesh of a lamb

10. INFO 627Lecture #710 Sounds Silly?  I hope so  But requirements for an unfamiliar area could be just as easily preposterous if you aren’t careful!

11. INFO 627Lecture #711 How to Reduce Ambiguity  Ease of memorization; ask people which requirements they remember Those which are not easily remembered are more likely to be unclear  Keyword technique; like used for Mary earlier, look for key words and see what definition best fits your context

12. INFO 627Lecture #712 Emphasis Technique  Say the following out loud; each time you do, shift the emphasis to a different word each time “I never said I beat my wife!”  How does the change of emphasis change the implication of the statement?

13. INFO 627Lecture #713 Which Technique to Use?  No one technique is best to use  What works best depends on your organization, customer, and many other factors  Good to try several techniques, particularly if you get stuck

14. INFO 627Lecture #714 To Improve Clarity  Use natural language whenever possible  Use pictures and diagrams to clarify your intent  When in doubt, ASK!  Even if not in doubt, ask anyway just to make sure  Use more formal methods where needed

15. INFO 627Lecture #715 Quality Measures  Quality is challenging to measure  Some wish to view it as subjective “I know it when I see it”  We’ll break it into quality for: Each requirement or specification Each technique, such as use case quality The entire SRS package

16. INFO 627Lecture #716 Each Requirement or Specification  Simply having defined the requirements is a good start  Beyond that, quality for each requirement or specification has nine aspects Correct Unambiguous Complete Consistent

17. INFO 627Lecture #717 Each Requirement or Specification Ranked Verifiable Modifiable Traceable Understandable  Most of these came from IEEE 830; the last one was added by the text

18. INFO 627Lecture #718 Correct  Requirements are correct if they address needs of the user  Hence the system needs to perform the right functions, and follow the business rules established by the customer or user  Generally can’t automate proving correctness of requirements

19. INFO 627Lecture #719 Unambiguous  A requirement is unambiguous if it can only have one interpretation  This is the key to capturing “what the user had in mind”  Beware of cultural differences, and the Mary- had-a-little-lamb example earlier

20. INFO 627Lecture #720 Complete  Completeness of requirements if they describe “all requirements of concern to the user, including requirements associated with functionality, performance, design constraints, attributes, or external interfaces” (IEEE 830)  Some aspects of completeness include accurate labeling and referencing of figures

21. INFO 627Lecture #721 Complete  Completeness can also include clear definition of the scope, domain, or boundaries of acceptable inputs sqrt(-1), age 100%  Completeness can include setting limits on acceptable performance, accuracy, or reliability

22. INFO 627Lecture #722 Complete  Missing functional requirements could include handling of special cases How processing is handled on a leap day, holidays, or snow days  Prototyping can help identify “what-if” questions, such as boundary conditions, exceptions, and unusual events

23. INFO 627Lecture #723 Consistent  Consistency within requirements means that none of the requirements disagree or conflict with any other requirements  Hardest to prove with performance or reliability requirements  Inconsistent responses or actions need to be deliberately avoided Process modeling may help Process modeling

24. INFO 627Lecture #724 Ranked  Requirements need to be ranked or categorized at least two ways Importance (criticality), which is most often used to determine which requirements get implemented if money or time run tight Stability (volatility), which affects how the requirement is implemented, and could reduce the chance it is implemented

25. INFO 627Lecture #725 Verifiable  A requirement is verifiable if there is a practical means possible to prove that the requirement has been met  We’ll look at specific methods for this later, but common verification methods include testing or inspection  Don’t make subjective things a requirement “easy to use”, “pleasing to the eye”, etc.

26. INFO 627Lecture #726 Modifiable  The set of requirements need to be structured so that changes to them can be done easily, completely, and consistently, and without changing the existing structure and style of the set  This is to support requirements changes  Without this, requirements become outdated

27. INFO 627Lecture #727 Traceable  Traceability means each requirement has a clear origin, and can be referred to uniquely Origin needed to know why the requirement exists; backward to its source feature, and forward to relevant design, code, or tests Unique (short) name or identifier needed to ensure that each requirement can be readily cited in other plans

28. INFO 627Lecture #728 Understandable  Understandability is an obviously desirable characteristic, but is easily lost as requirements get more detailed Both developer and user need to understand Beware of technical terms, existing terminology, and buzzwords May use storyboards or use cases to show the context for how the requirement is used

29. INFO 627Lecture #729 Use Case Quality  Text has lots of additional guidance for applying these quality concepts to use cases Are all existing functions described by one or more use cases? Are all functional requirements described by at least one use case? Is the reverse true, too? Look for interdependencies among use cases Are all use case assumptions described?

30. INFO 627Lecture #730 Use Case Quality Does each use case involve at least one actor? Look for flows of activity which always follow each other (then merge into one use case) Look for subsets of activity which are used in several places (which may become included use cases) Are use case names unique and clear? Is there a clear start and end to each use case?

31. INFO 627Lecture #731 Use Case Quality Is it clear when each use case is performed? Are all of the users related to some actor? Do any actors interact with the system in the same ways? If so, consider merging them into one actor, or use generalization Are all decisions within use cases covered? What happens if something doesn’t succeed? Do use cases account for all information flow?

32. INFO 627Lecture #732 SRS Quality  A good quality SRS, like any other technical document, should have a good structure Table of Contents Index (optional, IMHO) Revision History Glossary  See also my document review guidelinesdocument review guidelines

33. INFO 627Lecture #733 Table of Contents  The table of contents (TOC) helps define the structure of the document  Always update the TOC before printing or publishing the document  Large documents may need a separate TOC for each volume

34. INFO 627Lecture #734 Table of Contents  Within MS Word, identify each heading Click on a paragraph which is a section heading On the Formatting toolbar, select the style for the right level of header (Heading 1 for top level sections, Heading 2 for second level, etc.) Repeat first two steps for all section headings Use Format / Style to Modify the headings’ Format to suit (e.g. Font and Paragraph)

35. INFO 627Lecture #735 Table of Contents  Click where you want the TOC to be placed Generate the TOC using “Insert / Index and Tables…” and click on “Table of Contents” tab  Usually want to Show and Right align page numbers  Make sure the correct number of heading levels are selected  To update the TOC, right click over it and “Update Field”

36. INFO 627Lecture #736 Index  An index is handy for looking up topics alphabetically within the document  Need to determine what words or phrases need to be in the index After document is written, highlight a key word or phrase anywhere it appears Go back to “Insert / Index and Tables…” and click on the Index tab

37. INFO 627Lecture #737 Index Select Mark Entry and Mark All of that phrase Repeat for each key word or phrase Click where the Index will go Generate the Index with “Insert / Index and Tables…”; but here you don’t want to “Right align page numbers” Update the same as a TOC  Good for large, frequently-used documents

38. INFO 627Lecture #738 Revision History  Every controlled document should have a revision history  At a minimum, cite the revision date, author, and what changes were made  Could add the revision number (version 1.0, 1.1, 1.2, etc.), and who approved the document

39. INFO 627Lecture #739 Glossary  Any technical document should consider having a glossary  The glossary should define all acronyms, abbreviations, and project-specific terms Helps avoid confusion over user versus developer terminology  Sort the glossary alphabetically! Highlight glossary, then use Table / Sort

40. INFO 627Lecture #740 Numbering and Labeling  Also recommended for any technical document (not just the SRS) Page numbering  Hint: the TOC and Index don’t do much good otherwise! Clear labels and numbering for figures and tables  See my guidance for several numbering schemes

41. INFO 627Lecture #741 Technical Methods  There are seven common ways to describe requirements with more precision than natural language or use cases Pseudocode Finite state machines Decision trees Activity diagrams

42. INFO 627Lecture #742 Technical Methods Entity-relationship models Object-oriented analysis Structured analysis  Don’t want a lot of these methods used in an SRS – most likely to use them during analysis and design phases

43. INFO 627Lecture #743 Pseudocode  Pseudocode is a fake form of programming language which captures the main intent of the logic without the formality  Uses a limited vocabulary of phrases  Allows basic programming concepts Assignment statements, decisions, loops  Good for short algorithm description (business rules) 1E p. 299

44. INFO 627Lecture #744 Finite State Machines  Best known as state transition diagrams  Each bubble corresponds to a state of the system – off hook, Odd light lit, etc.  Lines between bubbles describe what event is needed to make the state transition – hang up, press Count button, etc.  Key challenge is to identify all states and events correctly 1E p. 300

45. INFO 627Lecture #745 Finite State Machines  Events might be grouped by similar result – all outcomes on this path are similar if I type any number, for example  Can make a matrix of all states and events, to ensure complete understanding  Used for OO analysis and in the Cleanroom methodology Cleanroom

46. INFO 627Lecture #746 Decision Trees  A decision tree is a graphic If statement  Each decision path is labeled Yes or No, and all possible outcomes should be shown  Calculations, if needed, should be phrased in the question – “Is budget overrun positive?” – instead of putting numbers in the decision paths 1E p. 302

47. INFO 627Lecture #747 Activity Diagrams  An activity diagram is the UML version of a flowchart  Boxes represent activities to be performed (processes or procedures)  Lines between boxes show the sequence of actions  Decisions are shown in diamonds 1E p. 303

48. INFO 627Lecture #748 Entity-relationship Models  An entity-relationship diagram (ERD) shows how data is structured in a system  Each box represents an entity, which will later correspond to data tables  Lines between boxes describe the relationship between the entities Customer places Order CustomerOrder places

49. INFO 627Lecture #749 Entity-relationship Models  The ends of the lines show the cardinality of the relationship, whether the distant entity may have zero, one, or many corresponding entries in the nearer entity Customer may have zero, one, or many Orders But each Order is from exactly one Customer  May be hard for non-technical people to understand

50. INFO 627Lecture #750 Object-oriented Analysis  Object-oriented methods not only model the data in a system, but limits the ways in which that data may be used  Data is isolated in objects, and can only be set, read, or changed using “methods”  Hence an object Employee might have methods to AddEmployee, UpdateEmployee, DismissEmployee, etc.

51. INFO 627Lecture #751 Object-oriented Analysis  A drawing to show those objects and whether they are allowed to communicate is a class diagram  Looks like an ERD, but each box is a class, and the lines between them show visibility  Again, may be way too complex unless customer is very technology-savvy

52. INFO 627Lecture #752 Structured Analysis  Where the ERD focused on data structure, the structured analysis tool called the Data Flow Diagram (DFD) focuses on processes  Has shapes for data stores (Inventory), users or external systems, and processes (Manufacture Products)  Lines among them show what kind of data flows (product info) 1E p. 306

53. INFO 627Lecture #753 Structured Analysis  Is used to help identify: Who performs a process Where that process gets data from Where the results of that process go  Less technical than the ERD, but still may be too detailed for laypeople

54. INFO 627Lecture #754 Maintaining Requirements  Make sure to use technical methods for requirements sparingly  Focus on system behavior, not design  Tough part is to keep the models consistent with the evolution of the system Effort devoted to it depends on how critical is the models’ information Be clear if a model is allowed to lapse