Requirements Engineering (1).pptx

Fundamentals of software development and software testing Fundamentals of Requirements Engineering Peter Illes 01. 10. 2019  Fundamentals of Requirements Engineering 2019.10. © Hungarian Testing Board 5  A követ...

Fundamentals of software development and software testing Fundamentals of Requirements Engineering Peter Illes 01. 10. 2019  Fundamentals of Requirements Engineering 2019.10. © Hungarian Testing Board 5  A követelménytervezés oka Javult a követelmények közlése A hibák 60%-a a követelménytervezési szakaszból származik Rossz, hiányzik, A programozás során 20-szor drágább Az elfogadási teszt során 100 alkalommal A követelmények figyelmen kívül hagyásának okai: Magától értetődő, nem kell kifejezetten kijelenteni 2019.10. © Hungarian Testing Board 6  A követelmény meghatározása Olyan feltétel vagy képesség, amelyre a felhasználónak szüksége van egy probléma megoldásához vagy egy cél eléréséhez. Olyan feltétel vagy képesség, amelyet egy rendszernek vagy rendszerösszetevőnek teljesítenie kell, vagy amellyel rendelkeznie kell ahhoz, hogy megfeleljen egy szerződéses szabványspecifikációnak vagy más formálisan előírt dokumentumnak. Egy feltétel vagy képesség dokumentált ábrázolása a fentiek szerint. (IEEE610.12-1990) 2019.10. © Hungarian Testing Board 7  Követelmények típusai Funkcionális követelmények A funkcionális követelmény olyan viselkedés eredményére vonatkozó követelmény, amelyet a rendszer valamely funkciója biztosít Minőségi követelmények (nem funkcionális) A minőségi követelmény olyan követelmény, amely funkcionális követelmények által nem lefedett minőségi problémára vonatkozik Teljesítmény, rendelkezésre állás, megbízhatóság, méretezhetőség, hordozhatóság (nem funkcionális követelmények) Korlátok A korlátozás olyan követelmény, amely az adott funkcionális és minőségi követelmények teljesítéséhez szükséges mértéken túl korlátozza a megoldási teret Határidő, csak web alapú megoldások, stb. IREB 8 2019.10. © Hungarian Testing Board  Requirements Types 2019.10. © Hungarian Testing Board 9  A követelménytervezés meghatározása A követelménytervezés szisztematikus és fegyelmezett megközelítés a követelmények specifikációjára és kezelésére, a következő célokkal: - A vonatkozó követelmények ismerete, konszenzus elérése az érintettek között ezekről a követelményekről, dokumentálása az adott szabványok szerint, és szisztematikus kezelése. Az érdekelt felek vágyainak és igényeinek megértésével és dokumentálásával meghatározzák és kezelik a követelményeket annak érdekében, hogy minimalizálják annak kockázatát, hogy olyan rendszert szállítsanak, amely nem felel meg az érdekelt felek vágyainak és igényeinek 2019.10. © Hungarian Testing Board 10  A követelménytervezés négy fő tevékenysége Kiderítés Dokumentáció Validálás és tárgyalás Menedzsment 2019.10. © Hungarian Testing Board 11  Követelménymérnök, a személy Analitikus gondolkodás Empátia Kommunikációs készségek Konfliktusmegoldó készségek Moderálási készségek Önbizalom Meggyőző erő 2019.10. © Hungarian Testing Board 12  Communication Common language – Natural – UML 2019.10. © Hungarian Testing Board 13  Eliciting Requirements A követelmények nem egyszerűen léteznek; Ki kell őket deríteni! 2019.10. © Hungarian Testing Board 14  Követelmények kiderítése Követelmények forrásai Érdekelt felek Személyek vagy szervezetek Példák: felhasználók, operátorok, fejlesztők, építészek, ügyfelek, tesztelők stb. Dokumentumok Jogi dokumentumok, szabványok, hibajelentések stb. Működő rendszerek Örökölt vagy elődrendszerek Versengő rendszerek 2019.10. © Hungarian Testing Board 15  Követelmények kiderítése Kano modell: Elégedetlenek Magától értetődő és magától értetődő tulajdonságok Kielégítők Kifejezetten megkövetelt rendszertulajdonságok Örömmelők Olyan rendszertulajdonságok, amelyeket az érdekelt felek nem ismernek vagy nem várnak el, és csak a rendszer használata során fedeznek fel 2019.10. © Hungarian Testing Board 16  Követelmények kiderítése Kiderítési technikák Felmérési technikák Pontos, de időigényes Interjúk A kérdőívek ennek formája Kreativitási technikák Néha nem elég pontos Ötletbörze, Hat gondolkodó kalap, analógia Dokumentumközpontú technikák Más technikákkal kell kombinálni Jó a régi rendszerekhez Rendszerrégészet (dokumentumból vagy kódból), Perspektíva alapú 17 2019.10. © Hungarian Testing Board olvasás, újrafelhasználás  Követelmények kiderítése Kiváltási technikák Megfigyelési technikák Azt mutatja, hogy "ahogy van", inkább "lenni" Nem alkalmas új folyamat kifejlesztésére Helyszíni megfigyelés, gyakornoki képzés Támogatási technikák A fenti technikák kiegészítése Elmetérképezés, workshopok, hang- és videofelvételek, use care modellezés, prototípusok 2019.10. © Hungarian Testing Board 18  Dokumentálási követelmények Dokumentációs perspektívák: Adatperspektíva Funkcionális perspektíva Viselkedési perspektíva Natura nyelvi dokumentáció Koncepcionális modellezés nyelv alapú dokumentáció Használatieset-diagram Osztály diagram Tevékenységi diagram Állapotdiagram 2019.10. © Hungarian Testing Board 21  Documenting Requirements Természetes nyelv, transzformációs folyamatok Nominalizáció A folyamat eseménnyé alakul Főnevek referenciaindex nélkül Nem teljesen meghatározott főnevek Univerzális kvantifikálók A megadott viselkedés vagy tulajdonság nem vonatkozik minden objektumra Nem teljesen meghatározott feltételek Nem teljesen meghatározott folyamatműveletek 2019.10. © Hungarian Testing Board 22  Requirements Template SHALL SHOULD Provide WILL BE ABLE TO MAY 2019.10. © Hungarian Testing Board 23  Requirements Template SHALL SHOULD Process verb examples: [When? Under THE SYSTEM Provide - Save WILL - Calculate BE ABLE TO - Transmit MAY Requirement example: If the option “Bill required” has been selected on the mobile device, the system shall provide the receptionist with the ability to print a bill on the network printer. 2019.10. © Hungarian Testing Board 24  Documenting Requirements A követelmények minőségi kritériumai Megbeszélt Egyértelmű Szükséges Következetes Ellenőrizhető Megvalósítható Követhető Teljes Érthető 2019.10. © Hungarian Testing Board 25  Documenting Requirements Tartalom: Rendszerkörnyezet Bevezetés: Építészet Cél A rendszer funkcionalitása A rendszer lefedettsége Felhasználó és célközönség Érdekelt felek Korlátok Meghatározások, Feltételezések mozaikszavak, rövidítések Követelmények Hivatkozások - Funkcionális és minőségi Áttekintés követelmények Általános áttekintés Függelékek Index © Hungarian Testing Board 27  Documenting Requirements A követelmények dokumentációjának használata Tervezés Építészeti tervezés Végrehajtás Teszt Változáskezelés Rendszerhasználat és karbantartás Szerződések kezelése 2019.10. © Hungarian Testing Board 28  Source 2019.10. © Hungarian Testing Board 29  Fundamentals of Software Development and Software Testing Fundamentals of Requirements Engineering Seminar Teacher’s instruction 2019.10. © Hungarian Testing Board 30  Fundamentals of Software Development and Software Testing Fundamentals of Requirements Engineering Seminar Teacher’s instruction Expected outcome: By experiencing the role of stakeholder and requirements engineer students will be able to adopt to real work situations and use their knowledge on requirements engineering in practice. Aim: Student experience the role of stakeholder and requirements engineer during practical requirement elicitation, definition and analysis. Timeline: 1. Let students know the aim of the seminar. 3’ 2. Remind students of the definition of requirements, requirements types, the Kano model, and the Rupp’s requirements template. (Slides are provided.) 8’ 3. Form teams of 3-4. Half of the teams play stakeholders the other half of teams play requirements engineers. 3’ 2019.10. © Hungarian Testing Board 31  Fundamentals of Software Development and Software Testing Fundamentals of Requirement Engineering Seminar Teacher’s instruction 4. Ask stakeholder teams to prepare for the requirement elicitation meeting by defining 3-4 features of a social media system (you may use any other realistic example) they want the development team to work on. Meanwhile ask the requirements engineer teams to prepare for the same meeting by preparing questions they will use to elicit requirements. Ask them to concentrate on the functional requirements but let them to come up with other types too. 8’ 5. During a simulated meeting of stakeholders and requirement engineers ask the requirement engineer plying students to elicit requirements using Rupp’s requirement template in written form. 10’ Teams change role. 6. Repeat step 4 and 5. 18’ 7. Ask the students about their experience. How they feel about the roles they played. What was difficult, what was easy. 5’ 2019.10. © Hungarian Testing Board 32  Fundamentals of Software Development and Software Testing Fundamentals of Requirement Engineering Seminar Teacher’s instruction 8. Ask each team to read out at least one requirement. Ask the stakeholder team of each requirement if they agree with it, consider complete and this is they really wanted at the beginning. Let the students go into a moderated debate. 15’ 9. Analyze agreed requirements against natural language transformational processes. 20’ 2019.10. © Hungarian Testing Board 33  Definition of Requirement A condition or capability needed by a user to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a system or system component to satisfy a contract standard specification, or other formally imposed documents. A documented representation of a condition or capability as in above. (IEEE610.12-1990) 2019.10. © Hungarian Testing Board 34  Requirements Types Functional Requirements – A functional requirement is a requirement concerning a result of behavior that shall be provided by a function of the system Quality Requirements – A quality requirement is a requirement that pertains to a quality concern that is not covered by functional requirements – Performance, availability, dependability, scalability, portability – Non-functional requirements Constraints – A constraint is a requirement that limits the solution space beyond what is necessary for meeting the given functional and quality requirements – Deadline – Web based solutions only 2019.10. © Hungarian Testing Board 35  Kano Model Dissatisfiers – Properties that are self-evident and taken for granted Satisfiers – Explicitly demanded system properties Delighters – System properties that the stakeholders does not know or expect and discovers only while using the system 2019.10. © Hungarian Testing Board 36  Requirements Template SHALL SHOULD Provide WILL BE ABLE TO MAY 2019.10. © Hungarian Testing Board 37  Natural Language, Transformational Processes Nominalization – Process is converted into an event Nouns without reference index – Incompletely specified nouns Universal quantifiers – Specified behavior or property does not apply to all objects Incompletely specified conditions Incompletely specified process verbs 2019.10. © Hungarian Testing Board 38 2019.10. © Hungarian Testing Board 39 2019.10. © Hungarian Testing Board 40 2019.10. © Hungarian Testing Board 41 2019.10. © Hungarian Testing Board 42