Consolidated Use Cases

From ZenWiki

Jump to: navigation, search

Contents

Use Case Model

This use case model shows the allocation of requirement between roles (aka, actors).

The relation between roles is generalization. SMART Member is a generalization of Interview, Analyst and Administrator.

Image:Use-Case-Model.png

Image:Use-Case-Actor-Generalization.png

Key: UML

Use Case Catalog
Use Case Name Description
Sign In SMART Member needs to sign in the system before performing any other operations.
Sign Out SMART Member can sign out from the system during any give time.
Acquire Engagement Data Prior to any interview phases of a given engagement, the interviewer obtains a copy of the engagement setup data prepared in the Setup Engagement Data use case.
Choose Question During an interview, the interviewer chooses a question in the system as the focus of the discussion. The interviewer browses through the categories of topics, and from which a desired question is located. To quickly locate a question, the interviewer can enter keywords and instruct the system to search the matching questions. The interviewer can also follow a predefined sequence of questions that facilitates a smoother interview session.
Record Answer During an interview, the interviewer records annotations to a selected question. The possible types of annotations include predefined answers, comments, and tags. One possible predefined answer can be "not-applicable". For the purpose of status, a question is considered to be "answered" if one of two mutually exclusive conditions are met. First, if there are one or more predefined answers associated with a particular question, then the question is considered to be "answered" if and only if at least one of the predefined answers has been selected or a comment has been entered. Second, if there are no predefined answers associated with a particular question, then the question is considered to be "answered" if and only if there is a comment entered for that question. A question may be annotated with one or more tags, but applying tags has no effect on the question's "answered" status. The purpose of the tags is for generating templates (Authors' note: Should we distinguish answer from annotation?)
Consolidate Interview Data After each interview phase of a given engagement, the interviewers submit their individual interview data for consolidation. Each interviewer associated with a specific engagement is expected to upload the data they took, however this is not mandated. Once at least two sets of data has been submitted, anyone of the interviewers can explicitly trigger the consolidation. This consolidated interview data can then be obtained by the interviewers.
Generate Report This use case applies to two circumstances: First, during an engagement, the analyst instructs the system to generate reports based on interview data collected so far. The analyst first chooses a report type, such as Current SMIG or Migration issues table, and then the system generates the report. Second, in between engagements, the analyst instructs the system to generate reports based on historical engagements. The analyst selects one report type, such as Draft of final report or List of questions per tag, and then the system generates the report accordingly.
Generate Template Analyst generates two kinds of templates: service table or component table. The format of the templates must be editable. The preferred format is xls but csv is also acceptable. The system is given the templates that are used during interview, and then the system adds new columns to them. The columns are the short names of questions marked with specific tags.
Setup Engagement Data Administrator prepares an engagement by entering information obtained prior to an engagement. The information includes the engagement client organization, type of system under evaluation, profiles of interviewees, the version of the SMIG which will be used, and the set of tags that will be used.
Update SMIG Information Administrator updates SMIG information. It includes the basic create, read, modify and delete operations. The administrator can also promote the updated SMIG into a new version. The system has to keep the old versions of SMIG in order to maintain data consistency for old engagement data.
Update Tag List Administrator updates the default tag list, which is used during Setup Engagement Data. It includes the basic create, read, modify, and delete operations.
Register User Account Administrator registers user account, which can be used in the Sign In use case. Additionally, administrator can modify, delete and reset user account.

Use Case - SMIG Navigation

Use Case 101: Choose question

Use case name: Choose question
Unique use case ID: UC101
Primary actor(s): Interviewer
Secondary actor(s): None
Brief description: During an interview, the interviewer chooses a question in the ZEN Client as the focus of the discussion. The interviewer browses through the categories of topics, and from which a desired question is located. To quickly locate a question, the interviewer can enter keywords and instruct the system to search the matching questions. The interviewer can also follow a predefined sequence of questions that facilitates a smoother interview session.
Preconditions: The interviwer has signed-in to the ZEN Client.
Flow of events:
  1. The interviewer chooses a question by either browsing or searching:
    1. The interviewer browses through the categories of topics and locates a desired question.
    2. The interviewer enters keywords and instructs the system to search the matching questions, from which the interviewer picks up one question.
  2. The system displays the detail of the question, so the interviewer can decide if it is actually the desired one.
  3. After the discussion of the question, the interviewer can either go to the next question in the predefined sequence or go back to step 1 to choose a new question.
Postconditions: The interviewer has been able to reach the question which was expected
Alternative flows and exceptions:
  • In addition to the predefined sequence of questions, the system keeps track of the visited questions; therefore, the interviewer can go back to the previous question even when it is not in the predefined sequence.
  • The search does not find any matching questions; the system displays a message saying so and allows the interviewer to enter other keywords. The interviewer can also decide to locate the question by browsing.
  • There is no next question in the sequence; the system displays a message indicating the situation. The interviewer goes back to step 1 to choose a new question.

Use Case - Information Gathering

Use Case 201: Enter answer

Use case name: Enter answer
Unique use case ID: UC201
Primary actor(s): Interviewer
Secondary actor(s): None
Brief description: During an interview, once an interviewer selects and loads a question from the SMIG, he/she should be able to select an answer to that question from a list of pre-defined answers within the SMIG. This use case focuses on this ability of the user.
Preconditions: The interviewer has selected and loaded a question from the SMIG.
Flow of events:
  1. The interviewer selects an answer to the current question from a list of pre-defined answers to that question and gets his/her choice recorded.
Postconditions: The interviewer records the answer for a particular question.
Alternative flows and exceptions:
  • Some questions may not have any pre-determined answers to choose from.
  • An interviewer may opt to not get his/her answer recorded to the question at hand and may leave the subject question unanswered.

Use Case 202: Enter comments

Use case name: Enter comments
Unique use case ID: UC202
Primary actor(s): Interviewer
Secondary actor(s): None
Brief description: In addition to selecting an answer for a question, an interviewer may enter a text based comment along with his/her response to the question. This use case focuses on this ability of the interviewer.
Preconditions: The interviewer has selected and loaded a question from the SMIG
Flow of events:
  1. The interviewer chooses to enter a text based comment along with his response for the subject question.
Postconditions: The interviewer records comments for a particular question
Alternative flows and exceptions:
  • The interviewer may opt to not enter any comment(s) along with his/her response to a question.
  • Adding only a comment without an answer will still make the question answered

Use Case 203: Tag Question

Use case name: Tag Question
Unique use case ID: UC203
Primary actor(s): Interviewer
Secondary actor(s): None
Brief description: In addition to selecting an answer for a question, an interviewer may choose one or more tags along with his/her response to the question. This use case focuses on this ability of the interviewer. The list of tags are predetermined during engagement setup. Tags are applied per question.
Preconditions: The interviewer has selected and loaded a question from the SMIG
Flow of events:
  1. The interviewer chooses one or more tags along with his/her response to the subject question.
Postconditions: The interviewer has been able to tag a question
Alternative flows and exceptions:
  • An interviewer may decide not to choose any tags with his/her response to the subject question.

Use Case 204: Save response

Use case name: Save response
Unique use case ID: UC204
Primary actor(s): Interviewer
Secondary actor(s): None
Brief description: Once the interviewer has entered his/her answer to a particular question along with any optional tags and/or comments, the user should be able to save this data into the Zen tool. This use case focuses on the ability of the interviewer to get the response to a question recorded into the Zen tool via the Zen client.
Preconditions: The interviewer has entered at least an answer or a comment to the subject question.
Flow of events:
  1. The interviewer enters his/her answer to the subject question
  2. The interviewer adds any optional tags and/or comments for the subject question
  3. The interviewers overall response to the question (i.e. answer, tags, and comments) are recorded into the Zen tool.
Postconditions: The interviewer's overall response to a question (i.e. answer, tags, and comments) are recorded by the Zen tool.
Alternative flows and exceptions:
  • The user may decide not to save his/her response to a question and may instead, move to another question.
  • If there is no answer available, then the interviewer has added a comment to the question

Use Case - Report Generation

Use Case 301: Generate Report

Use case name: Generate Report
Unique use case ID: UC301
Primary actor(s): Analyst, Interviewer, Notetaker
Secondary actor(s): Interviewer (in case interviewer wants to view data belonging to other engagements)
Brief description:
  • At the completion of an engagement, all the interview data is present in the server. The analyst would want to generate reports to view the data for the engagement.
  • During an engagement, the interviewer or notetaker would like to generate report on the engagement data collected so far.
Pre-conditions:
  • The analyst is logged in via the browser
  • The interviewer/notetaker is logged in the Zen client
Flow of events:
  • Server
  1. The analyst logs in to the Zen server via the browser
  2. The analyst selects the engagement on which he would like to run the report
  3. The analyst sees a list of report templates (TBD) already available
  4. The analyst clicks on one of the report and he sees the data rendered
  5. The analyst can browse across pages, export the data in the report (TBD) and print the report
  • Client
  1. The interviewer/notetaker logs into the ZEN client
  2. The interviewer/notetaker sees a list of report templates (TBD) already available
  3. The interviewer/notetaker clicks on one of the report and he sees the data rendered
  4. The interviewer/notetaker can browse across pages, export the data in the report (TBD) and print the report
Post-conditions:
  • The analyst is able to successfully generate reports
  • The interviewer/notetaker is able to successfully generate reports
Alternative flows and exceptions:
  • The analyst chooses a report and then chooses an engagement or engagments to view the data



Use Case 302: Modify Report

Use case name: Modify report
Unique use case ID: UC302
Primary actor(s): Interviewer, Analyst
Secondary actor(s): Administrator
Brief description: The interviewer or analyst might want to change the details being viewed for the report. He might want to hide an existing column or filter out rows. He might want to sort the results based on some column in the report.
Pre-conditions: The user is logged in to the Zen server via the browser
Flow of events:
  • Server
  1. The user logs into the Zen server via the browser
  • Client
  1. The interviewer/notetaker logs into the ZEN client
  • Both server and client
  1. The user sees a list of reports already available
    1. Current SMIG
    2. Draft of Final Report
    3. List of Questions Per Tag
    4. Different Types of Risk Summaries Per Engagement
    5. Different Types of Risk Summaries Across All Engagements
  2. The user clicks on one of the report and he sees the data rendered
  3. The user chooses to edit the report and hide an existing column
  4. The user chooses to filter the data based on certain queries
  5. The user chooses to sort data based on a particular column's value
Post-conditions: The report should be re-generated based on the changes made by the user
Alternative flows and exceptions:

Use Case - Interview Status

Use Case 401: Application launch

Use case name: Application launch
Unique use case ID: UC401
Primary actor(s): Interviewer, Note-taker
Secondary actor(s): None
Brief description: When the application is launched (either with a preexisting engagement or a new one), the interview status tool updates its progress display to reflect the portion of the questions in each SMIG category that has already been answered. The progress display for each category will follow the following color code:
  • gray: 0%
  • red: 0% < x <= 30%
  • yellow: 30% < x <= 60%
  • green: 60% < x < 100%
  • blue: 100%
Preconditions:
  • The interviwer/note-taker has signed-in to the ZEN Client.
  • The progress level in the status tool has not been initialized.
Flow of events:
  1. The interviewer launches the application by double-clicking on the application's icon.
  2. The interviewer will then begin a new engagement or load the engagement data that he wishes to use.
  3. The status tool will be loaded with the progress from the SMIG answers.
Postcondictions: * The progress level in the status tool is initialized.
Alternative flows and exceptions:

If the interviewer double-clicked a saved engagement file, the application will be launched automatically, that engagement will be loaded, and the status tool will be initialized with the engagement's SMIG interview data.


Use Case 402: Question answered

Use case name: Question answered
Unique use case ID: UC402
Primary actor(s): Interviewer, Note-taker
Secondary actor(s): None
Brief description: When an interviewer answers a question in the SMIG, the status tool is automatically updated to reflect the progress of the engagement.

Note:

  • A questions is considered answered when an answer and/or a comment is recorded.
  • The state change occurs, when the save button is pressed or when the user moves to the next question (in which case the answer is autosaved)
Preconditions:
  • The interviwer/note-taker has signed-in to the ZEN Client.
  • A new or existing engagement is loaded into the ZEN Client.
  • The status tool has been initialized.
Flow of events:
  1. The interviewer answers a question.
  2. The status tool will be updated with the progress from the SMIG answers.
Postcondictions: * The progress level in the status tool is updated (increased).
Alternative flows and exceptions:

Instead of marking an answer for a question, an interviewer removes the answer from a previously answered question.
The new flow would be:

  1. The interviewer removes an answer to a question.
  2. The status tool will be updated with the progress from the SMIG answers.

The postcondition is now that:

  • The progress level in the status tool is updated (decreased).


Use Case - Deployment

Use Case 501: ZEN Client Installation

Use case name: ZEN Client Installation
Unique use case ID: UC501
Primary actor(s): User
Secondary actor(s): None
Brief description: At any given time, the SMART Team may choose to install the ZEN Client on a target platform (usually a laptop) for use within a SMART engagement. To do so, a SMART Team member will run an installation program on the target platform.
Precondictions: The computer owner has been verified to be authorized to access and use the ZEN Tool (client, server, and browser).
Flow of events:
  1. The administrator starts the installation process.
  2. At some point during installation, the installer will prompt the administrator for the username and password unique to this installation.
  3. The installation finishes.
Postcondictions: The computer has the ZEN Client installed, and a unique username and password is associated with this installation.
Alternative flows and exceptions: None.


Use Case 502: ZEN Client Startup

Use case name: ZEN Client Startup
Unique use case ID: UC502
Primary actor(s): Interviewer, Analyst
Secondary actor(s): None
Brief description: At any time, a user can choose to start the ZEN Client. This can be to process a SMART Engagement, to upload or download data, or to analyze data.
Precondictions: The computer has the ZEN Client installed.
Flow of events:
  1. The user starts the ZEN Client program.
  2. The user logs into the program:
    1. The user logs in using the unique username and password to this installation., or
    2. The user logs in using the administrator username and password.
  3. The ZEN Client program successfully initializes and presents the user with the main menu.
Postcondictions: The ZEN Client is successfully initialized.
Alternative flows and exceptions:
  • If the user inputs an incorrect username and password, the ZEN client will allow 2 additional password input attempts.
  • If the user is unable to input a correct username and password within 3 attempts, the ZEN client will shut down.


Use Case 503: ZEN Server Installation

Use case name: ZEN Server Installation
Unique use case ID: UC503
Primary actor(s): Administrator
Secondary actor(s): None
Brief description: In order to support SMART Engagements using the ZEN Tool, the SMART team must set up a ZEN Server. This will involve installing the web server functionality and the database functionality.
Precondictions: None.
Flow of events:
  1. The administrator installs the necessary web server functionality.
  2. The administrator installs the necessary database functionality.
Postcondictions: The computer has the ZEN Server installed, and it is prepared to support SMART Engagements.
Alternative flows and exceptions: None.


Use Case 504: ZEN Server Startup

Use case name: ZEN Server Startup
Unique use case ID: UC504
Primary actor(s): Administrator
Secondary actor(s): None
Brief description: The ZEN Server should only need to be started upon initial installation and updates. Startup should make the ZEN Server support the ZEN Client and ZEN Browser online functionality.
Precondictions: The computer has the ZEN Server installed.
Flow of events:
  1. The user starts the ZEN Server program.
  2. TBD
Postcondictions: The ZEN Server is successfully running.
Alternative flows and exceptions:

None.


Use Case - Browser/ZEN Server Interaction

Use Case 601: Authenticate Identity

Use case name: Authenticate Identity
Unique use case ID: UC601
Primary actor(s): SMART Member
Secondary actor(s): None
Brief description: Whenever anyone logs onto the website, they go through an authentication process to determine and validate their identity.
Preconditions: The user has access to a web-enabled browser (IE, Firefox, ...).
Flow of events:
  1. The user enters the web site's address in a web-enabled browser.
  2. The user is provided with an authentication page.
  3. Upon entering a valid username/password combination, the user is directed to the main page of the site.
Postcondictions:
  • The user is given access to the main page of the site.
  • The ZEN Server logs every authentication attempt.
Alternative flows and exceptions:
  1. If the authentication process fails, then the user is refused access to the main site, and is given the choice to re-enter a username and password.


Use Case 602: Generate Report

Use case name: Generate Report
Unique use case ID: UC602
Primary actor(s): Analyst
Secondary actor(s):
Brief description: If a user successfully logs into the web server, he is presented a set of options that include the generation of various engagement reports.
Preconditions:
  • The user has access to a web-enabled browser (IE, Firefox, ...).
  • The user has successfully been authenticated into the web server.
Flow of events:
  1. The user gains authorized access to the web server.
  2. The user chooses to access the report generation section from the main page.
  3. The user is presented with various types of reports that can be generated.
  4. The user chooses one of the following engagement reports to be generated:
    1. Current SMIG
    2. Draft of Final Report
    3. List of Questions Per Tag
    4. Different Types of Risk Summaries Per Engagement
    5. Different Types of Risk Summaries Across All Engagements
  5. The user enters the relevant information for the selected type of report, and asks for the report to be generated.
  6. The report is generated and displayed to the viewer.
Postcondictions: The selected report is displayed to the viewer.
Alternative flows and exceptions:
  1. The user prints the report.


Use Case 603: Manage SMIG

Use case name: Manage SMIG
Unique use case ID: UC603
Primary actor(s): Administrator
Secondary actor(s):
Brief description: If a user successfully logs into the web server, he is presented a set of options that include the management of the SMIG.
Preconditions:
  • The user has access to a web-enabled browser (IE, Firefox, ...).
  • The user has successfully been authenticated into the web server.
Flow of events:
  1. The user gains authorized access to the web server.
  2. The user chooses to access the SMIG modification section from the main page.
  3. The user is presented with various actions to perform on the SMIG.
  4. The user chooses to add, modify, or deactivate a question to/from the current SMIG.
  5. The user enters the relevant information for this option.
  6. The question is updated on the server.
Postcondictions: The SMIG is updated on the server.
Alternative flows and exceptions:
  1. The user chooses to modify an existing question in the current version of the SMIG.
  2. The user selects the question to be modified.
  3. The user sets the related question to be a question that already points to this question.
  4. The server detects the cyclical reference, and warns the user of the inconsistency in the data entry.
  5. The user has the option to modify the data entry and correct the flaw, or cancel the SMIG operation.


Use Case 604: Manage Tags

Use case name: Manage Tags
Unique use case ID: UC604
Primary actor(s): Interviewer
Secondary actor(s): Administrator
Brief description: If a user successfully logs into the web server, he is presented a set of options that include the management of tags.
Preconditions:
  • The user has access to a web-enabled browser (IE, Firefox, ...).
  • The user has successfully been authenticated into the web server.
Flow of events:
  1. The user gains authorized access to the web server.
  2. The user chooses to access the tag handling section from the main page.
  3. The user is presented with various actions to perform with tags.
  4. The user chooses to modify the default list of tags.
  5. The user adds/modifies/removes the tag of interest in the default list.
  6. The default tags list is updated on the server.
Postcondictions: Changes to the list of tags is reflected on the server.
Alternative flows and exceptions:
  1. The user chooses to generate a custom tag.
  2. The user adds the custom tag's contents, and confirms its creation.
  3. The tag is added to the list of custom tags on the server.

or

  1. The user chooses to associate a tag with a particular engagement.
  2. The user is presented with a list of active engagements.
  3. The user selects the engagement to be tagged.
  4. The user checks off the tags that should be associated with the selected engagement, and confirms the tag association.
  5. The engagement's information is updated on the server.


Use Case 605: Download Data

Use case name: Download Data
Unique use case ID: UC605
Primary actor(s): SMART Member
Secondary actor(s):
Brief description: If a user successfully logs into the web server, he is presented a set of options that include the downloading of data.
Preconditions:
  • The user has access to a web-enabled browser (IE, Firefox, ...).
  • The user has successfully been authenticated into the web server.
Flow of events:
  1. The user gains authorized access to the web server.
  2. The user chooses to access the data download section from the main page.
  3. The user is presented with a list of engagements to choose from.
  4. The user chooses the desired engagement.
  5. The user is presented with various types of data to download (tag or setup data).
  6. The user chooses to download SMIG data for the selected engagement.
  7. The chosen data from the selected engagement is downloaded from the server.
Postcondictions: Selected data is downloaded to the user.
Alternative flows and exceptions:


Use Case 606: Manage Engagement

Use case name: Manage Engagement
Unique use case ID: UC606
Primary actor(s): Administrator
Secondary actor(s):
Brief description: If a user successfully logs into the web server, he is presented a set of options that includes setting up a new engagement or managing an existing one.
Preconditions:
  • The user has access to a web-enabled browser (IE, Firefox, ...).
  • The user has successfully been authenticated into the web server.
Flow of events:
  1. The user gains authorized access to the web server.
  2. The user chooses to access the engagement setup section from the main page.
  3. The user selects to create a new engagement.
  4. The user fills the new engagement setup form with all of the required fields.
  5. The user confirms the engagement creation.
  6. The new engagement information is updated on the server.
Postcondictions: None.
Alternative flows and exceptions:
  1. The user selects to modify an existing engagement.
  2. The user selects the engagement to modify.
  3. The user makes the desired modifications to the selected engagement.
  4. The user confirms the engagement modifications.
  5. The engagement information is updated on the server.

or

  1. The user chooses to cancel the new or existing engagement setup.
  2. The user doesn't confirm the new engagement setup cancellation.
  3. The user fills the new or existing engagement setup form with all of the required fields.
  4. The user confirms the engagement creation.
  5. The new engagement information is updated on the server.

or

  1. The user chooses to cancel the new or existing engagement setup.
  2. The user confirms the new engagement setup cancellation.
  3. The user is returned to the main web site page.


Use Case 607: Consolidate Interview Data

Use case name: Consolidate Interview Data
Unique use case ID: UC607
Primary actor(s): Interviewer
Secondary actor(s):
Brief description: If a user successfully logs into the web server, he is presented a set of options that includes consolidating interview data. This option allows the user to merge the information from multiple reports associated to a single engagement, and download the consolidated version of the reports.
Pre-conditions:
  • The user has access to a web-enabled browser (IE, Firefox, ...).
  • The user has successfully been authenticated into the web server.
Flow of events:
  1. The user gains authorized access to the web server.
  2. The user chooses to access the consolidate interview data section from the main page.
  3. The user selects the engagement he would like to have consolidated.
  4. The user presses the consolidate button.
  5. The ZEN Server consolidates the interview data from the various reports associated with that engagement.
  6. The user is presented with a consolidation status page that lets him know that the consolidation was successful or not; and in case of a successful consolidation, the user is presented with a button to download the consolidated report.
  7. The user presses the download button and obtains the consolidated report.
Post-conditions:
  • The ZEN Server contains a consolidated report of all of the most current interview reports from the given engagement.
Alternative flows and exceptions:
  1. The ZEN Server encountered an error while consolidating the reports, and displays the error to the user.
  2. The user is offered the option to reselect an engagement and restart the consolidation process, or to return to the main menu.
  3. The user returns to the main menu and chooses another server function.


Use Case - ZEN Client/ZEN Server Interaction

Use Case 701: Authenticate to Server using ZEN client

Use case name: Authenticate to Server using ZEN client
Unique use case ID: UC701
Primary actor(s): Interview, Notetaker
Secondary actor(s):
Brief description:
  • At the end of this functionality, the ZEN client communicating with the server, if successfully authenticated will gain access to use functionality on the server.
Pre-conditions:
  • The ZEN client knows the correct URL to connect to the ZEN server.
  • The interviewer/notetaker must be able to configure the correct URL
Flow of events:
  • ZEN client
  1. The interviewer/notetaker clicks on a button or menu to connect to the ZEN server
  2. The ZEN client internally authenticates to the ZEN server using preset credentials (known only in the source code and not to anyone outside)
  3. If the credentials are correct, the ZEN client is allowed to access functionality on the server
  4. If the credentials are incorrect (if somebody is trying to spoof the ZEN client, access is not allowed
Post-conditions:
  • The ZEN client is able to successfully log into the ZEN server
Alternative flows and exceptions:
  • The interviewer/notetaker configures an alternate URL
  • Connection to the internet or to the ZEN server could not be established


Use Case 702: Download Engagement Setup

Use case name: Download Engagement Setup
Unique use case ID: UC702
Primary actor(s): Interview, Notetaker
Secondary actor(s):
Brief description:
  • At the end of this functionality, the ZEN client must have the data about the new engagement on the local machine.
Pre-conditions:
  • The ZEN client has established a connection with the ZEN server
Flow of events:
  • ZEN client
  1. The interviewer/notetaker clicks on a button or menu to connect to the ZEN server
  2. The ZEN client internally authenticates to the ZEN server using preset credentials (known only in the source code and not to anyone outside)
  3. The ZEN client now has a list of engagements on the server listed on screen
  4. The interviewer/notetaker clicks on the required engagement and presses download
Post-conditions:
  • The ZEN client downloads the engagement setup data from the ZEN server
Alternative flows and exceptions:
  • Connection to the internet or to the ZEN server could not be established


Use Case 703: Upload Interview data

Use case name: Upload Interview data
Unique use case ID: UC703
Primary actor(s): Interview, Notetaker
Secondary actor(s):
Brief description:
  • At the end of this functionality, the ZEN client must have uploaded the interview data from the local machine to the ZEN server.
Pre-conditions:
  • The ZEN client has established a connection with the ZEN server
Flow of events:
  • ZEN client
  1. The interviewer/notetaker clicks on a button or menu to connect to the ZEN server
  2. The ZEN client internally authenticates to the ZEN server using preset credentials (known only in the source code and not to anyone outside)
  3. The interviewer/notetaker clicks on the upload interview data button / menu
  4. The ZEN client now uploads interview data to the server
Post-conditions:
  • The ZEN client uploads the interview data to the ZEN server
Alternative flows and exceptions:
  • Connection to the internet or to the ZEN server could not be established


Use Case 704: Download Consolidated Interview data

Use case name: Download Consolidated Interview data
Unique use case ID: UC704
Primary actor(s): Interview, Notetaker
Secondary actor(s):
Brief description:
  • At the end of this functionality, the ZEN client must have the consolidated interview data on the local machine.
Pre-conditions:
  • The ZEN client has established a connection with the ZEN server
Flow of events:
  • ZEN client
  1. The interviewer/notetaker clicks on a button or menu to connect to the ZEN server
  2. The ZEN client internally authenticates to the ZEN server using preset credentials (known only in the source code and not to anyone outside)
  3. The interviewer/notetaker clicks on the current engagement and presses download
  4. The ZEN client downloads the consolidated interview data from the ZEN server
Post-conditions:
  • The ZEN client downloads the consolidated interview data from the ZEN server
Alternative flows and exceptions:
  • Connection to the internet or to the ZEN server could not be established


Use Case 705: Secure Upload/Download

Use case name: Secure Upload/Download
Unique use case ID: UC705
Primary actor(s): Interviewer, Notetaker
Secondary actor(s):
Brief description:
  • The ZEN client must be able to securely send and receive data to and from the ZEN server.
Pre-conditions:
  • The ZEN client has established a secure connection with the ZEN server
Flow of events:
  • ZEN client
  1. The interviewer/notetaker clicks on a button or menu to connect to the ZEN server
  2. The ZEN client internally authenticates to the ZEN server using preset credentials (known only in the source code and not to anyone outside)
  3. The ZEN server authorizes the connection
  4. A secure connection is established
Post-conditions:
  • The ZEN client can now upload data securely to the ZEN server or download data securely from the ZEN server
Alternative flows and exceptions:
  • Connection to the internet or to the ZEN server could not be established


Retrieved from "http://msesrv1d.mse.cs.cmu.edu/wiki/index.php/Consolidated_Use_Cases"
Personal tools