Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Software Requirement Analysis and Specification

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 8

2.

Software Requirement Analysis and Specification

2.1 Related Work

1. A cluster-based approach to consensus based distributed task allocation


AUTHORS: D. Smith, J. Wetherall
This paper presents a novel extension to the Consensus-Based Bundle Algorithm (CBBA), which
we have named Cluster-Formed Consensus-Based Bundle Algorithm (CFCBBA). CF-CBBA is
designed to reduce the amount of communication required to complete a distributed task
allocation process, by partitioning the problem and processing it in parallel clusters. CF-CBBA
has been shown, in comparison with baseline CBBA, to require less communication when
allocating tasks. Three key aspects of task allocation have been investigated, (a) the time taken to
allocate tasks, (b) the amount of communication necessary to satisfy the requirements of
distributed task allocation algorithms such as CBBA, and (c) the efficiency with which a
collection of tasks (a mission) is completed by a group of robots (a collective).
2. Aodv routing protocol implementation design
AUTHORS: I. D. Chakeres and E. M. Belding-Royer
To date, the majority of ad hoc routing protocol researchhas been done using simulation only.
One of the most motivatingreasons to use simulation is the difficulty of creatinga real
implementation. In a simulator, the code is containedwithin a single logical component, which is
clearly definedand accessible. On the other hand, creating an implementationrequires use of a
system with many components, includingmany that have little or no documentation. The
implementationdeveloper must understand not only the routingprotocol, but all the system
components and their complexinteractions. Further, since ad hoc routing protocolsare
significantly different from traditional routing protocols,a new set of features must be introduced
to support therouting protocol. In this paper we describe the event triggersrequired for AODV
operation, the design possibilitiesand the decisions for our Ad hoc On-demand Distance
Vector(AODV) routing protocol implementation, AODV-UCSB.This paper is meant to aid
researchers in developing theirown on-demand ad hoc routing protocols and assist usersin
determining the implementation design that best fits theirneeds.
3. Optimized link state routing protocol (olsr)
AUTHORS: T. Clausen, P. Jacquet
In this paper we propose and discuss an optimized link state routing protocol, named OLSR, for
mobile wireless networks. The protocol is based on the link state algorithm and it is proactive (or
table-driven) in nature. It employs periodic exchange of messages to maintain topology
information of the network at each node. OLSR is an optimization over a pure link state protocol
as it compacts the size of information sent in the messages, and furthermore, reduces the number
of retransmissions to flood these messages in an entire network. For this purpose, the protocol
uses the multipoint relaying technique to efficiently and economically flood its control messages.
It provides optimal routes in terms of number of hops, which are immediately available when
needed. The proposed protocol is best suitable for large and dense ad hoc networks.
4. Simulation-based performance evaluation of mobile ad hoc routing protocols in a swarm
of unmanned aerial vehicles
AUTHORS: M. Hyland, B. E. Mullins
This paper evaluates the performance of several ad hoc routing protocols in the context of a
swarm of autonomous unmanned aerial vehicles (UAVs). It has been proposed that a wireless
network where nodes have on average 5.1774 log n neighbors, where n is the total number of
network nodes, has a high probability of having no partitions. By decreasing transmission range
and implementing multi-hop routing between nodes, while ensuring network connectivity is
maintained, spatial multiplexing of the wireless channel is exploited. The proposed process is
evaluated using the OPNET network simulation tool for the Greedy Perimeter Stateless Routing
(GPSR), Optimized Link State Routing (OLSR), and Ad hoc On- demand Distance Vector
(AODV) routing protocols in the context of a swarm of UAVs.
5. Performance analysis of mesh routing protocols for uav swarming applications
AUTHORS: J. Pojda, A. Wolff
Unmanned Aerial Vehicles (UAVs) are an emerging technology offering new opportunities for
innovative applications and efficient overall process management in the areas of public security,
cellular networks and surveying. A key factor for the optimizations yielded by this technology is
an advanced mesh network design for fast and reliable information sharing between UAVs. In
this paper, we analyze the performance of four available mesh routing protocol implementations
(open80211s, BATMAN, BATMAN Advanced and OLSR) in the context of swarming
applications for UAVs. The protocols are analyzed by means of goodput in one static and one
mobile scenario using the same embedded hardware platform installed at UAVs in current
research projects. Our results show that layer-2 protocols suit better for mobile applications in
comparison to layer-3. On the other hand, they often cause routing flippings, which are unwanted
route changes, in static scenarios imposing a small performance decrease. Hence, given the
aforementioned routing protocols, we recommend to currently use open80211s or batman-
advanced to establish a reliable multi-hop mesh network for swarming applications.

2.2 Product Function

 System Construction
 Key Management
 Secure Node-to-Node Keys
 Storage
 Communication Security

MODULES DESCSRIPTION
System Construction
In the first module, we develop the System Construction module with Source, Router and
Destination entities. The topology is the arrangement of nodes in the simulation area. The routers
are connected in MANET topology. In which each routers are connected to each other via other
routers (Path). In our simulation, we are using multi-nodes as the router node and nodes as the
client-server node. Totally we are having multi-nodes in our network. Each host is connected via
routers. Each host has multiple paths to reach a single destination node in the network. The nodes
are connected by duplex link connection. The bandwidth for each link is 100 mbps and delay
time for each link is 10 ms. each edges uses Drop Tail Queue as the interface between the nodes.

Key Management
In this module, we develop the Key management. Packet Type denotes the function of the
packet. Timestamps provide uniqueness, allowing detection of replayedpackets and providing a
basis for non-repudiation ofpreviously sent packets.
SUPERMAN relies on the dynamic generation of keys toprovide secure communication.The
Diffie-Hellman key-exchange algorithm provides ameans of generating symmetric keys
dynamically and isused to generate the SK keys. SKb keys can simply be generatedby means of
random number generation or anequivalent secure key generation service.

Secure Node-to-Node Keys


SKe keys are used to secure end-to-end communicationwith other nodes, with one SKe key
generated per node, forevery other node also authenticated with the network. SKpkeys are used
for point-to-point security and generated inthe same manner as SKe keys.It is important that SKe
and SKp keys are different, asthe network needs to secure both the content of a packetand the
route taken.
A KDF can be used to generate these two keys in conjunctionwith the result of the Diffie-
Hellman algorithm,requiring a DKSp/DKSpriv pair, to minimise the cost of securityon the
network and reduce the key re-use and, inturn the lifetime of each key.These keys are generated
when nodes receive DKSp’sfrom other SUPERMAN nodes.

Storage
SUPERMAN stores keys in each node’s security table. Thesecurity table contains the security
credentials of nodeswith which the node has previously directly communicated. This table has n
entries, wheren is the number of nodes that the node in question has directlycommunicated with.
Table has exchanged credentialswith two other nodes, X and Y.The shared symmetric broadcast
key (SKb) has two derivedforms, the SKbe and SKbp. These are stored in the localsecurity table
as a separate broadcast address.

Communication Security
Once a node has joined the network, it may engage in securecommunication with other nodes.
Secure communicationunder SUPERMAN provides two types of security;end-to-end and point-
to-point.End-to-end security provides security services betweensource and destination nodes by
using their shared SKe.Confidentiality and integrity are provided using an
appropriatecryptographic algorithm, which is used to generatean encrypted payload (EP).When
protected, data is propagated over multiple hops, itis authenticated at each hop. This is achieved
using a hashingalgorithm, such as HMAC. This is applied to the entirepacket to provide point-to-
point integrity.
2.3 Hardware Requirements
Processor : Core2duo

Hard Disk : 160GB

RAM : 1GB

2.4 Software Requirements

Operating system : Windows 7.


Coding Language : JAVA/J2EE
Tool : Netbeans 7.2.1
Database : MYSQL

2.5 Non-Functional Requirements

Non-functional requirements describe user-visible aspects of the system that are not directly
related to functionality of the system. Non-functional requirements these are constraints on the
services or functions offered by the System.

Non-functional requirements are often called qualities of a system. Other terms for non-
functional requirements are "constraints", "quality attributes", "quality goals", "quality of service
requirements" and "non-behavioral requirements". Qualities, that are non-functional
requirements, can be divided into two main categories:

1. Execution qualities, such as security and usability, which are observable at run time.
2. Evolution qualities, such as testability, maintainability, extensibility and scalability,
which are embodied in the static structure of the software system.
Non-functional requirements

Product
Organizational External
requirements
requirement requirement

Efficiency Reliability Portability Ethical


requirement requirement requirement Interoperability
requirement
requirement

Legislative
Usability Delivery Implementation
Standards requirement
requirement requirement requirement
requirement

Privacy
Safety
requirement
Performance Space requirement
requirement requirement

Fig 2.6.1: Non-Functional Requirements

The non-functional requirements are

Reliability
The packages will pick-up current transactions online. Regarding the old transactions, user will
enter them in to the system.

Security
The web server and database server should be protected from hacking, virus etc.

Portability
The application will be developed using standard open source software (Except Oracle) like
Java, tomcat web server, Internet Explorer Browser etc. these software will work both on
Windows and Linux OS. Hence portability problems will not arise.
Maintainability
The first tier is the GUI, which is said to be front-end and the second tier is the database, which
uses My-Sql, which is the back-end. The front-end can be run on different systems (clients).
The database will be running at the server. Users access these forms by using the user-ids and the
passwords.

Robustness
Time to restart after failure percentage of events causing failure probability of data corruption on
failure

Usability
The system is used by the four persons namely Administrator, Project Manager, Developer and
the customer. Each person is having their own roles and separated by the security issues.

Performance
System is highly functional and good in performance. The system must use the minimal set of
variables and minimal usage of the control structures will dynamically increase the performance
of the system.

Availability
The system is implemented based on the web browser and server. Using this web browser the
user can access the data and store the data in the server, here we can use the web browser as
Mozilla and server as Tomcat5.5. And windows XP professional is used as the platform.

Supportability
The system is designed to be the cross platform supportable. The System is supported on a wide
range of hardware and any software platform

Testability
The system software can be tested. Operability is the better it works, the more efficiency it can
be tested. It operates clearly. Observability is what you see is what you test. The results of each
test case are readily observer.

Accessibility
It is a general term used to describe the degree to which a product, device, service, or
environment is available to as many people as possible. Accessibility can be viewed as the
"ability to access" and benefit from some system or entity. Accessibility is often used to focus on
people with disabilities or special needs and their right of access to entities, often through use of
assistive technology .

Accessibility is not to be confused with usability which is used to describe the extent to which a
product (e.g., device, service, and environment) can be used by specified users to achieve
specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

Scalability

Scalability is the ability of a system, network, or process, to handle growing amount of work in a
capable manner or its ability to be enlarged to accommodate that growth. For example, it can
refer to the capability of a system to increase total throughput under an increased load when
resources (typically hardware) are added. An analogous meaning is implied when the word is
used in a commercial context, where scalability of a company implies that the underlying
business model offers the potential for economic growth within the company.

Scalability, as a property of systems, is generally difficult to define and in any particular case it
is necessary to define the specific requirements for scalability on those dimensions that are
deemed important. It is a highly significant issue in electronics systems, databases, routers, and
networking.

You might also like