High-Level Architecture v1. Overall Comments about Requirements. Some criticisms. Requirements Concerns. CMS DB Terminology

Transcription

1 Admin High-Level Architecture v1 Admin Web Access Control Configuration Access Control Customer DB Configuration Overall Comments about Requirements Uniformly nicely done Provided Clients with a number of good ideas Staff Mail System Query and Data Analysis Requests DBMS Customers Some criticisms Project Integration Overlap between tickets and threads Database Management Too much information about the internal DB schema and not enough information about the Client s interaction with the DB configuration Access Control Document had HLD information Data Analysis Too much information about the internal DB schema and not enough information about the statistical analysis results and merging capabilities Document needs some reorganization, need an overview of each section Requirements Concerns Terminology problems Customers versus Clients Our project clients are Thea and Sachin CMS is dealing with UMOCH customers Collections versus Thread - set of related interaction records for a customer Need to define what related means Will have collections of threads in the DBMS Tickets Clients like the idea of knowing which interactions still need to be processed But didn t like the ticket systems they have used in the past Could be handled by having a topic to indicate that an interaction is awaiting processing Pending interactions - interactions pending action by a staff member Project Integration team could provide special GUI to support functions for dealing with pending interactions But, may not be very different than functions for dealing with any topic Need to investigate this further CMS DB Terminology CMS DB contains one or more s consists of: 1 0 or more s An consists of: 1 or more related Interaction Entries 1

2 { Collection of Interaction { Collection of Interaction } Interaction Thread CMS DB Glossary CMS DB = collection of zero or more Customer Records = and collection of zero or more Customer Interaction Customer = one or more Customer Interaction Entries Note, collection is a conceptual term Abbreviations: Customer N can be shortened to N, when the meaning is clear E.g., DB, Interaction thread, Single or Multiple Databases? Currently one database, but maintaining this is not a priority We can assume that there are two separate data bases Customer Management System (CMS) Database Property Database Customers may register in the Property DB Interactions between the two Databases: Usecase A customer submits an entry for the Property Database Must be a registered customer Can a customer register on the spot? Fills out the appropriate on-line form Request goes to Staff who then accepts or rejects the request Mail message is sent to the customer indicating whether the request was accepted or not Currently, Staff manually creates a customer interaction entry that corresponds to this request Is a record created when the request is rejected? The entry into the CMS DB could be automated Perhaps with staff confirmation 2

3 Deletion Deletion is often a dangerous concept Clients prefer Active and Archived E.g. Binary value so one name is better than two Active: Y or N Must be able to set the value of Active Could be a predefined category or just based on the date of last interaction, or both E.g., only show (active) records that are less than # months old Should be able to select default value for # Should be able to use a date instead of relative time Same look and feel Need to have the various frames have a similar style E.g., Instant search for customer and for staff Project Integration team will create some proposals for discussion as part of their HLD DBMS Glossary DBMS= {s*} = {, Customer s*} Customer = {Customer Interaction Entries+} Categories Class proposed using: Customer ID Fields Interaction Entity Topics For now, we ll use categories Clients liked the idea of being able to define a hierarchy Whenever you have a constant, think about generalizing (e.g., 2=>N) Typical directory structure Try to generalize concepts, not just constants E.g., Also need Categories Try to generalize terms Categories, subcategories, subsubcategories, Category Directory Categories Predefined and Staff-defined categories Predefined Categories -- can not be changed, except to add new subcategories Staff-defined Categories Can only be defined by staff with appropriate permission Some possible attributes of a category Multiple values or single values Required or optional Possible values E.g., Yes/No text Default value and, if so, actual value to be used 3

4 with additional subcategories Parent Low Income with Attributes Shown [required, multiple values from subcategories, no default] Parent [optional, single value:text, no default] Low Income [optional, single value:y/n,default=y] Customer Customer Customer Issue Problem Website problem» password» Navigation» Disability accessibility Renter problem» Landlord» Evictions» Heat Roommate Customer Thinking Ahead Categories should be presented to the staff and implemented in a consistent way Adding categories easier to implement than removing or reorganizing them Could delay remove and reorganize for a future version of the system, but design the system to facilitate making this change in the future Often good but easy to overdo How do you know if something should be generalized or not? Provides needed functionality or expected future functionality Expected to reduce future maintenance Sometimes the cost is minimal or even less But sometimes it is considerably more 4

5 May not be able to decide until doing design Make this clear in the requirements Multiple costs to consider Cost to build Cost to maintain Cost of added complexity in the UI Impact on time to completion (Time to market) Some of these costs could go up and others down Clients may not want to pay for functionality if the cost is too high Need to keep the clients in the loop Alternatives to consider when doing design Don t generalize Fully generalization Intermediate level of generalization E.g., 3 level directory instead of N levels May decide not to generalize (or minimal generalization) but design the system so it is easy to change Agile methods advocate not generalizing, Spiral model advocates evaluating the risks Which team is responsible for what? Project Integration team Provide overall CMS project web interface that activates/deactivates all subfunctionality Interact with mail system Process mail automatically as appropriate to create and update single customer records Provide ticket system Provide instant search for a customers (general capability so can be instantiated for staff) Access Control Provide support for defining permission groups Provide support for maintaining staff info Provide instant search for a staff member Define permission items(?) (probably needs to be predefined, but should be done in a way that makes it relatively easy to modify) Support the requested permissions Which team is responsible for what? Database team Data Analysis Team Provide support for Provide to other teams Provide support to update and retrieve CMS DB info based on Category Directory Provide support for search based on Provide support for merge Initiated by staff Prioritize candidate customers Customize prioritization Do updates as requested by other After staff confirmation, make calls on teams DB to complete merge operation E.g., Set Pending to Y, Provide support for statistical analysis Merge (cust_1, cust_2) Requests for data reports based on retrieve information as requested category directory by other teams Customization of visualization E.g., single and collections of records/entries Reports Charts Slightly Revised Schedule March 3: Revised Requirement Documents Due March 23: HL Design Documents Due March 23, 24: HL Design Presentations 5