Lecture - Diagramming Tools and Techniques.pdf

INFO8655 - Requirements Modelling and Visualization Diagramming Tools Conestoga College Before we begin – Industry “Good” Practices Any diagram or stand-alone document should include: …a descriptive title …a project/software r...

INFO8655 - Requirements Modelling and Visualization Diagramming Tools Conestoga College Before we begin – Industry “Good” Practices Any diagram or stand-alone document should include: …a descriptive title …a project/software reference …a company name, department …a document date …a version number …an author name …a packet/index codes if appropriate  Tools of the Trade Rich Picture Pseudocode Dashboard Brainstorm PowerBI USE CASE Communication Paths Geographic Information Cockburn Notation Systems Mapping Champions PowerMaps Elicitation Practices Tree Diagrams Feature Tree ETL (*Time permitting) UXD/UI Context Diagram Mockups EcoSystem Map Wireframes Activity Diagrams Actor Diagram Prototypes State Activity Diagram FEATURE TREE  Feature Tree Multi-level view of Product Service Used to evaluate existing, or design new. Organized by features in three levels  0. Feature Tree (Building) Step 0: Rules Each product/service requires a unique feature tree. A feature tree may only traverse 3-levels deep The ‘trunk’ of the tree is the ‘product or service’ in questions  Step 1: Select your ‘trunk’ Select a trunk. The product or service that you are creating. List the name within the bubble. The trunk is the central line. From this line we will list features/functionality. Word Processing Program  Step 2: Determine Level 1 Primary level or “Branch” NEW DOCUMENT Each branch is a new feature Hosts MAIN feature Example: “NEW DOCUMENT” Word Processing Program  Step 3: Determine Level 2 Secondary level or “Twig” Options within the feature NEW DOCUMENT E AT Example: Select a template PL M Example: Create blank doc TE K AN BL Word Processing Program  Step 4: Determine Level 3 Tertiary level or “leaf” NEW DOCUMENT E AT T hem e Choices within option within PL M feature TE K Example: Choosing a theme AN BL or available for a template ol C Word Processing Program  Feature Tree (OVERVIEW) Summary: Branch Each diagram can have; 1 Trunk. Twig As many branches as af needed. Le As many twigs as needed. As many leaves as needed. Trunk Product or Service  Feature Tree Value Simply put, the feature tree gives us control and oversight. Evaluating the complexity of the user experience is hard. A Feature Tree can be seen as a logical mapping and evaluation tool. The feature tree has a set limitation for complexity. Three (3) levels deep. This restriction forces designers to make hard decisions. This limits the built-in complexity of any application. CONTEXT DIAGRAM  Context Diagram From the point of view of the system. This is the focal or centre of the diagram. Focused on objects that exchange data The exchange must be made DIRECTLY Only display systems with direct interface System is blind to 3rd party activities. Each system should have its own context diagram. Each context diagram can only have/use one system as a central focus.  Step 0 Rules All actions shown must originate or end with the central system. Databases are not specific objects. Circles denote systems Rectangle is external to the SYSTEM. This does not mean external to company. External entities can be a: person, system, database, role, place, or thing.  Step 1: Select a System We have the ‘CRM SYSTEM’ Everything is from the VIEWPOINT of the CRM CRM SYSTEM System.  2. Context Diagram (Building) Step 2: Identify the other actors and systems in DELL’s process Manufacturing CRM SYSTEM Ordering System Shipping Payment System Customer  3. Context Diagram (Building) Step 3: Select the actors where the ‘client’ has DIRECT interaction with Manufacturing - NO CRM SYSTEM Ordering System - YES Shipping - YES Payment System - YES Customer - YES  4. Context Diagram (Building) Step 4: Describe the interactions (context): Ordering System Customer submits order Ordering system displays results Shipping Shipping send to customer CRM Shipping can receive returns System SYSTEM Payment System Customer Pays through system System responds with approve/deny Customer Customer can submit orders Customer can contact for support/issues  5. Context Diagram (Building) Step 5: Each actor gets its own object. Ordering Ordering System System Customer submits order Ordering system displays results Shipping Shipping Shipping send to customer CRM Shipping can receive returns SYSTEM Payment System Customer Pays through system Payment System responds with approve/deny System Customer Customer can submit orders Customer can contact for support/issues Customer  Shipping 6. Context Diagram Step 6: Arrange the DIRECT actors around the ‘client’ Ordering CRM System SYSTEM Customer Good practice: Arrange entities in order. either clockwise or counterclockwise Payment System  Shipping 6. Context Diagram Step 7: Draw Customer connections and submits order populate with context Ordering CRM System SYSTEM Customer Continue 1 actor at a displays results time until complete Payment System  Shipping 6. Context Diagram (Building) Customer Step 7: Draw connections submits order and populate with context CRM Ordering System SYSTEM Customer displays Continue 1 actor at a time results until complete Confirm payment Update CRM if Each actor/system can status Payment made have multiple connections to primary system (CRM Payment System System)  Week 3 Activity 5 – Context Diagram Create a Context Diagram considering the user class below ECOSYSTEM MAP  Ecosystem Map What is the value of this tool? Allows a high-level view of a single system Informs us what systems will be affected by changes we make Allows us to understand the sources and storage of data. When would we use it? During design, maintenance or administration of a system. During structured development and deployment of a new system. EcoSystem Map A look at: Enterprise Systems Major Databases Major Software packages Actors (if necessary) Figure 5-7 Partial EcoSystem map for the Chemical Tracking System Usually used to create EVENT LISTS Provides overall view of the entire IT Infrastructure (system)  Step 2 Step 0: Rules Step 1 Displays 3rd party links [up to 2-steps] You are allowed to show indirect exchanges Written comments denote PRIMARY data exchange/interaction Completely AUTOMATED dependencies will not receive a description. Completely AUTOMATED dependencies will not receive a DIRECTION Ie,. A system accessing a database would not receive a description.  Step 1: Identify Identify the organization/scenario needs. Define the scope of our work. Create a list of the systems that exist within your organization Identify primary communication exchanges What data do these systems share? Automated, or not automated?  Step 2: Systems Which system is the primary system for YOUR project? EcoSystem maps typically are focused around a project. Divide your overall system lists into 3 categories. 1) Direct communication (Secondary systems) 2) Indirect communication (Tertiary and 3rd party systems) 3) No communication (greater than ‘2-steps’ from the system) Discard group 3 - No communication.  Step 3: Organize and Describe Primary Place primary system in the diagram center. Place the secondary systems around the primary. Order Request Draw arrows showing directionality. Which Secondary system is accessing which? Identify the activity (1-3 word description) I.e. Submit report, Purchase order.  Step 4: Secondary Connections Check to ensure proper PRIMARY system was identified. Check to ensure secondary systems are all listed. List tertiary systems. Identify all connections to secondary systems. Tertiary systems can connect to multiple secondary systems. Tertiary systems cannot connect to primary systems. ACTOR DIAGRAM Actor Diagrams Ordering System Sales & Marketing Purchaser Plant Manager EXTERNAL USERS CRM System INTERNAL USERS TPS System Manufacturer Accounting  Step 0: Explanation Actor diagrams have some similarities to USE CASE Actor diagram will divide actors; Internal Actors External Actors Between these actors we will place an ellipse. This ellipse will denote SYSTEMS.  Step 1: Rule The ellipse can contain only systems (and databases). Actors must be outside the ellipse. Actor connections; Each actor must have at least a single system connections. Each actor may have multiple connections to different systems. Actors cannot be replicated. (Multiple of same actor)  Step 2: Define Identify your target scenario. Within this scenario you will need to select out all systems. Each of these systems will receive a separate segment. Identify actors. Who will be using this system? This denotes direct interaction at any level. Divide into two categories; Internal External  Step 3: Organize Place each system into the ellipse. Draw lines separating each system. These form separate ‘segments’ within the ellipse. Station actors around the ellipse. Draw connections between each actor and the systems. Each should only display direct interaction. Never passive.  Step 4: Format While not a rule, formatting is especially important with Actor diagrams. Best Practices: Align objects. Reduce line overlap. Re-organize layout as needed. Proper labelling (Date, course, title, version, etc.)