REQUIREMENTS ANALYSIS Initialize Use Case for Encounter actors

  • Slides: 24
Download presentation
REQUIREMENTS ANALYSIS

REQUIREMENTS ANALYSIS

Initialize Use Case for Encounter actors player designer Encounter Use case details Initialize Use

Initialize Use Case for Encounter actors player designer Encounter Use case details Initialize Use case 1. System displays player’s Initialize main character in the dressing room. Travel to 2. System displays a window adjacent for setting his character's area qualities. 3. . . Encounter foreign character Set rules Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Initialize Use Case for Encounter actors player designer Encounter Use case details Initialize Use

Initialize Use Case for Encounter actors player designer Encounter Use case details Initialize Use case 1. System displays player’s Initialize main character in the dressing room. Travel to 2. System displays a window adjacent for setting his character's area qualities. 3. Player allocates the qualities of his main Encounter character. foreign 4. Player chooses an exit character from the dressing room. 5. System moves player’s main character into the area Set rules on the other side of the exit. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Engage Foreign Character Use Case Encounter Use case Initialize player Travel to adjacent area

Engage Foreign Character Use Case Encounter Use case Initialize player Travel to adjacent area Engage foreign character designer Set rules Use case details Engage Foreign Character 1. System displays the foreign character in the same area as the player’s. 2. System exchanges quality values between the two characters. 3. System displays the results of the engagement. 4. System displays player’s character in a random area. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Conceptual Model of the System Player 1 n Plays Has 1 1 1 Encounter.

Conceptual Model of the System Player 1 n Plays Has 1 1 1 Encounter. Game Entity Relationship Model or Object Model Has 1 Foreign. Character Main. Character 1 1 Has n Engagement n 1 Area Takes place in 1

Data Flow Diagram: Explanation of Symbols Processing element Direction of data flow Check deposit

Data Flow Diagram: Explanation of Symbols Processing element Direction of data flow Check deposit Get deposit Account # & deposit Data type

Data Flow Diagram: Explanation of Symbols Processing element Direction of data flow Check deposit

Data Flow Diagram: Explanation of Symbols Processing element Direction of data flow Check deposit Input Get deposit User Account # & deposit Output Data type Printer …. . . balance query account Data store database account data Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Create account summary

member banks bank name Partial Data Flow Diagram for ATM Application Get deposit Get

member banks bank name Partial Data Flow Diagram for ATM Application Get deposit Get inquiry User error account # & deposit account display Validate inquiry Validate deposit account # & deposit Display account data Do deposit transaction error Make inquiry account # Printer balance query account database account data Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Create account summary

Partial Encounter State-Transition Diagram Preparing Setting up Complete setup Waiting Player clicks qualities menu

Partial Encounter State-Transition Diagram Preparing Setting up Complete setup Waiting Player clicks qualities menu Foreign character enters area Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Engaging

Using Conditions in State-Transition Diagrams state event Waiting Player moves to adjacent area condition

Using Conditions in State-Transition Diagrams state event Waiting Player moves to adjacent area condition [foreign character present] [foreign charact er absent] condition Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Engaging state

Sketch of Encounter State-Transition Diagram Setting up Player completes setup Player dismisses set qualities

Sketch of Encounter State-Transition Diagram Setting up Player completes setup Player dismisses set qualities widow Setting qualities Reporting Player dismisses report window Player requests status Player requests to set qualities Foreign character enters area Waiting Player moves to adjacent area Player quits [foreign character absent] Foreign character enters area Encounter completed Engaging [foreign character present] Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Conceptualizing a System in terms of the User Interface • Customers/Users often conceive a

Conceptualizing a System in terms of the User Interface • Customers/Users often conceive a system in terms of its user interface • Screen prototyping and story boarding (screen facade but no code) works well in connection with Use Case

Step 1: Know your user Steps for Constructing User Interfaces* (C)‡ Step 2: Understand

Step 1: Know your user Steps for Constructing User Interfaces* (C)‡ Step 2: Understand the business function in question (C) Step 3: Apply principles of good screen design (C, D) Step 4: Select the appropriate kind of windows (C, D) Step 5: Develop system menus (C, D) Step 6: Select the appropriate device-based controls (C) Step 7: Choose the appropriate screen-based controls (C) Step 8: Organize and lay out windows (C, D) Step 9: Choose appropriate colors (D) Step 10: Create meaningful icons (C, D) Step 11: Provide effective message, feedback, & guidance (D) * adapted from Galitz [Ga 2] ‡ a C-requirement process

Applying Principles of Good Screen Design: “Before” Type checking Branch Main St. Privileges saving

Applying Principles of Good Screen Design: “Before” Type checking Branch Main St. Privileges saving Elm St. newsletter mmf CD High St. discounts quick loans First name Middle name Last name Street City State/county OK Apply Cancel Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Help * see Galitz [Ga 2]

Applying Principles of Good Screen Design: “After” New Customers Name Address First Street Middle

Applying Principles of Good Screen Design: “After” New Customers Name Address First Street Middle City Last State/county Branch Account type Privileges checking saving mmf CD Main St. Elm St. High St. OK Apply Cancel newsletter discounts quick loans Help Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Anticipate start New Customers Name Address First Street Middle Align like elements Ensure consistency

Anticipate start New Customers Name Address First Street Middle Align like elements Ensure consistency City Last Branch How Principles of Good Screen Design Were Applied State/county Border around like element Account type Use Captions Privileges checking saving Symmetry mmf CD Main St. Elm St. High St. Group like elements OK Proportion Apply Cancel newsletter discounts Balance quick loans Help Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

1. Purpose: display properties of an entity -- property window Properties of automobile 189

1. Purpose: display properties of an entity -- property window Properties of automobile 189 Property Value Window Usage 1 of 2 Brand Model ID Toyota Camry 893 -8913 -789014 2. Purpose: obtain additional information so as to carry out a particular task or command -- dialog window Help Word __________ This screen All screens Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

3. Purpose: provide information -- message window ABC alert message Caution: “age” must be

3. Purpose: provide information -- message window ABC alert message Caution: “age” must be < 120 OK Window Usage 2 of 2 4. Purpose: present a set of controls -- palette window ABC controls File Edit View Format Tools Help monitor 5. Purpose: amplify information -- pop-up window disk keyboard modem This is a popup window, designed to provide on-the-fly amplification Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Develop System Menus • Provide a main menu • Display all relevant alternatives (only)

Develop System Menus • Provide a main menu • Display all relevant alternatives (only) • Match the menu structure to the structure of the application’s task • Minimize the number of menu levels – Four maximum?

Common GUI Terms Cascading windows Tiled windows Icon New Customer Text box Name Screen

Common GUI Terms Cascading windows Tiled windows Icon New Customer Text box Name Screen First forward Last Radio button Button back Account type checking saving mmf Cancel Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Privileges newsletter discounts Apply Check box Graphics reproduced with permission from Corel.

Preliminary Sketch of User Interface for Setting Game Character Qualities 16 Adapted from Software

Preliminary Sketch of User Interface for Setting Game Character Qualities 16 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Preliminary Encounter Screen Shot Name of adjacent area Adapted from Software Engineering: An Object-Oriented

Preliminary Encounter Screen Shot Name of adjacent area Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 20001), with permission. Graphics reproduced with permission from Corel.

Express Customer Requirements 1/2 • If the requirement is simple, and stands alone, express

Express Customer Requirements 1/2 • If the requirement is simple, and stands alone, express it in clear sentences within an appropriate section of the SRS • If the requirement is an interaction between the user and the application, express via a use case. 1. Name the use case 2. Identify the “actor” • the external user role-- usually a person 3. Write the sequence of user - application actions • Minimize branching • Use general form. Avoid specific names and values as in “Ed enters $300”. Instead, say “customer enters deposit amount”. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

• If the requirement involves process elements, each taking inputs, and producing outputs,

• If the requirement involves process elements, each taking inputs, and producing outputs, use data flow. 1. Identify the processing elements (usually high level); as circles or rectangles 2. Identify the data sources & destinations; as names between two horizontal lines 3. Show the data paths among processing elements. Indicate types of data flowing on each show • If the requirement involves states that the application can be in (or parts can be in) 1. Identify the states (each a passive verb, e. g. , “waiting”); Express Customer show as rounded rectangles Requirements 2/2 2. Show initial state with special arrow 3. Identify the events (happenings external to the unit) that cause transitions among the states; show as labeled arrows 4. Identify sub-states; show as rectangles within rectangles

Actors Briefing Actors Briefing Actors Briefing Actors BriefingActors Briefing Actors Briefing Actors Briefing Actors Briefing
4 REQUIREMENTS ANALYSIS CASE STUDY Initialize Use Case4 REQUIREMENTS ANALYSIS CASE STUDY Initialize Use Case
Initialize 1 Private Sub Initialize Dim i aInitialize 1 Private Sub Initialize Dim i a
Typical Program Structure Initialize Window GLUT Initialize EventTypical Program Structure Initialize Window GLUT Initialize Event
Use Case Actors Associations and Use Case SpecificationsUse Case Actors Associations and Use Case Specifications
Use Case Diagrams Use Case Diagrams Use CaseUse Case Diagrams Use Case Diagrams Use Case
Use Case Diagrams Use case A use caseUse Case Diagrams Use case A use case
Use Case Diagrams Use case A use caseUse Case Diagrams Use case A use case
Use Case Diagrams Use Case n Use caseUse Case Diagrams Use Case n Use case
Use Case Diagrams Use case A use caseUse Case Diagrams Use case A use case
Use Case Diagrams Use case A use caseUse Case Diagrams Use case A use case
Use Case Use Case Diagrams Use Case DescriptionsUse Case Use Case Diagrams Use Case Descriptions
Use Case Diagrams Use Case Descriptions Use CaseUse Case Diagrams Use Case Descriptions Use Case
Requirements analysis Requirements Analysis and Specification 1 RequirementsRequirements analysis Requirements Analysis and Specification 1 Requirements
Requirements analysis Requirements Analysis and Specification 1 RequirementsRequirements analysis Requirements Analysis and Specification 1 Requirements
Requirements analysis Requirements Analysis and Specification 1 RequirementsRequirements analysis Requirements Analysis and Specification 1 Requirements
Requirements analysis Requirements Analysis and Specification 1 RequirementsRequirements analysis Requirements Analysis and Specification 1 Requirements
Meta Model I has Encounter Patient Encounter hasMeta Model I has Encounter Patient Encounter has
Encounter 7 15 18 I ENCOUNTER PROMISES FULFILLEDEncounter 7 15 18 I ENCOUNTER PROMISES FULFILLED
Encounter God 10 13 19 1 ENCOUNTER THROUGHEncounter God 10 13 19 1 ENCOUNTER THROUGH
Joint and Combined Operations Transnational Actors NonState ActorsJoint and Combined Operations Transnational Actors NonState Actors
NonState Actors and Governance Transnational NonState Actors TransnationalNonState Actors and Governance Transnational NonState Actors Transnational
NONSTATE ACTORS IN IR SUMMARY Nonstate actors inNONSTATE ACTORS IN IR SUMMARY Nonstate actors in