Szoftverkövetelmények

A szoftverkövetelmények a célrendszer jellemzőinek és funkcióinak leírása. A követelmények közvetítik a felhasználók elvárásait a szoftvertermékkel szemben. A követelmények lehetnek nyilvánvalóak vagy rejtett, ismertek vagy ismeretlenek, az ügyfél szempontjából elvártak vagy váratlanok.

Követelménytervezés

A szoftverkövetelmények ügyféltől való összegyűjtésének, elemzésének és dokumentálásának folyamatát követelménytervezésnek nevezzük.

A követelménytervezés célja a kifinomult és leíró “Rendszerkövetelmény-specifikáció” dokumentum kidolgozása és karbantartása.

Követelménytervezési folyamat

Ez a folyamat négy lépésből áll, amely magában foglalja –

• Megvalósíthatósági tanulmány
• Követelménygyűjtés
• Szoftverkövetelmény specifikáció
• Szoftverkövetelmény validálás

Lássuk röviden a folyamatot –

Megvalósíthatósági tanulmány

Mikor az ügyfél megkeresi a szervezetet a kívánt termék kifejlesztése érdekében, nagyjából elképzelése van arról, hogy a szoftvernek milyen funkciókat kell ellátnia, és milyen funkciókat várnak el a szoftvertől.

Ezekre az információkra hivatkozva az elemzők részletes tanulmányt készítenek arról, hogy a kívánt rendszer és annak funkciói megvalósíthatók-e a fejlesztés során.

Ez a megvalósíthatósági tanulmány a szervezet céljaira összpontosít. Ez a tanulmány azt elemzi, hogy a szoftvertermék megvalósítható-e a gyakorlatban a megvalósítás, a projekt szervezethez való hozzájárulása, a költségkorlátok, valamint a szervezet értékei és célkitűzései szerint. Megvizsgálja a projekt és a termék műszaki szempontjait, például a használhatóságot, a karbantarthatóságot, a termelékenységet és az integrálhatóságot.

Ez a szakasz eredménye egy megvalósíthatósági tanulmány jelentés, amelynek megfelelő megjegyzéseket és ajánlásokat kell tartalmaznia a vezetőség számára arról, hogy a projektet érdemes-e megvalósítani.

Követelménygyűjtés

Ha a megvalósíthatósági jelentés pozitívan áll a projekt megvalósításához, a következő szakasz a felhasználói követelmények összegyűjtésével kezdődik. Az elemzők és a mérnökök kommunikálnak az ügyféllel és a végfelhasználókkal, hogy megismerjék az elképzeléseiket arról, hogy mit kell nyújtania a szoftvernek, és milyen funkciókat szeretnének, hogy a szoftver tartalmazzon.

Szoftverkövetelményspecifikáció

A szoftverkövetelményspecifikáció egy olyan dokumentum, amelyet a rendszerelemző a különböző érdekelt felektől összegyűjtött követelményeket követően hoz létre.

A SRS meghatározza, hogy a tervezett szoftver hogyan fog kölcsönhatásba lépni a hardverrel, a külső interfészekkel, a működési sebességgel, a rendszer válaszidejével, a szoftver különböző platformokon való hordozhatóságával, a karbantarthatósággal, az összeomlás utáni helyreállítás sebességével, a biztonsággal, a minőséggel, a korlátozásokkal stb. kapcsolatban.

Az ügyféltől kapott követelmények természetes nyelven íródnak. A rendszerelemző felelőssége, hogy a követelményeket műszaki nyelven dokumentálja, hogy azok a szoftverfejlesztő csapat számára érthetőek és hasznosak legyenek.

Az SRS-nek a következő jellemzőkkel kell rendelkeznie:

• A felhasználói követelmények természetes nyelven vannak megfogalmazva.
• A műszaki követelmények strukturált nyelven vannak megfogalmazva, amelyet a szervezeten belül használnak.
• A tervezési leírást álkódban kell megírni.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions –

• If they can be practically implemented
• If they are valid and as per functionality and domain of software
• If there are any ambiguities
• If they are complete
• If they can be demonstrated

Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:

• Követelménygyűjtés – A fejlesztők megbeszélik az ügyféllel és a végfelhasználókkal, és megismerik a szoftverrel szembeni elvárásaikat.
• Követelmények rendszerezése – A fejlesztők fontossági sorrendbe állítják és elrendezik a követelményeket fontosság, sürgősség és kényelem szerint.

• Tárgyalás & megbeszélés – Ha a követelmények nem egyértelműek, vagy a különböző érdekelt felek követelményei között ellentmondások vannak, ha vannak, akkor azt megtárgyalják és megvitatják az érdekelt felekkel. A követelményeket ezután lehet rangsorolni és ésszerű kompromisszumokat kötni.

  A követelmények a különböző érdekelt felektől származnak. A kétértelműség és a konfliktusok megszüntetése érdekében megvitatják őket az egyértelműség és a helyesség érdekében. Az irreális követelményeket ésszerűen kompromittálják.

• Dokumentáció – Minden formális & informális, funkcionális és nem funkcionális követelményt dokumentálnak, és a következő fázisban történő feldolgozáshoz rendelkezésre bocsátanak.

Követelménykikérdezési technikák

A követelmények kikérdezése a tervezett szoftverrendszerre vonatkozó követelmények kiderítésének folyamata az ügyféllel, végfelhasználókkal, rendszerhasználókkal és más, a szoftverrendszer fejlesztésében érdekelt személyekkel való kommunikáció révén.

A követelmények feltárásának különböző módjai vannak

Interjúk

Az interjúk a követelmények gyűjtésének erős eszközei. A szervezet többféle típusú interjút is lefolytathat, például:

• Szerkesztett (zárt) interjúk, ahol minden egyes összegyűjtendő információt előre eldöntöttek, a beszélgetés mintáját és tárgyát szigorúan követik.
• Nem strukturált (nyílt) interjúk, ahol a gyűjtendő információkat nem döntik el előre, rugalmasabbak és kevésbé elfogultak.
• Szóbeli interjúk
• Írásos interjúk
• Egyszemközti interjúk, amelyeket két személy között tartanak az asztal túloldalán.
• Csoportos interjúk, amelyeket a résztvevők csoportjai között tartanak. Segítenek feltárni minden hiányzó követelményt, mivel számos ember vesz részt.

Felmérések

A szervezet felméréseket végezhet a különböző érdekeltek körében, lekérdezéssel az elvárásaikról és követelményeikről a készülő rendszerrel szemben.

Kérdőívek

Az összes érdekelt félnek átadnak egy dokumentumot, amely előre meghatározott objektív kérdéseket és a megfelelő opciókat tartalmazza, hogy válaszoljanak, amelyeket összegyűjtenek és összeállítanak.

A technika hiányossága, hogy ha a kérdőívben nem szerepel valamely kérdésre vonatkozó opció, a kérdés esetleg figyelmen kívül marad.

Feladatelemzés

A mérnökök és fejlesztők csapata elemezheti azt a műveletet, amelyhez az új rendszerre van szükség. Ha az ügyfél már rendelkezik valamilyen szoftverrel egy bizonyos művelet elvégzésére, akkor azt tanulmányozzák, és összegyűjtik a javasolt rendszer követelményeit.

Tartományelemzés

Minden szoftver valamilyen tartományi kategóriába tartozik. Az általános és specifikus követelmények elemzésében nagy segítséget nyújthatnak az adott terület szakértői.

Brainstorming

A különböző érdekelt felek között informális vitát tartanak, és minden inputjukat rögzítik a további követelményelemzéshez.

Prototipizálás

A prototipizálás a felhasználói felület megépítése anélkül, hogy részletes funkciókat adnának hozzá, hogy a felhasználó értelmezni tudja a tervezett szoftvertermék jellemzőit. Segít jobb képet adni a követelményekről. Ha az ügyfélnél nincs telepített szoftver a fejlesztő számára referenciaként, és az ügyfél nincs tisztában a saját követelményeivel, a fejlesztő prototípust készít az eredetileg említett követelmények alapján. A prototípust megmutatja az ügyfélnek, és feljegyzi a visszajelzéseket. Az ügyfél visszajelzései szolgálnak inputként a követelménygyűjtéshez.

Figyelés

A szakértői csapat ellátogat az ügyfél szervezetébe vagy munkahelyére. Megfigyelik a meglévő telepített rendszerek tényleges működését. Megfigyelik a munkafolyamatokat az ügyfélnél, és azt, hogy hogyan kezelik a végrehajtási problémákat. The team itself draws some conclusions which aid to form requirements expected from the software.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

Software Requirements

We should try to understand what sort of requirements may arise in the requirement elicitation phase and what kinds of requirements are expected from the software system.

Tágabb értelemben a szoftverkövetelményeket két kategóriába kell sorolni:

Funkcionális követelmények

A szoftver funkcionális aspektusával kapcsolatos követelmények tartoznak ebbe a kategóriába.

A szoftverrendszeren belüli és a szoftverrendszerből származó funkciókat és funkciókat határozzák meg.

Példák –

• A felhasználónak adott keresési lehetőség a különböző számlák közötti keresésre.
• A felhasználónak képesnek kell lennie arra, hogy bármilyen jelentést elküldhessen a vezetőségnek.
• A felhasználók csoportokba oszthatók, és a csoportok külön jogokat kaphatnak.
• Meg kell felelnie az üzleti szabályoknak és az adminisztrációs funkcióknak.
• A szoftver fejlesztése a lefelé kompatibilitás megtartásával történik.

Nem funkcionális követelmények

Azok a követelmények, amelyek nem kapcsolódnak a szoftver funkcionális aspektusához, ebbe a kategóriába tartoznak. Ezek a szoftver implicit vagy elvárt jellemzői, amelyeket a felhasználók feltételeznek.

A nem funkcionális követelmények közé tartoznak.

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Disaster recovery
• Accessibility

Requirements are categorized logically as

• Must Have : Software cannot be said operational without them.
• Should have : Enhancing the functionality of software.
• Could have : Software can still properly function with these requirements.
• Wish list : These requirements do not map to any objectives of software.

While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of debate with stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for software updates.

User Interface requirements

UI is an important part of any software or hardware or hybrid system. A software is widely accepted if it is –

• easy to operate
• quick in response
• effectively handling operational errors
• providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only way for users to perceive the system. A well performing software system must also be equipped with attractive, clear, consistent and responsive user interface. Otherwise the functionalities of software system can not be used in convenient way. A system is said be good if it provides means to use it efficiently. User interface requirements are briefly mentioned below –

• Content presentation
• Easy Navigation
• Simple interface
• Responsive
• Consistent UI elements
• Feedback mechanism
• Default settings
• Purposeful layout
• Strategical use of color and texture.
• Súgóinformációk nyújtása
• Használóközpontú megközelítés
• Group based view settings.

Software System Analyst

A rendszerelemző egy IT szervezetben olyan személy, aki elemzi a javasolt rendszer követelményeit, és biztosítja, hogy a követelmények megfelelően & fogantak és dokumentáltak legyenek. Az elemző szerepe az SDLC szoftverelemzési fázisában kezdődik. Az elemző felelőssége annak biztosítása, hogy a kifejlesztett szoftver megfeleljen az ügyfél követelményeinek.

A rendszerelemzőknek a következő feladatai vannak:

• A tervezett szoftver követelményeinek elemzése és megértése
• Az, hogy a projekt hogyan járul hozzá a szervezet céljaihoz
• A követelmény forrásainak azonosítása
• A követelmény validálása
• A követelménykezelési terv kidolgozása és végrehajtása
• Az üzleti, technikai, folyamat- és termékkövetelmények
• Koordináció az ügyfelekkel a követelmények rangsorolása, valamint a kétértelműségek megszüntetése érdekében
• Az elfogadási kritériumok véglegesítése az ügyféllel és más érdekeltekkel

Szoftver mérőszámok és mérések

A szoftver mérések a szoftver különböző tulajdonságainak és aspektusainak számszerűsítésére és szimbolizálására szolgáló folyamatként értelmezhetők.

A szoftver mérőszámok a szoftverfolyamat és a szoftvertermék különböző aspektusainak mérőszámait biztosítják.

A szoftver mérőszámok a szoftverfejlesztés alapvető követelményei. Nemcsak a szoftverfejlesztési folyamat ellenőrzésében segítenek, hanem abban is, hogy a végső termék minősége kiváló maradjon.

A Tom DeMarco (szoftvermérnök) szerint “Nem tudod ellenőrizni azt, amit nem tudsz mérni”. Az ő mondása alapján teljesen világos, hogy mennyire fontosak a szoftveres mérőszámok.

Lássunk néhány szoftveres mérőszámot:

• Mérőszámok – LOC (Lines of Code), többnyire a leszállított forráskódsorok ezreiben számolva, KLOC-ként jelölve.

  A funkciós pontok száma a szoftver által nyújtott funkcionalitás mérőszáma. A Function Point Count a szoftver funkcionális aspektusának méretét határozza meg.

• Komplexitás mérőszámok – A McCabe-féle ciklomatikus komplexitás a programban található független utak számának felső határát számszerűsíti, amit a program vagy a modulok komplexitásaként fogunk fel. Ezt gráfelméleti fogalmakkal, vezérlésáramlási gráf segítségével ábrázoljuk.

• Minőségi metrikák – A hibák, azok típusai és okai, következménye, súlyosságának intenzitása és következményei határozzák meg a termék minőségét.

  The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of product.

• Process Metrics – In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics.
• Resource Metrics – Effort, time and various resources used, represents metrics for resource measurement.