Chapter 6 USE CASES The indispensable first step

Chapter 6 USE CASES “The indispensable first step to getting the things you want out of life: decide what you want. ” - Ben Stein Objectives • Identify and write use cases • Use the brief, casual and fully dressed formats • Apply tests to identify suitable use cases • Relate use case analysis to iterative development Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005

Feature Lists vs. Use Cases • Older methods of detailing requirements tended to have many pages of detailed feature lists. Usually the details could not be seen in context. ID Feature FEAT 1. 9 The system shall accept entry of item identifiers. . . . FEAT 2. 4 The system shall log credit payments to the accounts receivable system. • Current philosophy is to use a higher level of detail with use cases instead of a list. • Use cases focus on who the key actors are, their goals, and common tasks. (High level System Feature Lists are still acceptable when they can give a succict summary of the system and ‘n some feature-driven applications, such as application servers, database products, middleware or back-end systems. ) Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 2

Use Cases • Writing Use Cases is not a specifically OO artifact – they are simply written stories: they are stories of using a system • However, they are a best practice for elaborating and understanding requirements. – Simple and familiar storytelling makes it easier, especially for customers, to contribute and review goals. – Use cases keep it simple (KISS) – They emphasize goals and the user perspective. – … Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 3

Example • Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment info, which the system validates and records. The system updates inventory. The customer receives a receipt from the system and then leaves with the items. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 4

Use Case Relationships • Use cases, in turn, influence many other analysis, design, implementation, project management and test artifacts. Business Model Domain Model VISION Use Case Model GLOSSARY SUPPLEMENTARY SPECIFICATION Requirements Design Dr. Kivanc Dincer Interaction Diagrams CS 319 Week 1 - Sept. 12, 2005 5

Fig. 6. 1 Sample UP artifact influence ? Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 6

Definitions • An actor is something with behavior, such as a person (identified by role), computer system, or organization. – Ex. Cashier • A scenario (use case instance) is a specific sequence of actions and interactions bw actors and the system. – It is one particular story of using a system or one path through the use case. • A use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal. • A Use Case Model is the set of all written use cases. – It is a model of the system functionality and environment. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 7

Three Types of Actors • Primary Actor – Has goals to be fulfilled by system – Emphasis is on the primary actor for the use case. – Ex. Cashier • Supporting Actor – Provides service to the system. – Other actors are listed as stakeholders. – Ex. Automated Payment Authorization Service. • Offstage Actor – Interested in the behavior, but no contribution – Ex. Government Tax Agency. In diagrams, Primary actors go on the left and others on the right. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 8

Use Cases are not diagrams ! – Use Cases may have a diagram associated with them, and a use case diagram is an easy way for an analyst to discuss a process with a subject matter expert (SME). – But use cases are primarily text. The text is important. The diagram is optional. – Use case modeling is primarily an act of writing text, not drawing diagrams. • Capture the specific ways of using the system as dialogues between an actor and the system. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 9

Use-Case Driven Development • Requirements are primarily recorded in the Use Case model. • Iterations are planned around implementing particular Use Cases. • Use Case Realizations drive design. – The team designs collaborating objects and subsystems in order to perform or realize the use cases. • Use Case often influence the way user manuals are organized. • Functional or system testing corresponds to the scenarios of use cases. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 10

Working with Use Cases • Determine the actors that will interact with the system. – We cannot understand a system until we know who will use it • • Direct users Users responsible to operate and maintain it External systems used by the system External systems that interact with the system • Examine the actors and document their needs. • For each separate need, create a use case. • During Analysis, extend use cases with interaction diagrams. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 11

Actors or Use Cases First? • Because you have to understand each part of Use Cases, the parts are presented separately. But those who create use cases switch back and forth. • The text describes use cases substantially before paying attention to actors. – Each specification must be testable – Write from actor’s perspective, in actor’s vocabulary • Typically, both actors and use cases are identified early and then examined to see if more use cases can be found from the actors, or more actors found by examining the use cases. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 12

Guideline: Emphasize Goals • Seeing requirements as identifying tasks to be done has a strong bias toward reproducing the existing system, even when it is being replaced because it is seriously defective. • Investigating goals rather than tasks and procedures improves information gathering by focusing on the essence of requirements—the intent behind them. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 13

Fig. 6. 2 Primary actors and goals at different system boundaries. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 14

Naming Use Cases • Appropriate use case names are very important. Because they are selected early, they tend to set the direction for the entire project. – Must be a complete process from the viewpoint of the end user. – Usually in verb-object form, like Buy Pizza – Use enough detail to make it specific – Use active voice, not passive – From viewpoint of the actor, not the system Golden Rule: Each use case should have a name that indicates what value (or goal) is achieved by the actor's interaction with the system. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 15

Naming Use-Cases Quick Test: Use Case Name Examples • Purchase Concert Tickets • Purchase Ticket • Ticket Purchase • Ticket Order • Pay for Ticket Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 16

Naming Use-Cases Use Case Name Examples • Excellent - Purchase Concert Ticket • Very Good - Purchase Concert Tickets • Good - Purchase Ticket (insufficient detail) • Fair - Ticket Purchase (passive) • Poor - Ticket Order (system view, not user) • Unacceptable - Pay for Ticket (procedure, not process) Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 17

Naming Use-Cases CRUD • Examples of bad use case names with the acronym CRUD. (All are procedural and reveal nothing about the actor’s intentions. ) – C - actor Creates data – R - actor Retrieves data – U - actor Updates data – D - actor Deletes data • Collapse CRUD into one CRUD use case, idiomatically called Manage <X>. – Ex. Manage Users use case. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 18

Naming Use-Cases Singular or Plural • This is usually determined by context. • There is a preference for the simplest form, but most common form can be better. – In the example of concert tickets, most people buy more than one, but a significant number buy only one. – At a supermarket, Buy Items would be best. – At a vending machine, it would be Buy Item. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 19

Use Case Template • • Name Primary Actor Scope Level: user-goal or subfunction Stakeholders and Interests Preconditions Success Guarantee • • Main Success Scenario Extensions • • Special Requirements Technology and Data Variations List Frequency of Occurrence Miscellaneous (such as open items) Dr. Kivanc Dincer Preface This is the basic format used in the text and in Alistair Cockburn’s Writing Effective Use Cases (Addison Wesley, 2000, ISBN 0201702258). See also www. usecases. org CS 319 Week 1 - Sept. 12, 2005 Optional items 20

User-goal level A complete process from the view point of a user to meet a goal of the user, roughly corresponding to an elementary business process. Subfunction level Details steps to support a user goal. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 21

Define Actors • Actors should not be analyzed or described in detail unless the application domain demands it. – Template for definition: • Name • Definition • Example for an ATM application: Customer: Owner of an account who manages account by depositing and withdrawing funds Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 22

Preconditions and Postconditions • Preconditions are anything that must always be true before beginning a scenario is a precondition. – Preconditions are assumed to be true, not tested within the Use Case itself. – Ignore obvious preconditions such as the power being turned on. Only document items necessary to understand the Use Case. • Success Guarantees (or Postconditions) state what must be true if the Use Case is completed successfully. This may include the main success scenario and some alternative paths. – For example, if the happy path is a cash sale, a credit sale might also be regarded a success. – Stakeholders should agree on the guarantee. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 23

Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 24

Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 25

Scenarios • The Main Success Scenario, or “happy path” is the expected primary use of the system, without problems or exceptions. • Alternative Scenarios or Extensions are used to document other common paths through the system and error handling or exceptions. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 26

Documenting the Happy Path • The Success Scenario (or basic course) gives the best understanding of the use case • Each step contains the activities and inputs of the actor and the system response • If there are three or more items, create a list • Label steps for configuration management and requirements traceability • Use present tense and active voice • Remember that User Interface designers will use this specification Note: Do not use the term “happy path” in formal documents. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 27

Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 28

Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 29

Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 30

Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 31

Extensions (Alternative Flows) • Extensions or Alternative Flow Use Cases allow the specification of – Different ways of handling transactions – Error processes • Sections are convenient way to handle alternative courses of action – Sections are a segment of a use case executed out of sequence Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 32

Two Parts for Extensions • Condition – Describe the reason for the alternative flow as a condition that the user can detect • Handling – Describe the flow of processing in the same manner as the happy path, using a numbering system consistent with the original section. 3 A. Condition: If [actor] performs [action] the system … Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 33

Documenting Extensions • Use same format as Happy Path • Document actions that vary from ideal path • Include error conditions • Number each alternate, and start with the condition: 3 A. Condition: If [actor] performs [action] the system … • If subsequent steps are the same as the happy path, identify and label as (same) • Steps not included in alternate course are assumed not to be performed. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 34

Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 35

Special Requirements • If a non-functional requirement , quality attribute, or constraint affects a use case directly, describe it as a special requirement. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 36

Technology and Data Variations List • Often there are technical differences in how things are done even though what is done is the same. These things can be described in the Technology and Data Variations List. – For example, if a card reader cannot read the magnetic stripe on a credit card, the cashier might be able to enter it on the keyboard. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 37

Types of Use Cases • High Level Use Case (Brief) – Name, Actors, Purpose, Overview • Expanded Use Case (Fully Dressed) – Add System Events and System Responses • Essential Use Case (Black Box) – Leave out technological implications – Ex. The system records the sale. (no mention of database etc. ) • Concrete Use Case (White Box) – Specify technology Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 38

Guideline: Defer Decisions • By using essential use cases as long as possible, and only using real use cases during module design, you allow time to understand the problem before you create a solution. Premature use of real use cases often confirms existing technology when a better technology might be available. • Define the problem fully before you start to define a solution. Any work that you do on the problem domain tends to increase the range of possible solutions, while work in the solution domain limits your choices. – You want to be certain that the problem domain is large enough to hold some good solutions and hopefully an ideal solution before you start to narrow your choices. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 39

Contrasting Examples • Essential Style: . . . 1. Administrator identifies self. 2. Systems authenticates identity. … • Concrete Style: . . . 1. Administrator enters ID and passsword in dialog box (See Picture 3). 2. System authenticates Administrator. 3. System displays the “edit users” window. (See Picture 4). . . Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 40

Types of Use Cases Technology • The distinction between an essential (black box) use case that leaves out technology and a real (white box) use case that includes technology is fundamental. – For example, in an Automated Teller Machine, an essential use can mention identification or validation, but only a real use can mention a key pad or card reader. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 41

Types of Use Cases Expanded Essential Use Cases (Fully Dressed Use Cases) • • Purpose: – to allow the system designer and client to visualize the flow of actor actions and system responses. From this the client will understand how users will use the system, and the designer will be able to write pseudocode for each function. In addition, it is possible to use this document to anticipate opportunities for user error, which must be accounted for in the final system. Definitions: – What it is: an analysis document which describes in detail the elements of functions identified in a High Level Use Case. – What is is not: Expanded Essential Use Cases are not graphical drawings. They do not include stick figures, boxes representing the system, or any other icons found in a High Level Use Case although they may be associated with one. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 42

Types of Use Cases Expanded Essential Use Cases • How to make one: – Step 1: Name the Use Case (system function, e. g. “enter timesheet information”). – Step 2: Identify the Actor(s) involved. – Step 3: Describe the Intent of the Use Case in language the client will understand. – Step 4: Identify the Assumptions and Limitations relevant to this Use Case and other Use Cases which the current one might extend or build upon. – Step 5: Specify the ideal flow of actions (using two columns, if you like) labeled “Actor Actions” and “System Responses. ” Number each step. This constitutes the Happy Path for this Use Case. – Step 6: Identify opportunities for user error and create an Alternative Path to handle each. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 43

Types of Use Cases Note (from page 68 of text) • The example on pages 68 -72 of the text of a fully dressed use case is very detailed and contains just about everything you could put into a use case. It is that detailed mainly for instructional purposes. • Almost all use cases are much smaller, usually a page or two. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 44

Segmentation • When a use case is repeated, you don’t want to repeat the contents. – For example, an alarm clock might show the same display when you are setting the current time and when you are setting the wake-up time – Separate out the “Display Time” use case and refer to it in both use cases Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 45

Extension Use Cases • Users appreciate simplicity, so most use cases leave out alternate courses • You can do this by extending the use case while leaving the original use case alone Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 46

Warning • Use cases should not be misused to imitate function specification by successive iteration • Don’t refine them until the program is fully specified • The uses relation should only be used when the same scenario is encountered more than once Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 47

Use Cases are always wrong! • Written documentation gives the illusion of authority and correctness, but it is an illusion. • Use cases give a preliminary understanding that users and developers can discuss and agree on. • But there should be constant feedback from customers in the development process to correct missing information and misinformation before it jeopardizes the functionality of the program. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 48

Fig. 6. 3 Partial use case context diagram system boundary communication Next. Gen POS Process Sale Customer Payment Authorization Service alternate notation for a computer system actor Handle Returns actor «actor» Tax Calculator Cashier «actor» Accounting System Cash In Manager «actor» Sales Activity System «actor» HR System Analyze Activity Manage Security System Administrator Manage Users use case . . . Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 49

Fig. 6. 4 Notation suggestions AND Alternate actor notation OR Payment Authorization Service Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 50

Fig. 6. 6 Use case diagram (“context diagram”) for Monopoly system. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 51

Use Case UC 1: Play Monopoly Game Scope : Monopoly application Level : user goal Primary actor : Observer Stakeholder and Interests: Observer: wants to easily observe the output of the game simulation. Main Success Scenario: 1. Observer requests new game initialization, enters number of players. 2. Observer starts play. 3. System displays game trace for next player move Repeat Step 3 until a winner or Observer cancels. Extensions: *a. At any time, System fails: 1. Observer restarts System. 2. System detects prior failure, reconstructs state, and prompts to continue. 3. Observer chooses to continue. Special Requirements: Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 Provide both graphical and text trace modes. 52

Fig. 6. 7 Process and setting context for writing use cases. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 53

Association Relationship • An association is the communication path between an actor and the use case that it participates in – It is shown as a solid line – It does not have an arrow, and is normally read from left to right – Here, the association is between a Modeler and the Create Model use case Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 54

Relationships in Use Cases • There are several Use Case relationships: – – – Association Extend Generalization Uses Include Most Use Cases have only associations. Use other relationships sparingly. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 55

Extend Relationship • Extend puts additional behavior in a use case that does not know about it. • It is shown as a dotted line with an arrow point and labeled <<extend>> • In this case, a customer can request a catalog when placing an order. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 56

Uses Relationship • When a use case uses another process, the relationship can be shown with the uses relationship • This is shown as a solid line with a closed arrow point and the <<uses>> keyword • Here different system processes can use the logon use case Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 57

Include Relationship • Include relationships insert additional behavior into a base use case. • They are shown as a dotted line with an open arrow and the key word <<include>> • Shown is a process that I observed in an earlier career. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 58

Use Case Example: Alarm Clock This is a contrived example, to show many relations. Your diagrams should be simpler. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 59

Chapter 7 OTHER REQUIREMENTS “Fast, Cheap, Good: Choose any two. ” - anonymous Objectives • Show Supplementary Specification, Glossary, Vision & Business Rules • Compare and contrast system features with use cases • Define quality attributes Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005

Introduction • While the primary requirements of a computer system tend to be the functional requirements, – i. e. , the list of activities that the system must perform, • it is also necessary to capture an number of other requirements to build a system, called non -functional requirements. – in a Vision Statement, Glossary, Business (Domain) Rules and Supplementary Specification. Produce only the required (or enough) documentation to produce the desired results efficiently and effectively. • Documentation costs money and takes time. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 61

Other Requirement Artifacts • Supplementary Specification – Captures and identifies other kinds of attributes, 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. • Business Rules (or Domain Rules) – Capture long-living and spanning rules or policies, such as tax laws, that transcend one particular application. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 62

Vision • When someone joins the project, it is useful to be able to say : – “Welcome! Please go read the 7 -page Vision at the project web site. ” • It is also useful to have an executive summary that briefly describes the project, as a context for the major players to establish a common vision of the project. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 63

The Vision • The Vision serves to communicate to project sponsors and key stakeholders – – – the reasons for the project, the problems to be solved, a description of the stakeholders and their needs, Root problems and goals, along with a description of the proposed solution. • It includes the core requirements and becomes the contractual basis to develop further requirements. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 64

Topics for a Vision • • • Introduction Positioning – Business Opportunity – Problem Statement – Product Position – Alternatives and Competition Stakeholder Descriptions – Market Demographics – Non-user Interests – User Interests – Key high-level goals and problems for stakeholders – User-Level Goals – User Environment Dr. Kivanc Dincer • Product Overview – Product Perspective – Summary of Benefits – Assumptions and Dependencies – Cost and Pricing – Licensing and Installation • System Features • Other requirements and constraints See Section 7. 6 Nex. Gen Example CS 319 Week 1 - Sept. 12, 2005 65

Why system features in Vision? • Use cases are not the only way to describe functional requirements. • Sometimes a succinct list of key functional requirements, called system features, will give a better immediate grasp of the problem and proposed solution. – A system feature is an externally observable service provided by the system which directly fulfills a stakeholder need. – Features are behavioral functions a system can do. They should pass the linguistic test: • The system does <feature X>. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 66

Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 67

Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 68

Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 69

Glossary • The Glossary captures terms and their definitions in the business domain supported by the system. – Be careful. Even simple terms may mean different things to different stakeholders and need to be defined. • The Glossary can also perform the role of a Data Dictionary, or be supplemented by one. – Data Dictionary records data about the data, that is metadata. • Aliases - relationships to other elements • Description - range of values • Format (type, length, unit) - validation rules See Section 7. 8 Nex. Gen Example Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 70

Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 71

Supplementary Specification • The Supplementary Specification captures such requirements as documentation, supportability, packaging, licensing and many of the “-ilities” of systems. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 72

Supplementary Specifications • Common Functionality • • • Purchased Components Free Open Source Components Interfaces • Usability • • Reliability • • Application-specific Domain Rules Legal Issues Info in Domains of Interest – – Logging Error Handling Pluggable Business Rules Security – Human factors – Recoverability – Performance • Supportability – Adaptability – Configurability • Implementation Constraints – Noteworthy hw and interfaces – Software interfaces – Pricing – Credit and Debit Payment Handling – Sales Tax – Item Identifiers See Section 7. 4 Nex. Gen Example Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 73

More Specifications • Reports • Operating Systems • Networking Systems Dr. Kivanc Dincer • • Process Tools Development Tools Design Constraints Internationalization Standards Physical Environment Operation Rules CS 319 Week 1 - Sept. 12, 2005 74

Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 75

Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 76

Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 77

Domain Rules • Domain or Business Rules are not functional requirements. – Domain Rules tell how the business works, while functional requirements tell how the system works. – Company policies, the laws of physics, and government regulations are examples of Domain Rules. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 78

Industry Domains • Most computer consulting firms organize their staff by industry, so that they can develop application specific knowledge that will be useful to the companies hiring them. – In New Jersey, most consulting companies have at least a Telecommunications Practice and a Pharmaceutical Practice. – Other areas might include Retail, Insurance, Wholesaling, Light Manufacturing, and Electric Utilities. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 79

Knowledge Domains • In addition to Industry specific knowledge, there are many areas of knowledge that apply across a number of industries. – The most thoroughly specified of these knowledge domains is accounting. – Others might include inventory, scheduling, and queuing. – Each has a body of specific knowledge that specialists know well. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 80

Guidelines • Should we analyze these thoroughly during inception? • Reliable Specifications: An Oxymoron? • Should these artifacts be at the project web site? Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 81

Requirements Reliability • Never assume that requirements are completely understood, adequately captured, effectively described, or reasonably complete. • Requirements discovery and scope creep tend to occur throughout the software development process and even after the system is put into production. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 82

UML Diagrams in Inception • Aside from the possible inclusion of a few high level use case diagrams, the inception phase is almost all text. • Most diagramming occurs in the Elaboration Phase. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 83

Process: Evolutionary Requirements in Iterative Methods Discipline Artifact Iteration-> Business Modeling I 1 Domain Model Construction Transition E 1…En C 1…Cn T 1. . T 2 s r Elaboration s r Vision s r Supplementa ty Specification s r Glossary s r Business Rules s r Requirements Use-Case Model Design Inception Design Model s Sw Arch Model s Dr. Kivanc Dincer Data Model s CS 319 Week 1 - Sept. 12, 2005 r r 84