1. Requirements Determining the requirements of software involves determining the needs of the users of the software. Determining the requirements of software involves determining the needs of the users of the software.

2. Requirements This can be done in several ways: This can be done in several ways: Interviewing users to elicit their needs. Interviewing users to elicit their needs. Perform a domain analysis. Perform a domain analysis. Create a need. Create a need.

3. Using UML to Elicit Requirements UML can be helpful in eliciting requirements UML can be helpful in eliciting requirements Object models (class and object diagrams) and behavior models (use cases and state diagrams) are commonly used. Object models (class and object diagrams) and behavior models (use cases and state diagrams) are commonly used.

4. Object Models Object models try to model the real world using “objects” that represent real world objects. Object models try to model the real world using “objects” that represent real world objects. The objects in the object model have “properties” (attributes) and “actions” (methods) that represent properties and actions of the real world objects to model the problem domain. The objects in the object model have “properties” (attributes) and “actions” (methods) that represent properties and actions of the real world objects to model the problem domain.

5. Object Models The following are rules for object models: The following are rules for object models: All real world entities (objects) that are important to understanding the problem domain must be included. All real world entities (objects) that are important to understanding the problem domain must be included. All methods and attributes important to understanding the problem domain must be included. All methods and attributes important to understanding the problem domain must be included. Objects, attributes, and methods only significant for implementation should not be included. Objects, attributes, and methods only significant for implementation should not be included.

6. Object Model Example Create an object model for depositing and withdrawing money from an ATM machine. Create an object model for depositing and withdrawing money from an ATM machine. We will need three classes, “Customer”, “ATM”, and “Account”. We will need three classes, “Customer”, “ATM”, and “Account”. Customer should have a pin number and should be able to get money from the account and put money into the account. Customer should have a pin number and should be able to get money from the account and put money into the account.

7. Object Model Example ATM’s should be able to get the pin number from the customer, dispense money to the customer, and receive money from the customer. ATM’s should be able to get the pin number from the customer, dispense money to the customer, and receive money from the customer. Accounts should have a balance and allow deposits and withdrawals. Accounts should have a balance and allow deposits and withdrawals.

8. Object Model Example

9. Behavior Modeling (Use Case) A use case diagram represents the functionality of the systems from the users point of view. A use case diagram represents the functionality of the systems from the users point of view. Use case diagrams should be designed and approved by both the software designer and the customer. Use case diagrams should be designed and approved by both the software designer and the customer.

10. Use Cases The Use case diagram is used to identify the primary elements and processes that form the system. The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The primary elements are termed as "actors" and the processes are called "use cases."

11. Use Cases The Use case diagram shows which actors interact with each use case. The Use case diagram shows which actors interact with each use case. Due to the simplicity of use case diagrams, and more importantly, because they are devoid of all technical jargon, use case diagrams are a great “storyboard” tool for user meetings. Due to the simplicity of use case diagrams, and more importantly, because they are devoid of all technical jargon, use case diagrams are a great “storyboard” tool for user meetings.

12. Use Case Example Create a use case diagram for the ATM machine problem for the customer. Create a use case diagram for the ATM machine problem for the customer. The customer can type in the pin number, put money into the ATM (deposit) and take money from the ATM (withdrawal) The customer can type in the pin number, put money into the ATM (deposit) and take money from the ATM (withdrawal)

13. Use Case Example

14. Behavior Modeling (Scenarios) A scenario (or use case scenario) is a sequence of actions that accomplishes a user task. A scenario (or use case scenario) is a sequence of actions that accomplishes a user task. Scenarios are used to illustrate an important capability or proposed use of the system. Scenarios are used to illustrate an important capability or proposed use of the system. In UML, an interaction diagram is used to represent a scenario. In UML, an interaction diagram is used to represent a scenario.

15. Scenario Example Write a scenario for a student withdrawing money from the ATM. Write a scenario for a student withdrawing money from the ATM. 1. Type in pin number. 2. Choose “withdrawal”. 3. Type in the amount. 4. Take the money. 5. Blow the money on a pizza and a six pack.

16. Differences between “use case” and “Use case scenario” So what’s the difference between a “use case” and a “scenario” (or sometimes called a “use case scenario”)? So what’s the difference between a “use case” and a “scenario” (or sometimes called a “use case scenario”)?

17. Differences between a “Use Case” and a “Use Case Scenario?” USE CASE: A visible and identifiable system behavior associated with one or more actors external to the system. USE CASE: A visible and identifiable system behavior associated with one or more actors external to the system. USE CASE SCENARIO: An elaboration of a Use Case into a precisely defined statement of system behavior. USE CASE SCENARIO: An elaboration of a Use Case into a precisely defined statement of system behavior. A Scenario is represented as a Use Case plus a set of assumptions (initial conditions) plus a set of outcomes A Scenario is represented as a Use Case plus a set of assumptions (initial conditions) plus a set of outcomes One Use Case creates multiple use case scenarios One Use Case creates multiple use case scenarios The Use Case Scenarios are more detailed and from a user’s task perspective The Use Case Scenarios are more detailed and from a user’s task perspective

18. State Diagrams A state diagram shows the state of the system and all possible transitions between the states. A state diagram shows the state of the system and all possible transitions between the states. In other words, a state diagram is a finite automaton. In other words, a state diagram is a finite automaton. I hope you remember your theory of computation. I hope you remember your theory of computation.

19. State Diagrams State diagrams can help to clarify requirements. State diagrams can help to clarify requirements. It is important that the states reflect domain conditions that are understandable to the user. It is important that the states reflect domain conditions that are understandable to the user.

20. State Diagram Example Create a state diagram for a student using the ATM machine. Create a state diagram for a student using the ATM machine. This is one of those strange automata where there are no final states. This is one of those strange automata where there are no final states.

21. Other Useful Tools Data dictionaries and systems diagrams can also be used to explain the proposed system to the client. Data dictionaries and systems diagrams can also be used to explain the proposed system to the client.

22. Data Dictionary A data dictionary is a table about each data element in the system. A data dictionary is a table about each data element in the system. A typical entry includes: A typical entry includes: The name of the item. The name of the item. In which class it is located. In which class it is located. The data type of the item. The data type of the item. The semantics (meaning) of the item. The semantics (meaning) of the item.

23. Data Dictionary Example A data dictionary for the ATM problem might look like: A data dictionary for the ATM problem might look like: Name Class TypeSemantics Pin Number Customer LongUsed to authenticate the customer Balance Account Float The amount of money in the account

24. System Diagrams A system diagram is a nonformally defined diagram used to give an overview of the proposed system. A system diagram is a nonformally defined diagram used to give an overview of the proposed system. System diagrams have ovals representing processing, cylinders representing databases, boxes representing data, and stick figures representing persons. System diagrams have ovals representing processing, cylinders representing databases, boxes representing data, and stick figures representing persons.

25. IEEE Standards for Software Requirements Specification See http://standards.ieee.org/reading/ieee/std _public/description/se/ See http://standards.ieee.org/reading/ieee/std _public/description/se/ http://standards.ieee.org/reading/ieee/std _public/description/se/ http://standards.ieee.org/reading/ieee/std _public/description/se/

26. Homework Pg 120 # 1,5,7,9,11 odd Pg 120 # 1,5,7,9,11 odd