SRS Social Networking SRS

Faculty of Engineering University of Ruhuna Galle Sri Lanka

Software Requirements Specification (SRS) IMPLEMENTATION OF SOCIAL NETWORK FOR INDUSTRIAL RELATIONS PROJECT

ALUMNI Version 1.0

ALUMNI SRS

Table of Contents 1 Introduction........................................................................................................4 1.1 Purpose...................................................................................................................................................4 1.2 Summary................................................................................................................................................4 1.3 Company (Client) Overview..................................................................................................................4 1.4 Project Overview...................................................................................................................................5 1.5 Definitions, Acronyms and Terminology..............................................................................................5 1.6 References (Optional)............................................................................................................................6

2 Project Scope and Impact.................................................................................7 2.1 Scope Inclusions....................................................................................................................................7 2.2 Scope Exclusions...................................................................................................................................8 2.3 Impact on Other Systems.......................................................................................................................9 2.3.1 Affected by Other Systems...............................................................................................................9 2.3.2 Effects on other systems..................................................................................................................9

3 Functional Requirements................................................................................10 3.1 System Administration........................................................................................................................10 3.1.1 Create a new blog account............................................................................................................10 3.1.2 Check Identity................................................................................................................................10 3.1.3 Create a new personal wiki...........................................................................................................10

4 Non-functional Requirements........................................................................11 4.1 Performance and Load Requirements.................................................................................................11 4.2 Compatibility Requirements................................................................................................................11 4.3 External Interface Requirements.........................................................................................................11 4.3.1 User Interfaces..............................................................................................................................12 4.3.2 Hardware Interfaces.....................................................................................................................12 4.3.3 Software Interfaces........................................................................................................................12 4.3.4 Communications Interfaces...........................................................................................................12 4.4 Security and Authentication Requirements.........................................................................................12 4.4.1 Data Storage Security...................................................................................................................12 4.4.2 Data Communication Security......................................................................................................12 4.4.3 Authentication...............................................................................................................................12 4.5 Quality Assurance Requirements.........................................................................................................13 4.5.1 QA Test Scope...............................................................................................................................13 4.5.2 QA Environment ...........................................................................................................................13 4.5.3 QA Data ........................................................................................................................................13 4.6 Development Requirements.................................................................................................................13 4.6.1 Development Environment............................................................................................................13 4.6.2 Development Data ........................................................................................................................13 4.6.3 Coding Standards..........................................................................................................................13 4.6.4 Implementation Packaging Requirements.....................................................................................14 4.7 Deployment Requirements..................................................................................................................14 4.7.1 Deployment Requirements.............................................................................................................14 4.7.2 Documentation Requirements.......................................................................................................14

Faculty of Engineering, University of Ruhuna

10/13/2013

ALUMNI SRS

4.8 Internationalization Requirements.......................................................................................................14 4.9 System Activity Log Requirements.....................................................................................................14 4.10 Special Documentation Requirements...........................................................................................15 4.11 Applicable Standards.........................................................................................................................15 4.12 Licensing Requirements....................................................................................................................15 4.13 Online User Documentation and Help System Requirements...........................................................15 4.14 Purchased Components......................................................................................................................16 4.15 Technical Requirements....................................................................................................................16 4.16 Supportability Requirements.............................................................................................................16 4.17 Reliability Requirements...................................................................................................................16 4.18 Usability Requirements......................................................................................................................16

5 Special User Requirements............................................................................18 5.1 User Training.......................................................................................................................................18 5.2 User Manuals and Online Help............................................................................................................18 5.3 Automated and Manual Functions.......................................................................................................18

Items To Be Decided .........................................................................................20 6 Future Requirements (Optional).....................................................................21 Appendix.............................................................................................................22

Faculty of Engineering, University of Ruhuna

10/13/2013

Document Revisions Date 28/09/2013

Version 1.0

Description First edition

Author

Document Approval

Signature

Signature

Date:

Date:

Name:

Name:

Client:

Faculty of Engineering, University of Ruhuna

10/13/2013

ALUMNI SRS

1

Introduction

1.1 Purpose The version 1.0 of Software Requirement Specification documentation of ALUMNI is prepared for offering detailed specification about our software project, not only to the client and approval panel but also to the developers of the system. This contains the detailed specifications of the purpose and features of the system, the interfaces of the system, what the system will do, the constraints under which it must operate and how the system will react to external stimuli.

1.2 Summary As our client Engineering Education Center (EEC) of Faculty of Engineering, University of Ruhuna which is responsible for the arrangement of industrial trainings for the undergraduates in the faculty, it is an essential need to communicate with the graduates (Alumni) of the its own faculty who are the main source of granting internships for the undergraduates. By the project of ALUMNI, not only EEC can make a relationship with past students, so that client can find internships in an efficient way, but also it makes other students aware about their colleagues. All the graduates can make a wiki account and they can update their profile information and the number of internships they can offer. Every user can view each other’s profiles and communicate. At the backend, list of internships and relevant companies with contact person can be access by the EEC administrator.

1.3 Company (Client) Overview Engineering Education Center (EEC) of Faculty of Engineering, University of Ruhuna which is responsible for the arrangement of industrial trainings for the undergraduates in the faculty. The basic source of internship opportunities is the graduated students of its own faculty. By collaboration with them, they have to find and manage, about 500 internships annually.

Faculty of Engineering, University of Ruhuna

4

10/13/2013

ALUMNI SRS

1.4 Project Overview This software project will be an implementation of social network for industrial relations in which every user (graduates from Ruhuna engineering faculty) can maintain and update their own profile and their ability to offer internship opportunities whilst the client (EEC) can access a list of internships offered and contact persons. And also the all users can look into other colleague’s profile and communicate with them. But this project does not contain a news feed that continuously updates a dynamic feed about recent changes of profile users.

1.5 Definitions, Acronyms and Terminology Term ALUMNI

Definition Name of the overall project which implies this is related with past graduates.

Administrator

Person who has the full authority about this system and he has direct access to the system.

Communication Channel Database Data Operator Graduate HS Database Industry person Member

The communication between all the actors All the information The authorized person of internships and job opportunities in EEC Passed out graduates from the faculty The existing membership database Person who involves with the faculty for various reasons special for offering job opposites and internships A member of the Historical Society listed in the HS database.

Profile

A wiki that every user update their information

Server

The machine that contain the application program and database.

Software Requirements Specification

A document that completely describes all of the functions of a proposed system and the constraints

Faculty of Engineering, University of Ruhuna

5

10/13/2013

ALUMNI SRS

under which it must operate. For example, this document. Network Stakeholder User

The communication channel we build through this project ALUMNI Any person with an interest in the project who is not a developer. Industry person or graduate who access the system via internet.

1.6 References (Optional) [1] IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998.

Faculty of Engineering, University of Ruhuna

6

10/13/2013

ALUMNI SRS

2

Project Scope and Impact

Through this project the cooperation between faculty and the graduated students will develop and obviously the internship finding procedure of EEC will impact positively and become easier and efficient. A also by maintaining a collection of data of graduated students the authority of the faculty can find sponsorships, scholarships to the current undergraduates. And also it makes a communication channel between pass out colleagues to meet up.

2.1 Scope Inclusions Currently Faculty of Engineering University Ruhuna don't have proper channel to communicate with industrial people as well as Graduates who pass out form Ruhuna. If the details of them with current status, contacts numbers, Job opportunities, Training opportunities etc., on the web it might be nice channel for Faculty.

Faculty of Engineering, University of Ruhuna

7

10/13/2013

ALUMNI SRS

FIGURE 1: SYSTEM ENVIRONMENT Figure 1 shows the overview of the system environment of project ALUMNI which will be a web based application. Graduates and industrial person can access the social network through the internet. They can communicate via communication channel and view each other’s profile. The administrator has all the privileges as well as direct access to the entire system .The data operator can access the generated contact information list of internships via directly and via internet. .

2.2 Scope Exclusions This project may not include a news feed in which the users can see the updates of other users in main page. And also the user can’t access the generated contact information list of internships. This project does not implement a mechanism to add restrictions on view-ability Faculty of Engineering, University of Ruhuna

8

10/13/2013

ALUMNI SRS

of others profiles. And also this program do not allow some features such as “comment”, “likes” in other’s profiles.

2.3 Impact on Other Systems Since this is a new project, there does not have any system affected by this system.

2.3.1 Affected by Other Systems At the moment, this system does not affected by other systems.

2.3.2 Effects on other systems There do not have such a programs that receive information from the application that need modification because of this project.

Faculty of Engineering, University of Ruhuna

9

10/13/2013

ALUMNI SRS

3

Functional Requirements

This section captures the functional requirements of the system. Categorize the requirements in to appropriate categories. Example: system administration, reporting, etc. Functions can be described in the form of detailed textual use cases. Describing the main cases will be enough for the use case description.

Example: Use case Diagram(s)

3.1

System Administration

3.1.1

Create a new blog account Use Case Name Pre-Conditions Successful end conditions Failed end conditions Primary Actors

3.1.2

Check Identity Use Case Name Pre-Conditions Successful end conditions Failed end conditions Primary Actors

Create a new blog account

Check Identity

3.1.3 Create a new personal wiki Description Faculty of Engineering, University of Ruhuna 10/13/2013

10

ALUMNI SRS

Use Case Name Pre-Conditions Successful end conditions Failed end conditions Primary Actors

4

Create a new personal wiki

Non-functional Requirements

4.1

Performance and Load Requirements

Include all performance requirements known at this point. Example: Number of Concurrent Users, Transaction Size (files sizes, etc.)

4.2 Compatibility Requirements Include all compatibility requirements for hardware, software and operating systems.

Example: HTML Versions to be supported, Browser Versions to be Supported, Database Versions to be Supported, Communication Protocol, Platform Version to be Supported, Any Other External Systems or Standards

4.3 External Interface Requirements Include any interface requirements that allow external systems to communicate with this application or allow this application to communicate with external systems. .

Faculty of Engineering, University of Ruhuna 10/13/2013

11

ALUMNI SRS

4.3.1 User Interfaces Describe the user interfaces that are to be implemented by the software. User interfaces can be described through wire frame designs. Also, mention any special user interface requirements.

4.3.2 Hardware Interfaces This section defines any hardware interfaces that are to be supported by the software, including logical structure, physical addresses, expected behavior, etc.

4.3.3 Software Interfaces This section describes software interfaces to other components of the software system. These may be purchased components, components reused from another application or components being developed for sub-systems outside of the scope of this document, but with which this software application must interact.

4.3.4 Communications Interfaces Describe any communication interfaces to other systems or devices such as local area networks, remote serial devices, etc.

4.4 Security and Authentication Requirements 4.4.1 Data Storage Security Describe any special requirements to protect data stored in the system, e.g. database security, encryption, etc.

4.4.2 Data Communication Security Describe any special requirements to protect data in transit, e.g. use of SSL, use of POST methods, etc.

4.4.3 Authentication Describe any special authentication requirements, e.g. NT Challenge Response, etc. Faculty of Engineering, University of Ruhuna 10/13/2013

12

ALUMNI SRS

4.5 Quality Assurance Requirements 4.5.1 QA Test Scope Describe the scope of QA (levels of testing, etc.).

4.5.2 QA Environment Describe QA software, hardware, tools and environmental requirements.

4.5.3 QA Data Describe the key data entities required to begin testing – including outside data sources, populated databases and/or data generation tools.

4.6 Development Requirements 4.6.1 Development Environment Describe development software, hardware, tools and environmental requirements.

4.6.2 Development Data Describe the key data entities required to begin development – including outside data sources, populated databases and/or data generation tools.

4.6.3 Coding Standards Describe the coding standards and naming conventions for this project or give a reference to where the standards can be found (if a separate coding standards document was created).

Faculty of Engineering, University of Ruhuna 10/13/2013

13

ALUMNI SRS

4.6.4 Implementation Packaging Requirements Describe special application module packaging requirements. For example, a Java package must be named in a certain way for the client to group certain functionality into certain packages.

4.7 Deployment Requirements Describe any of the following requirements, if applicable. The following fields are optional according to the project.

4.7.1 Deployment Requirements Describe how the application will be deployed including an outline of different locations where the servers are kept and how each type of user accesses the system. This should also include the OS versions, machine types and the version requirements (e.g. is it required to have multiple versions of the application running on the same machine).

4.7.2 Documentation Requirements Describe all documentation requirements – including standard documents produced throughout the process and special client requirements for technical or end user documentation.

4.8 Internationalization Requirements Describe the extent of internalization required for the system (language, locales, measurements, currency, etc.).

4.9 System Activity Log Requirements Describe the level of tracking on events as required. What type of activity logs should be maintained? For accountability purposes do we need to track all user activity?

Faculty of Engineering, University of Ruhuna 10/13/2013

14

ALUMNI SRS

4.10

Special Documentation

Requirements This section describes any necessary legal disclaimers, warranties, copyright notices, patent notices, word mark, trademark, or logo compliance issues for the software.

4.11

Applicable Standards

This section describes, by reference, any applicable standard and the specific sections of any such standards, which apply to the system being described. For example, this could include legal, quality and regulatory standards, industry standards for usability, interoperability, internationalization, operating system compliance, and so forth.

Examples of applicable standards: •

Legal and regulatory: FDA, UCC

•

Communications standards: TCP/IP, ISDN

•

Platform compliance standards: Windows, UNIX

•

Quality and safety standards: UL, ISO, CMM

4.12

Licensing Requirements

Defines any licensing enforcement requirements or other usage restriction requirements that are to be exhibited by the software.

4.13

Online User Documentation and

Help System Requirements Describes the requirements, if any, for online user documentation, help systems, about notices, etc.

Faculty of Engineering, University of Ruhuna 10/13/2013

15

ALUMNI SRS

4.14

Purchased Components

This section describes any purchased components to be used with the system, any applicable

licensing

or

usage

restrictions,

and

any

associated

compatibility

and

interoperability or interface standards.

4.15

Technical Requirements

Describe any technical requirements on the system being built. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s), etc. that need to be considered.

4.16

Supportability Requirements

This section indicates any requirements that will enhance the supportability or maintainability of the system being built, including coding standards, naming conventions, class libraries, maintenance access, and maintenance utilities.

4.17

Reliability Requirements

Describe reliability requirements of the system.

4.18

Usability Requirements

Describe any special user interface or usability testing requirements, for example, browser compatibility, use of specific widget sets, portability requirements of the user interface, etc.

Faculty of Engineering, University of Ruhuna 10/13/2013

16

ALUMNI SRS

Faculty of Engineering, University of Ruhuna 10/13/2013

17

ALUMNI SRS

5

Special User Requirements

Describe any of the following requirements, if applicable.

5.1 User Training 5.2 User Manuals and Online Help 5.3 Automated and Manual Functions Provide a list of the manual functions or manual interventions, which might be linked with the automated functions of the system. If there are any prerequisites for manual tasks/activities for the automated system to run successfully, or there is any impact of these manual tasks on the automated functions, they should be illustrated here.

Faculty of Engineering, University of Ruhuna 10/13/2013

18

ALUMNI SRS

Faculty of Engineering, University of Ruhuna 10/13/2013

19

ALUMNI SRS

Items To Be Decided At the moment we do not come to a conclusion, whether we introduce different kind of user account to the industry persons or same as the graduates. And also it is yet to be decided, how we identify the genuine graduates and industry persons from fake users.

Faculty of Engineering, University of Ruhuna 10/13/2013

20

ALUMNI SRS

6

Future Requirements (Optional)

As the next phase of this project, if we could develop a news feed, in which users can view others updates and status changes in a one page, it would be wonderful. It would be even grateful, if a mechanism to generate notifications on other’s status changes can be implemented. In this project there exists a sever concern about the privacy of the users, because anyone can view other’s information. So adding access restrictions may become major priority in future phases of this project. And finally, this would become quite an extra ordinary project, if we could extend this project to whole the university, that means this social network facilitate to all the students, lecturers, past graduates and industry persons to come into one platform and they can communicate with each other in a formal way.

.

Faculty of Engineering, University of Ruhuna 10/13/2013

21

ALUMNI SRS

Appendix [Include additional information related to the project that must be provided as part of this document.]

Faculty of Engineering, University of Ruhuna 10/13/2013

22