REQUIREMENTS ANALYSIS DOCUMENT
revision 2.9
STARS Authoring Team
Daniel Gindikin : David Guttendorf : Roger Hong : Graham Prud'homme : Jonathan Rosenberg : Roger Smith : Anthony Yip : Grace Ritter



1. General Goals
1.1 Purpose. The purpose of the Authoring Team is to facilitate the conversion of paper technical manuals to Interactive Electronic Technical Manuals (IETMs).

1.2 Objectives. Our objectives and criteria for success include ensuring the correct translation of the paper manuals into digital form; ease of use in all aspects of document creation, editing, and viewing; the creation of Level 3 IETMs as specified in MIL-PRF-87269B; and meeting a December 7th deadline for project completion.

1.3 References. Please see the following documents.
2. Current System
The current Technical Manuals are all in paper format. They are authored by aircraft parts manufactures (GE and Boeing) and aircraft assemblers (Boeing). The finished technical manuals are then shipped to navy maintenance organizations. The current system to annotate technical manuals consists of technical personnel delivering memos to the technical manual authoring group. After the correction has been made, new versions of Technical Manuals are distributed to the navy maintenance organizations.
3. Proposed System
3.1 Overview.
The authoring of IETMs from paper documents is to be done in two stages; the digitizing stage, and the conversion stage. The digitizing stage is to be done by Alaskan Native and American Native firms. They will use text and graphic conversion tools and apply quality control techniques to produce electronic data, which is then submitted to technical writers, who will convert the digitized data into IETM format.

Annotations to IETMs from external sources will also be handled by the Authoring subsystem.
3.2 Functional Requirements.
The functional requirements of the authoring subsystem are the conversion of a paper document into an IETM, and the annotation of IETMs. Quality control measures will be implemented at several stages of the process, including verification that the digitized document is identical to the original paper document, and verification that the finished IETM is correct with respect to the original paper document.

If mistakes are found at any stage, annotations are issued and corrections are made. Annotations by outside authors to IETMs or paper documents are also allowed.
3.3 Non-functional Requirements.
3.3.1 User Interface and Human Factors.
The authoring subsystem will be used by Native American and Native Alaskan document specialists who will digitize the paper manuals; and trained technical writers, who will convert the digitized data into IETM format. The proposed system should require less technical expertise than what is required by the current system.
3.3.2 Documentation.
Documentation to facilitate creating, editing, and viewing of documents and IETMs will be provided by the authoring system.
3.3.3 Hardware Consideration.
The hardware supported by the authoring subsystem is a networked personal computer. The platform must be able to run IETM conversion and creation tools such as AIMSS, ACS, and GCS. Currently, these tools run on the Microsoft Windows family of operating systems (95/98/NT). The systems must have adequate storage space to contain the IETMs, and must be able to submit the finished IETMs to the database via a secure network connection; a 10Mbit/sec or faster link is recommended.
3.3.4 Performance Characteristics.
The authoring subsystem will strive to achieve low latency for the end user of the IETM Viewer.
3.3.5 Error Handling and Extreme Conditions.
A version control system (supplied by the Workflow subsystem) will protect against data loss during the digitization and conversion process.
3.3.6 System Interfacing.
The authoring subsystem takes input from aircraft parts manufacturers (OEMs) in paper document format, and provides output to a database controlled by the workflow subsystem in IETM format.

The authoring subsystem additionally takes input from outside sources in the form of annotations to paper documents or IETMs.
3.3.7 Quality Issues.
Quality controllers verify the work done by document specialists and technical writers during the digitization and conversion stages of the authoring process, to ensure correct output. If errors are found, annotations are used to correct them.
3.3.8 System Modifications.
The authoring subsystem can be upgraded via updating the ACS, AIMSS, and GCS conversion software. Additionally, the system can be modified by replacing any of those specific components with other software that provides the same functionality.
3.3.9 Physical Environment.
The physical environment of the authoring subsystem is a distributed, networked environment. The digitization and conversion processes do not happen in the same location, and are independent from each other. As a result, a reliable network connecting the two facilities is important.
3.3.10 Security Issues.
Due to the distributed nature of the authoring process, secure network transmissions are important for ensuring the security of the data. Access control lists will also be used in the database to ensure only the proper actors have access to the data contained within.
3.3.11 Resource Issues.
The resource requirements of the authoring subsystem include storage space on the computers used to do digitization and IETM conversion, and a fast, secure, and reliable network connection to the database.
3.4 Constraints.
Our computing platform must be compatable with the required IETM authoring and conversion software; ACS, AIMSS, and GCS (or functional equivalents). The system will be developed in Java, and Together/J will be used as our case tool. CVS will be used as our source revision control system.
3.5 System Model.
3.5.1 Scenarios.
Scenarios describing the use of the Authoring system are as follows.
  • Introduction of the IETM Authoring process
    Dave, one of the Document Operation Manager from the Arctic Slope Regional Corporation (ASRC) receives the task to convert the paper technical manual to digital data for the GE 404 engine used in the F/A-18 A&B aircraft. He divides the scanning tasks into logical sections and checks if any of the sections have already been converted to IETM Sections through prior conversions. He then distributes the sections that have not yet been converted to the Document Specialists under his supervision.

    Jim, one of the Document Specialists receives his assignment from Dave and scans the section of technical manual he's responsible for into the Automated Conversion System (ACS) in order to convert the text. In Addition to that, he scans the document section into a companion tool (GCS), to convert the graphics. The result of these operations is an entity called Digital Document in which he checks and corrects the errors introduced by the ACS and graphic tool. Next, the Digital Document is passed to Katherine, a Quality Controller, who checks it and returns it to Jim for more corrections. When that iteration is completed, the document migrates to the next step in the process, the addition of links and structure to the digital document using an AIMSS IETM authoring system by a Technical Manual Writer.

    The product of the document structuring process is an entity identified as an IETM section. Anne, a Quality Controller assigned for the verification of this entity searches for any errors introduced by the AIMSS IETM authoring system. She verifies its correctness and sends the IETM section to another Quality Controller, Luc, to perform a final verification operation on the IETM Section document. Luc marks the document as approved and redirects it to the Workflow subsystem.

  • Digital document verification
    As John, a Quality Controller responsible for the verification of a digital document is examining his assigned portion, he finds that a caption is missing for an important diagram. He realizes this correction is critical and attaches a DigitalDocumentAnnotation to the digital document. The Annotation object associated with the digital document identifies the nature and description of the error in the document as well as the steps to rectify the error. Next, John sends the digital document and the associated annotation back to Tom, the Document Specialist responsible for this document, for immediate correction.

  • IETM section verification
    Joe, a Quality Controller in the IETM section verification process finds that a link is broken as he examines his assigned document. He determines that it is important for this error to be corrected in order for the maintenance personnel to be able to carry out their responsibilities, so he creates an IETMSectionAnnotation and enters the description of the error into it. He then sends the IETM section and the associated annotation to May, the technical writer responsible for the correction task described by the annotation.

  • IETM verification
    A Quality Controller, Jason, realizes that a page is duplicated in the IETM document. He attaches an IETMAnnotation requesting the correction to be made. Jerry, a technical writer receives the notification from the Workflow subsystem that a correction needs to be made in the document he is responsible for. He retrieves the document along with the associated annotation from the workflow subsystem and takes out the indicated duplicate page from the IETM.
3.5.2 Use Case Model.
3.5.2.1 Actors.
  • Document Operation Manager (DOM)
  • Database Requester, eXternal (Dr.X)
  • Document Specialist (DS)
  • Document Specialist Quality Controller (DSQC)
  • Technical Writer (TW)
  • Technical Writer Quality Controller (TWQC)
  • Workflow Subsystem
For descriptions of each of these actors, please refer to the Data Dictionary, in section 3.5.3.1 of this document.
3.5.2.2 Use Cases.
The following are diagrams illustrating the relationships between the Authoring use cases, relevant Workflow use cases, and their participating actors:

figure 1: Use Case diagram depicting the creation and conversion of documents.


figure 2: Use Case diagram depicting the quality control processes during the authoring process.


figure 3: Use Case diagram illustrating the relationship between Authoring and Workflow use cases.


figure 4: Use Case diagram for remaining Authoring use cases.

The following are all of the use cases contained within the scope of the Authoring Subsystem.


Use Case Name DigitizeDocument
Participating Actors Document Specialist
Entry Condition 1. DS receives notification from Workflow that there is a Paper Document Section available to be converted into a Digital Document.
Flow of Events 2. DS loads the Paper Document Section into the Scanner.
3. DS activates the OCR Software.
4. DS reads the new Digital Document, looking for errors that were generated in conversion.
5. If any errors are found, DS fixes them.
Exit Condition 6. DS uses Workflow's Submit use case on the Digital Document.
Special Requirements None.


Use Case Name DistributeScanningTask
Participating Actors Document Operation Manager, Document Specialist
Entry Condition 1. DOM is notified that there is a complete Paper Document available to be converted into many Digital Documents.
Flow of Events 2. DOM divides the Paper Document into Paper Document Sections.
3. DOM checks to see if any of the Paper Document Sections have been converted already. 4. DOM removes any Paper Document Sections that have already been converted from the set of Paper Document Sections that must still be converted. 5. DOM assigns and sends the Paper Document Sections that have not yet been converted to Document Specialists for conversion into Digital Documents.
Exit Condition 6. DOM uses Workflow's Submit use case (with notification to the appropriate Document Specialists that a Paper Document Section is available for conversion) to create a new file in the database corresponding to the IETM that will eventually be created.
Special Requirements None.


Use Case Name EditDigitialDocument
Participating Actors Document Specialist
Entry Condition 1. DS receives notification from Workflow that Digital Document requires editing.
Flow of Events 2. TW uses Workflow's Retrieve use case to retrieve the specified Digital Document and the associated Annotations.
3. TW opens the Digital Document in the Digital Document Editor.
4. TW opens the Annotations in the Annotation Viewer.
5. TW applies the changes dictated by the Annotations to the Digital Document.
6. TW marks the Annotations as completed.
Exit Condition 7. TW uses Workflow's Update use case on the Digital Document and completed Annotations.
Special Requirements None.


Use Case Name EditIETM
Participating Actors Technical Writer
Entry Condition 1. TW receives notification from Workflow that an IETM Section (which may or may not be a full IETM) requires editing.
Flow of Events 2. TW uses Workflow's Retrieve use case to retrieve the specified IETM Section and the associated Annotations.
3. TW opens the IETM Section in the IETM Section Editor.
4. TW opens the Annotations in the Annotation Viewer.
5. TW applies the changes dictated by the Annotations to the IETM Section.
6. TW marks the Annotations as completed.
Exit Condition 7. TW uses Workflow's Update use case on the IETM Section and completed Annotations.
Special Requirements None.


Use Case Name GetStatus
Participating Actors Document Operation Manager, Dr. X
Entry Condition 1. The Actor wants to know the status of a Document as it is being converted.
Flow of Events 2. The Actor uses Workflow's Retrieve Use Case on the Document.
3. The Actor opens the Document in the Document State Viewer.
4. The Actor reads the Document State that the Document State Viewer displays.
Exit Condition 5. The Actor closes the Document State Viewer.
Special Requirements none


Use Case Name IETM-ize
Participating Actors Technical Writer
Entry Condition 1. TW receives notification from Workflow that there is a Digital Document available to be converted into an IETM Section.
Flow of Events 2. TW uses Workflow's Retrieve use case to retrieve the Digital Document.
3. TW opens the Digital Document in the Digital Document to IETM Section Converter and produces an IETM Section.
4. TW checks the new IETM for conversion errors.
5. TW reads the IETM Section looking for errors brought about by the conversion process.
6. If any errors are found, TW corrects them.
Exit Condition 7. TW uses Workflow's Submit use case on the IETM Section.
Special Requirements None.


Use Case Name IssueAnnotation
Participating Actors Document Specialist, Document Specialist Quality Controller, Technical Writer, Technical Writer Quality Controller, Dr. X
Entry Condition 1. A mistake is found in a Digital Document or an IETM Section.
Flow of Events 2. The actor creates a new Annotation using an Annotation Editor, describing the fix to be made.
3. The actor associates the Annotation with the Digital Document or IETM Section that it annotates.
Exit Condition 4. The Actor uses Workflow's Update on the new Annotation and the faulty Digital Document.
Special Requirements Annotation can't be attached to a Paper Document that does not yet exist in the Authoring Sub-System.




Use Case Name VerifyDigitalDocument
Participating Actors Document Specialist Quality Controller
Entry Condition 1. A DSQC receives notification from Workflow that there is a Digital Document available for verification.
Flow of Events 2. DSQC uses Workflow's Retrieve use case to retrieve the Digital Document that is to be verified.
3. DSQC opens the Digital Document in the Digital Document Viewer.
4. DSQC compares the Paper Document to the Digital Document, and uses the IssueAnnotation use case if errors are found.
5. If there are no errors, DSQC marks the Digital Document as verified.
6. DSQC closes the Digital Document Viewer.
Exit Condition 7. DSQC uses Workflow's Update on the Digital Document.
Special Requirements None.


Use Case Name VerifyIETM
Participating Actors Technical Writer Quality Controller
Entry Condition 1. TWQC receives notification from Workflow that there is an IETM Section awaiting verification.
Flow of Events 2. TWQC uses Workflow's Retrieve use case to retrieve the IETM Section that is to be verified.
3. TWQC opens the IETM Section in the IETM Section Viewer.
4. TWQC compares the Paper Document to the IETM Section, and uses the IssueAnnotation use case if errors are found.
5. If there are no errors, TWQC marks the IETM Section as verified.
6. TWQC closes the IETM Section Viewer.
Exit Condition 7. TWQC uses Workflow's Update use case on the IETM Section.
Special Requirements None.


Use Case Name ViewIETM
Participating Actors Technical Writer, Technical Writer Quality Controller, Dr.X
Entry Condition 1. Somebody would like to view an IETM Section.
Flow of Events 2. The actor uses Workflow's Retrieve use case to retrieve the IETM Section as Read-Only.
3. The actor opens the IETM Section in the IETM Section Viewer.
4. The actor finishes viewing the IETM Section and closes the IETM Section Viewer.
Exit Condition 5. The local copy of the IETM Section is removed from the actor's computer.
Special Requirements None.
3.5.3 Object Model.
3.5.3.1 Data Dictionary.
Definitions that will be introduced in this paper include:
  • ACS: Automatic Conversion System
  • AIMSS: Advanced Integrated Maintenance Support System.
  • DOM: Document Operation Manager.
  • Dr.X: Database Requester, eXternal; a database consumer who is external to the Authoring subsystem.
  • DS: Document Specialist; those who convert paper documents to digital form.
  • DSQC: Document Specialist Quality Controller; those who check the work of the Document Specialists for accuracy.
  • DTD: Document Type Definition.
  • ETM: Electronic Technical Manual.
  • GCS: Graphical Conversion System.
  • IETM: Interactive Electronic Technical Manual.
  • OEM: Original Equipment Manufacturer.
  • STARS: Sticky Technology for Augmented Reality Systems.
  • STD: STARS Type Document; the DTD for our generated documents.
  • TW: Technical Writer; those who convert digital documents to IETM format.
  • TWQC: Technical Writer Quality Controller; those who check the work of the Technical Writers for accuracy.
  • VOID: Verified for Online Immediate Distribution.
3.5.3.2 Class Diagrams.

figure 5: class diagram for the Authoring subsystem
3.5.4 Dynamic Model.
3.5.4.1 Sequence diagrams.

Note that all objects labeled "Workflow" in the following sequence diagrams indicate the Workflow subsystem, and they are the only objects not contained within the Authoring subsystem.

DigitizeDocument sequence diagram:


DistributeScanningTask sequence diagram:


EditDigitalDocument sequence diagram:


EditIETM sequence diagram:


GetStatus sequence diagram:


IETM-ize sequence diagram:


IssueAnnotation sequence diagram:


VerifyDigitalDocument sequence diagram:


VerifyIETM sequence diagram:


ViewIETM sequence diagram:

3.5.5 Activity Diagram.