2. Követelmények (Requirements)

Hasonló dokumentumok
A követelm. vetelmény. analízis fázis. Az analízis fázis célja. fázis feladata

Információtartalom vázlata

Szoftvertechnológia 2008/2009. tanév 2. félév 6. óra. Szoftvertechnológia

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E

Verifikáció és validáció Általános bevezető

Szoftverdokumentáció

Követelmény meghatározás. Információrendszer fejlesztés módszertana, Dr. Molnár Bálint egyetemi docens 1

Szoftvertechnológia 2008/2009. tanév 2. félév 7. óra. Szoftvertechnológia

Szoftvertechnológia ellenőrző kérdések 2005

Bevezetés a programozásba

Bevezetés Mi a szoftver? Általános termékek: Mi a szoftvertervezés?

S01-7 Komponens alapú szoftverfejlesztés 1

01. gyakorlat - Projektalapítás

SZÁMALK SZAKKÖZÉPISKOLA

Autóipari beágyazott rendszerek Dr. Balogh, András

Web-programozó Web-programozó

evosoft Hungary Kft.

IT ügyfélszolgálat és incidenskezelés fejlesztése az MNB-nél

Bánsághi Anna Bánsághi Anna 1 of 54

SW-project management

Szoftverfejlesztő Informatikai alkalmazásfejlesztő

vbar (Vemsoft banki BAR rendszer)

MINISZTERELNÖKI HIVATAL. Szóbeli vizsgatevékenység

MINISZTERELNÖKI HIVATAL. Szóbeli vizsgatevékenység

MINTA Projektterv 2007

Tartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet

Név: Neptun kód: Pontszám:

A TANTÁRGY ADATLAPJA

PROGRAMTERVEZŐ INFORMATIKUS ALAPKÉPZÉSI SZAK

Agilis projektmenedzsment

Vezetői beszámoló Kerekegyháza Polgármesteri Hivatala ÁROP hivatali szervezetfejlesztésről

Projectvezetők képességei

Szoftver követelmények meghatározása

Értékesítések (összes, geográfiai -, ügyfelenkénti-, termékenkénti megoszlás)

7. A követelménytervezés folyamata

Tapasztalatok és teendők a szabvány változások kapcsán

Informatikai projektellenőr szerepe/feladatai Informatika / Az informatika térhódítása Függőség az információtól / informatikától Információs

DW 9. előadás DW tervezése, DW-projekt

Egyetemi adatbázis nyilvántartása és weben

A fejlesztési szabványok szerepe a szoftverellenőrzésben

S S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN. Structured Systems Analysis and Design Method

Minőségmenedzsment alapok

Ütemezés tervezése A leghátrányosabb helyzet kistérségek fejlesztési és együttm ködési kapacitásainak meger

Rendszer szekvencia diagram

S atisztika 2. előadás

Szervezetfejlesztés megvalósítása Nagykáta Város Önkormányzati Hivatalában ÁROP-3.A

Gyakorlati vizsgatevékenység A

Humán Erőforrás Menedzsment a General Motors Powertrain Magyarországnál. Toborzás Kiválasztás - Interjú

Jelentkezési határidő nappalis képzésre: július 13. A beiratkozás időpontja: augusztus 1. 9 óra

Nyomtatók, kiegészítők és állványok kompatibilitási útmutatója

Logikai adatmodell kialakítása

1. SZÁMÚ FÜGGELÉK MŰSZAKI LEÍRÁS

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban

PROJEKTMENEDZSERI ÉS PROJEKTELLENŐRI FELADATOK

INFORMATIKAI PROJEKTELLENŐR

Szakterületi modell A fogalmak megjelenítése. 9. fejezet Applying UML and Patterns Craig Larman

Jelentkezési határidő: július 31. nappali / augusztus 26. esti

ALKALMAZÁS KERETRENDSZER

Témaválasztás, kutatási kérdések, kutatásmódszertan

Személyügyi gazdálkodó és fejlesztő. Személyügyi gazdálkodó és fejlesztő É 1/5

Funkciópont elemzés: elmélet és gyakorlat

Hitelintézeti Szemle Lektori útmutató

A vezetőség felelősségi köre (ISO 9001 és pont)

2 A JELENTÉS FELÉPÍTÉSE...2

Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve

Gyakorlati vizsgatevékenység B

IV/4. sz. melléklet: Kontrolling és döntéstámogatás funkcionális specifikáció

IRÁNYTŰ A SZABÁLYTENGERBEN

Tisztelettel köszöntöm a RITEK Zrt. Regionális Információtechnológiai Központ bemutatóján.

Regiszterek létrehozása és működtetése

Információs rendszerek Információsrendszer-fejlesztés

Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár

MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI

5. Témakör TARTALOMJEGYZÉK

Megoldás. Feladat 1. Statikus teszt Specifikáció felülvizsgálat

Létesítménygazdálkodási szabványok a klubmenedzsmentben

Programrendszerek tanúsítása szoftverminőség mérése

Univerzális munkafolyamat szimulátor

Címtár Felhő Projektfeladat specifikáció

30 MB INFORMATIKAI PROJEKTELLENŐR

HASZNÁLATI ESET DIAGRAM (USE CASE DIAGRAM)

Telepítési útmutató a Solid Edge ST7-es verziójához Solid Edge

Szoftver-technológia II. Architektúrák dokumentálása UML-lel. Irodalom. Szoftver-technológia II.

Szoftverminőségbiztosítás

Informatikai prevalidációs módszertan

A projektvezetési eszköz implementációja hazai építő-, szerelőipari vállalkozásoknál

ESZKÖZTÁMOGATÁS A TESZTELÉSBEN

Szoftverfejlesztő képzés tematika oktatott modulok

Ami a vízesésen túl van

HOGYAN JELEZHETŐ ELŐRE A

III. Alapfogalmak és tervezési módszertan SystemC-ben

Feuerbach kör tanítása dinamikus programok segítségével

Szoftverminőségbiztosítás

Tartalommenedzser képzés tematika oktatott modulok

Folyamatmenedzsment módszerek a projekt menedzsment eszköztárában

Hogyan tudom soros eszközeimet pillanatok alatt hálózatba kötni?

Integrált Városfejlesztési Stratégia kiindulás

Programtervezés. Dr. Iványi Péter

Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Web:

Hát én immár mit válasszak?

Átírás:

2. Követelmények (Requirements) A szoftverfejlesztés első lépése a specifikáció, vagy más néven a követelménytervezés, amelynek célja, hogy meghatározzuk milyen szolgáltatásokat követelünk meg a rendszertől, és hogy a rendszer fejlesztésének és működtetésének milyen megszorításait alkalmazzuk. A követelmények tervezése a szoftverfolyamat különösen kritikus szakasza, azaz az ebben a szakaszban elkövetett hibák elkerülhetetlenül problémákhoz vezetnek majd a rendszertervezés későbbi szakaszában és az implementációban Követelménytervezés lépései: - Követelmények feltárása, elemzése (cél a rendszer jobb megértése, követelmények elemzése) - Követelményspecifikáció (az elemzési tevékenységből összegyűjtött információk egységes dokumentummá való transzformálása) - Követelményvalidáció (ellenőrzi, hogy mennyire valószerűek, konzisztensek és teljesek a követelmények) 2.1. Követelmény típusok Alapvetően a követelményeknek két nagy csoportja van: - felhasználói követelmények: diagramokkal kiegészített természetes nyelvű kijelentések arról, hogy mely szolgáltatásokat várunk el a rendszertől, és annak mely megszorítások mellett kell működnie. Az ügyfelek és a fejlesztők képviselői számára készülnek, akik nem rendelkeznek részletes technikai ismerettel a rendszerről. - rendszerkövetelmények: a rendszerszolgáltatásokat és megszorításokat jelöli részletesen. A rendszerkövetelmények dokumentumának, amelyet néhol funkcionális specifikációnak is hívunk pontosnak kell lennie. Ez szolgálhat alapul a rendszer vásárlója és a szoftverfejlesztő közötti szerződésnek. Ezzel a vezető technikai személyzetet és a projektvezetőket ajánlott megcélozni. Ezt mind az ügyfél, mind a vállalkozó dolgozói használni fogják. A rendszer végfelhasználói mindkét dokumentumot olvasni fogják. A felhasználói követelmények olvasói így az alábbi csoportok: - ügyfélmenedzserek, - rendszer végfelhasználói, - rendszerépítők. A rendszerkövetelmények olvasói így az alábbi csoportok: - rendszer végfelhasználói, - rendszerépítők, - szoftverfejlesztők.

2.1.1. Rendszerkövetelmények A szoftver rendszerkövetelményeket gyakran felosztják funkcionális, illetve nem funkcionális követelményekre. - Funkcionális követelmények: a rendszer által nyújtandó szolgáltatások ismertetése arról, hogyan kell reagálnia a rendszernek bizonyos bemenetekre, valamint hogyan kell viselkednie bizonyos szituációkban. Itt gyakran azt is definiálják, hogy mit nem szabad tennie a rendszernek. A funkcionális követelményt leíró specifikáció legyen teljes és ellentmondásmentes! A teljesség azt jelenti, hogy a felhasználó által igényelt összes szolgáltatást definiáljuk. Az ellentmondásmentesség azt jelenti, hogy ne legyenek ellentmondó megállapítások. - Nem funkcionális követelmények: a rendszer által kínált funkciókra és szolgáltatásokra tett megszorítások. Ennek három típusát különböztetünk meg: - termékkövetelmény: a termék viselkedését meghatározó követelmények, pl. használhatósági, megbízhatósági, hatékonysági (milyen gyorsan kell futnia, mekkora a memória igénye), hordozhatósági követelmények. - szervezeti követelmény: ez a megrendelő és a fejlesztő szervezetének szabályzataira, és ügyrendjére vonatkozik, pl. telepítési, implementálási, szabvány követelmények. - külső: együttműködési, etikai, adatvédelmi, biztonsági követelmények. 2.1.2. Felhasználói követelmények A rendszer felhasználói követelményeinek a funkcionális és nem funkcionális követelményeket kell leírniuk úgy, hogy a rendszernek azon felhasználói is megértsék, akiknek nincsenek részletes technikai ismereteik. A rendszer külső viselkedését javallott leírni, és kerülni kell a technikai jellegű szakkifejezéseket. A felhasználói követelményeket természetes nyelven, űrlapok és egyszerű, könnyen értelmezhető diagramok segítségével kell közreadni. A természetes nyelven írt követelményeknél az alábbi változatos problémák merülhetnek fel: - Egyértelműség hiánya: olykor nehéz a nyelvet pontosan, egyértelmű módon használni. - Követelmények keveredése: gyakran a funkcionális, nem funkcionális követelmények nem különíthetők el tisztán. - Követelmények ötvöződése: gyakran több követelmény egyetlen követelményként fogalmazódik meg. Pl. Egy szerkesztőrácsra vonatkozó felhasználói követelmények: Az egyedek diagramon történő pozicionálását segítendő a felhasználó bekapcsolhat egy rácsot akár centiméteres, akár hüvelykes beosztással, a vezérlőpanelen lévő opció segítségével.

Néhány gyakorlati javaslat a felhasználói követelmények írásakor felmerülő problémák kiküszöbölésére: - A szükséges követelményekre használjuk a kell, míg a kívánatosakra a javallott kifejezéseket! - Használjunk szövegkiemelést a követelmények kulcsfontosságú részeinek hangsúlyozására!

2.2. Követelmények feltárása, elemzése (Reqirement analysis) "Érdemes-e a terméket kifejleszteni? Nincs-e már ilyen a piacon? A piacon lévő termékek elég jók-e? Van-e igény az én termékemre? Az én csapatom képes-e egy ilyen terméket előállítani?" Az elemzés, analízis, más néven a követelmények megfogalmazása a szoftverfejlesztés első lépcsőfoka, ami a követelmény specifikációt eredményezi majd. A követelményelemzés tevékenységei: - felhasználói igények elemzése - 2.2.1. A követelményelemzés tevékenységei: Felhasználói igények elemzése: - követelmények összegyűjtése: mi lesz a termék funkciója (mit akarnak vele csinálni?), milyen legyen a felhasználói felület, sebesség, kapacitás, költség, hardware háttér milyen, - osztályozás (követelmények strukturálatlan gyűjteményét összefüggő csoportokba szervezi), - ellentmondások feloldása (különböző kulcsfigurák számára más és más dolog lehet fontos), - fontossági sorrend felállítása - követelményellenőrzés (kiderüljön, hogy a követelmények teljesek-e, ellentmondásmentesek-e, és összhangban vannak-e azzal, amit a kulcsfigurák a rendszertől elvárnak). Az elemzés eszközei, módszerei: - dokumentumok begyűjtése, tanulmányozása, elemzése, - ismeretszerzés kérdőívek segítségével (kérdőívek készítése, kitöltése, kiírtékelése), Szerkesztésnél ügyeljünk arra, hogy minden érthető legyen, a kitöltés egyértelmű legyen! Mellékeljünk kitöltési útmutatót! Pontosan definiáljuk, hogy hány válasz a helyes! Kérdőív típusai: o Nyílt kérdőív: kérdés után nem adunk meg válaszokat, hanem üres helyet, ahova szabadon írhat a felhasználó. o Zárt kérdőív: a kérdőíven a válaszhoz mellékeljük a válaszlehetőségeket is.

o Vegyes: a kérdőív nyílt és zárt kérdéseket tartalmaz. - ötletbörzék, brain stormingok szervezése, - egyéni interjúk a felhasználókkal: o felhasználó igényei, óhajai, o prioritás az igények és az óhajok között, Interjúk előkészítésénél az alábbiakra kell odafigyelni: o Pontosan fel kell készülni, ismerni kell a szervezet céljait! o Ismerni kell az interjúalany beosztását, emberi jellemzőit! o Meg kell tervezni a beszélgetés, kérdések menetét! o Fel kell készülni, hogy a felhasználó nem fog elmondani egy sor dolgot a munkájával kapcsolatban, mert az számára teljesen természetes! o Időben előre meg kell beszélni az interjú időpontját, témáját, helyét, hogy az interjúalany is fel tudjon készülni! o Legyünk pontosak, ne késsünk! o Beszélgetés során partnerként kezeljük a másikat, kerüljük a szakzsargonokat! o Hagyni kell beszélni a partnert, de ugyanakkor ügyesen kell irányítani a beszélgetés fonalát! o Érdemes visszakérdezni időnként, hogy jól értettük-e az elmondottakat! o Jegyezzük fel a fontos dolgokat! o Ha valami fontos, akkor arra többféleképpen is rá kell kérdezni! o Maradjunk diplomatikusak, ne tegyünk megjegyzéseket se rá, se a munkatársaira! o Ne hagyjuk, hogy mobiltelefonunk, vagy bármi más megzavarja a beszélgetésünket! o Ne legyünk udvariatlanok, ne ásítozzunk, ne nézegessük az óránkat, ne bámuljunk kifelé az ablakon, hanem mutassunk érdeklődést - etnográfia: felhasználók tevékenységének figyelése (Az elemző elmélyed abban a környezetben ahol a rendszert majd használni fogják. Megfigyel, jegyzeteket készít, ugyanis az emberek mindennapi munkájuk részleteit gyakran nem tudják elmondani, hiszen rengeteg számukra evidens, rutinszerű munkát végeznek, ugyanakkor legtöbbször azt sem látják, hogy a munkájuk milyen összefüggésben van a szervezet többi munkájával.), - elméleti kutatás, analógia más rendszerekkel, - "gyakorlat" az adott alkalmazási területen, - Ishikawa (halszálka) diagram (az egyes feladatok elvégzésekor adódó problémák feltárására, problémák és, az ok-okozati összefüggések elemzésére szolgál. A diagramon fel kell tüntetni a tevékenységeket, és a tevékenységek végzésekor adódható problémákat.)

2.2.2. A követelményelemzés tevékenységei: Rendszerelemzés helyzetfelmérés, piackutatás (milyen termékek vannak már amelyek ilyen célt szolgálnak), szakterület megismerése (pl. ha áruházi rendszerre van szükség meg kell vizsgálni hogy működnek az áruházak), amelynek lépései: megfigyelés, a működési folyamatok végigkövetése, interjúk a folyamatban résztvevőkkel, a jelenlegi rendszer, továbbá a már használatban lévő rendszerek teljes megértése, a meglévő dokumentációk teljes áttekintése, tanulmányok készítése. 2.2.3. A követelményelemzés tevékenységei: Megvalósíthatóság vizsgálata A megvalósíthatósági tanulmány bemenetéül a rendszer körvonalazott leírása szolgál, és az hogy hogyan fogják majd használni a rendszert egy adott szervezeten belül. Meg kell becsülni, hogy a felhasználók igényei, kívánságai kielégíthetők-e az adott szoftver és hardvertechnológia mellett. A vizsgálatoknak el kell dönteniük, hogy a beterjesztett rendszer költséghatékony-e az adott üzleti szempontból, és hogy a meglévő költségvetési megszorításokkal kivitelezhető-e. Az eredménynek információkkal kell szolgálnia arról, hogy folytassuk-e a munkát egy még részletesebb elemzéssel, vagy sem. Az eredményeket ajánlott egy jelentésben összefoglalni, ami egy rövid, tömör tanulmány, amely számos kérdést próbál megválaszolni: - Támogatja-e a rendszer a vállalat általános célkitűzéseit? - Megvalósítható-e a rendszer a jelenlegi technológiával adott költségen belül és adott ütemezés szerint? - Integrálható-e a rendszer más, már használatban lévő rendszerekkel? Információforrást jelenthetnek annak az osztálynak a vezetői, ahol a rendszert használni fogják, azok a rendszerfejlesztők, akik már ismerik az olyan típusú rendszereket, amelyeket itt is terveznek használni, a technológiai szakértők, a rendszer végfelhasználói, stb 2.3. Követelmény specifikáció A szoftverkövetelmény specifikáció a rendszerfejlesztőkkel szemben támasztott eljárások hivatalos leírása. Ajánlott tartalmaznia a felhasználói követelményeket és a rendszerkövetelményeket. Úgy kell felépíteni, hogy a rendszer vevői és a szoftverfejlesztők számára is egyaránt használható legyen. 2.3.1. A követelménydokumentum használói A követelmény specifikáció használói:

- Megrendelők: meghatározzák a követelményeket és ellenőrzik, hogy azok megfelelnek-e az igényeknek. Változtatásokat adnak meg a követelményekhez. - Menedzserek: a követelménydokumentációt használják az áraajánlat elkészítéséhez és a rendszerfejlesztési folyamat tervezéséhez. - Rendszertervezők: a követelményeket használják annak megértéséhez, hogy milyen rendszert kell fejleszteni. - Rendszerteszttervezők: a követelményeket használják, hogy validációs teszteket készítsenek. - Rendszerkarbantartás tervezők: a követelményeket használják, hogy segítsenek megérteni az összefüggéseket a rendszer és a rendszer részei között. 2.3.2. A követelménydokumentum felépítése Az IEEE/ANSI 830-1993-as szabványa a követelménydokumentumoknál az alábbi szerkezetet javasolja: 1. Bevezetés 1.1. A követelmény dokumentum célja (körvonalazza a dokumentum célzott olvasóit) 1.2. A termék felhasználási területe 1.3. Definíciók, betűszavak és egyéb rövidítések (Definiálja a dokumentumban használt szakkifejezéseket, rövidítéseket. Az olvasó tapasztalatát vagy szakértelmét nem szabad feltételeznünk) 1.4. Hivatkozások (hivatkozások más dokumentumokra) 1.5. A dokumentum hátralevő részének áttekintése 2. Általános leírás 2.1. A termék áttekintése (Indokolja miért van szükség a rendszerre) 2.2. A termék funkciói (Leírja részletesen a rendszerrel szemben elvárt követelményeket, a megvalósítandó rendszer funkcióit részletesen megadja) 2.3. Használati jellemzők 2.4. Általános megszorítások 2.5. Feltételezések és függőségek 3. Speciális követelmények (Nem funkcionális és az interfészekre vonatkozó követelményeket takarja. Itt definiálhatjuk az interfészeket más rendszerekhez). 4. Függelék (Pl. hardver vagy adatbázis leírások. Hardver követelmények meghatározzák a rendszer minimális és optimális konfigurációját. Adatbázis követelmények meghatározzák a rendszer által használt adatok logikai szerkezetét és a köztük lévő kapcsolatokat) 5. Tárgymutató (hagyományos, betűrendes tárgymutató mellett szerepelhet még funkciók, diagramok indexe is.) 2.3.3. Követelményspecifikációs eszközök Véges automaták

UML használati eset diagram Döntési tábla Állapotok input; akciók output feltételek szabályok c1: a,b,c egy háromszög N Y c2: a=b? Y N c3: a=c? Y N Y N c4: b=c? Y N Y N Y N Y N akciók szabályok a1 nem háromszög X a2 általános a3 egyenlőszárú X X X a4 szabályos X a5 lehetetlen X X X c1-c4: feltételek (conditions) a1-a5: akciók X