Požadavky na Software

Question 1

Požadavky na SW

Answer 1

Funkční požadavky popisuji co systém děla – na něco kliknu, něco se mi objevi
Nefunkčni požadavek – další omezeni které mam v práci na tom projektu(Musíme to dělat jenom v javě), Jsou užitečne: Zákazníkovi všchno běží na ubuntu tak mu tam nebudu cpát dotnet a emulovat mu to tam někde

Question 2

SRS

Answer 2

Busines požadavky + rozsah projektu –> VIZE
Požadavky uživatelů
+ Business pravidla(musíme generovat email který nás upozorni na něco)
–> USE CASE
Atibut kvality(kolik emailu které se měly poslat se neposlaly)
+ use case
+ business pravidla
+ požadavky na systém(framework)
+ externi rozhrani(když do banky davame spracovani plateb tak my implementujem interface od banky)
–> funkce –>
–> SRS

Question 3

Obecný postup při specifikaci požadavků

Answer 3

pochopení problému a jeho analýza
Identifikace lidí se zájmem na projektu
Definice systému a jeho hranic
Identifikac omezení, které musí systém mít(celá firma používá linux)

Question 4

Způsob indetifikace požadavků

Answer 4

Rozhovory s vybranými uživateli
Requirement workshop
Prototyp
User stories

Question 5

Tradiční způsoby soupisu požadavků

Answer 5

Sesbírat požadavky na systém detailně, na zakladě toho navrhnout architekturu aplikace a detailně vypracovat analýzu
Navrhnout DB
Forma zápisu převažně dokumentová

Question 6

Možné nevýhody při specifikaci požadavků

Answer 6

Ztráta celkového přeheldu
Navzajem vylučující se požadavky
Funkce jsou zafixovány po celou dobu vývoje
Funkce jsou většinou zaznamenány z pohledu systému ne uživatele

Question 7

UML

Answer 7

CLASS DIAGRAM
SEQUENCE DIAGRAM
USE CASE DIAGRAM
(aktivity diagram, deployment diagram, component diagram)

Question 8

USE CASE DIAGRAM

Answer 8

Jednoduchy diagram popsani high level pohledu na naši applikaci
Kolik j tam roli a jake jsou,
Use case – připad užiti, actor panaček který bude s tou bublinkou interagovat, scenař specificka sequence akci mezi nami a počítačem(vložte kartu, vložim kartu, zadej pin, zadam pin)

Question 9

STYL BLACK-BOX

Answer 9

Nepopisuji vnitřni praci systemu ale odpovědnost systemu: uživatel zaznamenává objednávky

Question 10

STYL WHITE-BOX

Answer 10

Bude tam SQL-INSERT(tohle je špatne, nikdo to po tomhle zapisu neudělá škalovatelné)

Question 11

ŠABLONA

Answer 11

Primarni actor, zainteresovaní lidě, Precondition(pokud chceme založit fakturu musíme mit něco v čiselniku), succes guarantee porovnáváme vystup s realnym požadavkem
Basic flow- hlavní problém(funkce projektu)
Alternative flow(odbočka basic flow)
Special requirements(další požadavky i technické)
Technology and Data variations list – většinou se použiva u externich rozhrani komunikace s API
Open issues

Question 12

USER STORIES

Answer 12

Alternativa pro User stories, psáno na malém papírku aby nanrostl na velikosti, Jsou psány zákazníkem As a <user>, <goal>, <benefit> vypadne nam z toho role pro use case goal je business část a goal je to co by se idealně mělo dělat</benefit></goal></user>

Question 13

User stories DoR

Answer 13

Je jasná,
připravena pro vyvoj,
Je testovatelná
Je doručitelná v nejbližším časovém období

Question 14

User stories DoD

Answer 14

Jakou kvalitu čekáme, bezpečnost
Výkon(10 uživatelů nebo 100k uživatelů)
Dokumentace(JavaDoc)

Question 15

User stories AC

Answer 15

Za jakých podmínek UC acceptuje zakaznik

Question 16

Co je to IEEE 803 a čeho se týká

Answer 16

Slouži pro zapisovani funkčních a nefunkčních požadavků, Pokud nevim jak to udělat si vezmu tuhle normu a dostanu jak napsat SRS
Definice – kontrakt, zákazník,dodavatel, uživatel
Je to doporučení jak psát SRS
Zabývá se Funkcionalitou, extreni rozhrani, výkon, atributy, návrhová omezení
SRS by měla být přesná
Důležité je nezapomenout na rozsah těch nefunkčních požadavku a nejlépe rozělit požadavky na funkčni a nefunkční

Question 17

Co je to FURPS+ popis písmen

Answer 17

Functionality – To co zakaznik vidi a chce

Usability – uživatelské rozhrani(responzivita)

Reliability – Co když vypadne paket, uloží se to? Vypadne proud, pojede to?

Performance – odezva, propustnost, přesnost

Supportability – Udržitelnost, Lokalizace(Použít slovník a ne IF statement)

+ znamena že nesmíme zapomenout na Návrhové,implementační a fyzické požadavky

Question 18

Transformace požadavků FURPS do výsledného produktu

Answer 18

vezmu furps requirementy převedu to do anylýzy. Z analýzy pujdu do designu kde mi přibuzdou Design requirements. z designu pujdu do implementace kde mi přibudou Implementačni požadavky

Question 19

Proč dělat prioritizaci požadavků?

Answer 19

Potřeby uživatelů
Relativní důležitost požadavků pro uživatele
Závislost – nějaky požadavek závisi na nějakem jinem
Čas – muže byt doručeno třeba zítra

Question 20

IN OR OUT požadavky

Answer 20

Dáme dohromady skupinu lidi kteří rozhodnout jestli požadavek udělam nebo ne a roztřídím je na dvě kupy

Question 21

Porovnání párů dle hodnocení požadavků

Answer 21

Srovnavame pomoci atributu. Vezmeme nějake score a do těch featur pomoci toho score udělame prioritu a to co ma největší prioritu tak udělame jako první

Question 22

Třístupňová stupnice požadavků

Answer 22

High medium low
Není uplné přesné jelikož je to subjektivní
Urgentní a neurgentní, duležity a neduležity
V agilnim vyvoji je vhodne to dělat vícekrát