ComputerScienceExpert
$18/per page/
$20 for the work and if you finish early I will tip. The diagrams must be saved in a why that i can edit it. Two diagrams. Open the file and read it. I include all my work and example 1 and 2 are what i'm looking for in format.
1. PLEASE recreate Figure 2.1.1 as the Example 1: ………………………………………………………………………………Place it here…………. 2. PLEASE turn Section 3.2.1into the Diagram as Example 2: ………………………………………………………………………………Place it here………….
3. Example 1 of a block diagram from someone else: My work: 2. Overall Description
2.1 Product Perspective
AGOA is an operator assistant program that will run on standard personal computer running XP. This
computer will be referenced as the “server” in the remainder of this document. It shall be accessed over
the internal network through a link that launches a restricted function web browser already established
on the mail inserter hardware. It will operate in the web browser on that hardware, and make minimal
impact to the operation of said device, and shall be transparent to the day-to-day operation of the
hardware except for a new icon on the main user interface.
When a user needs to use AGOA they will click on the icon and access it from there. AGOA will interact
through the touchscreen, keyboard, scanning device, operating system and mass storage of the device.
It’s output will be on screen or transmitted via appropriate hardware available to the mail inserter. Figure 2.1.1: Block Diagram for Abstract Giraffe Operator Assistant (AGOA) 2.1.1 System Interfaces
2.1.1.1 Graphical UI
Graphical UI is the basic user interface functionality. It shall use icons and standard web based interface
items including buttons, drop down lists, text boxes, check boxes, radio buttons, text, and images.
The interface shall use standard libraries of the chosen computer language to access standard input and
output procedures as allowed by the operating system. In the case of the mail inserters this includes a
touch screen for the equivalent of a mouse, a keyboard for text entry, and the same touch screen for
output. 2.1.1.2 QR-code Decode
QR-codes shall be read by scanning-gun hardware attached to the mail inserter hardware. These guns
replicate the act of typing when they read a valid QR-code, and the software shall treat it as such.
Since the gun acts like a keyboard, the interface shall use standard libraries of the chosen computer
language to access standard input and output procedures as allowed by the operating system. 2.1.1.3 File Storage
The various journaling function of the AGOS software including problem area logging and workaround
logging will use the mass storage system hardware that is part of the server hardware.
The interface shall use standard libraries of the chosen computer language to access standard input and
output procedures of the file system as allowed by the operating system. 2.1.1.4 File Access
The various journaling function of the AGOA software including previous shift log retrieval, module
trending, operator trending, and machine trending will use the mass storage system hardware that is
part of the mail inserter hardware.
The interface shall use standard libraries of the chosen computer language to access standard input and
output procedures of the file system as allowed by the operating system. 2.1.2 User Interfaces
The user interface for AGOA shall be simple standard World Wide Web based interfaces. The initial
interface is through a button on the main window. Clicking on this button shall launch a URL that will
send the user to the AGOA application which will use simple drop-downs for user identification, and
presses on the touch screen to adjust cursor location.
The interface shall be static with no inherent customization necessary.
Once the user has selected themselves, they can select the function of Decode, Log, or supervisor
functions. The supervisor functions are not particularly sensitive, so they will not require a specific login.
When decoding, the cursor shall default to an input field that will automatically detect input and not
require any additional input. Once input is received, usually from the scan gun, AGOA will run the
decode on the QR code and give human readable output on the same screen. When in logging mode, a simple set of text boxes and/or list drop downs, check boxes, and/or radio
buttons will allow the user to enter data using the keyboard.
When in supervisor mode, the supervisor will use the touch screen to select a specific report using a
series of narrowing drop down lists.
The QR scan gun is an interface itself. Users will point it at the QR code, and press the trigger to scan the
code. It will then automatically send this output as if the used typed text on the keyboard.
The interface will be optimized such that decoding can be completed by a novice user of the mail
inserter in thirty seconds after twenty uses over a week. Less uses will increase the time it takes to
become proficient and conversely more uses will decrease that time. That amount of uses is dependent
on the amount of diverts caused by the mail inserter and is not controllable by this team. 2.1.3 Hardware Interfaces
The hardware interfaces include the touch screen, QR scan gun, keyboard, and file system. These
interfaces shall use standard libraries of the programing language and be controlled by the Operating
system of the mail inserter device.
The keyboard, and QR decode gun will have a single port, and will logically share the same port as far as
the AGOA software is concerned. The software will not know the difference between keyboard and QR
gun input.
The touch screen will have an input and an output port and shall use the interfaces and protocols as
appropriate for the operating system.
AGOA shall allow the file system and operating system handle the amount of ports and access paths
necessary. It will work with multiple files, one for each log type, for both redundancy and simultaneity of
operation. 2.1.4 Software Interfaces
The only software interface that the AGOA software shall interface with is the Operating system software
of the mail inserter machines. This OS is Windows XP.
This interface allows for the basic functionality of the AGOA software, including file handling and
standard input and output from the touch screen, keyboard, and QR gun.
It is assumed that AGOA will be written using JAVA. Documentation on JAVAA standard I/O is well
documented, including a tutorial listed here: https://docs.oracle.com/javase/tutorial/essential/io/cl.html 2.1.5 Communication Interfaces
The AGOA software shall not communicate outside of the mail inserter devices and the server. Any
networking involved shall be handled by a networked file system and not any specific network
communication. The file system will handle the networked storage if that is a case, and nothing specific
shall be included in the AGOA software. 2.1.6 Memory Constraints
The AGOA software shall be limited by the memory available on the server hardware 2.1.7 Operations
The operations required for the AGO software are highlighted in the user interface section. 2.1.7 Site adaptation requirements
The AGOA software will be required to run on the mail inserter machines, and thus shall be compatible
with the operating system, memory, and devices attached to the mail inserter machines. 2.2 Product Functions
2.2.1 A simple GUI with FSSI logos and color schemes
This user interface will start with a button added to the standard user interface of the mail inserter
devices. A possible example is below: Once the AGOA button is pressed it launches a hyperlink and a window shall open with the
AGOA software. It shall resemble a standard web browser interface with simple standard
form units, and use a background similar to the one above. 2.2.2 The Journaling Tool
The journaling tool is a simple tool that allows for the user to report problem areas, and workaround
they used on a particular machine. Additionally they can look at a report created by the previous shift.
There are three basic functions that will be accessed through simple buttons. 2.2.2.1 Problem area Logging
This shall be a simple form with a text box for data entry and button to submit. 2.2.2.2 Workaround Logging
This shall be a simple form with a text box for data entry and button to submit. 2.2.2.3 Workaround Logging
This shall be a simple form with a text box for data entry and button to submit and an additional button
to look at the previous shift’s log. 2.2.3 Supervisor trending tools
These tools are various reports that assist a supervisor with analyzing trends with the machines,
operators, and modules of the mail inserter machines. 2.2.3.1 Machine Trends
This shall be a simple block of text formatted in an easy to read form that reports on the trends specific
to each mail inserter machine in the company. If the machines use a centralized file system, this will
allow for selection of specific machines or a report of all machines. If not, it will be specific to the
machine it is running on. 2.2.3.2 Operator Trends
This shall be a simple block of text formatted in an easy to read form that reports on the trends specific
to each operator of the mail inserter machine in the company. If the machines use a centralized file
system, this will allow for selection of specific operators on a specific machine or a report of and
operator on all machines and both reports will allow for reports of all operators. If there is no centralized
file system, it will be specific to the machine it is running on. 2.2.3.3 Machine Trends
This shall be a simple block of text formatted in an easy to read form that reports on the trends specific
to each module on mail inserter machine in the company. If the machines use a centralized file system,
this will allow for selection of specific module on specific machines or a report of all modules on all
machines. If not, it will be specific to the machine it is running on. 2.3 User Characteristics
The users of the AGOA need a basic high school educational level and basic computer literacy. Clicking on
links, using web based forms, typing, and basic literacy are the required skills.
Approximately 15 minutes of training should be sufficient for the average user, with 30 minutes for a
supervisor. 2.4 Constraints
2.4.1 Regulatory Policies
The AGOA software itself does not encounter any regulatory policies. A side issue is that an operator
using the information from the decoder may view customer private information. The client will need to
decide how to handle and regulate this as it is not an inherent issue with the AGOA software. 2.4.2 Hardware limitation
The AGOA software must run on a standard PC. 2.4.3 Interfaces with other applications
The AGOA software shall interact with the Windows XP operating system and the web browser software
on the mail inserters. 2.4.4 Parallel operations
The AGOA shall run parallel on multiple mail inserters and similarly network attached PC clients that
access a single server PC. The software shall be designed such that each client can run concurrently
without interference. 2.4.5 Audit functions
The AGOA software will have auditing functions built into the supervisor tools. 2.4.6 Control functions
A simple GUI will control AGOA 2.4.7 Higher-order language requirements
The AGOA software will require windows XP and a basic Web server. 2.4.8 Signal handshake protocols
The AGOA will not require explicit handshake protocols. The handshakes required will be handled by the
standard libraries for standard network communication and will be transparent to the AGOA software. 2.4.9 Reliability requirements
The AGOA will be expected to have a 96% uptime. 2.4.10 Criticality of the application
The AGOA is not mission critical software and instead is a time saving tool. 2.4.11 Safety and security considerations
The AGOA software has no safety considerations. Some security of customer data is affected, but is user
based more than software based. 2.5 Assumptions and dependencies
It is assumed that the AGOA software will run on the web server inherent to the Windows XP Operating
system.
It is assumed that the web browsers on the mail inserters can run Java. 2.5 Apportioning of requirements
A mobile phone based AGOA application will be a simple Decoder. This additional functionality will allow
the user to be flexible and access the decoder if the mail inserter is busy and not able to be used to
launch the AGOA application.
This function will also allow the user to Decode with their own familiar hardware and away from the mail
insterters. Example 2: Use Case Diagram My work
Section 3 Specific Requirements
3.1 External Interfaces
3.1.1 AGOA GUI
A. Name of item: AGOA GUI
B. Description of purpose: The purpose of the AGOA GUI is for the user to input journaling data
and enter DADM scan data for decoding.
C. Source of input or destination of output: The user shall navigate the functions of the AGOA
software by keyboard or mouse within a web browser routed to the AGOA application. The
DADM scan data shall be entered through the use of an FSSI provided 2D data matrix scanning
tool.
D. Valid range, accuracy and/or tolerance: Tolerances for scanned DADM codes must be within the
11 or 14 character FSSI DADM template. Scanned data outside this range shall display a fault
message.
E. Units of measure: Not Applicable
F. Timing: The user entered dates into the Supervisor tool and Operator Journaling tool shall be
within common format and must be past dates. G. Relationships to other inputs/outputs: The AGOA GUI is directly related to user keyed input.
The AGOA GUI shall be the input interface for the Journaling and DADM decoder tools.
H. Screen formats/organization: The AGOA GUI shall have the following screens available to the
various users:
The AGOA GUI home page shall display a scan entry field to populate the DADM decoder. It shall
also display links to the Supervisor and Journaling tools. When the DADM decoder has receives
a valid data entry, the AGOA GUI home screen shall display the DADM decoded message data.
The AGOA GUI Supervisor tool screen shall display selection menus for querying the AGOA
Database data.
The AGOA GUI Journaling tool screen shall display user entry fields for data collection.
I. Window format organization: The AGOA GUI window shall be displayed in a web browser
window. J. Data formats: Dates shall be displayed in mm/dd/yyyy format. Alphanumeric characters shall
be displayed in standard block font in English. K. Command formats: Issuing commands shall follow this format: “Input/Select, Actuate, Confirm”
method. 3.1.2 Web Service
A. Name of item: Web Service
B. Description of purpose: The web service shall perform work on the DADM code entered by the
user and to route the journaling data to the database.
C. Source of input or destination of output: The input to the web service shall come from the
AGOA GUI in the form of DADM codes and journal data. This input shall be transferred via FSSI
LAN. The output shall be a decoded DADM sent to the AGOA GUI home screen for display via
FSSI LAN.
D. Valid range, accuracy and/or tolerance: Data transfer shall be handled by TCP/IP protocol.
E. Units of measure: Data movement shall be measured in megabits per second.
F. Timing: Network timing shall be in according with IEEE 802.11g/n and IEEE 802.3 for wired
Ethernet clients. G. Relationships to other inputs/outputs: The AGOA DADM decoder shall be driven by the web
service. The journaling database and all traffic to and from shall be directed via the web service.
H. Screen formats/organization: The screen format and organization for the Web Services shall
make the AGOA GUI available to the desktop clients. Web Services shall present data in a
scalable web-page format conforming to the physical shape of the presentation device. Data
shall be presented in a top down format.
I. Window format organization: The window format shall be ?????? J. Data formats: Data input by the user shall be in Boolean or string formats. Data output by Web
Services shall be in text encapsulated in HTTP data. K. Command formats: Issuing commands shall follow this format: “Input/Select, Actuate, Confirm”
method.
L. End message: No end message shall be required.
3.1.3 Database
A. Name of item: Web Service
B. Description of purpose: The web service shall perform work on the DADM code entered by the
user and to route the journaling data to the database.
C. Source of input or destination of output: The input to the web service shall come from the
AGOA GUI in the form of DADM codes and journal data. This input shall be transferred via FSSI
LAN. The output shall be a decoded DADM sent to the AGOA GUI home screen for display via
FSSI LAN.
D. Valid range, accuracy and/or tolerance: Data transfer shall be handled by TCP/IP protocol. E. Units of measure: Data movement shall be measured in megabits per second.
F. Timing: Network timing shall be in according with IEEE 802.11g/n and IEEE 802.3 for wired
Ethernet clients. G. Relationships to other inputs/outputs: The AGOA DADM decoder shall be driven by the web
service. The journaling database and all traffic to and from shall be directed via the web service.
H. Screen formats/organization: The screen format and organization for the Web Services shall
make the AGOA GUI available to the desktop clients. Web Services shall present data in a
scalable web-page format conforming to the physical shape of the presentation device. Data
shall be presented in a top down format.
I. Window format organization: The window format shall be ?????? J. Data formats: Data input by the user shall be in Boolean or string formats. Data output by Web
Services shall be in text encapsulated in HTTP data. K. Command formats: Issuing commands shall follow this format: “Input/Select, Actuate, Confirm”
method.
L. End message: No end message shall be required. 3.2 Functions
3.2.1 Function Group 1: DADM Decoding
This function group shall decode the DADM user input into human readable
variables. It shall be dependent on the Web Service function group, and the
AGOA GUI function group. It shall receive data from the GUI, transferred via
web services, and display the information through the GUI.
3.2.1.1 Functional Requirement 1.1: Receive Input
The DADM Decoder shall receive user input via AGOA GUI DADM scanner field.
3.2.1.2 Functional Requirement 1.2: Input overflow and Underflow Checking
and Handling
The system shall verify the data received from the AGOA GUI DADM scanner
field is between 11 and 14 characters (inclusive).
3.2.1.3 Functional Requirement 1.3: DADM Decoding The system shall perform the DADM code translation and temporarily store
the variable values for output. The variables that shall be analyzed and
assigned are:
1. Page sequence (1-7)
2. Machine stop required
3. End of collation
4. Set sequence (1-7)
5. Zip code sortation
6. Mark for divert
7. Selective requirements (1, 2, 3, 4, 5, and 6)
8. Processing mode (2D or PD)
9. Statement number
3.2.1.4 Functional Requirement 1.4: Error Handling:
The system shall verify the validity of the DADM value, returning an error
message to the user if the value is invalid.
3.2.1.5 Functional Requirement 1.5: Data output
The system shall return the decoded data, based on function requirements in
3.2.1.3, in text form to the AGOA GUI for display.
3.2.2 Function Group 2: AGOA GUI
This function shall service the AGOA user view. It shall be dependent on the web services function
group.
3.2.2.1 Functional Requirement 2.1: Display Home Screen
This function shall display the AGOA home screen with functional icons and fields.
3.2.2.2 Functional Requirement 2.2: Display Decoded Data
This function shall switch GUI view to the decoded data view.
3.2.2.3 Functional Requirement 2.3: Display Operator Journaling View
This function shall switch the GUI to Operator Journaling view.
3.2.2.4 Functional Requirement 2.4: Display Supervisor View
This function shall switch the GUI to Supervisor View.
3.2.3 Function Group 3: Problem Area Logging
This function shall be used to store and retrieve operator data regarding machine problem areas. It
shall be dependent on the journaling database.
3.2.3.1 Functional Requirement 3.1: Problem Area Entry This function shall create a problem area entry record and store it in the journaling database.
3.2.3.2 Functional Requirement 3.2: Read Problem Area Entry
This function shall read problem area entries in data storage.
3.2.3.3 Functional Requirement 3.3: Search Problem Area Entries
This function shall search journal entry records for entries matching user inputted search
parameters.
3.2.3.4 Functional Requirement 3.4: Return Problem Area Entries
This function shall return specified journal entries to the AGOA GUI for display.
3.2.4 Function Group 4: Workarounds Logging
This function shall be used to store and retrieve operator data regarding machine work arounds. It
shall be dependent on the journaling database.
3.2.4.1 Functional Requirement 4.1: Workaround Entry
This function shall create a workaround entry record and store it in the journaling database.
3.2.4.2 Functional Requirement 4.2: Read Problem Area Entry
This function shall read workaround entries in data storage.
3.2.4.3 Functional Requirement 4.3: Search Problem Area Entries
This function shall search workaround records for entries matching machine and module selections.
3.2.4.4 Functional Requirement 4.4: Return Problem Area Entries
This function shall return specified problem area entries to the AGOA GUI for display.
3.2.5 Function Group 5: Previous Shift Log Retrieval
This function shall return all journal entries matching a selected machine and the current date to
the user via GUI for view. It shall be dependent on the Problem Areas and Workarounds Functions.
3.2.5.1 Functional Requirement 5.1: Search Journal Entries
This function shall query the journal database for all entries containing a user specified machine
and date.
3.2.5.2 Functional Requirement 5.2: Return Journal Entries
This function shall return the matching journal entries to the AGOA GUI from storage.
3.2.5.3 Functional Requirement 5.3: Error Handling
This function shall return an error message to the user if an invalid machine name or date is
entered.
3.2.5.4 Functional Requirement 5.4: Bandwidth Overflow Handling
This function shall return a maximum of x.x kb of data. If the requested journal entries exceed this
amount, this function shall return a link for returning an additional x.x kb of data.
3.2.5.5 Functional Requirement 5.5: Bandwidth Request Queueing This function shall regulate the bandwidth queue to prevent dropped data packets.
3.2.6 Function Group 6: Journaling Database
3.2.7 Function Group 7: Module Trending
3.2.8 Function Group 8: Operator Trending
3.2.9 Function Group 9: Machine Trending
3.3 Performance Requirements
In accordance with FSSI performance requirements the AGOA application must function at or above
a level described in the below mentioned sections. The below sections assume the utilization of
hardware at or above the minimum hardware specifications defined in section 2.1.3 of the SRS.
3.3.1 Number of Simultaneous Users to Be Supported
FSSI has 6 Mail Insertion machines capable of entering data into the AGOA application. In addition,
there are 2 supervisors at any given time capable of querying the journaling database. Considering
the nature of the data, and simultaneous nature of some functionality, the AGOA software could
create significant bandwidth draw on the existing FSSI server. Therefore, the number of users to be
supported will be based on bandwidth allocation from FSSI. The recommended bandwidth
allocation is 60kbps.
3.3.2 Number of Transactions
FSSI empirical data suggests a range of 2-5 journal entry worthy instances per machine, per shift.
There are 6 Mail Insertion machines running per shift. In total, this constitutes 12-30 entries per
shift. Even with a modest bandwidth allocation there shall be less than a 3% failed submission rate,
which is within FSSI demands. However, all 6 machines will likely be querying the previous shift
journal logs nearly simultaneously. This high usage period may experience a higher rate of failure if
the bandwidth allocation is below the AGOA suggested amount. If the allocation is at or above the
suggested amount there shall be an acceptable level of unsuccessful submissions (>3%).
3.4 Logical Database Requirements