Software Requirements

Specification Document
for
<client>
1. Introduction
1.1 Tujuan

Tujuan dari aplikasi yang kami buat adalah :

- Memudahkan seluruh civitas akademika untuk memperoleh informasi
kegiatan kampus IT Telkom (kegiatan akademis dan non-akademis kampus).
- Memberi informasi kepada calon mahasiswa IT Telkom ataupun para Guru
SMA tentang kegiatan di kampus IT Telkom
- Mempercepat penyampaian informasi tentang kegiatan kampus IT Telkom.

1.2 Ruang Lingkup

Aplikasi Sistem Informasi kegiatan kampus yang bernama Sisfokus berfungsi sebagai
pusat informasi kegiatan yang berlangsung di kampus IT Telkom. Aplikasi Sisfokus
memberi informasi kegiatan kampus yang terbagi menjadi 2 bagian,yaitu Bagian
Akademik dan Bagian Non-Akademik. Bagian Akademik terdiri dari BAA, BK,
Fakultas(Termasuk Lab), dan Perpustakaan. Bagian Non-Akademik terdiri dari UKM,
BEM, Himpunan dan Umum. Pada aplikasi ini, user dapat melihat semua kegiatan
yang telah diinputkan oleh semua sub-admin dari masing-masing bagian. Sub-admin
disini pada nantinya akan diberi kuasa untuk menginputkan informasi kegiatan pada
bagian mereka dan kemudian akan terpublikasi jika inputan sub-admin tersebut
sudah disetujui oleh admin.
Aplikasi ini berbasis web dan dibagi menjadi dua versi: versi desktop dan versi
mobile.
Keuntungan aplikasi ini adalah dapat diakses dimana saja dan kapan saja sehingga
memudahkan penyampaian informasi tentang kegiatan kampus kepada para user.

1.3 Referensi
[1] Software Requirements Specification for <Project>.
http://www.ittelkom.ac.id/staf/kms/Slide kuliah dan tugas RPL/SRS template.doc

2. Overall Description
2.1 Product Perspective

This subsection of the SRS puts the product into perspective with other related
products or projects.
􀂄􀀃If the product is independent and totally self-contained, it should be stated here.
􀂄􀀃If the SRS defines a product that is a component of a larger system or project,
as frequently occurs, then this subsection should:
􀁸􀀃 Describe the functions of each component of the larger system or project,
and identify interfaces
􀁸􀀃 Identify the principle external interfaces of this software product.
􀁸􀀃 A block diagram showing the major components of the larger system or
project, interconnections, and external interfaces can be very helpful.

2.2 Product Functions

Aplikasi Sistem Informasi kegiatan kampus yang bernama Sisfokus berfungsi sebagai
pusat informasi kegiatan yang berlangsung di kampus IT Telkom. Pada aplikasi ini,
user dapat melihat semua kegiatan yang telah diinputkan oleh semua sub-admin dari
masing-masing bagian,yaitu bagian Akademik dan bagian Non-Akademik.

2.3 User Characteristics

Admin

Sub Admin
Bagian
Akademik User
Bagian Non Internal Umum
Akademik

2.4 Assumptions and Dependencies

This subsection of the SRS should list each of the factors that affect the requirements
stated in the SRS. These factors are not design constraints on the software but if any
changes made to them, can affect the requirements in the SRS document. Also
describe other constraints like hardware and software limitations, audit function
controls, etc.
For example, an assumption might be that a specific operating system will be available
on the hardware designated for the software product. If, in fact, the operating system
is not available, the SRS would then have to change accordingly.

3. Requirements
3.1 Functional Requirements
Berikut merupakan Functional Requirement dari Sistem Informasi Kegiatan Kampus:

1. Untuk Admin:

a. Dapat melakukan proses input, edit, approve, dan delete postingan

Pada functional requirement ini, admin dapat melakukan input (menambahkan
data informasi), edit (mengubah data informasi), approve (menyetujui data
informasi yang akan dipublish), dan delete (menghapus data informasi yang
sekiranya tidak diperlukan). Keempat functional ini diperlukan oleh admin karena
admin memiliki kuasa tertinggi dalam aplikasi ini. Oleh karena itu, admin tidak
hanya dapat menginput, mengedit, dan mendelete seperti halnya sub-admin, tetapi
juga dapat meng-approve informasi kegiatan yang diinputkan.
Ketika admin sudah memasuki halaman admin, disana sudah terdapat daftar
informasi kegiatan yang telah diinputkan oleh sub-admin. Disini, admin berhak
menentukan mana saja informasi yang layak untuk dipublish dan mana yang tidak.
Selain itu, admin juga dapat mengedit informasi-informasi yang ada. Juga, bila ada
informasi kegiatan yang belum diinputkan oleh sub-admin, maka admin berhak
menginputkannya. Kemudian juga jika ada informasi yang ternyata tidak valid,
admin berhak menghapuskannya. Publish informasi disini termasuk membaginya
pada kalender kegiatan, hot news, dan review.
Setelah sub-admin menginputkan informasi kegiatan, admin harus segera
menentukan informasi tersebut sudah layak publish atau belum dalam waktu paling
lambat 1x24 jam (sudah layak atau belum ditentukan dari kelengkapan pengisian
data). Jadi, admin harus setiap hari mengkontrol aplikasi ini. Jika admin tidak
melaksanakan tugasnya dengan baik, sub-admin berhak menegur admin.
Admin hanya terdiri dari satu orang, sehingga tidak terjadi banyak
perpindahan tangan untuk proses-proses di atas.
Data yang diinputkan oleh semua pihak akan disimpan oleh admin di dalam
suatu tempak untuk back-up, sehingga jika suatu saat system mengalami
gangguan atau rusak, data tidak betul-betul hilang. Dan jika suatu ketika data yang
diinputkan sudah terlalu banyak dan menyebabkan gangguan pada cepat-
lambatnya system, maka admin berhak menghilangkan data-data yang sudah lama
dari dalam database aplikasi.

b. Dapat melakukan proses maintenance

Selain mengurusi data postingan, admin juga harus melaksanakan fungsi
perawatan yang melingkupi keseluruhan web sistem informasi kegiatan kampus ini.
Perawatan yang dimaksud adalah memastikan bahwa web ini tetap berjalan dan
tidak statis.
Proses pasti dari fungsi ini tidak ada. Tetapi, secara keseluruhan, admin harus
terus mengupdate konten dan gambar, serta melakukan perubahan desain secara
berkala.

2. Untuk Sub-Admin
a. Dapat melakukan proses input, edit, dan delete postingan
Sub-admin, dimana ia adalah seseorang yang diberi tanggung jawab oleh
setiap bidang, memiliki functional sebagai seseorang yang dapat melakukan proses
input (menambahkan data informasi), edit (mengubah data informasi), dan delete
(menghapus data informasi yang sekiranya tidak diperlukan) untuk segala kegiatan
yang dilakukan oleh bagiannya yang bisa diikuti oleh civitas akademika.
Ketika pada nantinya sub-admin sudah memasuki halaman sub-admin, di
sebelah kiri halaman, terdapat menu pilihan yang terdiri dari ketiga proses di atas.
 Pada menu edit, dimana ditampilkan seluruh postingan, akan terdapat status,
apakah postingan tersebut telah atau belum di-approve oleh admin.
Jika admin belum meng-approve dalam waktu 1x24 jam setelah postingan
dibuat, sub-admin layak memberikan teguran terhadap admin. Demikian pula
sebaliknya, bila sub-admin tidak melaksanakan tugasnya untuk menginputkan,
maka admin juga berhak menegur.
Account sub-admin berjumlah satu untuk setiap bagian yang telah ditentukan
dan bebas dipakai siapa saja oleh orang yang berada di bagian tersebut.
Tersebarnya account merupakan tanggung jawab koordinator yang ditunjuk oleh
bagian tersebut.
Jika terjadi ke-error-an selama sub-admin menggunakan aplikasi ini, sub-
admin harus segera menghubungi admin, dan kemudian admin yang akan
mencarikan solusinya.

3. Untuk User
a. Dalam versi Mobile

b. Dalam versi Desktop

3.2 External Interface/Dependencies on Other Functions

Specify the characteristics the function should possess for each human interface.

Response Time Consideration

The time a function should take to generate the desired results once the input has
been specified. In case it is difficult to define the time, indicate the response time as
high, medium or low.

Sequence of Output (In Case of Reports)

List the sequence in which the result of the function should appear.

Estimated Volume of Transactions

Specify the maximum amount of data that is to be processed by the function.

Any Assumptions made

List any assumptions made with respect to this function.

Retention Period
Specify the time for which the data generated by the function would be in use in the
system.

Usability
Usability requirements may include such sub-categories as:
􀂄􀀃Human factors
􀂄􀀃Aesthetics
􀂄􀀃Consistency in the user interface
􀂄􀀃Online and context-sensitive help
􀂄􀀃Wizards and agents
􀂄􀀃User documentation
􀂄􀀃Training materials

Reliability
Reliability requirements to be considered are:
􀂄􀀃Frequency/severity of failure
􀂄􀀃Recoverability
􀂄􀀃Predictability
􀂄􀀃Accuracy
􀂄􀀃Mean time between failure (mtbf)

Performance
A performance requirement imposes conditions on functional requirements. For
example, for a given action, it may specify performance parameters for:
􀂄􀀃Speed
􀂄􀀃Efficiency
􀂄􀀃Availability
􀂄􀀃Accuracy
􀂄􀀃Throughput
􀂄􀀃Response time
􀂄􀀃Recovery time
􀂄􀀃Resource usage

Supportability
Supportability requirements may include:
􀂄􀀃Testability
􀂄􀀃Extensibility
􀂄􀀃Adaptability
􀂄􀀃Maintainability
􀂄􀀃Compatibility
􀂄􀀃Configurability
􀂄􀀃Serviceability
􀂄􀀃Installability
􀂄􀀃Localizability (internationalization)

Design Requirements
A design requirement, often called a design constraint, specifies or constrains the
design of a system. Design constraints can be imposed by other standards, hardware
limitations, etc.

Implementation Requirements
An implementation requirement specifies or constrains the coding or construction of a
system. Examples are:
􀂄􀀃Required standards
􀂄􀀃Implementation languages
􀂄􀀃Policies for database integrity
􀂄􀀃Resource limits
􀂄􀀃Operation environments
Interface Requirements
An interface requirement specifies
􀂄􀀃An external item with which a system must interact, or
􀂄􀀃Constraints on formats, timings, or other factors used by such an interaction.

Standards Compliance
This subsection should specify the requirements derived from existing standards or
regulations.
They might include:
􀂄􀀃Report format
􀂄􀀃Data naming
􀂄􀀃Accounting procedures
􀂄􀀃Audit Tracing - For example, this could specify the requirement for software to
trace processing activity. Such traces are needed for some applications to meet
minimum government or financial standards. An audit trace requirement might,
for example, state that all changes to a payroll database must be recorded in a
trace file with before and after values.

Hardware Limitations
This subsection could include requirements for the software to operate inside various
hardware constraints. For example, these could include:
􀂄􀀃Hardware configuration characteristics (number of ports, instruction sets, etc.)
􀂄􀀃Limits on primary and secondary memory
􀂄􀀃Number of users the machine can handle at any given time

User Interfaces
This should specify:
1) The characteristics that the software must support for each human interface to the
software product. For example, if the user of the system operates through a display
terminal, the following should be specified:
􀂄􀀃Required screen format
􀂄􀀃Page layout and contents of any reports or menu
􀂄􀀃Relative timing of inputs and outputs
􀂄􀀃Availability of some form of programmable function keys
2) All the aspects of optimizing the interface with the person who must use the
system. This may simply comprise a list of do's and don'ts on how the system will
appear to the user. One example might be a requirement for the option of long or
short error messages. Like all others, these requirements should be verifiable and for
example, a clerk typist grade 4 can do function X in Z minutes after 1 hr of training
rather than a typist can do function X. (This might also be specified in the Attributes
section under a section titled Ease of Use.)
3) If the user specifies any particular interface that must be present then that must be
documented. Some examples of these interfaces are:
􀂄􀀃Provision of screen and field level help
􀂄􀀃Navigating from one function to another
􀂄􀀃Initializing the screen
􀂄􀀃Canceling the operation
􀂄􀀃Screen navigation
􀂄􀀃Pre-Printed stationeries
􀂄􀀃Multiple copies or single
􀂄􀀃80 col. or 132 col.
4. Terms and Conditions
By signing this document, I am agreeing to have provided complete information on the
product that will be developed. The product will be developed according to the specifications
listed in this document unless decreed otherwise By signing this document, I am indicating
that I am satisfied by the information present here and I am giving the company a full go-
head to build the product based on the information listed in this document.

<Project Manager> <Client Sign-off point>