1. 60-322 Object-Oriented Analysis and Design Jan 21, 2009

2. Jan 21, 2008 2 In the UP, use case writing is encouraged in a requirements workshop. This Figure offers suggestions on the time and space for doing this work.Figure Ch6 Use Cases into Perspective

3. Jan 21, 2008 3 Ch6 Use Cases into Perspective

4. Jan 21, 2008 4 Ch6 Use Cases into Perspective

5. Jan 21, 2008 5 The Use-Case Model is started in inception, with perhaps only 10% of the architecturally significant use cases written in any detail. The majority are incrementally written over the iterations of the elaboration phase. By the end of elaboration, a large body of detailed use cases and other requirements (in the Supplementary Specification) are written, providing a realistic basis for estimation through to the end of the project. Ch 6. Use cases

6. Jan 21, 2008 6 How to Write Use Cases in Inception? – Not all use cases are written in their fully dressed format during the inception phase. – The earlier part of the workshop day is spent identifying goals and stakeholders, and speculating what is in and out of scope of the project. – An actor-goal-use case table is written and displayed with the computer projector. – A use case context diagram is started. – After a few hours, perhaps 20 use cases are identified by name, including Process Sale, Handle Returns, and so on. Ch 6. Use cases

7. Jan 21, 2008 7 How to Write Use Cases in Inception? – Most of the interesting, complex, or risky use cases are written in brief format, each averaging around two minutes to write. – The team starts to form a high-level picture of the system's functionality. – After this, 10% to 20% of the use cases that represent core complex functions, require building the core architecture, or that are especially risky in some dimension are rewritten in a fully dressed format. Ch 6. Use cases

8. Jan 21, 2008 8 How to Write Use Cases in Inception? – The team investigates a little deeper to better comprehend the magnitude, complexities, and hidden demons of the project through deep investigation of a small sample of influential use cases. – Perhaps this means two use cases: Process Sale and Handle Returns. Ch 6. Use cases

9. Jan 21, 2008 9 How to Write Use Cases in Elaboration? – This is a phase of multiple timeboxed iterations (for example, four iterations) in which risky, high-value, or architecturally significant parts of the system are incrementally built. – The "majority" of requirements identified and clarified. – The feedback from the concrete steps of programming influences and informs the team's understanding of the requirements, which are iteratively and adaptively refined. – Perhaps there is a two-day requirements workshop in each iteration- four workshops. Ch 6. Use cases

10. Jan 21, 2008 10 How to Write Use Cases in Elaboration? – However, not all use cases are investigated in each workshop. They are prioritized; early workshops focus on a subset of the most important use cases. – Each subsequent short workshop is a time to adapt and refine the vision of the core requirements, which will be unstable in early iterations, and stabilizing in later ones. – Thus, there is an iterative interplay between requirements discovery, and building parts of the software. Ch 6. Use cases

11. Jan 21, 2008 11 How to Write Use Cases in Elaboration? – During each requirements workshop, the user goals and use case list are refined. – More of the use cases are written, and rewritten, in their fully dressed format. – By the end of elaboration, "80-90%" of the use cases are written in detail. Note that elaboration involves programming parts of the system. At the end of this step, the NextGen team should not only have a better definition of the use cases, but some quality executable software. Ch 6. Use cases

12. Jan 21, 2008 12 How to Write Use Cases in Construction? – The construction phase is composed of timeboxed iterations (for example, 20 iterations of two weeks each) that focus on completing the system. – The risky and core unstable issues have settled down in elaboration. – There may still be some minor use case writing and perhaps requirements workshops, but much less so than in elaboration Ch 6. Use cases

13. Jan 21, 2008 13 Ch 6. Use cases in Inception for POS

14. Jan 21, 2008 14 Ch 6. Use cases Books The most popular use-case guide. – http://www.amazon.com/gp/reader/0201702258/ref=sib_dp_pt/104- 2917505-6571940#reader-link http://www.amazon.com/gp/reader/0201702258/ref=sib_dp_pt/104- 2917505-6571940#reader-link Patterns for Effective Use Cases – http://www.amazon.com/Patterns-Effective-Cases-Software- Development/dp/0201721848 http://www.amazon.com/Patterns-Effective-Cases-Software- Development/dp/0201721848 Requirements by Collaboration: Workshops for Defining Needs – http://www.amazon.com/Requirements-Collaboration-Workshops- Defining-Needs/dp/0201786060 http://www.amazon.com/Requirements-Collaboration-Workshops- Defining-Needs/dp/0201786060 Use Case Modeling – http://www.amazon.com/Case-Modeling-Addison-Wesley-Object- Technology/dp/0201709139

15. Jan 21, 2008 15 A Short Review… The UML provides use case diagram notation to illustrate the names of use cases and actors, and the relationships between them. Guideline – Draw a simple use case diagram in conjunction with an actor-goal list. The important use case work is to write text, not diagram or focus on use case relationships. Use cases are central to the UP and many other iterative methods. The UP encourages use-case driven development.

16. Jan 21, 2008 16 Chapter 6 Use cases a technical team starts building the production core of the system when only perhaps 10% of the requirements are detailed, and in fact, the team deliberately delays in continuing with deep requirements work until near the end of the first elaboration iteration. This is a key difference between iterative development and a waterfall process: Production-quality development of the core of a system starts quickly, long before all the requirements are known. near the end of the first iteration of elaboration, there is a second requirements workshop, during which perhaps 30% of the use cases are written in detail.

17. Jan 21, 2008 17 Besides use cases, what other UP requirement artifacts? Use cases are not the whole story! There are at least the following other requirement artifacts: Ch7 Other Requirements

18. Jan 21, 2008 18 Supplementary Specification – captures and identifies other kinds of requirements, such as reports, documentation, packaging, supportability, licensing, and so forth. Glossary – captures terms and definitions; it can also play the role of a data dictionary. Vision – summarizes the "vision" of the project - an executive summary. It serves to tersely communicate the big ideas. Business Rules (or Domain Rules) – capture long-living and spanning rules or policies, such as tax laws, that transcend one particular application. Ch7 Other Requirements

19. Jan 21, 2008 19 What to do with these other requirements? Should We Analyze These Thoroughly During Inception? No. – UP is an iterative and evolutionary process. Yes. – research shows that is useful to have a high-level "top ten" list of coarse-grained requirements near the start. It is also useful to spend non-trivial early time understanding the non-functional requirements (such as performance or reliability), as these have a significant impact on architectural choices. Ch7 Other Requirements

20. Jan 21, 2008 20 Look at this sample document containing one of other requirement artifacts for the case study of NextGen POS. Open the Word Doc.(NextGen Example-CH7SS.doc) Ch7 Other Requirements

21. Jan 21, 2008 21 What a nicely written document ! It seems complete, accurate, reliable,….. It seems that: – the real requirements are understood and well-defined, and can (early on) be used to reliably estimate and plan the project This is the illusion: – This illusion is more strong for non-software developers; programmers know from painful experience how unreliable it is. Ch7 Other Requirements

22. Jan 21, 2008 22 – Research shows it is a misunderstanding to believe that early detailed requirements are useful or reliable on software projects. In fact, quite the opposite, as almost 50% of early waterfall-specified features are never used in a system. Then why are we doing this? – quickly building software that passes the acceptance tests defined by the users, and that meets their true goals - which are often not discovered until users are evaluating or working with the software Ch7 Other Requirements

23. Jan 21, 2008 23 – Writing a Vision and Supplementary Specification is worthwhile as an exercise in clarifying a first approximation of what is wanted, the motivation for the product, and as a repository for the big ideas. – But they are not - nor is any requirements artifact - a reliable specification. – Only writing code, testing it, getting feedback, ongoing close collaboration with users and customers, and adapting, truly hit the mark. Ch7 Other Requirements

24. Jan 21, 2008 24 This is not a call to abandon analysis and thinking, and just rush to code, but a suggestion to treat written requirements – lightly, – start programming early, and continually, – Ideally-daily, – engage users and tests for feedback. Ch7 Other Requirements

25. Jan 21, 2008 25 The Supplementary Specification captures – other requirements, – information, and constraints not easily captured in the use cases or Glossary, – including system-wide "URPS+" (usability, reliability, performance, supportability, and more) quality attributes or requirements. – Where is F in FURPS+? A friendly reminder – Non-functional requirements specific to a use case can (and probably should) be first briefly written within the use case, in the Special Requirements section while you are thinking through the use case. – But, after that informal step, these should then be moved to the Supplementary Specification, to keep all non-functional requirements in one place, and not duplicated. Ch7 Supplementary Specification

26. Jan 21, 2008 26 Elements of the Supplementary Specification include: – FURPS+ requirements, ie, functionality, usability, reliability, performance, and supportability – reports – hardware and software constraints (operating and networking systems,..) – development constraints (for example, process or development tools) – other design and implementation constraints – internationalization concerns (units, languages) – documentation (user, installation, administration) and help – licensing and other legal concerns – packaging – standards (technical, safety, quality) – physical environment concerns (for example, heat or vibration) – operational concerns (for example, how do errors get handled, or how often should backups be done?) – application-specific domain rules – information in domains of interest (for example, what is the entire cycle of credit payment handling?) Ch7 Supplementary Specification

27. Jan 21, 2008 27 Some functions or features don't fit in a use case format. For example, sometimes, one needs to think of the functionality in terms of features, such as "add EJB Entity Bean 1.0 support." The UP certainly allows this feature-oriented approach to requirements, in which case the feature list goes in the Supplementary Specification. The UP encourages but does not require use cases for functionality; use cases are a great way to think about and pull together a related set of features in terms of typical scenarios of using a product. They don't always fit. Ch7 Supplementary Specification

28. Jan 21, 2008 28 Application-Specific Domain (Business) Rules – General, broad domain rules such as tax laws belong in the UP Business Rules artifact, as a central shared repository. – However, more narrow application-specific rules, such as how to calculate a line-item discount, can be recorded in the Supplementary Specification. Information in Domains of Interest – It is often valuable for a subject matter expert to write (or provide URIs to) some explanation of domains related to the new software system, to provide context and deeper insight for the development team. That document may contain pointers to important literature or experts, formulas, laws, or other references. Ch7 Supplementary Specification

29. Jan 21, 2008 29 Read the sample Vision document first. Vision is an executive summary that briefly describes the project, as a context for the major players to establish a common vision of the project. The Vision should not be long, nor should it attempt to describe firm requirements in detail. It should summarize some of the information in the Use-Case Model and Supplementary Specification. Ch7 Vision

30. Jan 21, 2008 30 This section summarizes the goals and problems at a high level often higher than specific use cases, It reveals important non-functional and quality goals that may belong to one use case or span many, such as: – We need fault-tolerant sales processing. – We need the ability to customize the business rules. Ch7 Vision-The “Key High-Level Goals and Problems of the Stakeholders “ Section

31. Jan 21, 2008 31 System features are high-level, terse statements summarizing system functions. More formally, in the UP, a system feature is "an externally observable service provided by the system which directly fulfills a stakeholder need“. Features vs. functionality of a system – An alternative, complementary way to express system functions is with features, or more specifically in this context, system features, which are Should features be in use cases? No. Ch7 Vision-The “Summary of System Features “ Section

32. Jan 21, 2008 32 Simply listing the use case names is not sufficient in the Vision to grasp the major features. Why? – Too detailed or low-level. People want a short summary of the big ideas. There could be 30 or 50 use cases. – The use case name can hide interesting major features stakeholders really want to know about. For example, suppose that the description of automated payment authorization functionality is embedded in the Process Sale use case. A reader of a list of use case names can't tell if the system will do payment authorization. – Some noteworthy features span or are orthogonal to the use cases. For example, during the first NextGen requirements workshop, someone might say "The system should be able to interact with existing third-party accounting, inventory, and tax calculation systems." Ch7 Vision-The “Summary of System Features “ Section

33. Jan 21, 2008 33 Functional system features are to be contrasted with various kinds of non-functional requirements and constraints, such as: – The system must run on Linux, – must have 24/7 availability, and – must have a touch-screen interface. – These are non-functional requirement. Features are behavioral functions a system can do. They should pass this linguistic test: The system does. – For example, the system does payment authorization. – The system does Linux ? – The system does 24/7 availability?, and – The system does a touch-screen interface.? Ch7 Vision-The “Summary of System Features “ Section

34. Jan 21, 2008 34 How to write a system feature list? Terse, for example, – Here is a features example at a high level, for a large multi-system project of which the POS is just one element: – The major features include: POS services Inventory management Web-based shopping … Ch7 Vision-The “Summary of System Features “ Section

35. Jan 21, 2008 35 The major features include: POS services: – sales capture – payment authorization –…–… Inventory management: – automatic reordering –…–… Ch7 Vision-The “Summary of System Features “ Section

36. Jan 21, 2008 36 How many features do you list? Guideline – A Vision with less than 10 features is desirable, – more can't be quickly grasped. If more, consider grouping and abstracting the features. Ch7 Vision-The “Summary of System Features “ Section

37. Jan 21, 2008 37 Recall that – Vision should summarize some of the information in the Use- Case Model and Supplementary Specification. In the Vision, system features briefly summarize functional requirements often detailed in the use cases. Likewise, the Vision can summarize other requirements (for example, reliability and usability) that are detailed in the Supplementary Specification. But be careful to avoid going down the path of repeating yourself. Ch 7 Vision

38. Jan 21, 2008 38 Guideline – For other requirements, avoid their duplication or near-duplication in both the Vision and Supplementary Specification (SS). – Rather, record them only in the SS. – In the Vision, direct the reader to the SS for the other requirements. (see the example file, NextGenCh7Vision.doc) Ch 7 Vision

39. Jan 21, 2008 39 Guideline: Should You Write the Vision or Use Cases First? – It isn't useful to be rigid about the order. While developers are collaborating to create different requirements artifacts, a synergy emerges in which working on one artifact influences and helps clarify another. Nevertheless, a suggested sequence is: Write a brief first draft of the Vision. Identify user goals and the supporting use cases by name. Write some use cases in detail, and start the Supplementary Specification. Refine the Vision, summarizing information from these. Ch 7 Vision