Registers

Software Requirements Specification

Version: 1.0

19/10/2009

M Aravindh: 200801042

Prepared forICS261—SSAD

WSU-TC CptS 322 Software Requirements Specification Template

Registers

Revision History

Date Description Author Comments19/10/2009 Created the first copy of the

document from templateM. Aravindh First Version of SRS

Document Approval

The following Software Requirements Specification has been accepted and approved by the following:

Signature Printed Name Title Date

Dr. Kamal Karlapalem Dean Academics

Software Requirements Specification Page ii

Registers

Table of Contents

REVISION HISTORY................................................................................................................................................ II

DOCUMENT APPROVAL.........................................................................................................................................II

1. INTRODUCTION.................................................................................................................................................. IV

1.1 PURPOSE................................................................................................................................................................. IV

1.2 SCOPE.................................................................................................................................................................... IV

1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS........................................................................................................... IV

1.4 REFERENCES.............................................................................................................................................................V

1.5 OVERVIEW............................................................................................................................................................... V

2. GENERAL DESCRIPTION................................................................................................................................... V

2.1 PRODUCT PERSPECTIVE.............................................................................................................................................. V

2.2 PRODUCT FUNCTIONS................................................................................................................................................ V

2.3 USER CHARACTERISTICS........................................................................................................................................... VI

2.4 GENERAL CONSTRAINTS............................................................................................................................................VI

2.5 ASSUMPTIONS AND DEPENDENCIES............................................................................................................................. VI

3. SPECIFIC REQUIREMENTS..............................................................................................................................VI

3.1 EXTERNAL INTERFACE REQUIREMENTS........................................................................................................................ VI

3.1.1 User Interfaces............................................................................................................................................ vi3.1.2 Hardware Interfaces................................................................................................................................... vi3.1.3 Software Interfaces.................................................................................................................................... vii3.1.4 Communications Interfaces........................................................................................................................vii3.2.1 Create new register based on user specified parameters.......................................................................... vii3.2.4 Add a column............................................................................................................................................ viii3.2.8 Search for data............................................................................................................................................ ix

3.2.33 LOGIN............................................................................................................................................................. XVI

3.5.1 Performance.............................................................................................................................................. xxi3.5.2 Reliability.................................................................................................................................................. xxi3.5.3 Availability................................................................................................................................................ xxi3.5.4 Security...................................................................................................................................................... xxi3.5.5 Maintainability.......................................................................................................................................... xxi3.5.6 Portability..................................................................................................................................................xxi3.5.6 Software Quality Attributes....................................................................................................................... xxi

3.7 DESIGN CONSTRAINTS............................................................................................................................................ XXI

3.8 LOGICAL DATABASE REQUIREMENTS........................................................................................................................XXII

3.9 OTHER REQUIREMENTS.......................................................................................................................................... XXII

4. CHANGE MANAGEMENT PROCESS..........................................................................................................XXII

A. APPENDICES................................................................................................................................................... XXII

A.1 APPENDIX A........................................................................................................................................................XXII

A.2 APPENDIX B.......................................................................................................................................................XXIII

Software Requirements Specification Page iii

Registers

1. Introduction

1.1 Purpose

The SRS defines the requirements that the completed product should meet. This document is written fora) the Client – To confirm if the clients requirements would be met by the final product.b) the Software Engineer – To convey the details of the product that needs to be designed and to act as a ready reference incase of ambiguity of requirements of the final product.

1.2 Scope

1.2.1 To develop a wrapper around a DBMS, and providing additional functionality of the kind of a spreadsheet, an editor and a reader.

1.2.2 The wrapper will give interface to create a software version of a long book register. The register will be rendered as pages, each being a spreadsheet. It will allow the user to edit and search the data stored in these registers.

1.2.3 Some of the possible applications of the software includea) Creating registers which can be used for anything ranging from inventory management, courier management to attendence in a classroom.b) Enable datasharing across registers which is not possible in conventional long book registers.c) Allow scribling/ drawing using mouse / pen on the register.d) Print the register so as to obtain a hardcopy of the same.

1.3 Definitions, Acronyms, and Abbreviations

Definitions: Register: A software form of long book registers. A software form means, something that behaves and looks like a long book register to a large existent. This meaning applies to all uses of the word in this document except when it is used as “long book registers”.Pages: A register as defined above consists of content divided into logical / non logical groups called pages as is the case with long book registers.Column: A field in register. Eg: A students courier register has a column for signature of the student.Script: A piece of code written by a user, that follows a documentation specified syntax to perform special tasks using the functinality available in the software product.Tag: A single word made of characters that describes the entity that it is associated with.

Note: A tag is associated with some entity.User: A person who operates with the product directly.

Acronyms:NoneAbbreviations:DBMS: Database Management System

Software Requirements Specification Page iv

Registers

SRS: System Requirements Specification

1.4 References

I) TCP/IP suite of protocols specification document.Document Title: Transmission Control ProtocolDocument number RFC793.Date of publishing: September 1981Publishing Organization:

Information Sciences Institute University of Southern California 4676 Admiralty Way Marina del Rey, California 90291

1.5 Overview

This SRS gives overview of the software to be developed and then details the requirements it should meet. Each functional requirement is detailed by specifying its input, output, processing and error handling.It also lists the non functional requirements.The SRS is divided into 4 sections. The first of which ends with this paragraph. Section 2 gives a gereral broad picture which is further detailed in section 3. But section 2 is a precursor to section 3 and must be reffered before section 3 is referred.Section 4 defines the process by which changes can be made to this document.The appendix details the discussion between the client and the author and lists additional data. Any requirement specified/ not specified in appendix A and appendix B do not bind the final product in any way. Appendix C describes scripts in greater detail. Appendix D describes constraints in greater detail and appendix E describes supported data types in greater detail.

2. General Description

2.1 Product Perspective

This product is meant to be a easy replacement to conventional long book registers. It can be used by security personal or even by students in creating a task management register. The replacement would be easy as it resembles a long book register in terms of usage and look.

2.2 Product Functions

a) Creating registers which can be used for anything ranging from inventory management, courier management to attendence in a classroom.b) Enable datasharing across registers which is not possible in conventional long book registers.c) Allow scribling/ drawing using mouse / pen on the register.d) Print the register so as to obtain a hardcopy of the same.

Software Requirements Specification Page v

Registers

2.3 User Characteristics

The intended users of the system are of two typesRegister Users: These group of users will simpy populate the register by adding records. They would also search, edit or delete recods from the register. Such users need to know,How to use long book registers, that were being used before the system was installed.How to use basic input output methods of the hardware on which the system is installed.

Register Designer: These users will create new registers based on the long book registers allready in use or based on a hypothetical long book register that might have been used if no such system as the this be existant. Such users need different levels of computer proficiency depending on what kind of register the user wants to create and what functionality it should have. The user may be as novice as the one described above or be as proficient as a professional software engineer. The more the expertise the more is the functionality that the register designed will have.

2.4 General Constraints

None

2.5 Assumptions and Dependencies

The assumptions are:mysql is installed on the host system.Qt is installed on the host systemThe host machine has a minimum of 256 MB of RAMThe host machine has a minimum free disk space of 64 MBThe host machine has a processor which delivers a minimum clock rate of 1.7 Ghz.

3. Specific Requirements

3.1 External Interface Requirements

3.1.1 User Interfaces

1. The user interface should be similar to that of a simple editor. The spreadsheet should occupy majority screen area ( > 70%) on the main window which should not get over cluttured with toolbars and additional controls.2. Keyboard shotcuts should be provided so that all operations can be performed using keyboard alone so that a trained user can perform the same operation using keyboard in time not more that 5 * time taken for doing the same operation using mouse and keyboard combined.

3.1.2 Hardware Interfaces

No direct interface with any hardware applicance. Interface via operating system to a keyboard, a mouse, a pen input and network. The pen input behaves the same way as a mouse. The network is interfaced via network card.

Software Requirements Specification Page vi

Registers

3.1.3 Software Interfaces

Interface with mysql DBMS. This interface is to be implemented using any API binding for mysql. Mysql will act as the database for storing data that would be stored in the registers.

3.1.4 Communications Interfaces

Follows TCP/IP suite of protocols for networked communication. Please refer: http://www.faqs.org/rfcs/rfc793.html (TCP/IP suite of protocols specification document)

3.2 Functional RequirementsLegend:High priority RED (Must have)Medium priority BLUE (Should have)Low priority GREEN (Try to have)Very low priority BLACK (Will be part of future versions; not current version)“None” specified in the Output section implies: {Output: Render the register the way it was before the action was performed.}

3.2.1 Create new register based on user specified parameters

To create a new registerInputs: Name of the register, Columns in the register, data types corresponding to these fields and constraints on the domain to which values in each column belong.For details on constraints to be supported please refer appendix D.For details on data types to be supported please refer appendix E.Processing: Should create a new empty register that can be refered using the user specified name and make it available to entering data. If referencial integrity is specified for any set of columns a check should be performed to see if the corresponding register does exist and that those columns of that register store values of the same type as the corresponding columns of the new register.Outputs: Display the spreadsheet along with the column headings displayed on top of each column in the grid.Error Handling: If the condition of referential integrity is not satisfied then the user should change the details for the operation to complete.If the register could not be created because of error during interaction with DBMS, the error should be dislayed as is using a message box and the operation be canceled.

3.2.2 Open existing registerTo open an existing register whoes name is user specified.Input: Name of register to be openedProcessing: Read corresponding register, execute script corresponding to event OPEN REGISTER, if any, and render the register on the screen.Output: The register opened to the part of the page that was active before closing the register. Also the output, if any, corresponding to the script execution.Error Handling: Any errors while interacting with the DBMS should be reported as is using a message box and the operation be cancelled.Any errors that occured during script execution are displayed as is using a message box. The

Software Requirements Specification Page vii

Registers

script execution would be aborted if necessary.

3.2.3 Close registerTo close an open registerInput: NoneProcessing: Store the current state of the register. The state is defined by the currently active record. Close the register and execute the script corresponding to the CLOSE REGISTER event, if any. Append the register name to the history of recently used registers.Output: The register disappears from the screen. The recently used registers shows this registers name at the top. Output, if any, corresponding to the execution of the script.Error handling: Any error that occcured while accessing the DBMS would be shown as is using a dialog box. The operation would complete inspite of the error.

3.2.4 Add a column

To add a field to the grid in the currently active registerInput: Column name, data type, default value if any, constraints on the data to be stored in the column.Processing: Check if default value satisfies the constraints. Update existing records with default value else show them as blank if default value is not available. Render the output elements.. Execute script corresponding to event ADD COLUMNOutput: The currently active page with the extra field added and default values filled (in case it is provided). Also output corresponding to script corresponding to ADD COLUMN is delivered.Error Handling: Errors during interface with the DBMS would be reported as is and the transaction is cancelled. If the constraint is not satisfied by the default value the user would need to specify another default value or opt to fill nulls.

3.2.5 Delete a ColumnTo delete an already existing column from the register.Input: The column to be deleted.Processing: Delete the column after checking if that column does exist. Look at different columns that refer to this column and update them accordingly based on the rules specified at the time of creation of those columns.Output: The currently active page with the column no longer visible.Error Handling: Any errors raised by the DBMS will be reported as is and the operation will be aborted.

3.2.6 Insert new recordTo insert a new record using user entered data.Input: Data for the new record. That is data of all the required fields.Processing: Insert the record into the database. Update the user interface to reflect the same. Warp the record into a new page if the last page is full. A page is said to be full if it contains 30 records. Update the date of creation to current date if new page is created. Update date of modification of active page to current date. Execute scripts associated with event INSERT NEW RECORD

Software Requirements Specification Page viii

Registers

Output: The last page of the register where the new record is appended. Also any output corresponding to the script would be displayed.Error Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted. Any errors during the execution of the scripts will also be reported and the script will be terminated.

3.2.7 Delete existing recordTo delete selected record.Input: The set of selected records.Processing: Delete the selected record from the database and display the output. Shift records one page less whereever needed to make sure that all pages except the last are full. Delete last page if it is left empty. Update date of modification of the page from which the record was deleted to the current date unless the page has been deleted. Execute scripts associated with the event DELETE RECORDOutput: The page to which the record belongs with the record no longer visible. Also any output corresponding to the script would be displayed.Error Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted. Any errors during the execution of the scripts will also be reported and the script will be terminated.

3.2.8 Search for data

To search for string data in the register.Input: The string data to be searched for.Processing: Search for the data in the register and display the output. A match is said to have occured when a part of an entry matches the text being searched for. All searches are case insensitive and partial matches will be treated as matches. The entire document will be searched. Number of matches will be counted.Output: The corresponding matches should be displayed in a new unnamed register and user should be moved to the first record in this register. The number of matches is reported in a message box.Error Handling: None

3.2.9 Pagewise navigationTo move to next page/previous page/page based on page number/first page/last page based on user selection.Input: The page number to which the user wishes to jump to incase he/she chooses to open a random page. In other cases the input is just the option the user has selected.Processing: Display the output. Execute any scripts associated with navigation to pages.Output: The page the user desires to view. Also any output corresponding to the script would be displayed.Error Handling: If the page is not existing or could not be loaded then the error message “Could no move to requested page <page no>” would be displayed. Any errors during the execution of the scripts will also be reported and the script will be terminated.

Software Requirements Specification Page ix

Registers

3.2.10 Delete PageTo delete the currently active page.Input: The number of the currently active page.Processing: Delete the currently active page and move to the previous page (or the next page if the previous page does not exist (or show a blank new page if neither exist)). Update the page numbers of the pages that follow the current one.Output: The page the user desires to view.Error Handling: If the page is not existing or could not be loaded then the error message “Could no move to requested page <page no>” would be displayed.

3.2.11 Set HeadingTo insert a heading into the currently active page.Input: The number of the currently active page and the heading to be inserted.Processing: Appending the heading to the currently active page. Update table of contents if necessary.Output: The top few records of the currently active page with the heading visible.Error Handling: Any errors reported by mysql DBMS would be reported as is and the operation would be aborted.

3.2.11 Edit headingTo edit the heading of the currently active page.Input: The number of the currently active page and the new heading.Processing: Updating the heading stored in the database. Update table of contents if necessary.Output: The top few records of the currently active page with the heading visible.Error Handling: Any errors reported by mysql DBMS would be reported as is and the operation would be aborted.3.2.11 Set Header/FooterTo insert a header/footer into the register.Input: The contents of the header/footer. The content can include page number.Processing: Save the header/footer in the database. Read page numbers for each page if needed.Output: Render the header/footer and give the page number wherever indicated.Error Handling: Any errors reported by mysql DBMS would be reported as is and the operation would be aborted.

3.2.11 Edit Header/FooterTo edit header/footer of the register.Input: The new contents of the header/footer. The content can include page number.Processing: Save the new header/footer in the database. Read page numbers for each page if needed.Output: Render the header/footer and give the page number wherever indicated.Error Handling: Any errors reported by mysql DBMS would be reported as is and the operation would be aborted.

Software Requirements Specification Page x

Registers

3.2.12 Tag selected recordsTo tag records selected by user using user-defined tags for the currently active register.Input: Tag to be used for tagging along with the list of selected records.Processing: Store the tagging details – The tag and the list of tagged records into the database. Output: Render the currently active page as it was after the records were selected. The selected records still remain selected.Error Handling: Any errors reported by mysql DBMS would be reported as is and the operation would be aborted.

3.2.12 Create new tagCreate a new tag for the currently active register.Input: The string which is to be the label of the tag.Processing: Insert new tag into the database.Output: NoneError Handling: Any errors reported by mysql DBMS would be reported as is and the operation would be aborted.

3.2.13 Delete existing tagDelete existing tag from the list of user defined tags for the currently active register.Input: The tag to be removed from the register.Processing: Remove the tag and update the untag records tagged with this tag. Note: Only this tag should be removed while untagging. A record might be tagged with more that one tag in which case all other tags must be retained.Output: NoneError Handling: Any errors reported by mysql DBMS would be reported as is and the operation would be aborted.3.2.14 Edit existing tagChange the label of an predefined tag of the currently active register.Input: The new label of the tag and the tag which should be changed.Processing: Change the label of the tag and reflect the update in all records tagged with the original tag.Output: NoneError Handling: Any errors reported by mysql DBMS would be reported as is and the operation would be aborted.

3.2.15 Untag selected recordsUndo the operation of tagging a set of records with a set of tags.Input: The list of selected records and the list of tags whoes association with this tag should be nullified.Processing: Remove the association between the tag and the records which are specified in input. Note that all the specified tags will be removed from all the specified records.Output: Render the currently active page as it was after the records were selected. The selected records still remain selected.Error Handling: Any errors reported by mysql DBMS would be reported as is and the operation

Software Requirements Specification Page xi

Registers

would be aborted.

3.2.16 Filter by tagTo view the set of records tagged with a particular tag.Input: Predefined tag.Processing: Create a new register with the set of records that are tagged with the tag specified in input.Output: Display the new unnamed register containing all the records tagged with a particular tag. In the new unnamed register these records are tagged with this tag. Hence the new register would have the tag defined in it.Error Handling: Any errors reported by mysql DBMS would be reported as is and the operation would be aborted.

3.2.17 Fuzzy selection of recordsTo select records using fuzzy select tool.Input: The path trased by the mouse/pen.Processing: Indentify the set of records that the pen/mouse has passed by and select those.Output: As the path is trased the records which have been trased should be highlighted to indicate their selection.Error Handling: None

3.2.18 Generate table of contentsTo generate a table of contents based on page headings.Input: None except the currently active register.Processing: Read the set of heading given if any and note the page numbers corresponding to these pages. Renumber the pages so as to accomodate the table of contents page.Output: A new page in associated with the register giving the table of contents. This page is the new first page. The page number in this table of contents is based on the new page numbering and should reflect on changes made to the register after its generation as well.Error Handling: None

3.2.19 Filter based on date of creation/modification of page.Filter pages based on date of creation / modification.Input: Date range.Processing: Create a new unnamed register whoes date of creation / modification lies in the range inclusive of the extremities.Output: Render the new unnamed register. Each page in the new register has the date of modification and creation the same as that of the corresponding page in the original register.Error Handling: Any errors reported by the DBMS will be rendered as is and the operation will be aborted.

3.2.20 Import/Export registersImport data from other registers and export selected data into other registers/ new register. The other register may be on local machine or on network. During import all the records from the

Software Requirements Specification Page xii

Registers

other register will be appended to currently active register. If no register is active a new register which is a copy of the original register will be created. During export the selected records will be appended into the other register, or into a new register based on user selection.Input: For import: Source register For export: Destination register, set of selected records.Processing:For input: Append all records from source register into current register. If no register is currently active then create a new unnamed register which is a copy of the source register.For output: Append the selected records to the destination register. If no destination register is specified, create a new register on the local machine which contains all the selected records and the tags associated with them.Output:For import: The last page of the register containing some of the newly appended recordsFor export: The destination register should be rendered even if it be on network.Error Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted.

3.2.21 Create new scriptWrite a script to be executed when an event(s) occurs.List of event(s) isa) Open registerb) Close registerc) Insert new record Note: Also invoked when new record is inserted during import/exportd) Edit recorde) Delete record Note: Also invoked when record is deleted during delete page operation.f) Navigate to a pageFor more details on scripts please see appendix CInput: The code of the script, the event(s) when the script is supposed to be executed.Processing: Save the script and associate it with the concerned event(s) and register.Output: NoneError Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted.

3.2.22 Edit existing scriptEdit the code / event corresponding to an existing script.Input: The script to be edited, the changed script and the new event(s) it should be associated with.Processing: Update the details associated with the event.Output: NoneError Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted.

3.2.23 Delete existing scriptDelete an existing script

Software Requirements Specification Page xiii

Registers

Input: The script to be deletedProcessing: Delete the script.Output: NoneError Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted.

3.2.24 Add a constraintAdd a constraint to be enforced in the currently active register.Input: The constraint to be enforced.Processing: Save the constraint as part of the registers meta data and enforce it on the already existing records.Output: NoneError Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted.

3.2.25 Delete a constraintRemove an existing constraint.Input: The constaint to be removed.Processing: Remove the constaint from the meta data associated with the currently active register.Output: NoneError Handing: Any errors reported by the DBMS will be reported as is and the operation will be aborted.

3.2.26 Edit a constaintEdit an existing constraintInput: The modified constaint and the constraint that is to be modified.Processing: Update the metadata associated with the register and check if the existing records satisfy the new constraint.Output: NoneError Handing: Any errors reported by the DBMS will be reported as is and the operation will be aborted.

3.2.27 Autofill optionsFill the current cursur location with current date.Fill the serial number automatically using autoincrement.Input: Current cursor position in case of date autofill.Processing: Get current date or new serial number based on the autofill to be performed. Render the output.Output: The current date filled (if needed). Serial number generated and filled based when new record is going to be inserted.Error Handing: Any errors reported by the DBMS will be reported as is and the operation will be aborted.

Software Requirements Specification Page xiv

Registers

3.2.28 Draw/Erase using mouse/penProvide pen and eraser tool to draw on the spreadsheet and erase drawn contents..Input: The tool which is active, the path traversed by the mouse/pen.Processing: Render the output.Output: In case the eraser tool is active, any drawn element in its path would be completly erased. Elements include lines or random curves that were drawn in one stroke (in one mouse press and release cycle). In case of the pen tool the path trased would be maked by a line which is 2mm thick. This should be rendered when ever that part of the document is viewed.Error Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted. 3.2.29 PrintPrint different pages of the register. Only plain printing supported in version 1.0 of the product.Input: The set of pages to be printed. The content to be printed includes the records the header, footer, page heading and things drawn on the page.Processing: NoneOutput: The pages should be printed.Error Handling: Check if any printer is connected. If none are connected then the operation is aborted. If printing fails then the operation is aborted and further prints are cancelled.

3.2.30 Zoom In/ Zoom OutProvide a magnified/minimized view of the page in the register.Input: Percentage(x) zoom of final viewProcessing: Recalculation of display parameters like dimensions, coordinates.Output: The page should be rendered at x% of its original size. Each element on the page should be scalled proportionally.Error Handling: None

3.2.31 Intelligent tagging evaluatorEvaluate tags as they are placed and prompt the user is the tag placed on a record is not at all relevant to its contents.Input: The record being tagged, the tag being placed.Processing: Evaluate if it is legible to tag the concerned record with that tag.Output: A message prompt saying thtat the tag is not legible if it is the case. Give the user an option of retaining the tag or removing it.Error Handling: None

3.2.32 Undo and redoTo undo an operation or redo an undone operationInput: NoneProcessing: Undo / redo the concerned operation.Output: The same as the operation having been performed manually.Error Handling: None

Software Requirements Specification Page xv

Registers

3.2.33 Login

To convey to the system the designation of the user who is currently using the system so that he/she can avail his/her previledges.Input: Username, passwordProcessing: Verify if the username, password matches one entry in the database of registered users.Output: If a match is found then a welcome message is displayed.If no match is found then the user is asked to retry.Error Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted.

3.2.34 LogoutTo convey to the system that the designation of the user should be reverted to anonymus so that the previledges be disabled.Input: NoneProcessing: Reset the system to what it would be under an anonymus user.Output: A message indicating success value of the operation.Error Handling: If the current state of the system cannot be reset to that under an anonymus user then the operation is aborted and the user remains logged in.

3.2.35 Register UserTo create an account so that the user can login or logout.Input: Username, password, password verification, email, phone number.Processing: Check if password matches password verification. Add the new users details to the list of users of the system.Output: Notify the user of the success status of registration process.Error Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted.

3.2.35 Edit ProfileTo change the password, phone no, email of an existing user.Input: New password, new password verification , new email, new phone no.Processing: Retrieve the details of the user currently logged in and update his details in the database.Output: A dialog displaying the edited profile.Error Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted. If the user currently logged in is anonymus then the operation should be aborted.

3.2.36 Set permissionsBy default all newly created registers have read, write permissions only to the creator. To grant permissions to other users the owner needs to set permissions.Input: User for whom permissions are to be set, and whether the user can read or write or both on this register.Processing: Update the metadata to bind the permissions with the user details.

Software Requirements Specification Page xvi

Registers

Output: NoneError Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted.

3.2.37 Advanced SearchTo do case sensitive search, and search for exact word matches.Input: Case sensitivity enable/disable option, exacti word match enable disable option, string to be searched for.Processing: Peform the search.Output: Render a new register which contains all that records that had a match in any one of their fields.Error Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted.

3.2.38 Register templatesTo allow a user to save the meta data of a register as a template so that one can create a new register from the template.Input: Meta data of currently active register.Processing: Save the meta data so that it can be read later.Output: NoneError Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted.

3.2.39 Create new register from template.Create a new register which has the meta data stored in the template.Input: Name of new register, template to create it fromProcessing: Duplication of meta data.Output: The empty register with a plain page 1 rendered on the screen.Error Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted.

3.2.40 Rename RegisterRename an register (which may be unnamed temporary register).Input: New name of the register.Processing: Change the meta data to reflect on the change of name.Output: The register with the new name.Error Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted.

3.2.41 Edit Existing RecordsEdit an existing record.Input: The new data to be stored at the currently active record.Processing: Change the data stored for that record after checking if constraints are satisfied.Output: The register with the changed record visible to the user.

Software Requirements Specification Page xvii

Registers

Error Handling: Any errors reported by the DBMS will be reported as is and the operation will be aborted. If constraints are not satisfied then the operation is aborted.

3.3 Use Cases

3.3.1 Use Case Diagram for complete system

3.3.2 Use Case Descriptions

3.2.2.1 Use Case Description #1

Use Case ID: 1Use Case Name: Create new register

Created By: M. Aravindh Last Updated By: M. AravindhDate Created: 21st October 2009 Date Last Updated: 21st October 2009

Actors: Register UserDescription: The user creates a new register after specifying the different columns it

should have, the data types of each column and constraints on these columns.

Software Requirements Specification Page xviii

Registers

Preconditions: 1. User is logged in.Postconditions: 1. New register with a single blank page is created with the specified

columns.Normal Flow: 1.0 Create a register

1. User enters name of the new register and specifies number of columns.

2. The user fills in the heading of each column, the type of data that would be stored in that column (selecting it from the possible list).

3. User specifies constraints on records.3.1 User adds new constraints.Chooses the type of constraint. If user specifies password, unique, required or not null then the metadata is updated to store the constraint details.ElseUser specifies the set of columns in current register and maps each one of them into other columns in other registers.User specifies the primary key in the mapping.3.2 Edit created constraintUser chooses the constraint to edit. User specifies the type of the new constraint. If user specifies password, unique, required or not null then the metadata is update to store the constraint details.ElseUser specifies the set of columns in current register and maps each one to a new set of columns in another register.User specifies primary key in mapping.3.3. Delete created constraint.User selects the constraint to be deleted and it is removed from the meta data when confirmed by the user.4. Create new page with page number 1. No of records = 0. Render the

register with this page as active.Alternative Flows: 1.1 Don't specify constraints (after step 2)

1. Create the register without any constraints.Exceptions:1.1 Register meta data could not be conveyes to databases.

1.1 Abort the transaction and revert back to the state before the transaction was started.

3.2.2.2 Use Case Description #2

Use Case ID: 2Use Case Name: Filter by Tag

Created By: M. Aravindh Last Updated By: M. AravindhDate Created: 21st October 2009 Date Last Updated: 21st October 2009

Actors: Register UserDescription: To filter the records based on predefined tag.

Software Requirements Specification Page xix

Registers

Preconditions: 2. User is logged in and has read permissions on the register he is filtering.

Postconditions: 2. A new unnamed register containing the set of records which have the selected tag associated with it.

Normal Flow: 1.0 Filter by tag1. User specifies the tag(s) by which the records should be filtered.2. All the records that are tagged with this tag are copied into a new

register which is unnamed and temporary.3. The tags(s) associated with these records in the original register

are defined in the new register.4. The User is shown the first page in the newly generated register.

Alternative Flows: NoneExceptions:1.1 No record was tagged with the selected tag(s)

1.1 Abort the transaction and revert to the state before the transaction was started.

3.5 Non-Functional Requirements

3.5.1 Performance

Time taken for execution of a operation <= 5 * 5th root of number of records stored in the database.

3.5.2 Reliability

None. The software comes with no warranty or guarranty. For more details please read section 3.5.6

3.5.3 Availability

None

3.5.4 Security

Will prevent direct or indirect unauthorized manipulation of register records by implementing user authentication subsystem. This is not guaranteed in the event of a bypass of user authentication system.

3.5.5 Maintainability

The code should be easy to modify so that the source code can be changed by anybody who has intermediate knowledge of computer science. For more details please read section 3.5.6.

3.5.6 Portability

None

3.5.6 Software Quality Attributes

The product will be licensed under the GPL. Therefore anyone may add to it or edit it.The source code can be changed by anyone, as long as that modified code is released under the GPL. For more information on the GPL please visit

Software Requirements Specification Page xx

Registers

http://www.gnu.org/copyleft/gpl.html

3.7 Design Constraints

None

3.8 Logical Database Requirements

A database is used. Infact an entire DBMS will be used.The data formats to be supported areinteger, double, string, datetime, date, text, password, boolean, imageFor details on the data formats that would be supported please refer appendix E.

3.9 Other Requirements

None

4. Change Management ProcessTo make a change to this document a mail should be sent to the first signatory in the document approval section. Following an agreement to this mail a change should be made and sign off should be redone. This change should be noted in the change history section and the mail be copied into the appendix B.

A. Appendices

A.1 Appendix A

Discussion between the client and the author.

IGroup66Team Member: M.AravindhProject Name: CYOP3 - Long books in software

First DiscussionSubject: Initial brief-up on project expectations.

Some features were added to the initial set of features for consideration.These include :-1. Turing of pages2. Provision of header and footer which should be placed on all pages of a register.3. Pen Input - To be used for drawing, selection, signatures (We sign on long booksexample:: while collecting courier we sign).4. Tagging - One should be able to select a record in the register and tag it

Software Requirements Specification Page xxi

Registers

usinguser defined tags.5. Date Index - Each page should have date of creation and modification and oneshould be able to filter based on the date of modification or creation6. Content Index - Filtering based on the tags.7. Shrink - One should be able to shrink the page to say 1/4th.8. Print utility - Printing of pages in sequence, or in shrinked format. Enableprint reordering so that on folding the page we form a small booklet with pages inorder 1, 2, 3 ...9. Search - Searching of records in the register. Content based filtering.10. Drawing - One should be able to draw using mouse or pen input and save the drawing.11. Smart evaluation while tagging - When one tags a record then the utility willtry to estimate the legibility of the tag.12. Data sharing - Send pages or filter results to other registers when needed.

IISubject: Re: Validation of SRS of Registers Project CYOP3

From: "Kamal Karlapalem" <kamal@iiit.ac.in>Date: Wed, October 21, 2009 7:28 pm

To: "Aravindh Mahendran" <aravindh.mug08@students.iiit.ac.in>Cc: kamal@iiit.ac.in

Looks good.

kamal.> Respected Sir,> I have attached the SRS of CYOP 3 project on Register. I would like to> know of your approval/disapproval with respect to this SRS. In case of> disapproval please indicate the same in the .doc file attached below using> highlighted text.>> Thanking you,> Yours truly,> M.Aravindh> Ug2, CSE> IIIT H

A.2 Appendix B

Mail supporting the change log, indicating approval of the client for each change.

Software Requirements Specification Page xxii

Registers

[No changes yet]

A.3 Appendix C

Detailed description of scripts refered to in section3.2

The product will provide a C and python binding for accessing the following functions

1. Insert/Edit/Delete record

2. Goto page

3. Create new register

Apart from this the script can use any additional functionality that these languages independently provide.

A.4 Appendix D

Description on constraints to be supported.

The constraints to be supported area) Password field – The data stored is a string but is rendered as a series of '*'b) Unique field – No two records can have the same value for this column.c) Required field – No record can have this field as emptyd) Referencial Integrity – A set of columns map to another set of columns in another register. In this case the data stored in each record under these columns should map to an allready existing single record in the other register.

In case of referencial Integrity the user should also specify what should be done when a update is done at the element being referred to.

For enforcing referencial intergrity the user should input the mapping between the existing set of columns and another set of columns present in another register.

A.5 Appendix E

Data types to be supported are

a) integer (Range 2,147,483,648 to 2,147,483,647)−b) double (Range -0.1797693134862315807937289714053023E+309 to 0.1797693134862315807937289714053023E+309)c) string (length range 0 to 500 characters)d) datetime (datetime range supported by the version of mysql installed on host-system)e) date (date range supported by the version of mysql installed on host system)f) text (length range 0 to 1000 characters)g) password (Same as string except that it will be rendered in “*”)

Software Requirements Specification Page xxiii

Registers

h) boolean (Can store 0 or 1 and will be rendered using a checkbox on the spreadsheet)i) image (To render an image on a cell in the spreadsheet).

Software Requirements Specification Page xxiv