ENHANCED FILE
MANAGEMENT SYSTEM
Date: 21
stDecember, 2006
Table of Contents
1 Introduction
1.1 Purpose………...3
1.2 Scope………..3
1.3 Overview………3
1.4 Definitions/Abbreviations………..3
2 General Description
2.1 Product perspective………...5
2.2 Product functions………....5
2.3 User characteristics………...5
3
Requirements
3.1
Functional Requirements………6
3.1.1
General Requirements………..7
3.2
Interface requirements
3.2.1
User interface……….12
3.2.2
Software Interface………..13
3.3
Constraints and assumptions………13
3.4
Attributes
3.4.1
Availability………....14
3.4.2
Transferability/conversion……….14
3.4.3
Maintainability………...14
3.4.4
Reliability………...14
3.4.5
Security………..14
SECTION 1
Introduction
1.1 Purpose:
This document describes the software requirements for an Enhanced File Management System. It is intended for the designer, developer, the
maintainer and the user of the system.
1.2 Scope:
This File Management System is designed to enable the better handling of files on the user’s computer intended mainly for personal or office use
.
1.3
Overview:
The rest of the document contains the following: Some important abbreviations and definitions that will be used throughout the document. Section 2 will contain a general product description. Section 3 specifies the functional requirements, performance requirements and the attributes of the product.
1.4
Definitions/Abbreviations:
MANAGEMENT:
When taken in terms of files and folders the term management includes classification, searching, adding, deleting, and categorization.
EFM
:
This is an abbreviation used for the Enhanced File Management System, that is, the product that is being designed
.
FILES/FOLDERS:
A file is a basic unit of storage that enables the computer to distinguish one set of information from another. It is a collection of data that a user can retrieve, change, delete, save or send to an output device such as a printer.
A folder is a container for programs and files. It is used to organize programs and documents on a disk.
LABELS:
Labels will be used for classification purposes on files and folders. Files/folders can have multiple labels. The labels will be in text. Labels can be assigned to both files and folders. There may be sub-labels under a label.
GUI:
GUI is the abbreviation for Graphical User Interface. It is where the user will interact with the program to perform the product functions. The GUI is designed to be easily useable by customer. This will be described more precisely in Section 3.2.1.
LABEL-PATH:
This means the path of a label / file as given by our EFM system. So for example, suppose the top-level label ROOT contains a sub-label PICS which contains a sub-label EID-PICS which contains a picture file called eid1.jpg. The label-path of eid1.jpg would be ROOT \ PICS \ EID-PICS \ eid1.jpg
.
FILE-PATH:
This is the file path as given by the Windows Explorer file management scheme. Referring to the previous example, suppose the file eid1.jpg is stored in MyDocuments under a folder named RandomStuff. Then the file path would be C\MyDocuments\RandomStuff\eid1.jpg
FILEHANDLER:
This is a record that gives the complete information of a file and includes, among other things, the file-path (as defined above) and the file name. For obvious reason, two files with the same file handler are not allowed to exist under the same label (as they are identical).
SECTION 2
General Description
2.1 Product Perspective:
It is a stand–alone product intended for Windows XP environment that the users will be able to install on their computer. Users will interact with the software via a user-friendly GUI(see section). The software will enable the user to create new labels, add files to labels, search for labels, delete labels and other such functionality. No extra software or hardware installations are required.
2.2 Product Functions
The product should be able to create and delete labels. In addition, it should be possible to add or remove files from already existing labels. The user may modify a label as well. If the user modifies/deletes files through the Windows Explorer interface, the product should be able to update its records to catch these changes. The product utilizes a search capability, to search within labels for files and to search for labels themselves
(a) Add label: The product adds a new label for classification purposes.
(b) Add to label: The product adds files and folders to an already existing label. (c) Delete from label: The product removes files from a label, so that they are no
longer associated.
(d) Delete label: The product deletes a label altogether (e) Modify/Rename: A label can be renamed.
(f) Update: If the user renames or deletes a file/folder through Windows explorer interface, the product should be able to update its own records to reflect changes. (g) Search: The search capability can search for labels and also search within labels
for sub-labels and their files as well. The aim is to meet the same functionality of search as offered by the Windows Operating system.
2.3 User Characteristics
1) The customer:
In this case, the customer and the user are the same entity. We assume an adult user who has basic computer knowledge. By that, we mean the user is comfortable with GUIs of difficulty level similar to Microsoft Office Software and understands file and folder creation/deletion/shifting/searching in Windows interface. This level of knowledge should be sufficient for understanding the EFM interface and functionality, with no specialized computer expertise required. The product is meant for a single user system, and will be used in an office type environment or for personal use. The user emphasis is on classifying various documents although our system can handle other types of files as well.
Section 3
Requirements
3.1 Functional Requirements
Before the document begins to explain the Functional Requirements, it needs to discuss some definitions and terms that may be encountered. The user, at the simplest level, requires the system to hold the files inside labels. Furthermore the system is supposed to have a hierarchy of labels, i.e. there can be a label PICTURES which can have multiple files inside it. As an example we will take it to have image1.jpg and image2.jpg. Apart from the ability of files being attributed to labels, the system should also have the ability to attribute labels to other labels. In short, the system is required to cater for sub-labels. For the purpose of our example, we will say, the PICTURES label contains the sub-labels
FRIENDS and FAMILY. Furthermore, the FAMILY label also contains the sub-label
PARENTS. It should be noted that the system would have a “starting point” which would contain inside it all other labels. All the labels would lie over it. This “starting point” label will be referred to as the Root Label in the section that follows. This Root Label would not hold any files on its own (as explained later in the Functional Requirements); rather it will hold all the top-level labels, or as the Functional Requirements will refer to it, “level 1” labels. So if in our example PICTURES was a “level 1” label, then both the
FAMILY and FRIENDS labels are “level 2” labels. Building upon it, it is clear that the
PARENTS label is “level 3” label. Hence each label belongs to a certain “hierarchical level”.
3.1.1 General Requirements
1) Create Label
a) Create Label at a given hierarchical level
Inputs: Label name, Intended File Path. All the inputs will be given through the system’s GUI.
Processing: This case happens when the user tries to create a label at a given level. The user gives the name of the label he wants to create and the intended label path where he wants to create it. The intended label path will also give the system the hierarchical level of the Label i.e. if the user wanted to create the PICTURES label over the ROOT LABEL, the path will be simply the ROOT LABEL and the hierarchical level would simply be of level 1. The system will check that there are no conflicts with the names of labels already present at the label path given and any other restrictions that might be decided at the design phase (e.g. there can be a maximum number of labels at a given path). If the request doesn’t cross any restrictions and create conflicts, the label is created at the label path and the system is updated accordingly. The GUI will also reflect the changes in the system. The system will also note the statistics of the label created like the time and date of creation.
Output: The output will be in the form of a new label created at the intended label path. The output will be visible from the GUI at the intended path of the label
b) Clash of label names while creating Labels at a given hierarchical level
Inputs: Label name, Intended Path name. All the inputs will be given through the system’s GUI.
Processing: This case occurs when the label name given is already present at the intended path name. As an example if we consider that a PICTURES label is already present as a level 1 label, and the user tries to create a new label with the name, PICTURES inside the ROOT LABEL (i.e. at level 1). The system should deny such a procedure. It is yet to be decided what would be the end output of the system in such a case as there can be two possible outcomes: deny the action and create no label; or deny the action and ask the user to suggest a new label name.
Output: The output of the system in this case would be a denial to proceed with the request. The final output given would be decided at the design phase and on client’s confirmation. The error warning and denial of request would be given through the system’s GUI.
2) Add file to a Label
Inputs: File handler (which includes among other things the filename and its path), Label path (which will also include the complete label name). The inputs should be given through either the standard windows explorer shell, or the system GUI.
Processing: This case will happen when the user sends a request of adding a file to an already created label. To proceed with the request, the system needs to know the full path of the label and the unique File handler from the Operating System. These inputs can come from the windows explorer or the system GUI itself. For the input to come from the windows explorer there will be a customized menu for each valid file to be added to a user specified label which should invoke the system for the request. The system will add the file to the label after checking for any conflicts (see the next Functional Requirement) and limitations. The system will also update its state to reflect the changes after a specific file is added to a specific label.
Output: The output of the request would show that the file has been added to the specified label. The GUI will also reflect the changes made to the system after the file has been added to the label.
i. Add a file to a label which already attributed to another label (addendum to a.)
Inputs: Inputs would be the same as given in part a. Another way to inform the system of such a request would be to input the request through the GUI by making the request on the file that has already.
Processing: The processing will be exactly the same as in part a. The only thing that is different in this requirement that if the system recognizes the file as already attributed to another label, then the system might want to do something different with the file. Although the end result of this function should be exactly the same as part a. All the other restrictions and conflicts are going to be checked by the system in the same way as given in part a.
Output: The output to the request will be exactly the same as given in part a.
b) Add a file to a given label which already holds the given file
Inputs: File handler (as also given in part a.), Label path (as also given in part a.). The inputs should be given through either the standard windows explorer shell, or the system GUI.
c) Attempt to add a file to the ROOT LABEL
Inputs: File handler (as also given in part a.), Label path (the ROOT LABEL). The input is going to be through the system GUI.
Processing: This case will happen when the user sends a request from the GUI to add a file to the ROOT LABEL. Basically the system should deny processing any such request as it beats the whole purpose of the client trying to categorize his files. The system should automatically know that such a request has come in because the path of creating label is also input to the system.
Output: The output of the request will be an error presented through the system’s GUI informing the user that the file cannot be added to the root label.
3) Delete Label
a) Attempt to delete an empty label
Inputs: File handler (which includes among other things the filename and its path), Label path (which will also include the complete label name). The inputs should be given through the system GUI.
Processing: If the label is empty, i.e, does not refer to any files, the system will directly remove the label from its records.
Output: The system will display a message informing the user that the label was successfully deleted.
b) Attempt to delete a non-empty label and its contents which are lying directly in the Root Label
Inputs: File handler (which includes among other things the filename and its path), Label path (which will also include the complete label name). The input should be given through system GUI.
Processing: The system asks the user whether he wants to delete all sub-labels and files in the folder. If the user replies in the affirmative, the label, and all sub-labels and files within it are deleted.
Output: The system will display a message informing the user that the label and its contents were successfully deleted.
c) Attempt to delete a non-empty label (but not its contents) lying directly in the Root Label
Inputs: File handler (which includes among other things the filename and its path), Label path (which will also include the complete label name). The input should be given through system GUI.
Processing: The system asks the user whether he wants to delete all sub-labels and files in the folder. If the user replies in the negative, the target label is deleted, and all sub-labels and files within it are shifted down to the lower hierarchical level. So for instance, suppose the PICTURES label is a level 1 label which contains an EIDPICS sub-label (level 2) and several picture files. Upon deletion of the PICTURES label, the EIDPICS sub-label is shifted to level 1. However, since files cannot be placed directly at the level 1, the files are
shifted into the “UNCLASSIFIED” label and the sub-label EIDPICS is now a level 1 label
Output: The system will display a message informing the user that the label was successfully deleted, and its contents moved in the hierarchy.
d) Attempt to delete a non-empty label which is doesn’t belong to the Root Label, and no name clashes occur
Inputs: File handler (which includes among other things the filename and its path), Label path (which will also include the complete label name). The input should be given through system GUI.
Processing: The user is asked through GUI if he wants to delete the contents of the label as well. If he replies yes, the label and its sub-contents are deleted. If he replies no, the files and sub-labels in the label are shifted down to the next level in the hierarchy.
Output: The system will display a message informing the user that the delete operation has been successfully concluded.
i. Conflict of label names or file names during movement of labels after deletion of a label (Addendum to c. and d.)
Inputs: File handler (which includes among other things the filename and its path), Label path (which will also include the complete label name). The input should be given through system GUI.
Processing: Let us suppose that EID2005 and EID-END are both labels at level 2, and EID2005 contains a sub-label also called EID-END at level 3. If EID2005 is deleted without erasing its contents, then shifting sub-label EID-END to level 2 creates a names clash with the other label named EID-END at level 2. Whenever this scenario of a names clash of file or label occurs, the system will either a) prevent the delete outright, or b) prompt the user to change one of the file/label names causing a clash, or c) automatically rename one the file/labels. E.g, in this case, the sub-label END being shifted to level 2 would be renamed as EID-END(1). The final choice of what option to take will only be confirmed after consulting client, and design phase.
Output: The intermediate output would be the same in all three cases, which is the delete will not be allowed to proceed directly. The final option of whether anything is done after this is yet to be confirmed from client.
system will be updated accordingly; i.e. not completely remove the file from the system, rather just remove one label name attributed to the specified file.
Output: The GUI should show a message indicating that the file has been removed from the label, and the GUI system as whole should reflect that.
5) Search
a) Search for an expression which matches a File or a Label held by the system
Input: The user enters a filename or a Label name to search. Here the user may be given an option of whether to search for a file or a label.
Processing: The program will then parse the entire database for any file or label matching the given name.
Output: If found, the file or label will be displayed with its complete hierarchy.
b) Search for a criteria (e.g. date of creation) which matches the attributes of a File or a Label
Input: Here the user will be entering the date of creation or any other attribute associated with the file or label that the program will be able to lookup.
Processing: Same as part (a) except with the attribute now in place of the filename..
Output: Same as part (a).
c) Search does not produce any results
If the program is unable to match filenames and labels with the search query, a message will be generated informing the user about the failure of the search.
6) Update according to File System
a) The file is removed from Windows File System itself.
Input: The input is generated whenever a file is deleted on the Windows system.
Processing: The deleted file will be checked on the system to see if it has been attributed to any label. If not then the system will ignore the file deletion. If the system recognizes that the file is already present in one of the labels, the system will notify the user that the file being deleted is contained in label.
Output: The file deleted, should be removed from all the labels it was contained in.
b) The file is moved to another folder from the Windows File System
Input: The input is generated whenever a file is moved from one folder to another. The input would contain the FILE HANDLER and the new path.
Processing: First the system will try to recognize if either the file is contained in some label or not. If so, the characteristics of the file in
our system would be changed to reflect the new path name. If this file happens to be in multiple labels, the path name has to be changed at all the required labels.
Output: The output of the system would be to come at a state where the GUI reflects the new file path of the file moved in the Windows File System.
c) The file is renamed from the Windows File System
Input: The input will be generated whenever the user tries to change the filename from the Windows File System
Processing: Like in all other cases, the system will first identify if either the file that is renamed is located in same label or not. If so, the file will be renamed inside all the labels to show the new filename.
Output: The output will be in the form of the System GUI showing the most current filename of the file (which has just been renamed in the Windows File System) in all the labels it is contained in.
7) Move Label / File to another Label path
a) Moving Labels / Files to new paths in the System
Input: SourceLabel-path of the file/label to be shifted, and the destination label-path of the file/label to be shifted. This input can only be given through the GUI of the product.
Processing: If shifting a label, the label and the sublabels and files within it are shifted to the destination label-path. Before making this shift of a label, the system checks that the source label-path and the destination label-path exist, and that the destination path is NOT one of the sublabels of the given label-path. If both these conditions are met, then the label and its contents are shifted. If shifting a file, the only condition to check is that the destination label-path exists and the source Labelpath (i.e, the file itself) exists.
Output: If the above-mentioned conditions are met, then the file/label is shifted and a message is displayed to user that the file/label has been successfully shifted. Otherwise, if the destination label-path does not exist, or if the user is trying to shift a label to one of its sub-labels, then an error message is displayed accordingly.
access to product functions and a text area where messages to user will be displayed. This is just one sample scheme of how a simple GUI could be implemented; details are deferred till design/analysis phase.
3.2.2: Software Interfaces
As this is a stand-alone software, the product will not interface with any other products. It may interact indirectly with the operating system. To implement the “update” functionality (see section 2.2 for details), the product will have to be aware when files are deleted/modified through the Windows explorer interface. This will require some level of interaction between the Operating System and the product, although this process need not be visible or directed by user. The mechanism of how this will be implemented is deferred to the design/analysis stage.
3.3: Constraints and Assumptions
1) The product will be operating on a Windows XP operating system.
each label.
3) There will be no network capability built into the product. 4) Each copy of the product will be used by a single user.
5) The product is not intended to be a high-end application, any PC with reasonable specifications (which we define to be 128 MB RAM, and processor Pentium 3 upwards or equivalent) should be able to run the product.
3.4: Attributes
3.4.1: Availability
The software product will be running in the background continuously, which is required to implement the “update” functionality (see section 2.2). The interface will only open when the user opens it, whereupon the user may carry out his desired file management options through the product. The user may choose to turn off the product, in which case it will not provide any functionality till reopened
.
3.4.2: Transferability/conversion
This system is explicitly designed to work in Windows XP, and at this stage, there is no provision for making it transferable/convertible to other platforms.
3.4.3: Maintainability
The file hierarchy and classification should be easy to maintain, view, modify and keep updated (see Section 2.2 for further explanation of these functions) even upon large increase in number of files/folders being managed by the EFM product, to the upper bound mentioned in Section 3.3. For the developer, there should be the option of later adding other features onto the product, such as perhaps network functionality or making it compatible with platforms other than Windows XP.
3.4.4: Reliability
The product should not be subject to crashing even upon invalid operations by user (see Section 3.1 for details), nor should it in any way hinder the Operating System in its management of files or any other operation. In particular, the system
