Contents

<IN THIS TEMPLATE YOU WILL FIND TEXT BOUNDED BY THE <> SYMBOLS. THIS TEXT APPEARS IN ITALICS AND IS INTENDED TO GUIDE YOU THROUGH THE TEMPLATE AND PROVIDE EXPLANATIONS REGARDING THE DIFFERENT SECTIONS IN THIS DOCUMENT. THERE ARE TWO TYPES OF COMMENTS IN THIS DOCUMENT. THESE COMMENTS THAT ARE IN BLACK ARE INTENDED SPECIFICALLY FOR THAT COURSE. THESE COMMENTS THAT ARE IN BLUE ARE MORE GENERAL AND APPLY TO ANY SRS. PLEASE, MAKE SURE TO DELETE ALL OF THE COMMENTS BEFORE SUBMITTING THE DOCUMENT. ....................................................II THE EXPLANATIONS PROVIDED BELOW, DO NOT COVER ALL OF THE MATERIAL, BUT MERELY, THE GENERAL NATURE OF THE INFORMATION YOU WOULD USUALLY FIND IN SRS DOCUMENTS. IT IS BASED ON THE IEEE REQUIREMENTS AND WAS ADAPTED SPECIFICALLY FOR THE NEEDS OF SOFTWARE ENGINEERING 3K04/3M04 COURSES. MOST OF THE SECTIONS IN THIS TEMPLATE ARE REQUIRED SECTIONS, I.E. YOU MUST INCLUDE THEM IN YOUR VERSION OF THE DOCUMENT. FAILURE TO DO SO WILL RESULT IN MARKS DEDUCTIONS. OPTIONAL SECTIONS WILL BE EXPLICITLY MARKED AS OPTIONAL. IF YOU HAVE ANY QUESTIONS REGARDING THIS DOCUMENT PLEASE REFER TO THE MINITHERMOSTAT SRS EXAMPLE ON THE COURSE WEB-SITE.>.........................................................................................................II INTRODUCTION.........................................................................................................................................................1 1.1 PURPOSE OF DOCUMENT ...................................................................................................................................1 1.2 SCOPE...........................................................................................................................................................1 1.3 INTENDED AUDIENCE AND DOCUMENT OVERVIEW..................................................................................................2 1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS.....................................................................................................3 1.5 DOCUMENT CONVENTIONS.................................................................................................................................5 1.6 REFERENCES AND ACKNOWLEDGMENTS................................................................................................................5 OVERALL DESCRIPTION........................................................................................................................................6 1.7 PRODUCT PERSPECTIVE.....................................................................................................................................6 1.8 PRODUCT FUNCTIONALITY ................................................................................................................................7 1.9 USERS AND CHARACTERISTICS ............................................................................................................................8 1.10 OPERATING ENVIRONMENT..............................................................................................................................9 1.11 DESIGN AND IMPLEMENTATION CONSTRAINTS....................................................................................................10 1.12 USER DOCUMENTATION.................................................................................................................................10 1.13 ASSUMPTIONS AND DEPENDENCIES..................................................................................................................10 SPECIFIC REQUIREMENTS..................................................................................................................................11 1.14 EXTERNAL INTERFACE REQUIREMENTS.............................................................................................................11 1.15 FUNCTIONAL REQUIREMENTS..........................................................................................................................13 1.16 BEHAVIOUR REQUIREMENTS...........................................................................................................................13 OTHER NON-FUNCTIONAL REQUIREMENTS................................................................................................14 1.17 PERFORMANCE REQUIREMENTS.......................................................................................................................14 1.18 SAFETY AND SECURITY REQUIREMENTS............................................................................................................14 1.19 SOFTWARE QUALITY ATTRIBUTES ...................................................................................................................15

System requirements Specification for .Contact Management System (CMS)

Page ii

OTHER REQUIREMENTS......................................................................................................................................15

Revisions
Version Draft Type and Number Primary Author(s) Full Name Description of Version Information about the revision. This table does not need to be filled in whenever a document is touched, only when the version is being upgraded. Date Completed 00/00/00

<In this template you will find text bounded by the <> symbols. This text appears in italics and is intended to guide you through the template and provide explanations regarding the different sections in this document. There are two types of comments in this document. These comments that are in black are intended specifically for that course. These comments that are in blue are more general and apply to any SRS. Please, make sure to delete all of the comments before submitting the document. The explanations provided below, do not cover all of the material, but merely, the general nature of the information you would usually find in SRS documents. It is based on the IEEE requirements and was adapted specifically for the needs of Software Engineering 3K04/3M04 courses. Most of the sections in this template are required sections, i.e. you must include them in your version of the document. Failure to do so will result in marks deductions. Optional sections will be explicitly marked as optional. If you have any questions regarding this document please refer to the MiniThermostat SRS example on the course web-site.>

Software Requirements Specification for a Contact Management System (CMS)

Page 1

Introduction
PalFusion IT is a new company that offers ICT (Information Communication Technology) services in areas such as, consultancy and repairs to its clients. Been a new company they agreed a Contact Management System (CMS) will be the solution in order to maintain an upto-date Client record and keep track of all Clients Events. The illustrations and scenarios of the system will focus on the repair department of PalFusion IT.

1.1 Purpose of Document

The purpose of this document is to illustrate the requirements specification for the Contact Management System to be developed. The details of this document are based on the analysis of the requirements gathered from PalFusion IT. The final artifact will meet the requirements stated in this document. This document will operate as a statement of understanding between the intended audience that is, the customer (PalFusion IT) and the Software Developer (Sorie Kabba).

1.2 Scope
The project is basically to update the current manual system to a computerised Contact Management System.The Contact Management System (CMS) will be use as the main Client database for PalFusion IT. The CMS will be a Client/Server Windows based system, using components that provide integrated solutions to effectively manage information about PalFusion IT Clients and the Events of these Clients. The information is stored on a database located on the CMS server, when the CMS Client connects to the CMS server the data is synchronised.

Better quality of information Process data efficiently, decreasing time, cost and improved productivity. Creates motivated workforce, by providing flexibility and enhance communication Respond to changes without incurring extra costs

Software Requirements Specification for a Contact Management System (CMS)

Page 2

The scope of this system is as follows: Agreed closing date for the project is 21 April 2010 Creates database on CMS Server Creates users for the database with different permissions Add, edit, and delete category for Client Add, edit, and delete category for Event Add Client account linked with Event(s) Add Event Linked with Client account(s) Modify and client contact details and events Verify and Update client contact details and events Set Clients to categories Set Events to categories Maintain history of clients events Easily access of all transactions with clients User follows set standard and procedures to maintain data integrity

There is an awareness of individual existing as customer they will be treated as business customers.

There are fields which have been ignored ie DOB, and the business does not have dealings with underage individual

1.3 Intended Audience and Document Overview

The document contains a summarized product perspective and a brief description of the intended software functionalities. The Characteristics of the intended users are discussed and any assumptions, constraints or dependencies are listed. The various requirements are categorized as functional requirements, performance requirements, non- functional requirements, or design constraints. Functional requirements are further categorised in terms of registration, operation and reporting. Non-functional requirements are further categorised in terms of security, maintainability, and scalability.

The intended audience is: Software Developer: This is the person(s) that will develop the system. Customer/User: This is the main stakeholder in the project. The customer sponsors the project, and is the primary beneficiary of the product. The requirements in this document will be reviewed at various stages in the development of this system; this is done to ensure that the requirements are adhered to. In the case where there is any changes t the requirements, they must be documented.

Software Requirements Specification for a Contact Management System (CMS)

Page 3

Overall Description: ? Overall Description will describe major components of the system, interconnection ? Specific Requirements will describe the functions of actors, their role in the system and constraints.

The next chapter, the Overall Description section, of this document gives an overview of the functionality of the product. It describes the informal requirements and is used to establish a context for the technical requirements specification in the next chapter. The third chapter, Requirements Specification section, of this document is written primarily for the developers and describe in technical terms the details of the functionality of the product. Both sections of the document describe the same software product in its entirety, but are intended for different audiences and thus use different language.
Overall Description: This chapter of the document This will involve the main components of the ICMS system, the interconnections within the system, and external interfaces with the operating environment. This section explains the system more clearly to the customer or users. Specific Requirements: This section shows technically the components of the ICMS system, and its functions. This section explains the system more clearly to the system developers.

1.4 Definitions, Acronyms and Abbreviations

<Define all the terms necessary to properly interpret the SRS, including acronyms and abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire organization, and just include terms specific to a single project in each SRS. TO DO: Please provide a list of all abbreviations and acronyms used in this document sorted in alphabetical order.> Admin Administrator SRS CMS Client Event GUI CMS Server

CMS Client

Managing Director (MD) Store Manager (SM) Head of Repairs (HOR)

Software Requirements Specification for a Contact Management System (CMS)

Page 4

RAM

The following are the list of conventions and acronyms used in this document and the project as well: Administrator: A user with full privileges to the system. In the context of this project, this individual will also be referred to as the Admin. User: Other user accounts created for the system. This can further be divided into two: Read only: Users with read only access to the System. Read and Write: Users that can read, write and modify data in the system. Client: In the context of this system, a customer to PalFusion IT is a client. Event: entities. overview Interface: A point of communication between different medium. Use Case: A broad level diagram of the project showing a basic SQL: Structured Query Language; used to retrieve information from a database SQL 2005 Server: The database server used to store and share data. User Interface Layer: The section of the assignment referring to what the user interacts with directly. Data Storage Layer: The section of the assignment referring to where all data is recorded Data flow diagram (DFD): It shows the flow of data between the

TCP/IP(Transmission Control Protocol/Internet Protocol.

Software Requirements Specification for a Contact Management System (CMS)

Page 5

1.5 Document Conventions

This document follows the Staffordshire University requirements for formatting. Use Arial font size12 throughout the document for text. Use italics for comments. Document texts should be 1.5 line spaced. The Section and Subsection titles the IEEE template standard is followed. For referencing, the Harvard Referencing format is used.

1.6 References and Acknowledgments

The Institute of Electrical and Electronics Engineers, Inc., IEEE Guide to Software Requirements Specifications, IEEE Standard 830-1998, New York, The Staffordshire Ethical form

Software Requirements Specification for a Contact Management System (CMS)

Page 6

Overall Description
1.7 Product Perspective
PalFusion IT is a new company and they do not have a system to manage their clients, therefore they required a CMS system. Even though there is no system, a manual system is assumed as the current system and the CMS as the required system. The design goal for the required system is a self-contained system that achieves the functionalities and requirements and outline in this document. The system is designed as a desktop based CMS that provides users with details of Clients and Events from the CMS database. This is accessed via the local network or the internet using TCP/IP(Transmission Control Protocol/Internet Protocol) to connect to the server. The system will be use for the recording, processing and, reporting on PalFusion IT Clients. The diagram (Figure 1) below is a Level 0 Dataflow Diagram (DFD), it shows the sources and the recipients of data and resources, to and from the CMS system. It also shows the system boundary; differentiating internal and external entities of the system. The details is based on the Repair department of PalFusion IT.

Figure 1: Illustrating the flow of data and resources in the CMS

Software Requirements Specification for a Contact Management System (CMS)

Page 7

1.8 Product Functionality

The CMS will create user account, granting users different level of permission to access the database. The user will be able to add, edit, or delete a Client or Event and their categories depending on users permission. The Client or Event created can only be assigned to only one category at a given time, this category of the Client or Event can change as and when necessary. Each Event can be set to one status and one type at a give time, this can change as and when necessary. The system will also allow event to be linked to one or many client, and a client can also be linked to one or many events. The information in the CMS database can be easily accessed and reports generated. The diagram (Figure 2) below shows how these functions are related and the flow of data.

Figure 2: DFD Showing how the functions are related

Software Requirements Specification for a Contact Management System (CMS)

Page 8

1.9 Users and Characteristics

The characteristics of the users will be explained using a scenario based on the repair department of PalFusion IT. The users will be prioritised based on frequency of use of the system in their designated job roles. All proposed users of the system have got experience with some sort of contact management system As illustrated in Page 6, Figure 1, The system have seven proposed users, these are listed below: Managing Director (MD) Store Manager (SM) Head of Repairs (HOR) Supervisor Technician Admin (Administrator) The Client Main Users The Admin and the Technician are identified as the two main users of the system, they use the system more frequently and they are the only users within the system boundary. The Admin: The Admin uses both the CMS Client and CMS Server on a daily basis. The Admin is responsible for the management of information on the system. The Admin is the only user with authority to add, modify, or delete a contact, event or category., The Admin will be responsible for entering Clients details, creating events, and categories. The admin initiate and close an Event. The technician: The Technician works with the CMS Client side of the system on a daily basis. After the Admin have created the Events the Technician picks up any job that has been assigned to a related category, for example Workshop Job category. And when the job is finished, it is then assigned to a category that is managed by the Admin, so that the client can be informed. Other Users: There is an awareness that an individual hold more than one job roles at the same time. The supervisor: uses the CMS client side of the system on a weekly basis to generate reports. The Head of repairs: The HOR uses the CMS client side of the system on a monthly basis to generate reports. Store Manager: The SM uses the CMS Client side of the system on a monthly basis to generate reports Managing Director: The MD uses the CMS client side of the system on a quarterly basis to generate reports. The MD is the main stakeholder of the project. Client: The Client contact details and linked Event is stored on the system, the Client receives invoice from the system.

Software Requirements Specification for a Contact Management System (CMS)

Page 9

1.10 Operating Environment

<Describe the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist. In this part, make sure to include a simple diagram that shows the major components of the overall system, subsystem interconnections, and external interface TO DO: As stated above, in at least one paragraph, describe the environment your system will have to operate in. Make sure to include the minimum platform requirements for your system. > The system will operate in a windows based operating system environment. Versions of Operating System are 2000, XP, and Vista. It can also coexists with Microsoft SQL Server 2005, .. The diagram(Figure 3) shows the various ways that the CMS clients (Administrator, Local Network User, and Internet User) interacts with the system.

Figure 3: Shows interaction between CMS Server an CMS Clients

Software Requirements Specification for a Contact Management System (CMS)

Page 10

1.11 Design and Implementation Constraints

<Describe any items or issues that will limit the options available to the developers. These might include: hardware limitations (timing requirements, memory requirements); interfaces to other applications; specific technologies, tools, and databases to be used; parallel operations; language requirements; communications protocols; security considerations; design conventions or programming standards (for example, if the customers organization will be responsible for maintaining the delivered software). TO DO: In this section you need to consider all of the information you gathered so far, analyze it and correctly identify at least 5 constraints.> The system will be developed using Visual Basic for the interface and coding, and SQL 2005 server for the database. The system will use TCP/IP to share data stored on the database server with other local and remote users. The database and users for the database must only be created at the server side of the system. The user interface to be design is in English language only, there will be login facility to enable the security function. The date for implementation is 21 April 2010.

1.12 User Documentation

<List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software. Identify any known user documentation delivery formats or standards. TO DO: You will not actually develop any user-manuals, but you need to describe what kind of manuals and what kind of help is needed for the software you will be developing. One paragraph should be sufficient for this section.>
A brief tutorial will be provided with the system. Showing users how to user the system, it will have examples of how users can use the system depending on their job roles. It will have screenshots to help user understand easier and better.

1.13 Assumptions and Dependencies

<List any assumed factors (as opposed to known facts) that could affect the requirements stated in the SRS. These could include third-party or commercial components that you plan to use, issues around the development or operating environment, or constraints. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors, such as software components that you intend to reuse from another project. TO DO: Provide a short list of some major assumptions that might significantly affect your design. For example, you can assume that your client will have 1, 2 or at most 50 Automated Banking Machines. Every number has a significant effect on the design of your system. > All clients will come to the office to deliver item(s) to be repaired An individual Client as a business client The system will be installed on a maximum of 10 computers

Software Requirements Specification for a Contact Management System (CMS)

Page 11

Please note: An agreement was reached that the Chat facility will not be part of the system, instead social network websites will be use as an interaction point between PalFusion IT and its Clients. Therefore the name of the system has changed from ConChat to Contacts Management System (CMS).

Specific Requirements
1.14 External Interface Requirements

1.14.1 User Interfaces

<Describe the logical characteristics of each interface between the software product and the users. This may include sample screen images, any GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g., Cancel) that will appear on every screen, error message display standards, and so on. Define the software components for which a user interface is needed. TO DO: The least you can do for this section is to describe in words the different User Interfaces and the different screens that will be available to the user. Those who will be able to provide optional Graphical User Interface screenshots, will be rewarded by extra marks.>

1.14.2 Hardware Interfaces

<Describe the logical and physical characteristics of each interface between the software product and the hardware components of the system. This may include the supported device types, the nature of the data and control interactions between the software and the hardware. You are not required to specify what protocols you will be using to communicate with the hardware, but it will be usually included in this part as well. TO DO: Please provide a short description of the different hardware interfaces. If you will be using some special libraries to communicate with your software mention them here. In case you have more than one hardware interface divide this section into subsections.>

Server and Client Side: Operating System: Windows 2000,ME, XP, Vista Processor: Pentium 3 (equivalent) or higher Hard Disk: 10GB or higher RAM: 256 Mb or higher

Software Requirements Specification for a Contact Management System (CMS)

Page 12

Note: Check installation requirement for SQL Server 2005 1.14.3 Software Interfaces
<Describe the connections between this product and other specific software components (name and version), including databases, operating systems (Windows? Linux? Etc), tools, libraries, and integrated commercial components. Identify the data items or messages coming into the system and going out and describe the purpose of each. Describe the services needed and the nature of communications. Identify data that will be shared across software components. If the data sharing mechanism must be implemented in a specific way (for example, use of a global data area in a multitasking operating system), specify this as an implementation constraint. TO DO: The previous part illustrates some of the information you would usually include in this part of the SRS document. To make things simpler, you are only required to describe the specific interface with the operating system.>

Database: SQL Server. Application: ASP (Active Server Pages) Web Server: IIS (Internet Information Services (IIS) is a powerful Web server that provides a highly reliable, manageable, and scalable Web application infrastructure) 1.14.4 Communications Interfaces
<Describe the requirements associated with any communications functions required by this product, including e-mail, web browser, network server communications protocols, electronic forms, and so on. Define any pertinent message formatting. Identify any communication standards that will be used, such as FTP or HTTP. Specify any communication security or encryption issues, data transfer rates, and synchronization mechanisms. TO DO: Do not go into too much detail, but provide 1-2 paragraphs were you will outline the major communication standards. For example, if you decide to use encryption there is no need to specify the exact encryption standards, but rather, specify the fact that the data will be encrypted and name what standards you consider using. > For the information stored on the CMS Server to be available to the CMS clients, local users will use a network server communication protocol (TCP/IP), for users trying to access the system remotely, an internet connection is required. The system will also provide interface for users to enter clients details and events details.

Software Requirements Specification for a Contact Management System (CMS)

Page 13

1.15 Functional Requirements

< Functional requirements capture the intended behavior of the system. This behavior may be
expressed as services, tasks or functions the system is required to perform. This section is the direct continuation of section 2.2 where you have specified the general functional requirements. Here, you should list in detail the different product functions with specific explanations regarding every function. TO DO: Break the functional requirements to several functional areas and divide this section into subsections accordingly. Provide a detailed list of all product operations related to these functional areas.

1.16 Behaviour Requirements

1.16.1 Use Case View
<A use case defines a goal-oriented set of interactions between external actors and the system under consideration. Since sometimes we will not be able to specify completely the behaviour of the system by just State Diagrams, we use use-cases to complete what we have already started in section 3.3.1. TO DO: Provide a use case diagram which will encapsulate the entire system and all possible actors. Do not include detailed use case descriptions (these will be needed when you will be working on the Test Plan), but make sure to include a short description of what every use-case is, who are the actors in your diagram. For more information please refer to your UML guide and the MiniThermostat SRS example file.>

Software Requirements Specification for a Contact Management System (CMS)

Page 14

Other Non-functional Requirements

1.17 Performance Requirements

<If there are performance requirements for the product under various circumstances, state them here and explain their rationale, to help the developers understand the intent and make suitable design choices. Specify the timing relationships for real time systems. Make such requirements as specific as possible. You may need to state performance requirements for individual functional requirements or features. TODO: Provide at least 5 different performance requirements based on the information you collected from the client. For example you can say 1. Any transaction will not take more than 10 seconds, etc> The system can be run in Local Area Networks (D-link, Intel etc). This software works between client and server. Server should have right configuration.

The required system that will be developed

1.18 Safety and Security Requirements

<Specify those requirements that are concerned with possible loss, damage, or harm that could result from the use of the product. Define any safeguards or actions that must be taken, as well as actions that must be prevented. Refer to any external policies or regulations that state safety issues that affect the products design or use. Define any safety certifications that must be satisfied. Specify any requirements regarding security or privacy issues surrounding use of the product or protection of the data used or created by the product. Define any user identity authentication requirements. TODO: Provide at least 3 different safety requirements based on your interview with the client or, on your ABM related research, and again you need to be creative here. Describe briefly what level of security is expected from this product by your client and provide a bulleted (or numbered) list of the major security requirements.>

Security Requirements
Only server Administrator can create database Only server Administrator can create user accounts for database Each user will be assigned a username and password to access the System Security will be provided by access level control Read only users cannot add, modify, or delete record. The database will be backup at regular intervals users should take breaks to avoid Repetitive Strain Injuries (RSI)

Software Requirements Specification for a Contact Management System (CMS)

Page 15

1.19 Software Quality Attributes

<Specify any additional quality characteristics for the product that will be important to either the customers or the developers. Some to consider are: adaptability, availability, correctness, flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability. Write these to be specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for various attributes, such as ease of use over ease of learning. TODO: Use subsections (e.g., 4.3.1 Reliability, 4.3.2 Portability, etc) provide requirements related to the different software quality attributes. Base the information you include in these subsections on the material you have learned in the class. Make sure, that you do not just write This software shall be maintainable Indicate how you plan to achieve it, & etcDo not forget to include such attributes as the design for change. Please note that you need to include at least 2 quality attributes, but it is the mere minimum and it will not receive the full marks.>

1.19.1 Reliability:
With reliability, it provides different levels of access to only users with correct user credentials.

1.19.2 Flexibility:
The flexibility of the system can be identified with its ease of use, and intuitive processes.

1.19.3 Portability:
The system is a desktop-based application that can be used in any setup that meets the software requirements.

Other Requirements
<This section is Optional. Define any other requirements not covered elsewhere in the SRS. This might include database requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.>

Software Requirements Specification for a Contact Management System (CMS)

Page 16

Appendix A Data Dictionary

<Data dictionary is used to track all the different variables, states and functional requirements that you described in your document. Make sure to include the complete list of all constants, state variables (and their possible states), inputs and outputs in a table. In the table, include the description of these items as well as all related operations and requirements.>

Software Requirements Specification for a Contact Management System (CMS)

Page 17

Appendix B - Group Log

<Please include here all the minutes from your group meetings, your group activities, and any other relevant information that will assist the Teaching Assistant to determine the effort put forth to produce this document>

The information stored on the CMS Server database, can only be accessed by CMS Clients that are connected on the same network or via the internet to the CMS Server. The availability of upto-date information to users regardless of their location will improve quality of service by allowing quicker response to queries.

The system will also enhance data integrity by providing different user access permissions.

Software Requirements Specification for a Contact Management System (CMS) To improve Management and business transactions, users will need to maintain set standards and

Page 18

procedures in dealing with Clients and Events details. The idea is to compile Client data from various categories so that you can get better understanding and profiling. This will create good data interaction and, enable appropriate service to clients within the context of their relationships. Also analysing this data can help in making strategic marketing and business decisions.

In the future, there is a possibility to include functions such as, financial calculations, stock control, and, assets inventory. The probability of the above exclusions are all thought of but will not be part of the current system because of time and available resources.