ADT Chapter 2

• Technology architecture


  • Computing hardware
  • Network hardware and topology
  • System software
• Application architecture


  • Information systems
  • Subsystems
  • Supporting technology
• Existing RMO systems


  • Supply Chain Management (SCM)
  • Phone/Mail Order System
  • Retail Store System
  • Customer Support System (CSS)
• Proposed CSMS subsystems


  • Sales Subsystem
  • Order Fulfillment Subsystem
  • Customer Account Subsystem
  • Marketing Subsystem
• The New Consolidated Sales and Marketing System (CSMS) will require discovering and understanding extensive and complex business processes and business rules
• Systems analysis activities


  • Gather detailed information
  • Define requirements
  • Prioritize requirements
  • Develop user-interface dialogs
  • Evaluate requirements with users
• Functional requirements


  The activities the system must perform
• Non-functional requirements


  Other system characteristics, constraints and performance goals
• Types of non-functional requirements

  • Usability
  • Reliability
  • Performance
  • Security
• Other non-functional requirement types

  • Design constraints
  • Implementation requirements
  • Interface requirements
  • Physical requirements
  • Supportability requirements
• Stakeholders


  Persons who have an interest in the successful implementation of the system
• Types of stakeholders


  • Internal stakeholders
  • External stakeholders
  • Operational stakeholders
  • Executive stakeholders
• RMO CSMS stakeholders


  • Phone/mail sales order clerks
  • Warehouse and shipping personnel
  • Marketing personnel
  • Marketing, sales, accounting, and financial managers
  • Senior executives
  • Customers
  • External shippers
• Information-gathering techniques


  • Interviewing users and other stakeholders
  • Distributing and collecting questionnaires
  • Reviewing inputs, outputs, and documentation
  • Observing and documenting business procedures
  • Researching vendor solutions
  • Collecting active user comments and suggestions
• Interviewing


  1. Prepare detailed questions

  2. Meet with individuals or groups of users

  3. Obtain and discuss answers to the questions

  4. Document the answers

  5. Follow up as needed in future meetings or interviews
• Observing and documenting business processes involves watching and learning, then documenting with an Activity diagram
• Researching vendor solutions involves seeing what others have done for similar situations, such as white papers, vendor literature, and competitors
• Collecting active user comments and suggestions involves feedback on models and tests, as users know it when they see it
• Model


  A representation of some aspect of the system being built
• Types of models


  • Textual model
  • Graphical models
  • Mathematical models
• Unified Modeling Language (UML)


  Standard graphical modeling symbols/terminology used for information systems
• Purposes of modeling


  • Learning from the modeling process
  • Reducing complexity by abstraction
  • Remembering all the details
  • Communicating with other development team members
  • Communicating with a variety of users and stakeholders
  • Documenting what was done for future maintenance/enhancement
• Workflow


  Sequence of processing steps that completely handles one business transaction or customer request
• Activity Diagram


  Describes user (or system) activities, the person who does each activity, and the sequential flow of these activities
• Activity Diagrams are a UML diagram useful for showing a graphical model of a workflow
• Domain Modeling


  Systems Analysis and Design in a Changing World 7th Ed
• Chapter 4 Outline


  • "Things" in the Problem Domain
  • The Domain Model Class Diagram
• Learning Objectives


  • Explain how the concept of "things" in the problem domain also define requirements
  • Identify and analyze data entities and domain classes needed in the system
  • Read, interpret, and create a domain model class diagram
  • Understand the domain model class diagram for the RMO Consolidated Sales and Marketing System
• Problem domain


  The specific area (or domain) of the users' business need that is within the scope of the new system
• "Things"


  Items users work with when accomplishing tasks that need to be remembered
• "Things"


  • products, sales, shippers, customers, invoices, payments, etc.
• Domain classes


  The "Things" that are modeled
• In this course, we will call them domain classes. In database class you may call them data entities
• Brainstorming Technique


  1. Identify a user and a set of use cases

  2. Brainstorm with the user to identify things involved when carrying out the use case

  3. Use the types of things (categories) to systematically ask questions about potential things

  4. Continue to work with all types of users and stakeholders to expand the brainstorming list

  5. Merge the results, eliminate any duplicates, and compile an initial list
• Noun Technique


  A technique to identify problem domain classes (things) by finding, classifying, and refining a list of nouns that come up in in discussions or documents
• The Noun Technique is a popular, systematic technique but it does end up with long lists and many nouns that are not things that need to be stored by the system. It has difficulty identifying synonyms and things that are really attributes. It is a good place to start when there are no users available to help brainstorm.
• The Noun Technique: Steps

  1. Using the use cases, actors, and other information about the system— including inputs and outputs—identify all nouns.

  2. Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed.

  3. As this list of nouns builds, refine it by asking questions to decide whether to include, exclude, or research further.

  4. Create a master list of all nouns identified and then note whether each one should be included, excluded, or researched further.

  5. Review the list with users, stakeholders, and team members and then define the list of things in the problem domain.
• Partial List of Nouns for RMO


  • With notes on whether to include as domain class
• Attribute


  Describes one piece of information about each instance of the class
• Identifier or key


  One attribute uniquely identifies an instance of the class. Required for data entities, optional for domain classes.