Software Requirements Specifications Document

Stor Rewrite
Team Members:
Iqbal Talaat (Project Lead)
Najam Ahmed Ansari (Software Developer)
Hashim Muqtadir (Software Developer)

Software Requirements Specification

Document

Version: (1) Date: (01/16/2014)

/var/www/apps/conversion/tmp/scratch_3/346922287.doc Page 1 of 20
3/2/17
f
 Software Requirements Specifications Document

Table of Contents

1. Introduction ............................................................................................................................................................4
1.1 Purpose .............................................................................................................................................................4
1.2 Scope ..................................................................................................................................................................4
1.3 Definitions, Acronyms, and Abbreviations. .......................................................................................................5
1.4 References .........................................................................................................................................................5
1.5 Overview ...........................................................................................................................................................6

2. The Overall Description ........................................................................................................................................7

2.1 Product Perspective ..........................................................................................................................................7
2.1.1 System Interfaces..........................................................................................................................................8
2.1.2 User Interfaces..............................................................................................................................................9
2.1.3 Hardware Interfaces......................................................................................................................................9
2.1.4 Software Interfaces.....................................................................................................................................10
2.1.5 Communications Interfaces .......................................................................................................................12
2.1.6 Memory Constraints...................................................................................................................................12
2.1.7 Operations...................................................................................................................................................12
2.1.8 Site Adaptation Requirements....................................................................................................................13
2.2 Product Functions ............................................................................................................................................13
2.3 User Characteristics ........................................................................................................................................13
2.4 Constraints ......................................................................................................................................................14
2.5Assumptions and Dependencies..........................................................................................................................14
2.6 Apportioning of Requirements...........................................................................................................................14

3.Specific Requirements ...........................................................................................................................................16

3.1 External Interfaces.............................................................................................................................................16
3.2 Functions............................................................................................................................................................18
3.3 Performance Requirements................................................................................................................................20
3.4 Logical Database Requirements........................................................................................................................20
3.5 Design Constraints.............................................................................................................................................21
3.5.1 Standards Compliance .............................................................................................................................21
3.6 Software System Attributes.................................................................................................................................21
3.6.1 Reliability...................................................................................................................................................21
3.6.2 Availability..................................................................................................................................................21
3.6.3 Security.......................................................................................................................................................21
3.6.4 Maintainability...........................................................................................................................................22
3.6.5 Portability...................................................................................................................................................22
3.6.6 Flexibility...................................................................................................................................................22
3.6.7 Interoperability...........................................................................................................................................22
3.6.8 Reusability..................................................................................................................................................22
3.6.8 Testability...................................................................................................................................................22
 Software Requirements Specifications Document

3.7 Organizing the Specific Requirements...............................................................................................................23

3.7.1 System Mode..............................................................................................................................................23
3.7.2 User Class...................................................................................................................................................23
3.7.3 Objects........................................................................................................................................................23
3.7.4 Feature........................................................................................................................................................23
3.7.5 Stimulus......................................................................................................................................................24
3. 7.6 Response....................................................................................................................................................24
3.7.7 Functional Hierarchy..................................................................................................................................24
3.8 Additional Comments.........................................................................................................................................24

4.Change Management Process.................................................................................................................................25

5.Document Approvals................................................................................................................................................25

6.Supporting Information..........................................................................................................................................25

/var/www/apps/conversion/tmp/scratch_3/346922287.doc Page 3 of 20
3/2/17 f
 Software Requirements Specifications Document

1. Introduction
1.1 Purpose

The document will cater to the processes involved in rewriting Stor so that it meets the
current functionalities in a more reliable, maintainable and efficient manner.

This document is also intended to serve as a reference going forward. It will aid in
standardization efforts throughout the company.

1.2 Scope

The scope of the document covers:-

1. Technology Selection
2. Selected APIs that will be carried over from the previous version of stor(excluding those
that we deprecate because nobody is using them).
3. System Design & Architecture
4. Software & Hardware Interfaces that the intended system would have.
5. A brief on Functional Capabilities.
6. A brief on Acceptability & Test Case requirements.
7. A brief on Parameters that require testing.
8. A brief on Deployment steps.
9. A brief on upgrading/modifying this document due to the following(error correction /
adding more findings / new decisions made in the light of new data / modifications based
on changes in Scope).

1.3 Definitions, Acronyms, and Abbreviations.

Glossary of Terms:-
1. Stor: Stor is a multimedia ingestion server which takes a bunch of image, audio, video
and document formats. It redirects audio and video to Kaltura. Stor can provide the
original assets, their exif info and their thumbnails
2. Kaltura: A video(and multimedia) publishing server that covers analytics, storage,
derivative generation, access control and smart players.

1.4 References

General Domain References: -

1. General Information About STOR may be obtained via:

http://redmine.acit.com/projects/dastor1/wiki
 Software Requirements Specifications Document

Project Lifecycle Documents: -

1. Resource Allocation, Project Plan, Use Cases Document, Test Case Document, Release
Document and other documents related to Planning, Execution, Monitoring & Control
and Closing will be attached / linked and this section will be revised regularly as the
project proceeds.

Manuals & SOPs : -

1. Project Execution Workflows are documented within the Ontime Manual.

1.5 Overview

The document is roughly split into four parts:-

1. The introduction is intended for all audience types that are connected to the project. It
does not require any technical, domain specific knowledge. Its an executive summary of
the document itself and not the project.
2. The next section or the Overall Description describes the project and its characteristics.
The audience can be technical or non technical. All audience types who want to get a
birds eye view of this project can go through this section. After a summary, this section
expands into classifying the interfaces, Functions, User Characteristics, Constraints and
the Assumptions that pertain to the project and ecosystem that STOR plays in. This
section needs to be read by every manager, end user, developer, tester associated with this
project or anyone who is to make a project related decision. It can also serve as a
reference for people working on associated projects in the Shared Shelf Ecosystem.
3. Specific Requirements are technical requirements. They quantify the what and delve
into the how. The design & architecture, functional, non-functional, technical, user,
system requirements are all covered here. Every other technical planning and closing
lifecycle document will reference this section.
4. Change management that covers both the Document and the Project. This would also
serve as an audit trail.

/var/www/apps/conversion/tmp/scratch_3/346922287.doc Page 5 of 20
3/2/17f
 Software Requirements Specifications Document

2. The Overall Description

2.1 Product Perspective

Stor plays a part in the Shared Shelf ecosystem. A graphical black box component
diagram is given below:-

BIT Services, Fixity Check and Scanner Daemon are all STOR related functionality. A
change in STOR could impact these other products.

The Interface between STOR and {BIT Service / ADAM / SSIMATA} shall be
considered as full and final with no modifications being made in the protocol so that
reverse compatibility of releases is ensured.

Currently, STOR is written in an esoteric language and with time its maintenance will
become costlier (in terms of effort ). We believe rewriting STOR would allow us to save
on long term support costs and provide a faster and more extensible system for our future
growth.

That said, the new perspective that we are taking on STOR itself is that the system will be
broken into small easily maintainable purpose based components that would include:-
1. Load Balancing Layer
2. Web Service Layer
3. Delivery Layer (Message Queue)
 Software Requirements Specifications Document

4. Persistence Layer (Database / File System)

5. Worker Layer:-
a. Thumbnail Generator Worker
b. Pyrimidal Worker
c. Restful Communication Worker
d. Persistence Worker
e. Fixity Worker
f. Virus Scanner Worker

As far as interfaces that exist between STOR and ADAM and SSIMATA exist they will
be maintained and persisted to ensure backwards compatibility.

Additionally, well have a monitor tool that would be a part of the web layer that will be
able to measure system throughput / health.

Our web layer would further be abstracted into front end server and application layer.
Extensive use of header directives would be used for performance and security purposes.

2.1.1 System Interfaces

The system Interfaces that we have to interact with will be as follows:-

1. KTS: For purposes of Video Ingestion

2. SSDAM: Callback to ADAM in transfer of control scenarios
3. External File System: For Storing Files Externally. Currently we use NAS which can be
mounted locally.

/var/www/apps/conversion/tmp/scratch_3/346922287.doc Page 7 of 20
3/2/17f
 Software Requirements Specifications Document

4. External API Interface: For use by consumers of STOR. i.e. Adam, SSDAM, BIT, etc.
5. Metrics: Currently we use newrelic, which means that we must have the option for
turning this on / off.

These interfaces are detailed in the specific requirement(s) section.

2.1.2 User Interfaces

Human interfaces will involve:-

1. Admin Dashboard that reports Utilization, health and investigation options.

2. New Relic / External Dashboards(s) for server Monitoring.
3. Diagnostic Tools for Ingestion like loader.py

Other than these, the other interfaces are present via consumable APIs that will be
covered under communications interfaces.

2.1.3 Hardware Interfaces

Hardware Interfaces would involve:-

1. Underlying Operating System. Ubuntu 12 LTS.

2.1.4 Software Interfaces

Interfaces with other software:-

1. Database / Postgres(9.0+ for Hot Failover and Hot Backup)

2. Indexer / Elastic Search
3. FFMPEG
4. LCMS
5. NetPBM
6. OpenJPEG
7. UFRaw
8. Image Magick
9. Bftools
10. Pnmtools
11. Python 2.7 (but using 3 like syntax)
12. Memcache
13. Message Queue / (RabbitMQ or Active MQ)

The version numbers will be latest at the time of system design and initial testing after
which the version numbers will go in along with the tools specified. This section needs to
be regularly revised because as the system is engineered tool selection can change.
 Software Requirements Specifications Document

/var/www/apps/conversion/tmp/scratch_3/346922287.doc Page 9 of 20
3/2/17
f
 Software Requirements Specifications Document

2.1.5 Communications Interfaces

Communication Interfaces within the Stor Ecosystem will be as follows:-

1. Message Queue Layer (The system should also be able to talk in a high performance
fashion with other machines on the same internal network without incurring the
overheads of the HTTP Layer). This list will only consist of the essential services that are
required for system functioning itself at first and added functionality would be a result of
post-ship system(Shared Shelf) wide optimization efforts. This list shall be defined
during implementation and the SRS / project documentation would be modified in the
iterations and on delivery.

2.1.6 Memory Constraints

Everything is designed to run on a single machine with 10 GB RAM, but this will be
variable with respect to the type of operation being needed. RAM heavy operations are
all image processing tasks which are also CPU intensive.

Only system testing can let us know about the actual usage post design.

2.1.7 Operations

The operations on this system would be of the following types:-

1. Maintenance Operations: Checking the Monitor utility to look at throughput and to
identify bottlenecks and perform preventative action before the system is capped.
2. Software Upgrade Operations: This would be aided by tools such as Jenkins and more
modern sysops tools such as chef and puppet later on, however the Upgrade would need
to be initiated and sanity tested by the user. There are two types. One is an Automated
build and one is an upgrade in Operating system libraries or dependencies that usually
requires an operational maintenance window.
3. Backup Operations: This needs to be done wherever the data or files are stored:-
4. Another Copy of the Files at another location and locked for edits so in cause of any
software or physical catastrophe (electrical outages, fire, alien invasion) the original
system can be rebuilt.
5. Another Copy of the Databases at another location.

2.1.8 Site Adaptation Requirements

Since the system is essentially a rewrite it would entail:

1. Installation & Configuration Activities: For all the new Components and their
dependencies. This could be via following a manual or via running a script. The
estimated time for such an activity would at first be a day.
2. Data Migration: This would entail running scripts on the exsiting data to transform it and
load it into the new system. This should not take a lot of time to execute but will require
 Software Requirements Specifications Document

some QA effort to validate that the data has been properly migrated and to the end user
everything remains the same.
3. Requisition of New Hardware as Appropriate: Since the system greatly benefits in terms
of redundancy and throughput by adding hardware, the complete testing of the system is
viable by having the right type of hardware available for configuration and assimilation
into the system.
2.2 Product Functions

The Product will consist of a complete rewrite of the STOR API, but in addition to that it
will also be able to perform the following:-

1. Rolling Restart(s): Whereby if a Cluster is aptly configured, then Stor should be able to
restart without any observed downtime experienced by the end user.
2. Performance / Ability to add throughput: Since the Stor Rewrite consists of a collection
of modules with different responsibilities{derivative generation, asset storage} by adding
more of such units into the cluster configuration.
3. Redundancy: The ability for databases, components, etc to go down without impacting
the functioning of the overall system. The only impacted performance variable will be
capacity and throughput.
4. Separation of Concern: Since there will be many small modules that will make up the
ecosystem of the stor rewrite that will talk from and write to a Message queue, the
module owners can be different and one must only know about the interaction layer to
develop a new module.
5. Monitoring: Dashboard functionality to look at the health of the underlying components
with respect to capacity and also be able to run some diagnostics.
6. Administrative Maintanence Commands: These can include Fixity Checks(integrity
matching of already ingested assets / thumbnails), Virus Scans of newly ingested assets,
etc
7. Maintainibility: Shifting away from a more esoteric language(erlang in this case) to
commonly adopted tools and technologies. Using the best in class Open Source Off the
shelf components for the purposes of Message Queues, etc.

2.3 User Characteristics

There are 2 types of intended users:-

1. A system end user: Will use the system through Adam, Imata, etc. This type of user will
not need to interact with the system directly.
2. A system Operator: This user will need to interact with the monitoring tools, will be able
to perform diagnostics and upgrade activities.

2.4 Constraints

Provide a general description of any other items that will limit the developer's options.
These can include:

/var/www/apps/conversion/tmp/scratch_3/346922287.doc Page 11 of 20
3/2/17f
 Software Requirements Specifications Document

(1) Regulatory policies: NA

(2) Hardware limitations: System should not leak memory.
(3) Interface to other applications: System should conform to exisiting and agreed
API that is used to communicate with Adam / Imata, etc
(4) Parallel operation: The system should be able to support many parallel users. 20
concurrent ingestions and 100 concurrent thumbnail accesses can be a good
starting criteria for stress and soak testing that we should aim for.
(5) Audit functions: The system should contain data that allows audit. Log all
necessary crud operations and that can be used to measure activity or investigate
problems. Fixity checks are another type of audit function.
(6) Control functions: System capacity and health should be obesevable via
appropriate web interfaces so that the appropriate corrective action may be taken.
(7 Reliability requirements: Simple updates should not cause down time and the
system should ideally be up at all times despite of isolated hardware failure
(8) Criticality of the application: critical

2.5 Assumptions and Dependencies

- Ubuntu 12 LTS linux operating system installed on all hardware.

2.6 Apportioning of Requirements.

N/A
 Software Requirements Specifications Document

3. Specific Requirements

3.1 External Interfaces

HTTP Requests:
All such requests will be received by STOR on its HTTP/HTTPS interface(s).
/stor/uuid
GET request used to request an asset from STOR. This will return the
original asset as it was ingested into STOR. All UUID values should match
this regex: "^[a-f0-9\-]*$". Performing a database query on a UUID should
not take more than a few hundred mili-seconds.
/stor/uuid_sizeX
GET request used to request an asset's thumbnail from STOR. This will
return the thumbnail of the specified size as generated by STOR. All UUID
values should match this regex: "^[a-f0-9\-]*$". Performing a database
query on a UUID should not take more than a few hundred mili-seconds. Valid
values of X are 0, 1, 2, 3 and 4. These values correspond to
sizes 64x64, 128x128, 256x256, 512x512 and 1024x1024, respectively.
/stor/uuid_kplayer
GET request used to request an asset's Kaltura player from STOR. This
will return the KTS URL for the specified asset. All UUID values should
match this regex: "^[a-f0-9\-]*$". Performing a database query on a UUID
should not take more than a few hundred mili-seconds. Retrieving an asset's
Kaltura player should not take more than a few hundred mili- seconds.
/stor/uuid_original
GET request used to request an asset from STOR. This will return the
original asset as it was ingested into STOR. These requests are meant to
be used by Kaltura for pulling a multimedia asset from STOR. All UUID
values should match this regex: "^[a-f0-9\-]*$". Performing a database
query on a UUID should not take more than a few hundred mili-seconds.
/stor/uuid_xml
GET request used to request an asset's Exif information from STOR. This
will return the data obtained from ExifTool. All UUID values should match
this regex: "^[a-f0-9\-]*$". Performing a database query on a UUID should
not take more than a few hundred mili-seconds. Running ExifTool should not
take more than a couple hundred mili-seconds
/stor/uuid_longsideX
GET request used to request an asset's thumbnail from STOR. This will
return the thumbnail of the specified size as generated by STOR. All UUID
values should match this regex: "^[a-f0-9\-]*$". Performing a database
query on a UUID should not take more than a few hundred mili-seconds. This
request transforms the dimension specified by X into a size number as taken

/var/www/apps/conversion/tmp/scratch_3/346922287.doc Page 13 of 20
3/2/17f
 Software Requirements Specifications Document

by the /stor/sizeX request defined above and returns the thumbnail for that
size.
/stor/uuid_noredirect
GET request used to request an asset from STOR. This will return the
original asset as it was ingested into STOR without the redirect to
/stor/uuid.ext. All UUID values should match this regex: "^[a-f0-9\-]*$".
Performing a database query on a UUID should not take more than a few
hundred mili-seconds.
/stor/uuid_profile
GET request used to request profiled JPEG and TIFF assets from STOR.
This will return the asset converted to a depth of 8 bits per color sample
in a pixel. These conversions will be performed on demand. All UUID
values should match this regex: "^[a-f0-9\-]*$". Only JPEG and TIFF
assets can be profiled, profile calls on other assets will fail. Performing a
database query on a UUID should not take more than a few hundred mili-
seconds. Profiling should not take more than 1 minute for very large TIFF
assets.
/stor/uuid_kdata
GET request used to request an asset's JSON information from Kaltura.
All UUID values should match this regex: "^[a-f0-9\-]*$". Performing a
database query on a UUID should not take more than a few hundred mili-
seconds. The call to KTS/Kaltura should not take more than a few hundred mili-
seconds.
/stor/uuid_kencoded
GET request used to request an asset's Kaltura flash player URL from
STOR. All UUID values should match this regex: "^[a-f0-9\-]*$".
Performing a database query on a UUID should not take more than a few
hundred mili-seconds. The call to KTS/Kaltura should not take more than
a few hundred mili-seconds.
/stor/uuid_kthumb
GET request used to request an asset's from Kaltura. This will return the
asset's thumbnail as generated by Kaltura. All UUID values should match
this regex: "^[a-f0-9\-]*$". Performing a database query on a UUID should
not take more than a few hundred mili-seconds. The call to KTS/Kaltura should
not take more than a few hundred mili-seconds.
/Rotate/dir/uuid [Deprecated Will not Support in Rewrite]
GET request used to request a rotated version of an asset from STOR.
This will return the rotated asset. All UUID values should match this regex:
"^[a-f0-9\-]*$". Performing a database query on a UUID should not take more
than a few hundred mili-seconds. The rotation operation should not take more
than a minute for very large files.
/message/Tail [Deprecated Will not Support in Rewrite]

GET request which provides a control REST interface to STOR data. All
UUID values should match this regex: "^[a-f0-9\-]*$". The following
operations are supported: parent, ancestor, children, archiving, archive
 Software Requirements Specifications Document

(PUT/GET/location/drop/mark), backup
(partials/delayed/failed/solo/copied), who_has, count, sysload, status,
look_for_twist, look_for.
/crossdomain.xml
GET request used to request an the crossdomain xml file from STOR.
/stor/
POST request used to ingest an asset via HTTP POST. Supported
filetypes are (<insert list of supported filetypes here>). Ingestion time per
media type (<insert list of timing data here>).
/insertimage/
GET request used to ingest an asset via HTTP GET and also insert it in
ADAM. Currently used by SSIMATA. Supported filetypes are (<insert list
of supported filetypes here>). Ingestion time per media type (<insert list
of timing data here>).
/copyfrompost
POST request used to ingest an asset via HTTP POST. Currently used by
ADAM. Supported filetypes are (<insert list of supported filetypes
here>). Ingestion time per media type (<insert list of timing data here>).
/movefrompath
POST request used to ingest assets via HTTP POST. Receives a JSON of
assets and sequentially ingests them. It also returns status of ingestion in
chunked form. Supported filetypes are (<insert list of supported filetypes
here>). Ingestion time per media type (<insert list of timing data here>).
/copyfrompath
POST request used to ingest assets via HTTP POST. Receives a JSON of
assets and sequentially ingests them. It also returns status of ingestion in
chunked form. Currently used by ADAM. Supported filetypes are (<insert
list of supported filetypes here>). Ingestion time per media type (<insert
list of timing data here>).
Database interface:
This section will depend upon the database chosen for this project. If we choose
PostgreSQL, we will use SQLAlchemy as the ORM. But if we choose MongoDB,
we will use PyMongo and write our own encapsulating classes around it
Filesystem I/O:
All assets will be stored on a disk location.
All logs will be stored on a disk location.
Temporary files may be created as needed and shall be cleared up afterwards.
Dependencies:
Some of the dependencies have Python APIs. Wherever available, such APIs shall
be used for image manipulation operations. For the rest, we will run bash
commands as in the existing STOR implementation.
External requests:
STOR communicates with external services (ADAM and KTS) over HTTP. These
are a mixture of HTTP GET and POST requests.
Message Queue:

/var/www/apps/conversion/tmp/scratch_3/346922287.doc Page 15 of 20
3/2/17
f
 Software Requirements Specifications Document

STOR will communicate with the message queue using the Celery API.
Memcached:
If chosen, Memcached will be used to cache data. This is something that will be
brought in on the database communication layer/ORM and the rest of the code
should not be impacted by this change in any manner.
3.2 Functions

Ingestion:
On ingestion, STOR shall attempt to identify the file and check for validity
Valid files will start their ingestion workflow
Errors can be thrown if:
One of the conversion/thumbnail operations fails on the asset
KTS fails to respond
KTS throws an error
The database is unavailable
ADAM fails to respond
ADAM throws an error
There is an error in saving the asset to the disk
Server is overloaded
Retrieval:
Upon receiving a request, STOR will verify that the UUID is conforms to the regex
(^[a-f0-9\-]*$)
STOR will perform a lookup against the UUID
If the asset is a STOR asset, STOR will return the requested element (exif
info/thumbnails/rotated image/original image)
If the asset is a Kaltura asset, STOR will return the requested element (Kaltura
player/Kaltura info json/Kaltura thumbnail/Kaltura raw video URL)
Errors can be thrown if:
Exiftool fails
Profiling fails
Rotation fails
KTS fails to respond
KTS throws an error
The database is unavailable
The UUID is not found
The UUID is not valid
The server is overloaded
Management API:
Allows for backup, integrity-checking, deletion, log-viewing facilities. We may also
couple up the virus scannre daemon with this.
The health monitoring functionality should also be a part of this API
 Software Requirements Specifications Document

STOR should periodically run checks to verify integrity of data, MD5 hashes should be
stored in DB at the time of ingestion and these should be used to ensure that the asset is
still healthy

3.3 Performance Requirements

As a minimum, a standalone STOR instance should be able to support concurrent
ingestions from 20 users. An ingestion of 100 MB should not take more than 3 minute
provided both the ingestion client and STOR server are on the same local network. Since
the architecture is modular and supports hot plugging in of new instances, concurrent
ingestions can be increased by adding more workers to the cluster.

3.4 Logical Database Requirements

The Proposed new ERD would consist of the following Object Types:-

1. Asset: Uuid, Metadata, timestamps, type, etc

2. Derivatives (many to 1 with Asset): Thumbnails, locations, etc.
3. State: Stage in the Process. Also Timing Information for performance analysis.
4. Maintenance Operation: Either of Fixity Type or Virus Scan Type.

The ERD would be published during the Project execution Phase.

If PostgreSQL is chosen as the database, then we might use the existing databases (with
any changes to the schema that might be necessary). For MongoDB, we will create
databases with similar schemas.

3.5 Design Constraints

3.5.1 Standards Compliance

All ingestion and retrieval operations must be logged in event log
Details of ingestion and retrieval operations must be logged in operational log
Any errors encountered should be logged in error log
All management operations must be logged in management log
UUIDs must conform to the regex: ^[a-f0-9\-]*$
3.6 Software System Attributes
3.6.1 Reliability

All files ingested into STOR must be stored in a secure and reliable storage location. All
responses from STOR should be well documented so that developers of other services can
handle responses and/or errors in an appropriate manner.
3.6.2 Availability

/var/www/apps/conversion/tmp/scratch_3/346922287.doc Page 17 of 20
3/2/17 f
 Software Requirements Specifications Document

STOR should always be available for both ingestion and retrieval operations. In order to
ensure this, STOR should provide health monitoring and alerts over its own workers, the
message queue, the database and the database connection, the filesystem location for
asset storage and the linked KTS service.
3.6.3 Security

Currently STOR operates over HTTP. Considering that artwork is usually under
copyrights, the web interface should expose an HTTPS service to prevent eavesdropping
and stealing of artwork. This will be taken into consideration but not the focus of the
rewrite.
For management operations, there should either be a log-in interface OR an API that
takes authentication tokens issued by ADAM/SSIMATA
Security and integrity of all stored assets must be ensured to prevent data-corruption and
un-authorized access
Integrity of data in the message bus must be ensured
3.6.4 Maintainability

The software MUST be written following good BDD/TDD practices. All classes,
methods and functions MUST be documented and accompanied with unit tests. No line
of code shall be committed into source control without these. Following these
guidelines, we can ensure that future developers who join this project don't have any
problems understanding the code-base.
3.6.5 Portability

The software will be fully compatible with the latest LTS release of Ubuntu and other
*NIX systems. However, its dependencies may or may not be supported for a particular
version of a particular distribution. Furthermore, we will bundle up STOR as a Debian
package and use that package for deployments. The package will also contain information
about STOR's dependencies. In this way, STOR deployments will be streamlined
reducing total deployment time.
3.6.6 Flexibility

The workflow shall be designed so that new components can be added to the system with
ease.
3.6.7 Interoperability

Since we will be replicating STOR's current HTTP API, the system should be a drop-in
replacement and function normally with SSIMATA, AWS and BIT.
3.6.8 Reusability

Any new application will be able to work with STOR using the APIs described above.
3.6.8 Testability
 Software Requirements Specifications Document

Sanity testing can be performed with the loader.py script. For the complete test cycle, QA
will use SSIMATA and AWS.

3.7 Organizing the Specific Requirements

NA

3.7.1 System Mode

NA

3.7.2 User Class

NA

3.7.3 Objects

NA

3.7.4 Feature

NA

3.7.5 Stimulus

NA

3. 7.6 Response

NA

3.7.7 Functional Hierarchy

NA

3.8 Additional Comments

NA

/var/www/apps/conversion/tmp/scratch_3/346922287.doc Page 19 of 20
3/2/17 f
 Software Requirements Specifications Document

4. Change Management Process

In order to change the document, all stakeholders must approve and the changes should
be communicated via email.

Changes are of the following type:-

1. Document revision in the initiation phase. i.e. Before Planning work has begun.
2. Document revision in the monitoring / control phase. This might be because of
modification to some architectural requirement or some unforeseen issue(s) with the
toolset, etc.
3. Document revision post project closing. i.e. Updates that are carried out post mortem. A
user might want some small unit of functionality to be implemented and that would
eventually need to be revised here.
4. List(s) such as the list of related documents need to be updated here.
5. Currently this document is a word document, but this should be maintained on a wiki / or
in a digital versioned format. We propose Red mine.

5. Document Approvals

Name of approver Date of approval

6. Supporting Information

NA