CS406 Software Engineering I

Tellabs Group A

Project Sherlock: SRS Document, Version 1

Team 1 Team 2

Scott Freeman (Team 1 Leader) Tobey Pasheilich (Team 2 Leader)

Eric Laabs Benjamin Foster (Group A Leader)

Eric Bowman Gregory Ebert

Drew Michaels Douglas Clark

William Craver Rajiv Talwar

First Version: September 24, 1998

Last Modified: September 28, 1998
TABLE OF CONTENTS

Introduction 3

System Model 4

Functional Requirements 6

Non-functional Requirements 11

Glossary 13

SECTION 1: INTRODUCTION

The purpose of this document is to specify the requirements for the Sherlock system, using data gathered during video conferencing sessions, meetings, and the requirements document provided by Tellabs as sources of information.

In an enterprise the size of Tellabs, tasks as trivial as finding information about a co-worker or reserving a conference room can become daunting. The Sherlock system is intended to simplify such tasks. Sherlock will give Tellabs personnel the ability to quickly and easily locate information and reserve enterprise resources. This will be accomplished through a graphical, platform-independent, client/server information system.

SECTION 2: SYSTEM MODEL

Sherlock will be based on the client/server model. The client may be any entity with read/search access permissions, or a administrator with add, delete, and modify access permissions. The server will handle requests and store and retrieve information via an LDAP interface.

System Model Diagram (IO=”Input/Output” and DP=”Data Processing”):

The IO Layer of the server is responsible for all connection management, and also stores the state of all current connections. The DP Layer handles all storage, retrieval, and other processing of data within the server. This layer also interfaces with LDAP and other external entities, such as the calendar manager.

Our system model obviously follows the “thin client” paradigm. The client is to be kept as “dumb” as possible, for several reasons. First, this will vastly simplify security management. We feel that any non-necessary functionality in the client simply invites hacking. Also, it will effectively allow anyone with a web browser to have immediate access to Sherlock.

SECTION 3: FUNCTIONAL REQUIREMENTS

Introduction

We have attempted to capture Sherlock’s functionality and formulate it in terms of use case modeling. Our use case diagram consists of two actors and six use cases. The actors are “Information Browser” and “Administrator,” and the use cases are “Search,” “Navigate,” “Notify,” “Modify Data,” “Modify Access,” and “Modify View.”

Use Case Diagram:

The Information Browser actor plays the role of any user who is simply searching for information about some object in the system, such as a person or conference room. The Administrator actor plays the role of anyone who modifies personal or otherwise sensitive information, display format of information, or access permissions to information.

User Use Cases

3.1 Search

The initial function most users will employ is the search option. This option will allow the user to locate specific information about various types of objects. Examples include people, printers, offices, conference rooms, jacks, ports, and computers. After the user specifies what type of object he is looking for, a set of search criteria will be presented to him. This set of criteria will be modifiable by each user according to personal preference. The user will also be able to specify what information about the matching objects will be displayed in the results. This might be useful if a person is only interested in a certain piece of information that could easily be viewed from the results screen, like birth date. The information he chooses to be displayed on the results page, as well as his search criteria, will be stored as his preference, and the next time he searches for an object of this type, his saved settings will be used. After the user determines the criteria by which to search, he will fill in the form with the information he knows, and click search. Within ten seconds, the user will be presented with a screen of results showing all objects that meet the search criteria. Each object listed will refer to a page showing relevant information about that object. The map location of the object will link to the map navigation view where the user will be able to view the physical location of the object. This leads the user to the next use case: the navigation interface to Sherlock.

3.2 Navigate

If the user elects to enter into the map navigation function of Sherlock directly, he will initially be asked to choose which of the Tellabs campuses he wants to view. Mouse-over data should be supported for the campuses themselves. When the user selects a campus, he will be presented with all the buildings at that campus. Once a building is selected, the user will get to a building/floor view and be able to choose a floor. Further zooming will be allowed, and the user will be able to browse the map as desired. All devices in the area will support mouse-over data, and if the user clicks on an object, the object’s information screen will appear with detailed information. This will show the same screen as that which would be shown if the user had found the object using the search use case. He will be able to choose any devices to appear on the map. This might be useful when looking for relatively small objects that could be covered by others.

3.3 Notify

The final functionality available to the user is the ability to send notifications. This functionality is fairly simple from the user’s standpoint. He simply clicks on someone's email address and an email form will appear for him to write a message. Users will also be able to directly reserve a conference room. Likewise, clicking on a pager number will allow the user to send a page. If the pager being accessed is alpha-numeric, the user should be presented with a form similar to the email form to type a message to be sent.

Administrative Use Cases

3.4 Modify Data

The Modify Data use case is the simplest, being integrated directly into the data display. As Sherlock interacts with a user browsing through the database, it will give him the option to change any piece of data it determines he has permission to modify. In the most common case, this will be for a regular employee to modify his own personal data, such as contact information. Access permissions, as administrated in the Security use case, can be set to prohibit any data modification, as with a kiosk user, all the way to a master login which would allow modify access to any piece of data in the system. Information updates are done through the same general interface as the browser, but the option to modify something is presented alongside the data if the user is allowed to do so. Any person choosing to modify data will be changing roles from information viewer to administrator when doing so.

3.5 Modify View/Format

An important feature of Sherlock is the ability to customize it's look and feel. There are two issues at hand: the layout and organization of the GUI components and data display, and the settings of personal preferences for each user. Sherlock will give administrators the ability to customize screen layouts for every screen it presents, with the option of uniquely specifying the layout for each user community. A user community is a template defined within Sherlock that holds screen layouts, default preferences, and restrictions on all users belonging to that group. Screen layouts include search forms and search results screens, which are dynamically generated, though the general look and feel can be customized. Screen layouts also include the data display screens for an object and an object class, such as the layout of a person's page, a printer information screen, a building/facility summary, and the home page for a department. These layouts will be easy to modify, with an intuitive interface that uses the names of object fields to represent their positions on a page. Sherlock preferences allow each user to tailor the Sherlock interface to his or her needs. Depending on the preference restrictions for a user's group, a user could elect to hide certain information fields from view, default search criteria and result set for each object, and which devices should be labeled on maps.

3.6 Modify Security

The Security use case will be used by Sherlock administrators only. Sherlock will allow administrators to define and manage the user groups of the system. They will be able to change the default preferences for new users in a user group, and enforce restrictions on what preferences a user in a group will be allowed to modify. For example, if a user group is defined for all employees of the HR department, Sherlock could prevent them from electing to have their e-mail address hidden from view in normal data display. For each user group, it is possible to customize what types of data they may see at all, and what data they are allowed to change. For example, a kiosk user will have a very restricted range of data he can see, and will not be able to modify anything. Administrators can add, delete, and modify accounts. Because most of the properties of a user are defined by his user group, there will be very little additional data here. Modifications of this type include changing passwords, giving privileges, and setting restrictions. At the lowest level, Sherlock administrators will be able to customize the security level structure itself. Sherlock will provide a security level system that is flexible and intuitive, giving Tellabs the ability to specify permissions for as many user groups as are needed to fully implement the system.

SECTION 4: NON-FUNCTIONAL REQUIREMENTS

Due to the need for remote administration and security, the server will run in a Solaris or Linux environment. The client will be an SSL-capable web browser, and may be Java-enabled.

The server will be customizable, distributable, and scalable. It must be customizable to handle the changing information needs and uses that the customer might have for Sherlock. If the database is distributed on multiple servers, then Sherlock must provide a means of keeping the multiple databases in sync. The server must also be scalable to handle an increased load as the customer grows.

The choice of implementation language for the server will be limited to those which have wide commercial support and do not have a negative effect on the performance of the system-- probably C or C++. The source code for the project will be delivered to Tellabs at the conclusion of the project and this source code must be modifiable.

Sherlock will be able to handle multiple, simultaneous client queries. These queries will be processed in under ten (10) seconds, given a moderate server and network load. Sherlock will also be able to update quickly, under a moderate load, from its parent LDAP server, allowing scheduled update events between the two.

For the directory service, open protocols will be used for client/server communication. The directory solution will be robust and secure, and will support replication and distribution. Tools will be provided for data management.

Sherlock will support a standalone, or connectionless, mode of operation. This will be provided via a CD-ROM distribution. The CD-ROM will include most of the features and functionality available through a network connection, which means that the Sherlock server and its data components will not exceed 650 MB.

SECTION 5: GLOSSARY

CD-ROM Compact Disk-Read Only Memory

DSM Data Store Module

EIM External Interface Module

LDAP Lightweight Directory Access Protocol