Structuring System Requirements: Conceptual Data Modeling

1
Structuring System RequirementsConceptual Data
Modeling
2
ERM
3
(No Transcript)
4
Analysis Sub Phases
Generate Alternatives Select best
Structure Requirements
Determine Requirements
5
Implementing Effective Systems

• If you do not understand organizational data and
  cannot represent the data requirements of an
  application unambiguously in logical terms, you
  cannot implement a system that will effectively
  serve the needs of management or users.

6
Data Modeling

• Shows the definition, structure, and
  relationships within data.
• Process modeling only shows how, where when
  data is used.

7
Conceptual data model

• Conceptual Data Model
• Is a detailed data model that captures the
  overall structure of organizational data,
• Is independent of DBMS.
• Shows as many rules about the meaning and
  interrelationships among data as possible
• Is what the organization does and rules that
  govern how the work is done
• primary deliverable ? Entity Relationship Diagram

8
(No Transcript)
9
Entity Relationship Diagram IS

• a logical representation of
• entities,
• attributes, and
• relationships.
• Lets examine each of these...

10
Entity

• Entity (object/noun)
• person, place, object, event, or concept of
  interest

11
Entities

• An entity is a person, place or object, event, or
  concept of interest
• An instance is a single occurrence of an entity
  

Entity
An Instance of this entity
12
A word about entities...

• An ERD entity is not the same as a source or sink
  in a Data Flow Diagram.
• There will usually be multiple instances.
• Data entities have to be described by attributes.

13
Attributes

• Lets look as some attributes which identify
  entity instances.
• They may or may not be unique.
• They may be composite attributes.

Unique Attribute Composite Non-unique
Attribute Non-unique Attribute Unique Attribute
14
Hoffers take on Keys

• Entities must have an identifier.
• Candidate Key
• an attribute(s) that uniquely identifies each
  instance of an entity. (e.g. SSN and Name)
• Out of the multiple candidate, only one is
  selected to be the
• Identifier
• the candidate key selected as the identifier for
  an entity. (e.g. SSN)

15
For purposes of our discussion...

• Entities must have a primary key.
• Primary Key
• a key that uniquely identifies each instance of
  an entity (ex SSN)
• Secondary Key
• a key that cannot uniquely identify each instance
  of an entity but can be used to select a group of
  records that belong to a set (ex Aggies that
  come from Texas)
• Starting to sound a little bit like Info428?

16
More on the subject of keys

• Concatenated Key
• When it is not possible to identify each instance
  of a relationship uniquely by choosing one of the
  attributes in the entity, a key can be
  constructed by choosing two or more attributes
  and combining them.
• For example 99C-Info320-Section 504
• Hoffers Candidate Keys include concatenated or
  other single attributes.

17
Attributes

• Characteristic of an entity
• May have a composite attributes
• Also known as field
• Multivalued attribute has more than 1 value for a
  given instance of an entity.(e.g. phone although
  not shown)

Attributes
Composite Attribute
Attribute Values
18
Relationship

• An association between two or more entities
• a verb phrase connecting entities
• Directional
• Event
• Something happens
• Linkage
• We will use the Crows Foot notation style

19
One-to-one An EMPLOYEE is assigned one PARKING
SPACE. A PARKING SPACE is assigned to one
EMPLOYEE.
PARKING SPACE
EMPLOYEE
One-to-many An EMPLOYEE supports many
DEPENDENTs. A DEPENDENT is supported by one
EMPLOYEE.
EMPLOYEE
DEPENDENT
Many-to-many An EMPLOYEE is assigned to many
PROJECTs A PROJECT is assigned many EMPLOYEEs.
EMPLOYEE
PROJECT
20
Degree of Relationship

• unary - one entity is related to itself
  (recursive)binary - two entities are related

21
Degree of Relationship (2)

• ternary - three entities are related

22
(No Transcript)
23
Cardinality

• the number of instances of entity-B that can be
  associated with each instance of entity-A.
• specify both minimum and maximum cardinalities
  for each relationship
• Minimum
• 0 (i.e.. optional)
• 1 (i.e.. mandatory)
• Maximum
• 1
• many

24
In other words...

• The lower and upper bounds on number of
  occurrences involved on each side of a
  relationship
• zero
• one
• many
• specific number
• 11 1M MN

25
One-to-one
PARKING SPACE
EMPLOYEE
One-to-many
EMPLOYEE
DEPENDENT
Many-to-many
EMPLOYEE
PROJECT
26
Entity Relationship Diagram (ERD)
PARKING SPACE
PROJECT
DEPENDENT
27
Steps for Creating an ERD

• Identify the entities
• Identify the attributes
• Identify the relationships
• Identify cardinalities
• maximum
• minimum
• Set business rules - discuss next time

28
A Simple Example to Dream On ?

• Each semester each student must be assigned an
  advisor who counsels students about degree
  requirements and helps students register for
  classes.

29
A Simple Example to Dream On ?

• Each semester each student must be assigned an
  advisor who counsels students about degree
  requirements and helps students register for
  classes.

counsel
Advisors
Students
30
More about Attributes
Primary Key Attribute Multivalued Attribute
31
Some Examples
Dep-Name, Dep-age, Dep-relation
Employee No.
Employee
Dep-Relation
Dep-Name
Employee No.
Dep-Age
Employee
Dependent
32
Types of Entities

• Fundamental Entity
• regular rectangle (exist by themselves)
• Associative Entity (Gerund)
• result from many to many relationship
• Attributive Entity (Weak Entity)
• only exists because of the existence of some
  other entity

33
Associative Entity (Gerund)
Warehouse
shipment
Vendor
Quantity
Shipment No.
Part
34
Attributive Entity (Weak Entity)
Dep-Relation
Dep-Name
Employee No.
Dep-Age
Employee
Dependent
35
ERD Practice

• A company has employees (Name, Address, birth
  date) and projects (code, description, start
  date). Each employee may be assigned to one or
  more projects, or may not be assigned to a
  project. A project must have at least one
  employee assigned, and may have several employees
  assigned.

36
ERD Practice (2)

• A laboratory has several chemists (ID, Name,
  phone number) who work on projects (project ID,
  start date) certain kinds of equipment (number,
  cost) may be used by chemists on projects.

37
ERD Practice (3)

• A company has employees (name, title) work work
  in departments (d-num, manager name) All
  employees work in at most one department, and all
  departments have at least one employee. Each
  employee has zero, one, or more dependents
  (dep-name, age)Also, each department is managed
  by one employee, who can manage at most one
  department.

38
ERD Data Sources

• Data entry forms (paper and screen)
• Reports (paper and screen)
• Existing Databases
• DFDs (if completed. Each data flow must be an
  attribute of some entity. Data stores may be
  associated with entities.)
• Interviews, questionnaires, JAD

39
What to ask during Requirements Determination
40
Steps for Creating an ERD

• Identify the entities
• Identify the attributes
• Identify the relationships
• Identify cardinalities
• maximum
• minimum
• Set business rules

41
Four Types of Business Rules

• 1. Entity integrity - each instance of an entity
  type must have a unique identifier that is not
  null.
• 2. Referential integrity constraints - rules
  concerning the relationships between entity types
  (chapter 16)
• 3. Domains - constraints on valid values for
  attributes
• 4. Triggering operations - other business rules
  that protect the validity of attribute values

42
Business Rules

• Done after most of the diagram is complete
• Examples
• A technician must have an electrician certificate
  if performing an inspection service
• A technician may only have a vehicle if (s)he has
  been employed more than 30 days

43
How do you build an ERD for your case project?

• Here is a cookbook approach
• to creating an ERD

44
Cookbook 1

• Derive a high level, first cut data model
• What are the techniques?
• look at forms, look at existing database,
• Identify data entities
• What are the entities of interest around which
  data must be stored?
• Model the world be more rather than less
  comprehensive

45
Cookbook 2

• Identify likely attributes of those entities
• What are the keys? (Primary, Alternate, Foreign)
• How should you name them?
• Determine what type each is
• Determine constraints (cardinalities) of
  attributes
• Determine relationships among entities
• How are they related? Optional or mandatory?
• Fundamental, attributive, and associative
  entities
• What are the cardinalities of the relationships?

46
(No Transcript)
47
Introduction

• The chapter will address the following questions
• Which features on available terminal and
  microcomputer displays can be used for effective
  user interface design?
• What are the backgrounds and problems encountered
  by different types of terminal and microcomputer
  users?
• How do you design and evaluate the human
  engineering in a user interface for a typical
  information system?
• How do you apply appropriate user interface
  strategies to an information system? How do you
  use a state transition diagram to plan and
  coordinate a user interface for an information
  system?
• How can prototyping can be used to design a user
  interface.

48
Styles of User Interfaces

• Introduction
• User interface design is the specification of a
  conversation between the system user and the
  computer.
• This conversation generally results in either
  input or output -- possibly both.

49
Styles of User Interfaces

• Menu Selection
• The menu selection strategy of dialogue design
  presents a list of alternatives or options to the
  user. The system user selects the desired
  alternative or option by keying in the number or
  letter that is associated with that option.
• More sophisticated technology allows menu
  selection by touching the screen, or selecting
  menu options with a pen, mouse, cursor keys, or
  other pointing devices.

50
Styles of User Interfaces

• Menu Selection
• Menu Bars
• Menu bars are used to display horizontally across
  the top of the screen/window a series of choices
  from which the user can select.
• The choices typically correspond to commands or
  properties that the user can select or toggle.
• The choices themselves are typically organized
  from left-to-right on the basis of the frequency
  that a choice is selected.
• Menu bars are used to identify common and
  frequently used actions that take place in a wide
  variety of different windows that make up the
  application.

51
Styles of User Interfaces

• Menu Selection
• Menu Bars
• Menu bars advantages
• Always being readily visible to the user
• Consistently located
• Easily selected via the keyboard or mouse
• Menu bars disadvantages
• Menu choices are organized for left-to-right
  scanning.
• Studies have shown that users can more easily
  browse and select from a list that is vertically
  arranged.
• To aid in clearly scanning the list, adequate
  spacing between choices is necessary.

52
Menu Bar
53
Styles of User Interfaces

• Menu Selection
• Pull-Down Menus
• Pull-down menus provide a vertical list of
  choices to the user.
• A pull-down menu is made available once the user
  selects a choice from a menu bar.
• The list of choices are typically organized from
  top-to-bottom according to the frequency in which
  they are chosen
• One special type of pull-down menu is called a
  tear-off menu.
• With a tear-off menu, the user can select the
  menu and drag to relocate it elsewhere on the
  screen.
• The tear-off menu is then available for continual
  referencing.

54
Styles of User Interfaces

• Menu Selection
• Pull-Down Menus
• Pull-down menu advantages
• Allows the designer to simplify a menu bar that
  may otherwise contain too many choices.
• Related set of choices are grouped into its own
  separate list.
• Pull-down menu items can be selected via the
  keyboard or mouse.

55
Styles of User Interfaces

• Menu Selection
• Pull-Down Menus
• Pull-down menu disadvantages
• The user is not provided with a visual clue that
  suggests the menu exists.
• Pull-down menu may obstruct the users view of
  other areas of interest appearing within the body
  of the screen/window.
• A choice appearing on a pull-down menu may result
  in yet another list or menu of choices.
• Choices which have a a right-pointing arrow next
  to the label result in a cascading menu.
• Choices which have an eclipse next to the label
  result in a dialogue box being displayed that
  contains commands and properties for the user to
  complete a task.

56
Pull-down Menu
57
Dialogue Box
58
Styles of User Interfaces

• Menu Selection
• Cascading Menus
• A cascading menu is a menu that must be requested
  by the user from another higher-level menu.
• The cascading menus existence is suggested by
  the visual clue of a right-pointing arrow
  appearing next to the higher-level menu choice.
• When requested, the menu list will appear to the
  immediate right (in some cases, to the left) of
  the selected choice from the higher-level menu.

59
Styles of User Interfaces

• Menu Selection
• Cascading Menus
• Cascading menu advantages
• Cascading menus simplify higher-level menus into
  a smaller set of related group of choices.
• Vertical arrangement of the choices also makes
  scanning the choices easier.
• Cascading menu disadvantages
• Menu must be requested by the user.
• User may have to traverse several levels of menus
  to locate and select a desired option.

60
Cascading Menu
61
Cascading Menu
62
Styles of User Interfaces

• Menu Selection
• Pop-up Menus
• A pop-up menu is a vertical listing of choices
  that must be requested by the user.
• A pop-up menu is requested by clicking the right
  mouse button.
• Unlike pull-down and cascading menus, the pop-up
  menus appearance depends on where the pointer
  was located when the menu was requested.

63
Styles of User Interfaces

• Menu Selection
• Pop-up Menus
• Pop-up menu advantages
• Provide a list of options that pertain to a
  specific object that the user selected.
• When the cursor is positioned over an object of
  interest and the right mouse button is clicked, a
  pop-menu containing commands or properties
  pertaining to that object appears in the vicinity
  of the object.
• Allows the user to obtain a list of actions
  without changing their focus away from the object
  or work area on the screen.

64
Styles of User Interfaces

• Menu Selection
• Pop-up Menus
• Pop-up menu disadvantages
• No visual clue that suggests their existence.
• Users must learn about the existence pop-up
  menus.
• May obstruct portions of the viewing area of
  interest to the user.

65
(No Transcript)
66
Styles of User Interfaces

• Menu Selection
• Iconic Menus
• An iconic menu uses graphic representations for
  menu options.
• These types of menus are typically used to
  present the user with options that pertain to
  special functions that can be performed within
  the application.
• Iconic menu advantages
• Easy recognition of options.
• The use of graphic images helps the user to
  memorize and recognize the functions available
  within an application.
• The choice presented in the form of an icon also
  provide a relatively larger selection target than
  the previously discussed menus.

67
Styles of User Interfaces

• Menu Selection
• Iconic Menus
• Iconic menu disadvantages
• May be difficult to find or create meaningful
  graphic images.
• Not everything can easily be represented as a
  picture.
• What is a readily identifiable and meaningful
  picture to one person may not be to the next
  person.

68
Iconic Menu
69
Styles of User Interfaces

• Instruction Sets
• Instead of menus -- or in addition to menus
  applications can be designed using a dialogue
  around an instruction set (also called a command
  language interface).
• Users must learn the syntax of the instruction
  set and this approach is suitable only for
  dedicated users.
• There are three types of syntax.
• A form of Structured English can be defined as a
  set of commands that control the system.
• A mnemonic syntax is built around meaningful
  abbreviations for all commands.

70
Styles of User Interfaces

• Instruction Sets
• There are three types of syntax. (continued)
• Natural language syntax is when the system user
  enters commands using natural English (either
  conversational or formal, written English).The
  system interprets these commands against a known
  syntax and requests clarification if it doesn't
  understand what the user wants. As new
  interpretations become known, the system learns
  the system user's vocabulary by saving it for
  future reference.

71
(No Transcript)
72
(No Transcript)
73
Styles of User Interfaces

• Question-Answer Dialogues
• Question-answer dialogue strategy is an style
  that was primarily used supplement either menu
  driven or syntax-driven dialogues.
• This strategy involves the system asking the
  system user questions.
• The simplest questions involve yes or no answers.
• This strategy requires that you make sure to
  consider all possible correct answers and deal
  with the actions to be taken if incorrect answers
  are entered.
• Question-answer dialogue is difficult because you
  must try to consider everything that the system
  user might do wrong!

74
Question
Answer
75
Styles of User Interfaces

• Direct Manipulation
• Allows direct manipulation of graphical objects
  appearing on a screen.
• This user interface style focuses upon using
  icons, small graphic images, to suggest functions
  to the user.
• Selecting the icon with a pointing device like a
  mouse or light pen executes the function.
• Icons can work in conjunction with one another.
• A pointing device can be used to drag the icon of
  a file folder (representing a named file) to a
  trash can icon intuitively instructing the
  system to delete (or throw away) the file.

76
(No Transcript)
77
Human Factors for User Interface Design

• Introduction
• System users can be broadly classified as either
  dedicated or casual.
• A dedicated system user is one who will spend
  considerable time using specific programs. This
  user is likely to become more comfortable and
  familiar with the terminal or PC's operation.
• The casual system user may only use a specific
  program on an occasional basis. This user may
  never become truly comfortable with the terminal
  or the program.

78
Human Factors for User Interface Design

• General Human Engineering Guidelines
• Guideline 1 The system user should always be
  aware of what to do next.
• Tell the user what the system expects right now.
• Tell the user that data has been entered
  correctly.
• Tell the user that data has not been entered
  correctly.
• Explain to the user the reason for a delay in
  processing.
• Tell the user that a task was completed or was
  not completed.
• Guideline 2 The screen should always be
  formatted so that the various types of
  information, instructions, and messages always
  appear in the same general display area.

79
Human Factors for User Interface Design

• General Human Engineering Guidelines
• Guideline 3 Messages, instructions, or
  information should be displayed long enough to
  allow the system user to read them.
• Guideline 4 Use display attributes sparingly.
• Guideline 5 Default values for fields and
  answers to be entered by the user should be
  specified.
• Guideline 6 Anticipate the errors users might
  make.

80
Human Factors for User Interface Design

• Dialogue Tone and Terminology
• The overall tone and terminology of a dialogue
  are important and the session should be user
  friendly.
• With respect to the tone of the dialogue, the
  following guidelines are offered
• Use simple, grammatically correct sentences.
• Don't be funny or cute!
• Don't be condescending that is, don't insult the
  intelligence of the system user.

81
Human Factors for User Interface Design

• Dialogue Tone and Terminology
• With respect to the terminology used in the
  dialogue, the following guidelines are offered
• Don't use computer jargon.
• Avoid most abbreviations.
• Use simple terms.
• Be consistent in your use of terminology.

82
Human Factors for User Interface Design

• Dialogue Tone and Terminology
• With respect to the terminology used in the
  dialogue, the following guidelines are offered
  (continued)
• Instructions should be carefully phrased, and
  appropriate action verbs should be used.
• The following recommendations should prove
  helpful
• Try SELECT instead of PICK when referring to a
  list of options.
• Use TYPE, not ENTER, to request the user to input
  specific data or instructions.
• Use PRESS, not HIT or DEPRESS, to refer to
  keyboard actions.
• When referring to the cursor, use the term
  POSITION THE CURSOR, not POINT THE CURSOR.

83
Display Features That Affect User Interface Design

• Display Area
• The size of the display area is critical to user
  interface design.
• For terminal displays, the two most common
  display areas are 25 (lines) by 80 (columns) and
  25 by 132.
• For microcomputer and workstation display
  monitors, display size is measured in pixels.
• The greater the number of pixels, the more
  information can be displayed.
• Pixel display areas are specified in width by
  height.

84
Display Features That Affect User Interface Design

• Character Sets and Graphics
• Every display uses a predefined character set.
• Most displays use the common ASCII character set.
  
• Some displays allow the programmer to supplement
  or replace the predefined character set.
• Most displays today offer graphics capabilities.
• Graphics capabilities must be supported by
  graphics controllers and software that allow the
  programmer to take advantage of the graphics
  capabilities.
• Graphics-based displays may support a virtually
  unlimited character set.

85
Display Features That Affect User Interface Design

• Paging and Scrolling
• The manner in which the display area is shown to
  the user is controlled by both the technical
  capabilities of the display and the software
  capabilities of the computer system.
• Paging displays a complete screen of characters
  at a time. The complete display area is known as
  a page (also called a screen or frame). The page
  is replaced on demand by the next or previous
  page.
• Scrolling moves the displayed characters up or
  down, one line at a time.

86
Display Features That Affect User Interface Design

• Display Properties
• Most displays in use today provide a wide variety
  of display properties that may be manipulated to
  more effectively present data and information.
• Display properties are characteristics that
  change the way in which a character or group of
  characters is displayed on a screen.

87
Display Features That Affect User Interface Design

• Split-Screen and Windowing Capabilities
• Split-screen capability is a variation on the
  windows concept.
• The display screen, under software control, can
  be divided into different areas (called windows).
  
• Each window can act independently of the other
  windows, using features such as paging,
  scrolling, display attributes, and color.
• Each window can be defined to serve a different
  purpose. Windows can be resized, moved, and
  hidden or recalled on user demand.

88
Display Features That Affect User Interface Design

• Keyboards and Function Keys
• Most modern terminals and monitors are integrated
  with keyboards.
• The number of keys and their layout may vary, but
  most keyboards contain special keys called
  function keys.
• Function keys (usually labeled F1, F2, and so on)
  can be used to implement certain common,
  repetitive operations in a user interface (for
  example, START, HELP, PAGE UP, PAGE DOWN, EXIT).
  These keys can be programmed to perform common
  functions.
• Function keys should be used consistently.
• A system's programs should consistently use the
  same function keys for the same purposes.

89
Display Features That Affect User Interface Design

• Pointer Options
• There are many selection options, such as
  touch-sensitive screens, voice recognition, and
  pointers.
• The most common pointer is the mouse.
• A mouse is a small hand-sized device that sits on
  a flat surface near the terminal. It has a small
  roller ball on the underside. As you move the
  mouse on the flat surface, it causes the pointer
  to move across the screen. Buttons on the mouse
  allow you to select objects or commands to which
  the cursor has been moved. Alternatives include
  trackballs, pens, and trackpoints.

90
How to Design Prototype a User Interface

• Step 1 Chart the Dialogue
• A state transition diagram is used to depict the
  sequence and variations of screens that can occur
  when the system user sits at the terminal (PC or
  workstation).
• Rectangles are used to represent display screens.
• The arrows represent the flow of control and
  triggering event causing the screen to become
  active or receive focus.
• The rectangles only describe what can appear
  during the dialogue.
• The direction of the arrows indicate the order in
  which these screens occur.

91
(No Transcript)
92
How to Design Prototype a User Interface

• Step 2 Prototype the Dialogue and User Interface
• Many screens may have to be designed and
  prototyped.
• Some screens were identified for the purpose of
  bringing together the application and its input
  and output screens.
• Some screens were identified for the purpose to
  provide the user some flexibility with
  customizing the applications interaction to suit
  their own preferences.
• Other screens may have been identified to deal
  with system controls such as backup and
  recovery.
• It is through studying the entire collection of
  screens that you may discover the need to make
  revisions to some screens.
• It is likely that such issues as color, naming
  consistencies of common buttons and menu options,
  and other look-and-feel conflicts may need to be
  resolved.

93
(No Transcript)
94
(No Transcript)
95
(No Transcript)
96
(No Transcript)
97
(No Transcript)
98
(No Transcript)
99
(No Transcript)
100
(No Transcript)
101
(No Transcript)
102
How to Design Prototype a User Interface

• Step 3 Obtain User Feedback
• Exercising (or testing) the user interface is a
  key advantage of all prototyping environments.
• Exercising (or testing) the user interface means
  that system users literally experiment with and
  test the interface design prior to extensive
  programming and actual implementation of the
  working system. Analysts can observe this testing
  to improve on the design.
• In the absence of prototyping tools, the analyst
  should at least simulate the dialogue by walking
  through the screen sketches with system users.

103
Designing Interfaces and Dialogues
104
Figure 15-6aPop-up Menu
105
Figure 15-6bDrop-Down Menu
106
Figure 15-18Sections of a Dialogue Diagramming
Box
107
Figure 15-19Dialogue Diagram illustrating
Sequence, Selection, and Iteration
108
Figure 15-21Highlighting Graphical User
Interface Design Standards
109
Figure 15-22State-Transition Diagram for Spell
Checker