application architecture - thedataorg.comthedataorg.com/01processes/matters-architecture.pdf ·...

Matters Database

Application Architecture

Created March 15, 2001 Rainer Schoenrank

Last Updated December 27, 2008

My Matters Application Architecture

The information contained in this document is confidential and proprietary. It may not be used by any person or

organization outside of Brobeck, Phleger & Harrison without express written permission.

Table of Contents

1. INTRODUCTION .................................................................................................................................................... 3 1.1 PURPOSE OF THE DOCUMENT .............................................................................................................................. 3 1.2 SCOPE OF THE DOCUMENT ................................................................................................................................... 3 1.3 ORGANIZATION OF THE DOCUMENT .................................................................................................................... 3

2. SYSTEM OVERVIEW ............................................................................................................................................ 4 2.1 PERSPECTIVE ....................................................................................................................................................... 4 2.2 SCOPE OF MATTERS APPLICATION ...................................................................................................................... 5 2.3 CONTEXT ............................................................................................................................................................. 6 2.4 FUNCTIONS .......................................................................................................................................................... 7

3. PROCESS ARCHITECTURE ................................................................................................................................ 8 3.1 INTRODUCTION .................................................................................................................................................... 8 3.2 MATTERS STRUCTURE CHART ............................................................................................................................. 8 3.3 STRUCTURE CHART COMPONENTS ...................................................................................................................... 8 3.4 APPLICATION SCOPE DIAGRAM (PROCESSING MODEL) ..................................................................................... 10 3.5 PROCESS MODEL COMPONENTS ........................................................................................................................ 10

4. DATA ARCHITECTURE ..................................................................................................................................... 12 4.1 INTRODUCTION .................................................................................................................................................. 12 4.2 CONCEPTUAL DATA MODEL .............................................................................................................................. 12 4.3 DATA MODEL COMPONENTS ............................................................................................................................. 12 4.4 DATA BASE MANAGEMENT SYSTEM ................................................................................................................. 14 4.5 DATA INTERFACES ............................................................................................................................................ 14

5. PHYSICAL ARCHITECTURE ............................................................................................................................ 16 5.1 INTRODUCTION .................................................................................................................................................. 16 5.2 HARDWARE ARCHITECTURE .............................................................................................................................. 16 5.3 APPLICATION SERVICES .................................................................................................................................... 17 5.4 COMMUNICATIONS INTERFACES ........................................................................................................................ 18

6. SYSTEM CONTROLS .......................................................................................................................................... 19 6.1 INTRODUCTION .................................................................................................................................................. 19 6.2 SECURITY .......................................................................................................................................................... 19 6.3 NAMING ............................................................................................................................................................ 20 6.4 SEARCHING ....................................................................................................................................................... 20 6.5 REPORTING ........................................................................................................................................................ 20 6.6 AUDITING .......................................................................................................................................................... 20 6.7 ARCHIVING ........................................................................................................................................................ 21

7. SYSTEM CONSTRAINTS .................................................................................................................................... 22 7.1 DESIGN .............................................................................................................................................................. 22 7.2 PERFORMANCE .................................................................................................................................................. 23

8. IMPLEMENTATION ............................................................................................................................................ 24 8.1 HARDWARE ....................................................................................................................................................... 24 8.2 MIDDLEWARE .................................................................................................................................................... 24 8.3 DEVELOPMENT ENVIRONMENT ......................................................................................................................... 25 8.4 USER INTERFACES ............................................................................................................................................. 25 8.5 SOFTWARE DISTRIBUTION ................................................................................................................................. 25




1. INTRODUCTION

1.1 Purpose of the Document The Application Systems Architecture outlines the context of the Brobeck Matters Proposal process. The systems architecture is the fundamental organization of the system embodied in its components, their relationships to each other and the environment, and the principles guiding the system’s design and evolution. This report describes the results of the policy decisions that created the application framework, the hardware and network environment, the data base concepts, and the organization of the business application environment.

1.2 Scope of the Document The scope of the document is limited to the architectural framework for the Matters application. The details of the application, implementation and functionality are described in various files on the IT file servers. This document outlines the Brobeck Matters systems architecture. This architecture is based on the principles and policies for employing technology to meet the Brobeck business requirements. It serves as a reference for management and other interested parties to make sure that the ongoing decisions for the Mattersapplication is consistent with the underlying architectural frameworks.

1.3 Organization of the Document INTRODUCTION specifies the purpose, scope and organization of this document. SYSTEM OVERVIEW describes the context of the Application Systems Architecture, its functionality, and the organization of the business processes. PROCESS ARCHITECTURE describes the Matters primary business processes and how they work together to support the required functionality. DATA ARCHITECTURE describes the organization and functionality of the application systems that make up the Application Systems Architecture. PHYSICAL ARCHITECTURE describes the network environment, hardware, and system services in which the Application Systems Architecture operates. IMPLEMENTATION STRATEGY describes how the application will be developed and rolled out to its users.




2. SYSTEM OVERVIEW This section provides a contextual view of the application within the current Brobeck environment as well as defining the scope and mission of the Matters application.

2.1 Perspective For years the firm has invested time and money to prepare for “something” – we have converted to SQL-based systems such as CMS and PeopleSoft, moved data from old and varied database formats, and collected new data in SQL databases. What is the “something” for which the firm has been preparing? It is a system in which this information can be delivered to the right hands at the right time; one platform-independent point of access that delivers information to improve the firm’s performance, to help everyone in the firm do their jobs better than they have before. In the form of a new BrobeckNet, we will realize the promise of a single point of access to all firm data that does not depend on desktop applications. This will move the data from where it lives to where it becomes truly useful. In addition, we will enable access for internal users from any Internet-connected computer, and deliver secure extranet functionality to our clients. The implicit benefits include improvement of the firm’s performance, facilitation of all employees’ work, and consistency and integrity of information available to all. One are where significant improvements can be realized is access to client matter-related information. The main users of this type of information are the firm’s timekeepers (attorneys, paraprofessionals) as well as back-office departments (finance, etc.). Creating a streamlined access path for matter-related information is one of the key components of the new BrobeckNet.

2.1.1 Goals and Objectives

The goals and objectives of BrobeckNet 2.0 and the Matters application component are listed below. BrobeckNet 2.0 will:

1. Develop a firm wide view of vital firm information for firm management 2. Develop secure extranet functionality that is easy to build and deploy 3. Provide dynamically built pages to access all information (documents, calendar, images, contacts,

task list, news, billing, etc.) related to any matter. 4. Provide the ability to easily add any form of content regardless of file type or source to one or more

areas of the intranet, extranet and Internet sites. 5. Provide single login across multiple applications 6. Define a “standard” extranet that can be deployed dynamically

The Matters application will:

• Provide an area where anyone can view a list of matters on which he/she has billed time. • Provide the ability to define how many matters display and in what order. • Allow a user to click on a matter in the list and be able to view a page that displays links (or

summaries) to information related to that matter. This information includes, but is not limited to documents, images, calendar, contacts, task list, billing, discussion, news, and status.

• Allow a user to access a client’s web site, link to public documents, view client-related news, and view client-specific information (contacts, address, etc.).

• Provide clients the ability to view a subset of this information for each of their matters. • Include an administration module that will govern access to matters and related information.




2.1.2 Anticipated Benefits This project component will provide an area where anyone can view a list of matters on which he has billed time. The timekeeper can define how many matters display and in what order. Clicking on a matter in the list will return a page that displays links (or summaries) to information related to that matter; i.e., documents, images, calendar, contacts, task list, billing, discussion, news, status. Other items that might appear on this page would be a link to the client’s web site, links to public documents, a stock tracker. Clients would see a subset of this area for each of their matters. An administration module would provide an administrator the ability to grant or deny access to matters to users and groups.

2.2 Scope of Matters Application

The Matters application will provide BrobeckNet users centralized access to the firm’s matter-related information. This information will be stored within a discrete database in which data supplied by various sources will be retained and formatted for use by the application. The application will provide a user views of the following:

• Relationships between employees and matters • Relationships between clients and matters • Data about employees, clients, and matters

The resulting system will be a record-keeping application, with a four-layer structure:

Presentation Layer

Business Application Layer

Data Access

Database

Presentation Layer

• Displays the graphical user interfaces and performs the field edits and validations.

Business Application Layer • Implements the Business Rules, Policies, Transactions, and Workflows of the Business Procedures

Data Access Layer

• Converts business objects (transaction data structures) into the tables and relationships of the data model and vice versa.

Database

• Contains the tables and relationships of the data model. This structure allows a data model design that is independent of the business rules.




2.3 Context The Matters functionality will be delivered as part of the enterprise portal utilizing network security and the web based interfaces to the core business systems. The diagram below illustrates the context of Matters (dotted blue line) within the BrobeckNet 2.0 environment.

(.CFM)

Portal(TBD)

User Navigation

(TBD)

KnowledgeSearch

(TBD)

Business ApplicationLayer

(Cold Fusion)

Brobeck Databases

(SQL Server)

Personalization

(TBD)

User Profiles

FAQ

(TBD)

Q & A

W eb ContentManager

(TBD)

HTML Content

Data Access Layer(SQL Server)

USER

Security

User Validation

(TBD)

Etc.NCM

Directory

Statistics Package

(TBD)

ReportingSubsystem

(TBD)

DMS

(iManage)

Documents

Web Rebuild Project Phase IIProposed Functional Architecture (April 2001)

Key:TBD - Package solution will be recommended/implemented - Core Functionality Packages - Currently in place

Discussions

Discussion

(TBD)




2.4 Functions This section should match the site flow diagrams features for Matters. Locate any client matter by client name, client number, matter name, matter responsible attorney, lawyers who worked on it, industry, matter type. Must be able to search intersections – e.g., Larry Engel and telecommunications. Once a specific matter is located, clicking on the matter name would produce a page with links to the following for each matter:

♦ Client information from Interaction (CRM) ♦ Matter information ♦ Contact list - also email distribution list – can mail to everyone or select individual addressees ♦ All timekeepers on the matter, sorted by most recent and amount of hours billed, with names, titles

and practice group ♦ Internal billing/collections contact ♦ Documents ♦ Images from Introspect (litigation support application by Steelpoint Technologies) ♦ Calendar – docket and client event calendar. Matter event calendar is public calendar in Outlook, the

user can create meetings and send meeting requests. ♦ Status reporting ♦ Billing in process – history of bills sent, Work in progress, payment history ♦ Budget ♦ Link to client web site ♦ Latest news about the client. ♦ Industry news (if required for the matter) ♦ Client-specific policies ♦ Client specific forms ♦ Discussion area ♦ Task list




3. PROCESS ARCHITECTURE

3.1 Introduction This section describes the processes and structures used to access the information about a matter. There are two ways to access a matter, from the My Matters page and from the Matters Search page. The connections between these pages and the matter functionality are shown in the diagram below.

3.2 Matters Structure Chart

My MattersPage

Matter DetailPage

Matters SearchPage

Recent MatterDocuments

Matter CMSBilling

MatterCalendar

MatterBudget

MatterDocument

Images

ClientInformation

InvolvedEmployees

ModifyMatter

Information

...see Site Map

for details

3.3 Structure Chart Components 3.3.1 My Matters Page

The My Matters Page lists the client name, client number, matter number, matter name, matter responsible attorney, matter type and industry of the all the open matters that the logged on person is involved in.

3.3.2 Matters Search Page The Matters Search Page lists the client name, client number, matter number, matter name, matter responsible attorney, matter type and industry of the all the open matters that the logged on person is not barred from seeing.

3.3.3 Matter Detail Page The Matter Detail Page displays the detailed data about the matter and provides links to the related Documents, Calendars, etc.

3.3.4 Documents The Recent Matter Documents Page displays a list of the ten most recent documents that the logged on person is allowed to see.




3.3.5 Calendar The Calendar Page displays the upcoming docket events for the matter and allows the data to be modified.

3.3.6 Billing The Billing Page displays a list of CMS reports that are available. Which reports are in the list depends on the privileges on the person logged on to the application.

3.3.7 Budget The Budget Page displays the details of the matter budget and allows the data to be modified.

3.3.8 Document Images The Recent Matter Documents Page displays a list of the ten most recent documents that logged on person is allowed to see.

3.3.9 Client The Client Page displays the details of the Client for this matter and allows the data to be modified.

3.3.10 Involved Employees The Involved Employees Page displays the list of Brobeck employees that are linked to this matter and the role that they have. The data for the employee involvement may be modified.

3.3.11 Modify Matter Information The Modify Matter Information displays matter detail information and allows the matter data to be modified.




3.4 Application Scope Diagram (Processing Model) The Process Model describes how Matters organizes its processes to deal with its procedures and the outside world. The diagram below shows the interactions (circles) between the outside world (squares) consisting of users and core business systems and the Matters database (drum). Once data has been collected in the database, it is available for reports (paper) to the matter responsible attorney and management.

Matter Data Base

CMS

PeopleSoft

CMS

ClientList

EmployeeList

Matter List

MatterReports

ReportingProcess

DataUpdateProcess

SearchProcess

My MatterSearchProcess

PeopleSoft

PositionList

MatterDocument

List

DMS

My MatterSearch

MatterSearch

ApplicationAdministration

CMS EmployeeMatter

MatterProcessEvents

NCM

3.5 Process Model Components 3.5.1 Position List

The Position List is an interface process that transfers data about positions from the PeopleSoft application to the Matters database.




3.5.2 Client List The Client List is an interface process that transfers data about clients from the CMS Financial application to the Matters database.

3.5.3 Matter List The Matter List is an interface process that transfers data about matters from the Financial Accounting System (CMS) application to the Matters database.

3.5.4 Employee List The Employee List is an interface process that transfers data about employees from the PeopleSoft application to the Matters database.

3.5.5 Employee Matter The Employee Matter is an interface process that transfers data about relationship between employees and matters from the CMS Financial application to the Matters database.

3.5.6 Matter Process Events The Matter Process Events is an interface process that transfers data about the matter events that have been recorded in the NCM and CMS Financial applications to the Matters database.

3.5.7 Search Process The Search Process is a database process that accepts a matterid, userid, and user role, and returns either a list of all matters (matterid is null) or the matter detail data (matterid is not null)

3.5.8 My Matters Search Process The My Matters Search Process is a database process that accepts a matterid, userid, and user role (userid and user role are provided by the security application), and returns either a list of matters (matterid is null) the user is involved in or the matter detail data (matterid is not null)

3.5.9 Matter Document List The Matters Document List is a database process that accepts a matterid, userid, and user role, and returns a list of recent documents for the user and role for that matter.

3.5.10 Reporting Process The Reporting Process is a database process that accepts a userid, and userrole, and returns a list of available reports for that user.

3.5.11 Data Update Process The Data Update Process is a database process that allows the application administrator to modify the data in the Matter database.




4. DATA ARCHITECTURE

4.1 Introduction Now we will look at the Matters processing from a data point of view. We show the data about the matters, clients, employees and tasks and their relationships required to record the progress of a matter through the Brobeck business processes. The intention of the database is to store all of the client, matter, employee and position history (i.e., data is not deleted from the data base).

4.2 Conceptual Data Model When the tables containing the data (rectangle), the relationships (rounded rectangles) between the tables and links (arrows) between the rectangles are diagrammed, a data model is created. The data model for Matters is shown below.

Client Client To Matter

Matter

Employee To MatterEmployeer9

Activity

r10

r2

r3

r4Position Employee To Position

Time Card

tc2

tc4

tc1

tc3

tc5

Client Contact

c2

r1

4.3 Data Model Components 4.3.1 Matter

A Matter is a set of tables that contains all of the data (identification and detailed description) of all the matters (cases) that were worked on by the employees of the business. There are at least three states of a matter, matters being considered for acceptance, accepted matters (matters in progress) and completed matters.




4.3.2 Matter Process Event

A Matter Process Event is a table that collects the measurements of the events (past, present and future) involved in a Matter as the Employees of the firm work on the Matter. The Matter Process Events are the measurement of the workflows in the operational procedures.

4.3.3 Client A Client is a set of tables that contains all of the data (identification and detailed description) of all the legal entities (companies and individuals) that pay for and/or receive the services sold by the business. There are at least three states of a client, clients that have no previous matters (i.e., prospective clients), clients with matters in progress (current clients) and clients with completed matters (previous clients) that pay for the products sold by the business.

4.3.4 Client Matter A Client Matter is a table that contains the data (identification and detailed description) of the role and relationship between a Client and a Matter. The table enables a client to be related to many matters (normal method of operation) and a matter to have many clients involved in it (e.g., class action litigation).

4.3.5 Employee Employee is a set of tables that contains all of the data (identification and detailed description) of all the individuals that provide labor for the business. Employee is a list of the individuals who have been paid for their labor. There are at least four states for an employee, employee candidates, employees that are no longer employed, employees that are currently employed and employees that have retired. These individuals are directors, partners, full-time employees, part-time employees, contractors, temporaries, etc.

4.3.6 Employee Matter An Employee Matter is a table that contains the data (identification and detailed description) of the role and relationship between an Employee and a Matter. The table enables an employee to be related to many matters and a matter to have many employees working on it.

4.3.7 Employee / Position An Employee / Position is a table that contains the data (identification and detailed description) of the relationship between an Employee and a Position.

4.3.8 Position The basis of the company organization is the Position tables that contain the identification and description of all the Positions (or offices) that are used and/or planned by the business. The company organization is the structuring of the positions in the firm into an organizational chart.

4.3.9 Task

A Task is a set of tables that contains all of the data (identification and detailed description) of all the tasks or activities that maybe associated with a matter.




4.4 Data Base Management System Brobeck’s preferred DBMS is Microsoft SQL Server. The implemented data model is organized into three separate sections, each in its own database. The data section (named <MattersData>) contains the only the tables that implement the data model. The data access section (named <MattersAccess>) contains the stored procedures that encapsulate the data access layer interfaces. The reports section (named MattersReports>) contains the report output tables and the stored procedures that populate the report tables each night.

4.5 Data Interfaces The data interfaces between Matters and other applications will attempt to decouple the systems. To achieve this data will be transferred using comma delimited text files with the first row of the file containing the list of field names.

4.5.1 CMS The interface between the Matters database and the CMS Financial database will be a process that extracts data from the CMS database and creates data in the MattersDTS-CMS database. A second process will read the database and update the Matters database.

4.5.2 People Soft The interface between the Matters database and the PeopleSoft database will be a process that extracts data from PeopleSoft and creates data in the MattersDTS-PeopleSoft database. A second process will read the database and update the Matters database.

4.5.3 NCM The interface between the Matters database and the NCM database will be a process that has read access on the NCM database and creates data in the MattersDTS-NCM database. A second process will read the database and update the Matters database.

4.5.4 Web Pages There are more than one interface between the application and various web pages.

4.5.4.1 Matters List Interface When the data access layer object <MatterList> is invoked with parameters <user id> and <user role>, the object returns a collection of matters containing only the matter id and matter name. The collection contains all of the matters the user is allowed to see.

4.5.4.2 My Matters Long Interface When the data access layer object <MyLongMatterList> is invoked with parameters <user id> and <user role>, the object returns a collection of matters containing all the matter description, relationships and details. The collection contains all of the matters the user is related to in the <user role>/Matter relationship table.




4.5.4.3 My Matters Short Interface When the data access layer object <MyShortMatterList> is invoked with parameters <user id> and <user role>, the object returns a collection of matters containing the matter id, the matter name, the client id and the client name. The collection contains all of the matters the user is related to in the <user role>/Matter relationship table.

4.5.4.4 Matter Details Interface When the data access layer object <MatterDetails> is invoked with parameters <matterid>, <user id> and <user role>, the object returns the matter object that has an identifier value of <matterid>.




5. PHYSICAL ARCHITECTURE BROBECK IT will fill in this section. The section is included for completeness of the Table of Contents as an application specification.

5.1 Introduction The Physical Architecture describes the logical connectivity of the system services required to execute the application and deliver information to the application user and data manager.

5.2 Hardware Architecture The Hardware Architecture describes how the Matters application organizes its functionality on the system services and servers. The diagram below shows a four-tier architecture connecting the application user (at the web browser) to the database.

Web Server

BusinessApplication

Server

DataBase

Network

WebBrowser

TransferFile

Systemof RecordProcess

OtherWebApps

DataStructure

Data Access Layer

DatabaseServer




The hardware architecture is based on the separation of the processing architecture into four layers: • The presentation layer is implemented in the browser and Web server • The business application layer is implemented in the Business Application Server • The data access layer and the database layer are implemented in the Data Base Server

The hardware architecture provides the information technology infrastructure for the shared information technology services to support the focused business functionality of the application.

5.2.1 Web Browser

The web browser is the set of browsers on which the application user can see and update the data in the database. Matters will utilize IE4, Netscape 4 and Opera 2 and above browsers.

5.2.2 Network The network connecting the browser to the application services is a TCP/IP base network that passes HTML messages to and from the browser.

5.2.3 Web Server The Web Server is IIS 4 with ASP extensions. BROBECK IT will provide the starting directory name and mapping.

5.2.4 Business Application Server The Business Application Server is Citrix XPS. BROBECK IT will provide the location and access requirements

5.2.5 Data Base Server The Data Base Server is Microsoft SQL Server 2000 with stored procedures used to implement the data access layer. BROBECK IT will provide the server name, location and access requirements.

5.3 Application Services Application Services are part of Brobeck’s system-wide infrastructure and provide services and API’s that can be used by the application to implement some of the required functionality. Desktop services are part of the system wide infrastructure:

• E-mail • Communications • Core Applications (DMS, Legalkey, etc.) • File maintenance • Window Manager Subsystem • Print Spooler Subsystem.




Network/Server Infrastructure The following subsystems exist and are usable by the business applications:

• Security Subsystem (e.g., Access Control Lists) • Reporting Subsystem • Batch Processing Subsystem • Help Subsystem • Data Base Management Subsystem. • Message Passing Subsystem (e.g., COM+, SOAP, etc.)

Data base services are part of the system-wide infrastructure:

• Disaster Recover/Business Continuity • Backup/Restore • Integrity validation • Ad hoc query languages.

5.4 Communications Interfaces BROBECK IT will fill in this section. The section is included for completeness of the Table of Contents as an application specification.

5.4.1 BrobeckNet

5.4.2 Extranet

5.4.3 Internet




6. SYSTEM CONTROLS BROBECK IT will fill in this section. The section is included for completeness of the Table of Contents as an application specification.

6.1 Introduction The system controls that are discussed below are services and application programmer interfaces (APIs) available to the application system so that the application system will conform to the requirements of Brobeck’s computing environment.

6.2 Security When discussing security, there are several different aspects to the problem. There is the problem of

• physical security • operating system security • application system security.

Application system security assumes that problems of physical and operating system security have been addressed and that the application is executing in a trusted environment. Application security has two parts, authentication and authorization. Authentication answers the question:

• Is the object what it says it is (user sign on)? Authorization answers the questions:

• Is the object allowed to use the requested functionality? • Is the object allowed to view the data available through the functionality?

6.2.1 User Authentication

The weakest form of authentication consists of a user identifier and a password. Stronger forms of authentication would require that the user possess a token (e.g., a Smart Card, key, etc) or be authenticated by some biometric (e.g., fingerprint, handprint, iris scan, etc.). Brobeck will be using the token-based SECURID card security system and Matters will require access to an authentication API.

6.2.2 User Authorization There are two models of authorization, hierarchical and hypercube. In the hierarchical model of authorization, a user or process is assigned an authorization level and can access any object or data that has an equal or lower level of authorization. The hierarchical model of authorization is used mainly by the Department of Defense. The hierarchical authorization model does not work in a business environment such as Brobeck where authority is distributed throughout all levels of the organization. In a business environment, data and processing objects are not labeled with authorization levels and the allowed authorization labels would change in time. To solve these problems, a sparse hypercube (a cube with more than 3 dimensions) of all valid authorizations is used. The dimensions of the hypercube are:

• users • functionality • data • locations • time.




Each executing process would call the Authorization System to validate the user’s authorization at the beginning of each processing cycle.

6.3 Naming Everything in the application environment will be named, either by accident or design. The methods for assigning names to objects in the environment are given below.

6.3.1 Directory Names BROBECK will provide a reference to the current corporate standards to be used.

6.3.2 File Names BROBECK will provide a reference to the current corporate standards to be used.

6.3.3 Table Names BROBECK will provide a reference to the current corporate standards to be used.

6.3.4 Attribute Names BROBECK will provide a reference to the current corporate standards to be used.

6.4 Searching The data searching capabilities will be provided either by the DBMS or by third party tools. BROBECK will provide a reference to the current corporate standards to be used.

6.5 Reporting The data reporting capabilities will be provided by third party tools (i.e., the reporting subsystem). A reasonable choice for the reporting subsystem would be Seagate’s Info 7, Brio Technology’s Analysis or Cognos’ OLAP. BROBECK will provide a reference to the current corporate standards to be used.

6.6 Auditing BROBECK will provide a reference to the current corporate standards to be used.

6.6.1 Audit Trails An audit trail records when and who (userid, date, time) made the last modification of the data in an entity occurrence (table row). The data model reserves room for audit trails in each entity or table.




6.6.2 Change Logging A change log is a file containing all data base changes made on a specified data base table. The format of each record in the change log is:

before image after image change date change time.

The before and after images are complete images of the table row that changed. When a table row is added, the before image is empty or blank. When a table row is deleted, the after image is empty or blank. For every row changed in the table, there is one row in the change log. Change logging is not required for the Matters application.

6.6.3 Error Logging The application will not record who, when, where and what errors occurred during normal desktop operation in displaying and updating the matter information.

6.6.4 Access Logging The application will not record when the application was used, what was done and by whom. BROBECK will provide a reference to the current corporate standards to be used.

6.7 Archiving Archived data should remain meaningful, correct and constant in relation to the business. Because any application system, and its use, changes with time, data that relies on an old version of the data model or applications program becomes indecipherable. To prevent this, archiving attempts to preserve information in the database in a form that does not depend on a particular data model or application program to interpret the information. Archived data represents the technology independent repository of the company’s operations, e.g., created a product, sold a product to a new customer, and received payment from an existing customer. Rigorously defined archived data contains no coded information. BROBECK will provide a reference to the current corporate standards to be used.




7. SYSTEM CONSTRAINTS

7.1 Design This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.

7.1.1 Assumptions

The Matters application is a custom built application.

7.1.2 Dependencies The Matters application does not depend on the correct functioning (white box knowledge) of other applications (i.e., it will treat all other applications as black boxes and only check the validity of the inputs provided to Matters).

7.1.3 General Constraints Technical Architecture is defined, i.e. Hardware is available Network exists Network software is installed DBMS software is installed. Development environment exists.

7.1.4 Software Maintainability The Mean Time To Repair (MTTR) the application software measures the maintainability of software once a software error has been found. For commercial software, this time can be as long as a year (i.e., the next release or version). Brobeck will provide a reference to the current corporate standards to be used.

7.1.5 Standards Compliance

Brobeck will provide a reference to the current corporate standards to be used.

7.1.6 Design Criteria

The high level criteria for the design of the application system are that the design be: - understandable - adaptable - effective - accurate - process mature. These criteria can be tested in the follow ways: • understandable - are the design documents coherent and self-contained? • adaptable - can the proposed design be extended (added to without changing the existing design) to

include new subtypes of data, or, better still, does the proposed design handle the additional subtypes in the design?

• effective - is the design reasonable and straightforward? • accurate - does the design satisfy all of the requirements of the application?




• process mature - is the proposed design the general solution to the problem or is it a particular solution? A general solution is independent of the values of the data. A particular solution depends on the knowledge of particular data values. Have all the elements of the proposed design been implemented before? If not, then the process is not mature.

7.2 Performance 7.2.1 Availability

The availability of the application is the period of time when the functionality is available for use (or its inverse, the length of time the application is down). Examples of such statements are: the application hardware and software will have no unscheduled down time or the application will have one hour of unscheduled down time per month. Brobeck will provide a reference to the current corporate standards to be used.

7.2.2 Reliability

The reliability of the application is the period of time between failure events. The Mean Time Between Failure (MTBF) for the equipment measures the reliability of the application hardware. Brobeck will provide a reference to the current corporate standards to be used.

7.2.3 Hardware Maintainability

The Mean Time To Repair (MTTR) the hardware component measures the maintainability of hardware once the component failure has been found. For most hardware components, this time depends on the maintenance agreement negotiated with the equipment supplier. Brobeck will provide a reference to the current corporate standards to be used.

7.2.4 Input-Output Load Factors

This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.

The input output load factors are unknown at this time.

7.2.5 Data Base Load Factors

This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.

7.2.6 Response Factors

The response time for the application will be less than 3 seconds between keyboard lockup to unlock 95% of the time. The application response time assumes that there is no propagation delay in the network.




8. IMPLEMENTATION BROBECK IT will fill in this section. The section is included for completeness of the Table of Contents as an application specification. There is a continuum of implementation choices for the application and the implementation choices are not independent of each other. The choice of DBMS may limit the use of certain development and integration tools, for example if ORACLE is not chosen, the ORACLE FORMS cannot be used for development. There are four points on the implementation continuum that can identified for this project are:

1.• a commercial off the shelf (COTS) application package 2.• an MS Access forms implementation 3.• a custom developed implementation 4.• a web/html implementation.

Each of these implementations would be able to meet the requirements known so far and there are no known systems criteria to narrow the choices.

8.1 Hardware This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.

8.1.1 Directory Structures The Matters Application directory structure begins at \\SFRSMATDEV01\Matters BROBECK IT will provide the location and access requirements for the development directories

8.2 Middleware This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.

8.2.1 Tools This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward. Microsoft SQL Server 2000 Citrix XPS Microsoft Internet Explorer 5.0 or better Microsoft Windows Scripting Host 2.0 or better Microsoft Data Access Components (MDAC) 2.5 or better

8.2.2 Organization This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.




8.3 Development Environment This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.

8.3.1 Tools This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.

8.3.2 Organization This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.

8.4 User Interfaces This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.

8.4.1 System This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.

8.4.2 Network This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.

8.4.3 Application This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.

8.5 Software Distribution This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.

8.5.1 To Clients This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.

8.5.2 To Servers This section is out of scope for this phase of the project. The section is included for completeness of the Table of Contents as an application specification. It will be completed as the project goes forward.