Topics

1. Topics • Requirements • Business Process Modeling • Business Concept Modeling • System Envisioning • Use Case Modeling • Module Summary • Appendix: Project Estimation • Hands-on: Requirements Definition

2. Poor staffing 6% Poor technical skills 7% Changing requirements 12% Other 50% Incomplete requirements 12% Poor user input 13% Factors on Challenged Software Project • 37% of factors related to problems with requirements, making requirements issues the largest single contributor to problems. • Jim Johnson, “Chaos: Charging the Seas of Information Technology”, Published Report. The Standish Group, 1994]

3. Requirements • A requirement is a property that must be exhibited by a system developed or adapted to solve a particular problem. • Requirements on a system are typically a complex combination of requirements from different people at different levels of an organization and from the environment in which the system must operate. • Requirement engineering • The systematic handling of requirements. • Software requirements are one of the products of the requirement engineering process.

4. Main Objectives of Requirements Engineering • To discover how to partition the system • to identify which requirements should be allocated to which components. • Good communication between system users and system developers.

5. Breakdown of Topics for Software Requirement [“SWEBOK: Guide to the Software Engineering Body of Knowledge”, IEEE, 2001]

6. Business Process Modeling • Purpose • Understand the business needs in terms of strategy, organization, process and information. • Provide a good starting point before define user requirements. • Representation • Activity Diagram • Input • Domain Knowledge • Business Strategy • Output • Business Process Model (or Domain Model) • Modeling Techniques • An important point at this stage is how you worked together with users, business analysts, and domain experts. • Business process description is in no way a statement of the requirements an IT system.

7. Example: Business Process Model • Business Process for hotel reservation • The reservation process is initiated by an enquiry from a potential customer. • Room availability is checked. • If a suitable room is available, the customer makes a reservation. • Details of the reservation are confirmed to the customer by e-mail. • Then one of four things can happen • The customer take up his reservation. • He might cancel. • He might amend some details of it. • This will require another confirmation. • He might no-show. • But He is going to get a bill anyway.

8. Take up reservation Wait for event customer arrives/ enquiry/ [else] cancel request/ Check availability amendment request/ [suitable room] Cancel reservation Amend reservation Make reservation no-show/ Confirm reservation Process no-show Notify billing system Example: Business Process Model – Cont’d • Business Process for hotel reservation

9. Business Processes Requirements Requirement Definition Specification Component Identification Component Interaction Component Specification Provisioning Assembly Deployment Requirements Definition Stage • Purpose • Agree on some Basic Concepts • Define the Scope of Project • Capture User Requirements • Input • Domain(Business Process) Model • User Requirements • Output • Business Concept Model • High level System Envisioning Statement • Use Case Model • Activities • Business Concept Modeling • System Envisioning • Use case Modeling

10. Business Processes Requirements Requirement Definition Business Process Model Specification Requirement Definition Component Identification System Envisioning Component Interaction Business Concept Model Use Case Model Component Specification Business Concept Model Use Case Model Provisioning Assembly Deployment Activities in Requirement Definition

11. Business Concept Modeling • Purpose • Introduce principal Concepts within the project scope. • Representation • Represented by Class Diagram, But informal. • Input • Domain Knowledge • Business Process Model • Output • Business Concept Model • Modeling Techniques • Identify Business Concept. • Define each Business Concept. • Identify association between Business Concepts. • Identify any obvious attributes of the Business Concepts.

12. Namkyu Cho Customer Person Finding Business Concept • Find objects in problem statement, domain vocabulary, scenarios • Any noun (or noun-phrase) • If you can count, see, or touch it, it is a candidate • The memory of an event – e.g., Order • Any object that directly participates in an action • Consider different varieties of objects • Physical – e.g., Vehicle, Person, Equipment, Book, Location • Process or activity – e.g., Meeting, Order, Accident • Abstract – e.g., Organization Unit, Rule, Project • Not too generic or specific • Select level appropriate to business.

13. Defining Business Concept • Dictionary-style definition • One or two sentences • Avoid using the concept name in its definition • Applicable to the domain • Add any obvious attributes • More can be added later as they are discovered. • Precise, but not detailed. • Examples • Customer – a person or organization that rent a car from HVH company. • Order – a set of goods that a customer wants to buy. • Payment – a financial transaction where the customer pays for ordered goods.

14. Customer Payment number name deliverlyAddress date method amount Finding Attributes • Optional task • Ensuring that information is not forgotten. • Only document known attributes • Do not spend time searching for attributes. • Just name attributes • Do not define them • Examples

15. Fruit Basic Concepts of Class Diagram • Type is a set of objects that have some (but not necessarily all) behavior in common. • A type is a partial description. • Different from a class which specifies how an object does what it does. • Corresponds to a real-world description.

16. Fruit apple sweet 25 name: Text taste: Taste avgNumSeeds: Number Basic Concepts of Class Diagram – Cont’d • Attribute is a specific characteristic of a type which is itself of a type. • A type typically has a set of attributes of interest. • An instance of that type will have a set of values corresponding to the attributes.

17. Fruit Fruit Juice name: Text taste: Taste avgNumSeeds: Number price: Money stock: Units apple sweet 25 1.99 5500 Basic Concepts of Class Diagram – Cont’d • Association is a pair of attributes that are inverses of each other, usually drawn as a line connecting two types. • Defines type of relationship between instances of types.

18. 1 1..* Clerk Room Type Room Reservation Bill Payment Address Customer Hotel Chain Hotel 1..* 1 * 1 contactedHotel 1..* * allocation 1 * 1 1 * * 1..* contactAddress 1 0..1 1 1 0..1 Example: Business Concept Model • Business Concept Model for hotel reservation

19. Create a business concept model under the Business Concept Model package Requirements Business Concept Model Use Case Model Specification Business Type Model Interface Specifications Component Specifications Component Architecture Interactions Package Structure: Business Concept Model

20. System Envisioning • Purpose • Describe the system’s functionalities from the point of view of its users to identify the software boundary. • Modeling Technique • Storyboarding. • Example: High-level system envisioning statement for hotel reservation 호텔 체인 내의 어느 호텔이든 예약 시스템을 통해 예약 업무를 수행 할 수 있다. 현재 각 호텔은 서로 호환되지 않는 각자의 시스템을 가지고 있으며, 예약은 중앙의 예약 센터나 각 호텔로 전화를 통해서 하거나 인터넷을 통해서도 할 수 있다. 새로운 시스템의 주요한 장점이라면 원하는 호텔에 객실이 없을 경우 인접한 다른 호텔의 객실을 제공할 수 있다는 점이다. 예약을 위하여 호텔내의 접수 데스크, 사무실, 접객원 데스크 등의 시설이 이용된다. 각 호텔에는 예약을 통제할 수 있는 담당자가 있지만 허가를 받았다면 누구라도 예약을 접수할 수 있다. 전화나 사람을 통한 예약 접수는 3분 이내에 가능해야 한다. 이상의 업무 진행 시간을 단축시키기 위해서 이미 고객으로 등록된 정보는 저장되고 언제든지 사용 가능한 상태로 관리되어야 한다.

21. Use Cases Modeling • Purpose • Identify and scope the business context of the software behavior. • Representation • Use Case Diagram • Use Case Description • Input • Domain Knowledge • Business Process Model • Output • Use Case Model • Modeling Techniques • Identify business needs. • Discover use cases and actors. • Storyboard the use cases. • Factoring out <<include>> and <<extend>> use cases. • Describe each use case.

22. Actors and Roles • A coherent set of roles that users of use cases play when interacting with these use cases. • An actor has one role for each use case with which it communicates. • “can play the role of” • Always external to your system, not a part of your system. • An actor defines a single role played by users in their interactions with the system: • Multiple users can play a single role • A single user may play multiple roles

23. <<actor>> BillingSystem <<actor>> Guest <<actor>> ReservationMaker <<actor>> ReservationAdministrator <<actor>> Customer <<actor>> Clerk Example: Actors and Roles

24. Identifying Actors • Look for things in the categories of people, other software, hardware devices, data stores, or networks… • Who uses the system? • Who installs the system? • Who starts up the system? • Who maintains the system? • Who shuts down the system? • What other systems use this system? • Who gets information from this system? • Who provides information to the system? • Does anything happen automatically at a present time?

25. Use Cases • The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system. • A use case should be a complete task from the actor’s perspective. • The behavior of a single use case is often complete in a relatively short period of time. • A use case is always started by an actor.

26. Use Case Identification • Look for things that actors want the system to do • What functions will the actor want from the system? • Does the system store information? What actors will create, read, update, or delete that information? • Does the system need to notify an actor about changes in its internal state? • Are there any external events the system must know about? What actor informs the system about those events?

27. Make a reservation Cancel a reservation Take up a reservation Use Case Granularity • Use Cases can be big or small. • Consider spectrum of granularity. LOW HIGH Stock Control Monitor Stock Find Supplier Manage Reservation

28. Use Case Granularity – Cont’d • There can be various level of granularity on use cases. • However, in the same model, you must keep the granularity consistent • That is, it is not allowed that “(Big) Purchasing” and “(Small) Find Supplier” are in the same use-case model. • Then, what is the appropriate level of granularity? • In [CF98], Martin Folwer says “They used around 170 use-cases, while another authority would have expected 25.” • This disagreement comes from the different purposes • Some wants to manage a project with use cases. • While others just want to draw an agreement of his customers. • In this presentation, we will follow the view of the latter • Then, we will the notion of “system operation” in the analysis phase for the view of the former.

29. Documenting CRUD • You will often need the use case which has functionality known as CRUD when your application includes maintaining data. • There are two approaches • One is to create a separate use case for each kind of access to the data. • The other is to create one use case for a data type that embeds all of the CRUD functions. • In this class, we uses the first approach. • Because different actors use separate CRUD functions, so it makes more sense to make them separate use cases. • On the other hand, in some applications combining them may be sensible. for example, if the application is for a database administrator to update tables in a database.

30. Take Up Reservation Cancel Reservation Make Reservation Process No-Show Amend Reservation Identify Use cases from Business Process A use case describes the interaction that follows from a single business event. Where an event triggers a number of process steps, all the steps form a single use case. Guest Take up reservation Wait for event customer arrives/ enquiry/ [else] cancel request/ Check availability amendment request/ [suitable room] Cancel reservation Amend reservation Make reservation Reservation Maker no-show/ Confirm reservation Process no-show Notify billing system System

31. Print a System Report Every day at midnight Print a System Report System administrator Print a System Report Every day at midnight System administrator Handling Time • In some systems, there are activities that take place at certain times or conditions. For examples, • Process No-Show • {A reservation not claimed by 8 a.m. on the day after scheduled arrival will be treated as a no-show.} • There are essentially two ways to handle times (or conditions) in use cases • Treat time as an actor • Treat handling time as part of the system • Combine above methods

32. Check Use Cases • Pore over the business concept model, asking following questions. • Business concept model create/destroy check • Do the things these boxes represent get created and destroyed? • Does the software need to know about this? • If so, how does it find out? • Does this thing have attributes that might change? • Business concept model association update check • Do the relationships between these things, as indicated by the associations, change over time? • If so, does the software need to know and how does it find out?

33. Concept Model Create/Destroy Check

34. Concept Model Association Update Check

35. Drinker Basic Concepts of Use Case Diagram • Actor is a role that a user plays with respect to the system. • Not specific to a person or job title – a user can play more than one role. • An actor can perform many use cases. • A use case may be performed by more than one actor. • Actor does not necessarily need to be a person – can be an external system. • Often easier to list actors first and then identify the use cases for each actor. • Some users gain value from the use case whereas some others may just participate.

36. Drinker Basic Concepts of Use Case Diagram – Cont’d • Use case is a typical interaction between a user and a computer system. • A use case captures some user-visible function. • A use case may be small or large. • A use case achieves a discrete goal for the user. • Yields an observable result of value to a particular actor. Vending Machine Pick up the fruit juice

37. Reservation system Cancel a reservation ReservationMaker Make a reservation Update a reservation Guest Take up a reservation Process no shows BillingSystem Add, amend, remove hotel, room, customer, ... ReservationAdministrator Example: Use Case Diagram

38. Use Case Descriptions • Think about how the initiating actor will interact with the system. • Guided by the business process description and the system envisioning statement. • Begin with the basic path, then add alternatives. • Contents of Use Case Description • Use case name • List the participating actors • Clearly define the goal • Describe basic path • Write from user’s perspective, but consider who will be reading the use cases. • Clearly define responsibilities(actor versus system). • Use business language. • Consider alternative paths separately

39. Use Case Descriptions – Cont’d • Details of use cases are expressed textually. • But typically need graphical depiction of the interaction • Activity Diagrams • Emphasize the steps in the process. • Sequence Diagrams • Emphasize the message flow and sequencing. • Collaboration Diagrams • Emphasize the context, message, and data flow. • UI Prototype • Emphasize the user & system interactions. • Not all information can be, or should be, shown on a use case diagram. • You will often need a combination of diagrams to get a complete picture of your system.

40. Presentation Styles • Informal text form • Numbered steps form • Table form request display form enter the information transaction respond • request • display form • enter the information • transaction • respond

41. Example: Use Case Description • Name Take up reservation • Initiator Guest • Goal Claim a reservation and check in to the hotel • Main Success Scenario • Guest arrives at hotel and claim a reservation. • Guest provides reservation tag. • Guest confirms details of stay duration, room type. • System allocates room. • System notifies billing system that a stay is starting.

42. Alternative Paths • An alternative path gives alternatives to the basic path. • We also document errors as alternative paths. • The alternative paths are good for showing things that can happen at any time • something that interrupts the normal flow of events.

43. Finding Alternative Paths • Go through the basic path line by line with following questions • Is there some other action that can be taken at this point? • Is there something that can go wrong at this point? • Is there some behavior that can happen at any time? • Use categories • An actor exists the application • An actor cancel a particular operation • An actor requests help • An actor provides bad data • An actor incomplete data • An actor chooses an alternative way of performing the use case • The system crashes • The system is unavailable

44. Documenting Alternatives more complex use cases 1. 2. 3. If 4. 1. 2. 3. 1. 2. 3. Alternative Paths

45. Vending Machine Count the coins <<include>> Pick up the fruit juice Drinker Advanced Concepts in Use Case Diagram • Include is a relationship from a base use case to an inclusion use case, specifying how the behavior for the base use case contains the behavior of the inclusion use case. The behavior is included at the location which is defined in the base use case. The base use case depends on performing the behavior of the inclusion use case, but not on its structure. • You can abstract the common behavior with a include relationship. • Including use case is no longer complete by itself. • The use case being included does not know when or it is included. • A use case can use any number of other use cases. You can have as many levels of include as you desire.

46. Vending Machine Count the coins <<include>> Pick up the fruit juice No-Ice <<extend>> Drinker Advanced Concepts in Use Case Diagram • Extend is a relationship from an extension use case to a base use case, specifying how the behavior defined for the extension use case augments (subject to conditions specified in the extension) the behavior defined for the base use case. The behavior is inserted at the location defined by the extension point in the base use case. The base use case does not depend on performing the behavior of the extension use case. • Extend is used to conditionally extend the behavior of an existing use case. • The extension includes a conditional expression. When the extension point is reached, if the condition is true, the steps in the extension are executed.

47. Reservation system Cancel a reservation <<include>> ReservationMaker Make a reservation <<include>> Identify reservation Update a reservation Guest Take up a reservation <<include>> Process no shows BillingSystem Add, amend, remove hotel, room, customer, ... ReservationAdministrator Example: Included Use Case

48. Example: Use Case Abstraction • Name Identify reservation • Initiator Included only • Goal Identify an existing reservation • Main Success Scenario • Actor provides reservation tag. • System locates reservation. • Extensions • 2. System cannot find a reservation with the given tag. • a. Actor provides name and post code. • b. System display active reservations for that customer. • c. Actor select the reservation. • d. Stop. • 2. The reservation tag refers to a reservation at a different hotel. • a2. Fail. • 2b. No active reservations at this hotel for this customer. • a. Fail.

49. Example: Use Case Abstraction • Name Take up reservation • Initiator Guest • Goal Claim a reservation and clerk in to the hotel • Main Success Scenario • Guest arrives at hotel and claim a reservation. • Include Identify Reservation. • Guest confirms details of stay duration, room type. • System allocates room. • System notifies billing system that a stay is starting. • Extensions • Reservation not identified. • Fail.

50. Create a use case model under the Use Case Model package Requirements Business Concept Model Use Case Model Cancel a reservation Make a reservation ... Specification Business Type Model Create sub-packages for each use case with the same name as the use case, and then write an use case descriptions under the Sub-Package Interface Specifications Component Specifications Component Architecture Interactions Package Structure: Use Case Model