Remote Control System

MViewer
Remote Control System

Software Requirements Specification

Version 1.0
05/06/2012

Darie Mihai
Software Engineer
DSWT 1B

1
Software Requirements Specification

Remote Control System

Revision History
Date
05/06/2012

Description
MViewer SRS

Author
Darie Mihai

Comments
Remote Control System
Software Specifications

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

Printed Name
Darie Mihai

Title
Software Engineer

Date
02/20/2012

Table of Contents

2
Software Requirements Specification

Remote Control System

Revision History..2
Document Approval2
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview
2. General Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 General Constraints
2.5 Assumptions and Dependencies
3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interface
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Interfaces
3.2 Functional Requirements
3.2.1 Functional Requirement or Feature #1
3.2.2 Functional Requirement or Feature #2
3.3 Use Cases
3.4 Classes / Objects
3.4.1 Class / Object #1
3.4.2 Class/ Object #2
3.5 Non-Functional Requirements
3.5.1 Performance
3.5.2 Reliability
3.5.3 Availability
3
Software Requirements Specification

Remote Control System

3.5.4 Security
3.5.5 Maintainability
3.5.6 Portability
3.6 Inverse Requirements
3.7 Design Constraints
3.8 Logical Database Requirements
3.9 Other Requirements
4. Analysis Models
4.1 Sequence Diagrams
4.2 Data Flow Diagrams (DFD)
5. Change Management Process
A. Appendices
A.1 Appendix 1
A.2 Appendix 2

1. Introduction
4
Software Requirements Specification

Remote Control System

1.1 Purpose
The Software Requirements Specifications document is meant to assure the project
management stakeholder(s) that the development team (in this case, me) really understood the
business requirements properly. It provides a complete description of all features of MViewer.
The SRS is documented in such a way that it splits the deliverable software product into
small components. The developers will understand what functionality needs to be developed and
in what order. It forms the basis for a load of the Software Design Specification document and
saves both project time and cost (in my case the time is considered to be also a cost).
The intended audience of the SRS is the Project Manager which will review the
document and give his approval.

1.2 Scope
In the actual life lot of people want/need to access a friends or work colleagues
computer in order to see his actions such as a presentation or to take control of his computer so
that he can be the presenter and provide ad-hoc support or administer the OS. Considering this,
we can say that the purposes of a remote control system are to gain control from distance of an
activity, process or machine. Of course, a remote control system can be used for hacking/spying,
but we must keep it legal, arent we?
MViewer has to be a simple, fast and secure application for computer remote control and
teamwork that can be used to provide ad-hoc support to friends, administer their computers and
share your desktop for online presentations or collaboration.

1.3 Definitions, acronyms and abbreviations

SRS - Software Requirements Specifications
OS - Operating System
TBC

1.4 References
TODO

1.5 Overview
5
Software Requirements Specification

Remote Control System

TODO

2. General Description
TODO

2.1 Product Perspective

TODO

2.2 Product Functions

The main services provided by the system for the end users will be the desktop sharing
and the remote controlling. Using these main features, the user must be able to see the others
desktop and to have the possibility of taking control of his machine.
The secondary services that the system will offer for the end users will be the voice chat
and (hopefully) the video chat. Any future use of the MViewer for XXX causes is prohibited and
will be punished very seriously (by having the developer viewing the users webcam if
applicable or the users girlfriends webcam).

2.3 User Characteristics

The MViewer should/can be used by regular users such as private persons in a LAN
similar to the TuIasi network used by the students in the University Campus but it can be also
used in peer-to-peer or other public networks, of course, only in demonstrative scopes.
The final user must have minimal knowledge in configuring the MViewer according to
the specifications of the User Guide so that the MViewer can be successfully used.

2.4 General Constraints

2.4.1 Hardware limitations
The machine(s) used by the developer(s) for designing the system must have a minimum
of 2GB RAM and 2Ghz processor so the system can perform lots of send/receive operations
which involve the transfer of serialized images in a very(!) short time span.
Also, the machines must have a webcam and a microphone attached so the video and
voice chat features of the system can be implemented and tested.
A good Internet connection is also required so the system can perform fast image
transfers and remote control commands execution.
6
Software Requirements Specification

Remote Control System

2.4.2 Interface to other applications
At a first instance, such as the beta version, the MViewer doesnt have to provide any
interface for external applications.
2.4.3 Safety and security considerations
The system must respect at least one security policy studied at Distributed Systems
Security and implement its features.
The images must be transferred over HTTPS (using client and server certificates) - if
applicable.
Access Control List must be used for defining who and what feature of the MViewer may
use.
2.4.4 High-order language requirements
The system must be implemented by using C# programming language, the development
environment being Visual Studio 2010.
WPF technology must be used in designing and implementing rich UI.
.NET Remoting must be used to implement the backend logic of the system.
2.4.5 Criticality of the application
The most critical feature/module of the MViewer is the desktop sharing and remote
control part which is mandatory for the system and it must be functional in any circumstances.

2.5 Assumptions and Dependencies

The single factor that can affect the requirements stated in the SRS is the allotted time for
the development of the MViewer so the SRS document might change (by removing the video
chat requirement).

3. Specific Requirements
3.1 External Interface Requirements
3.1.1

User Interface

3.1.1.1 Client application UI

The UI must contain the following controls:
- picture box where the remote desktop will be displayed;
7
Software Requirements Specification

Remote Control System

- labels where the local IP address, local hostname, connection status, button to be used
to connect/disconnect to the remote server, the ID assigned by the remote server for the client
application, textbox where the remote server address can be configured;
- buttons that will start/stop the voice chat and video chat;
- picture box where the video chat has to be displayed;
- controls where the voice chat status has to be displayed.
3.1.1.2 Server application UI
The UI must contain the following controls:
- a startup form which will indicate that the server is waiting for remote connections;
- a listbox where the remote connections will be displayed;
- a button which will give the possibility of shutting down specified remote connections;
- a form where the video chat will be displayed (multiple such forms will be opened for
multiple video chats);
- a form (or only just a listbox) which will display the active voice chats having the
possibility of closing the voice chat.
3.1.2

No hardware or software interface should be provided by the system.

3.2 Functional Requirements

3.2.1 Functional Requirement of Feature #1
The client application must be able to connect to the remote server, see and control its
display.
The client application must be able to initiate a voice and/or video chat with the server
application.
The input of the client application will be the remote server hostname/IP address.
3.2.2 Functional Requirement of Feature #2
The server application must listen for incoming connections and must accept the desktop
sharing, remote commands, voice and video chat requests.
The server must use the ACL in order to determine the clients role and the access rights
for the usage of the MViewers features.

3.3 Use Cases

See the UML diagrams in the Modeling project (to be opened with VS2010).
8
Software Requirements Specification

Remote Control System

3.4 Classes / Objects

3.4.1 Class / Object #1
TODO
3.4.2 Class/ Object #2
TODO

3.5 Non-Functional Requirements

3.5.1 Performance
TBD
3.5.2 Reliability
TBD
3.5.3 Availability
TBD
3.5.4 Security
Already mentioned at 2.4.3.
3.5.5 Maintainability
No maintenance should be done because the system will never be put on production.
3.5.6 Portability
TBD

3.6 Inverse Requirements

TBD

3.7 Design Constraints

TBD

3.8 Logical Database Requirements

The system will not have any database.

3.9 Other Requirements

4. Analysis Models
4.1 Sequence Diagrams
See the UML diagrams in the Modeling project (to be opened with VS2010).
9
Software Requirements Specification

Remote Control System

4.2 Data Flow Diagrams (DFD)

See the UML diagrams in the Modeling project (to be opened with VS2010).

5. Change Management Process

A. Appendices
A.1 Appendix 1
A.2 Appendix 2

10
Software Requirements Specification