---

1. Introduction

1.1 Purpose

This document describes the detailed functional requirements of eccvs, a version control system. It provides a reference for validation of the final product.

1.2 Document Conventions

The entire document uses the same font. No specific font sizes are used. The font sizes adhere to the default value of the HTML tags.

The heading tags are used to differentiate the sections, sub-sections, etc., The <h2> tag is used for main section headings. The subsections are defined using <h3> tag. The rest of the type of headings are defined by <h4> HTML tag.

The illustrative diagrams are centered with no text behind or beside them.

1.3 Intended Audience and Reading Suggestions

This document is intended for customers, users, developers, testers and students. Customers and users shall read the section-2 of this document to get an overview of the functional requirements.

The developers are suggested to shift their focus to section-3 and section-4 for the details of specific system features. This section can be helpful for the designers to design the system effectively.

1.4 Scope of the Development Project

eccvs is a version control system, intended to perform software configuration management. The user interacts with the system through the sophisticated GUI which makes the version control simpler and easier. This system will enable the user to perform only the basic and much needed functionalities of version control. The main objective of this software is to provide an uncomplicated version control mechanism to the novice user.

1.5 Definitions, Acronyms and Abbreviations

1. eccvs - Easy Concurrent Versions System
2. Repository - a centralized storage location
3. Working copy - the copy (stored locally) retrieved from the repository
4. Check out - the process of retrieving a version from the repository
5. Check in (Commit) - saving the modifications to the repository

1.6 References

1. http://www.cvshome.org/docs/ - "The Cederqvist" by Per Cederqvist et al
2. http://cvsbook.red-bean.com/ - "Open Source Development with CVS, 3rd Edition" by Moshe Bar and Karl Fogel
3. http://www.cvshome.org/ - CVS home page
4. http://developer.gnome.org/projects/gup/hig/ - Gnome Human Interface Guidelines standard

1.7 Overview of Document

The section-2 of this document describes the functional requirements that are intended for the customers and users. Customers can use this section-2 for validating the final product.

The rest of the document can act as a reference for the upcoming software engineering tasks (design, etc.,)

2. Overall Description

2.1 Product Perspective

eccvs is a stand-alone product encompasses the facilities for performing configuration management activities.

The identified users and their interaction with the system are depicted using the above context diagram.

2.2 Product Functions

The major functions provided by the product from user perspective are:

1. Retrieval of specified version.
2. Saving the changes with log information.
3. Provision for creating new versions.
4. Viewing the log information.
5. Retracing the modifications.
6. Establishment of central storage.
7. Importing files into the repository.
8. Viewing the status information.
9. Incorporating the changes to the working copy.

2.3 User Classes and Characteristics

The various user classes who will use this product are:

a) Administrator:

They utilize the product to perform functions such as creation of new repository and importing data into the repository. They will not be able to perform other administration activities such as backup and restore, user management, etc.,

b) Novice programmers / Beginners:

They will use the system to perform the functions listed out in Product Functions section. The novice programmers will expect the system to provide comfortably accessible, user-friendly environment and will rarely modify the default values defined in the system.

c) Expert users:

These users will also be able to use all the functionalities defined for novice user. There can be some provisions like shortcut-keys which make them to use the system efficiently.

d) Others

The other infrequent users of the system are documentation writers, testers and analyst.

The product will not distinguish the users by providing usernames and passwords. This depends on the usual unix/linux security model (user permissions for the resources) and repository settings.

2.4 Operating Environment

Hardware: 128MB RAM, 1GHz Processor
Operating system: Linux
GUI: GNOME, GTK+ Libraries

2.5 Design Constraints

The user interface shall be expected to meet the Gnome Human Interface Guidelines Standard.

2.6 User Documentation

Concise tutorials shall be provided in HTML format with the final product. Other formats of tutorials may be provided if needed.

2.7 Assumptions and Dependencies

Not applicable

2.8 Overview of Data Requirements

The system may take the input either from the user through the GUI or take the data from the default settings of the system.

The system responds to the user by performing the required function with appropriate confirmation or error message. A small set of possible outputs from the system are:

1. log information
2. status information
3. difference between versions

2.9 General Constraints, Assumptions, Dependencies, Guidelines

The initial release of this product shall have the basic functional features (listed as use-cases in section-4). The product may not include the implementation of optional arguments (which are described in each use-case) processing and parsers (which give the meaningful output and error messages). These requirements can be defferred until the subsequent releases of the product.

The product shall only work with Linux operating system comprising Gnome and Gtk+ libraries.

2.10 User view of Product Use

Refer to the use-case diagram presented in the section-4 of this document.

3. External Interface Requirements

3.1 User Interfaces

The GUI for this product is expected to meet the Gnome Human Interface Guidelines Version 2 standard (HIGv2).

Every functionality defined in section-2.2 needs an user interface. Besides these, there can be additional software components which will be identified during the design stage. These user interfaces should meet the above mentioned interface guidelines standard.

3.2 Hardware Interfaces

Not applicable

3.3 Software Interfaces

Not applicable

3.4 Communication Interfaces

Not applicable

4. System Features

The following use-case diagram shows the major services provided by this product.

There are basically two abstract use-cases that are used or extended by the main use-cases. They are:

1. Configuration input

This use-case deals with the configurations (files that are to be maintained by this product) that are required by other use-cases. The configurations can be a single file, multiple files, or a directory name.

2. Retrieval process

The commonality among all the use-cases that retrieve information from the CVS repository is put into this use-case.

The other features (use-cases or major services) are explained in the subsequent sections.

4.1 Create a repository

4.1.1 Brief Description The Create a repository enables the user to create new repository.

4.1.2 Step-by-Step Description 1. User enters the following details a. Repository name b. Path of the repository 2. System creates the repository 1. For remote repository The user will be queried for authentication details (username, password) if not available. 2. For Local repository No authentication needed. 3. System responds with the confirmation message.

4.2 Import files

4.2.1 Brief Description The Import Files enables the user to import new project into the repository.

4.2.2 Step-by-Step Description 1. User inputs the following details Mandatory Optional Path of the repository. Module name. Path of the module Vendor tag Release tag Log message File names to ignore Keyword Substitution mode 2. System imports the specified the into the repository 1. For remote repository The user will be queried for authentication details ( username, password) if not available. 2. For Local repository No authentication needed. 3. System responds with the confirmation message and displays the files imported if available.

4.3 Checkout a module/project

4.3.1 Brief Description The Checkout a module / project enables the user to retrievve a copy of a module / project from the repository.

4.3.2 Step-by-Step Description 1. User inputs the following details Mandatory Optional Path of the repository. Module name. Path to keep the checkedout module. Name for checked out module. Specific revision. Date specification Enable Prune empty directories option. Enable Run in current working directory only option. 2. System gets a copy called a working copy, from the repository to the local machine. 1. For remote repository The user will be queried for authentication details (username, password) if not available. 2. For Local repository No authentication needed. 3. System responds with the confirmation message and displays the successfully checked out files modules if needed.

4.4 Compare working copy against repository

4.4.1 Brief Description The Compare working copy against repository use case enables the user to view the difference between working copy and repository.

4.4.2 Step-by-Step Description 1. User inputs the following details Mandatory Optional File/Files/Working Copy. Date Specification. Specify revision/tag. Enable Run in current working directory only option. Enable Unified output format option. Enable Keyword Substitution mode Option. 2. System performs comparison. 3. System displays the output in the specified format.

4.5 Commit changes

4.5.1 Brief Description The Commit changes use case enables the user to save changes from the working copy to the repository

4.5.2 Step-by-Step Description 1. User inputs the following details Mandatory Optional File/Files/Working Copy. Log message. Specify a revision. Enable Run in current working directory only option. 2. System commits the changes in the working copy to the repository. 3. System responds with the confirmation message and displays the successfully committed files, if needed.

4.6 Update the working copy

4.6.1 Brief Description The Update the working copy enables the user to merge changes from the repository into the working copy.

4.6.2 Step-by-Step Description 1. User inputs the following details Mandatory Optional File/Files/Working Copy. Date Specification. Specify revision/tag. File names to ignore Enable Create missing directories option. Enable Run in current working directory only option. Enable Prune Empty Directories option. Enable Reset sticky tags option. 2. System merges the changes from the working copy to the repository. 3. System displays the updated files along with the status information.

4.7 View the status

4.7.1 Brief Description The View the status use case enables the user to view the status of files in the working copy.

4.7.2 Step-by-Step Description 1. User inputs the following details Mandatory Optional File/Files/Working copy. Tag information. Enable Run in current working directory only option. 2. System obtains the staus information and displays the same.

4.8 View the log information

4.8.1 Brief Description The View the log information use case enables the user to view the log information which is being given by the user during various operations.

4.8.2 Step-by-Step Description 1. User inputs the following details Mandatory Optional File/Files/Working copy. Enable Run in current working directory option. 2. System collects the log information and displays to the user.

4.9 Create new version

4.9.1 Brief Description The Create new version use case enables the user to attach a name to a particular revision/collection of revisions for a project.

4.9.2 Step-by-Step Description 1. User inputs the following details Mandatory Optional Version name. File/Files/Working copy. Date Specification. Enable Create branch option. Enable Run in current working directory option. 2. System creates a new version and displays the confirmation message.

4.10 Add new files

4.10.1 Brief Description The Add New Files use case enables the user to add a new file/files to an existing project.

4.10.2 Step-by-Step Description 1. User inputs the following details Mandatory Optional File/Files. Log message. Use Keyword Substitution mode. 2. System adds the given files to the project 3. System responds with the confirmation message and displays the added files.

4.11 Remove files

4.11.1 Brief Description The Remove files use case enables the user to remove a file/files from a project.

4.11.2 Step-by-Step Description 1. User inputs the file/files details to the system. 2. System removes the file from the project. 3. System responds with the confirmation message and displays the deleted files.

5. Other Non-functional Requirements

5.1 Performance Requirements

Not applicable

5.2 Safety Requirements

The users should not delete the configuration information stored in the working copy. If this information is deleted then it will cause irreversible data loss.

To be in the safer side, the administrators are expected to take periodic backups which will prevent loss of data.

5.3 Security Requirements

The authorization mechanism provided by this product mainly depends on the unix UID based security model. If the user has access to a directory structure that contains the (local) repository then they will be able to perform the listed version control activities.

In case of remote repository, the user access depends on both the repository configuration and the usual unix UID based security model.

5.4 Software Quality Attributes

5.4.1 Usability

The system shall have intuitive user interface which reduces learning curve of the user.

5.4.2 Extensibility

The design of this product shall be extensible so that more sophisticated services can be included in future versions of this software without much reengineering.

5.4.3 Traceability

The functionalities offered by the final product shall be traceable to functional requirements defined in this document.

5.5 Business Rules

Not applicable

5.6 Special User Requirements

Not applicable

6. Other Requirements

Not applicable

---

Change Log for the SRS

• January 3, 2005: Version-2.0 released (A major release)
• January 2, 2005: Added new use-cases and General constraints
• December 28, 2004: Section-4 has been completely rewritten and reorganised using use-cases
• December 17, 2004: The initial version released

---