A szoftverkövetelmény-előírás (SRS) egy olyan dokumentum, amely leírja egy projekt, szoftver vagy alkalmazás jellegét. Egyszerűen fogalmazva, az SRS dokumentum egy projekt kézikönyve, feltéve, hogy a projekt/alkalmazás elindítása előtt elkészül. Ez a dokumentum SRS-jelentés, szoftverdokumentum néven is ismert. A szoftverdokumentum elsősorban egy projekthez, szoftverhez vagy bármilyen alkalmazáshoz készül.
A szoftverkövetelményspecifikációs dokumentum elkészítése során számos iránymutatást kell követni. Ez magában foglalja a projekt célját, hatályát, funkcionális és nem funkcionális követelményeit, szoftver- és hardverkövetelményeit. Ezen kívül tartalmazza a szükséges környezeti feltételekről, a biztonsági és védelmi követelményekről, a projekt szoftverminőségi jellemzőiről stb. szóló információkat is.
What is a Software Requirements Specification document?
A Software requirements specification document describes the intended purpose, requirements and nature of a software to be developed. It also includes the yield and cost of the software.
In this document, flight management project is used as an example to explain few points.
Table of Contents
Suggested Read:
- SRS report for a Lab Administration project
INTRODUCTION
1.1 PURPOSE
The purpose of this document is to build an online system to manage flights and passengers to ease the flight management. <<Include the purpose as applicable to your project >>
1.2 DOCUMENT CONVENTIONS
This document uses the following conventions. <<Include the conventions as per your application >>
| DB | Database |
| DDB | Distributed Database |
| ER | Entity Relationship |
1.3 INTENDED AUDIENCE AND READING SUGGESTIONS
This project is a prototype for the flight management system and it is restricted within the college premises. This has been implemented under the guidance of college professors. Ez a projekt hasznos a járatkezelő csapat és az utasok számára is.
1.4 PROJEKT HATÓKÖRE
Az online járatkezelő rendszer célja, hogy megkönnyítse a járatok kezelését, és egy kényelmes és könnyen használható alkalmazást hozzon létre az utasok számára, akik repülőjegyet próbálnak vásárolni. A rendszer egy relációs adatbázisra épül a járatkezelési és foglalási funkciókkal. Lesz egy adatbázis-szerverünk, amely a világ több száz nagyvárosát, valamint a különböző légitársaságok több ezer járatát támogatja. Mindenekelőtt azt reméljük, hogy kényelmes felhasználói élményt nyújtunk az elérhető legjobb árképzés mellett.
1.5 Hivatkozások
- Fundamentals of database systems by ramez elmarsi and shamkant b.navathe
ÁLTALÁNOS LEÍRÁS
2.1 TERMÉLETI ELEMZŐ
Egy elosztott légitársasági adatbázisrendszer a következő információkat tárolja.
- A járat adatai:
Ez tartalmazza a kiindulási és a célállomás terminálját, a közbeeső megállókkal együtt, a két célállomás között lefoglalt/elérhető helyek számát stb. - Ügyfél leírása:
Ez tartalmazza az ügyfélkódot, a nevet, a címet és a telefonszámot. Ez az információ felhasználható az ügyfél nyilvántartásának vezetésére bármilyen vészhelyzet vagy egyéb információ esetén. - Foglalás leírása:
Ez tartalmazza az ügyfél adatait, a kódszámot, a járat számát, a foglalás dátumát, az utazás dátumát.
2.2. TERMÉKJELLEMZŐK
A légitársasági adatbázis-rendszer főbb jellemzői az alábbi entitás-kapcsolati modell (ER-modell)
A diagram a légitársasági adatbázis-rendszer felépítését mutatja – entitás-kapcsolati modell
2.3 FELHASZNÁLÓI OSZTÁLY és JELLEMZŐK
A rendszer felhasználóinak képesnek kell lenniük arra, hogy az adatbázisból lekérdezzék a két adott város közötti járatinformációkat az adott utazási dátummal/időponttal. Az A városból B városba tartó útvonal az A és B közötti csatlakozó járatok olyan sorozata, amelynél: a) legfeljebb két átszállás van, kivéve az utazás kiinduló és célvárosát, b) az átszállási idő egy és két óra között van. A rendszer kétféle felhasználói jogosultságot támogat: Ügyfél és Alkalmazott. Az ügyfelek az ügyfélfunkciókhoz, az alkalmazottak pedig mind az ügyfél-, mind a járatkezelési funkciókhoz hozzáférnek. Az ügyfélnek a következő funkciókat kell tudnia:
- Új foglalás készítése
– Egyirányú
– oda-vissza út
– Több város
– Rugalmas dátum/időpont
– Visszaigazolás
- Meglévő foglalás törlése
- útvonaltervének megtekintése
A munkavállalónak a következő kezelési funkciókkal kell rendelkeznie:
- VÁLLALKOZÁSI FUNKCIÓK.
– Az összes olyan ügyfél lekérdezése, akinek egy adott járatra foglalt helye van.
– Az összes járat lekérdezése egy adott repülőtérre.
– A járatok menetrendjének megtekintése.
– Az összes olyan járat lekérdezése, amelyek érkezési és indulási ideje pontos/késve van.
– Az összes eladás kiszámítása egy adott járatra.
- ADMINISZTRATÍV
– Járat hozzáadása/törlése
– Új repülőtér hozzáadása
– A járatok viteldíjának frissítése.
– Új járatszakasz példány hozzáadása.
– A járatszakasz példányok indulási/érkezési idejének frissítése.
Minden járat korlátozott számú szabad ülőhellyel rendelkezik. Számos olyan járat van, amely különböző városokból indul vagy különböző időpontokban érkezik különböző városokba.
2.4. ÜZEMELTETÉSI KÖRNYEZET
A légitársaság-irányítási rendszer működési környezete az alábbiak szerint alakul. <<Az alkalmazásnak megfelelő részletek >>
- elosztott adatbázis
- kliens/szerver rendszer
- működő rendszer:
- adatbázis: sql+ adatbázis
- platform: vb.net/Java/PHP
2.5 TERVEZÉS és MEGVALÓSÍTÁS KÖTELEZŐK
- A globális séma, a töredezettségi séma és a kiosztási séma.
- SQL parancsok a fenti lekérdezésekhez/alkalmazásokhoz
- Hogyan generálódik a válasz az 1. és 2. alkalmazáshoz. Feltételezve, hogy ezek globális lekérdezések. Magyarázza el, hogy a különböző fragmentumok hogyan lesznek ehhez kombinálva.
- Az adatbázis megvalósítása legalább egy központosított adatbázis-kezelő rendszer segítségével.
2.6 FELTÉTELES FELTÉTELEK
Tegyük fel, hogy ez egy elosztott légitársaság-kezelő rendszer, és a következő alkalmazásban használjuk:
- Egy járat foglalására/lemondására vonatkozó kérés bármely forrásból bármely célállomásra, kapcsolt járatokat adva abban az esetben, ha a megadott forrás-célállomás pár között nincs közvetlen járat.
- A sokat utazók (leggyakrabban utazók) kiszámítása és megfelelő jutalompontok kiszámítása ezen utazók számára.
Tételezve, hogy mindkét tranzakció egyszeri tranzakció, egy elosztott adatbázist terveztünk, amely földrajzilag négy városban van elszórva: Delhi, Mumbai, Chennai és Kolkatta, amint az az ábrán látható.
RENDSZERJELLEMZŐK
- LEÍRÁS és PRIORITÁS
A légitársaság foglalási rendszere információkat tart fenn a járatokról, a helyosztályokról, a személyes preferenciákról, az árakról és a foglalásokról. Természetesen ez a projekt kiemelt prioritást élvez, mivel előzetes foglalás nélkül nagyon nehéz országok között utazni.
- STIMULUS/RESZPONZSZEKCIÓK
- Légitársasági járatok keresése két utazási városra
- A rendelkezésre álló járatok részletes listájának megjelenítése és “Foglalás” vagy jegyfoglalás egy adott járatra.
- Meglévő foglalás törlése.
- FUNCTIONAL REQUIREMENTS
- Some sites are client sites and others are server sites.
- All the data resides at the server sites.
- All applications execute at the client sites.
- Front-end software: Vb.net version
- Back-end software: SQL+
- Windows.
- A browser which supports CGI, HTML & Javascript.
- ENTITÁSOK: Amelyek egy alkalmazásban megkülönböztetett, valós világbeli elemeket határoznak meg.
- PROPERTIES/ATTRIBUTES: Amelyek egy entitás és a kapcsolatok tulajdonságait határozzák meg.
- KAPCSOLATOK: Amelyek összekötik az entitásokat, és értelmes függőségeket jelentenek közöttük.
- KAPHATÓSÁG: A járatnak a megadott napon és a megadott időpontban elérhetőnek kell lennie, mivel sok ügyfél végez előzetes foglalásokat.
- KORREKTRÁLISÁG: A járatnak a helyes indulási terminálról kell indulnia és a helyes célállomásra kell érkeznie.
- MEGFELELŐSSÉG: Az adminisztrátoroknak és a járatok töltőinek a járatok helyes menetrendjét kell fenntartaniuk.
- HASZNÁLHATÓSÁG: A járatok menetrendjének a lehető legtöbb ügyfél igényét ki kell elégítenie.
Other system features include:
DISTRIBUTED DATABASE:
Distributed database implies that a single application should be able to operate transparently on data that is spread across a variety of different databases and connected by a communication network as shown in below figure.
Distributed database located in four different cities
CLIENT/SERVER SYSTEM
The term client/server refers primarily to an architecture or logical division of responsibilities, the client is the application (also known as the front-end), and the server is the DBMS (also known as the back-end).
A client/server system is a distributed system in which,
EXTERNAL INTERFACE REQUIREMENTS
4.1 USER INTERFACES
4.2 HARDWARE INTERFACES
4.3 SOFTWARE INTERFACES
Following are the software used for the flight management online application. <<Include the software details as per your project >>
| Software used | Description |
| Operating system | We have chosen Windows operating system for its best support and user-friendliness. |
| Database | To save the flight records, passengers records we have chosen SQL+ database. |
| VB.Net | To implement the project we have chosen Vb.Net language for its more interactive support. |
4.4 COMMUNICATION INTERFACES
This project supports all types of web browsers. A foglalási űrlapokhoz, jegyfoglaláshoz stb. egyszerű elektronikus űrlapokat használunk.
NONFUNKCIÓS KÖVETELMÉNYEK
5.1 TELJESÍTÉSI KÖVETELMÉNYEK
A légitársasági adatbázis megvalósításának lépései az alábbiakban vannak felsorolva.
A) E-R DIAGRAM
Az E-R diagram az adatbázis logikai szerkezetének képi ábrázolásának technikáját jelenti. Ezt az elemzést azután az adatok relációként való szervezésére, a reláció normalizálására és végül egy relációs adatbázis előállítására használjuk.
B) NORMALIZÁCIÓ:
A normalizálás alapvető célja a redundancia csökkentése, ami azt jelenti, hogy az információt csak egyszer kell tárolni. Az információ többszöri tárolása a tárhely pazarlásához és a tárolt adatok összméretének növekedéséhez vezet.
Ha egy adatbázis nem megfelelően van kialakítva, akkor módosítási anomáliákhoz vezethet. A módosítási anomáliák akkor keletkeznek, amikor adatokat adnak hozzá, módosítanak vagy törölnek egy adatbázis-táblából. Hasonlóképpen a hagyományos adatbázisokban és a nem megfelelően tervezett relációs adatbázisokban is problémát jelenthet az adatredundancia. Ezek kiküszöbölhetők az adatbázis normalizálásával.
A normalizálás egy tábla kisebb táblákra bontásának folyamata. Úgy, hogy minden egyes tábla egyetlen témával foglalkozik. Az anomáliák módosításának három különböző fajtája létezik, és az első, második és harmadik normálforma (3NF) megfogalmazása a legtöbb gyakorlati célra elegendőnek tekinthető. Ezt csak alapos elemzés és a következmények teljes megértése után szabad megfontolni.
5.2 BIZTONSÁGI FELTÉTELEK
Ha az adatbázis nagy része katasztrofális meghibásodás, például lemezösszeomlás miatt nagymértékben károsodik, a helyreállítási módszer visszaállítja az adatbázis egy archív tárolóra (jellemzően szalagra) mentett múltbeli példányát, és a mentett naplóból a hiba időpontjáig az elkötelezett tranzakciók műveleteinek újbóli alkalmazásával vagy újra elvégzésével rekonstruálja az aktuálisabb állapotot.
5.3 BIZTONSÁGI KÖVETELMÉNYEK
A biztonsági rendszereknek ugyanúgy szükségük van adatbázis-tárolásra, mint sok más alkalmazásnak. A biztonsági piac speciális követelményei azonban azt jelentik, hogy a gyártóknak gondosan kell megválasztaniuk az adatbázis-partnert.
5.4 SZOFTVER MINŐSÉGI JELLEMZŐK