Ramy wymagań niefunkcjonalnych
NFR ( wymagania niefunkcjonalne ) potrzebują struktury do zagęszczania. Analiza zaczyna się od celów miękkich reprezentujących NFR, na które zgadzają się interesariusze. Miękkie cele to cele, które trudno wyrazić, ale zazwyczaj są to globalne cechy systemu oprogramowania. Mogą to być użyteczność, wydajność, bezpieczeństwo i elastyczność w danym systemie. Jeśli zespół zaczyna je zbierać, często znajduje ich bardzo dużo. Aby zredukować liczbę do możliwej do opanowania ilości, cennym podejściem jest ustrukturyzowanie. Dostępnych jest kilka frameworków, które są przydatne jako struktura.
Strukturyzacja wymagań niefunkcjonalnych
Poniższe ramy są przydatne jako struktura dla NFR:
1. Modelowanie celów Sfinalizowane cele miękkie są następnie zwykle rozkładane i udoskonalane w celu odkrycia struktury drzewiastej celów i celów cząstkowych, np. celu miękkiego elastyczności. Po odkryciu struktur drzewiastych na pewno znajdzie się przeszkadzające cele miękkie w różnych drzewach, np. cele bezpieczeństwa generalnie kolidują z użytecznością. Te drzewa celów miękkich tworzą teraz strukturę grafu celów miękkich. Ostatnim krokiem w tej analizie jest wybranie określonych celów miękkich typu liść, tak aby wszystkie podstawowe cele miękkie zostały spełnione.[1]
2. IVENA – zintegrowane podejście do pozyskiwania NFR Metoda zawiera zintegrowane drzewo wymagań. [2]
3. Kontekst organizacji Istnieje kilka modeli opisujących kontekst organizacji, takich jak Business Model Canvas , OrgManle [3] lub inne [4]. Modele te stanowią również dobre ramy do przypisywania NFR.
Mierzenie wymagań niefunkcjonalnych
SNAP to proces oceny niefunkcjonalnego oprogramowania. Podczas gdy punkty funkcyjne mierzą wymagania funkcjonalne poprzez określanie rozmiaru przepływu danych przez aplikację, SNAP firmy IFPUG mierzy wymagania niefunkcjonalne.
Model SNAP składa się z czterech kategorii i czternastu podkategorii do pomiaru wymagań niefunkcjonalnych. Wymagania niefunkcjonalne są przypisane do odpowiednich podkategorii. Każda podkategoria ma rozmiar, a rozmiar wymagania jest sumą rozmiarów jego podkategorii.
Proces ustalania rozmiaru SNAP jest bardzo podobny do procesu ustalania rozmiaru punktu funkcyjnego. W granicach aplikacji wymagania niefunkcjonalne są powiązane z odpowiednimi kategoriami i ich podkategoriami. Korzystając ze znormalizowanego zestawu podstawowych kryteriów, każda z podkategorii jest następnie oceniana zgodnie z jej typem i złożonością; rozmiar takiego wymagania jest sumą rozmiarów jego podkategorii. Te rozmiary są następnie sumowane, aby dać miarę niefunkcjonalnego rozmiaru aplikacji.
Testy beta modelu pokazują, że rozmiar SNAP ma silną korelację z nakładem pracy wymaganym do opracowania niefunkcjonalnej części aplikacji.
Zobacz też
[1] Mylopoulos, Chung i Yu: „Od obiektowej do zorientowanej na cel analizy wymagań” Komunikaty ACM, styczeń 1999 [CACM.f.doc [ 1] [2] Götz, Rolf; Scharnweber, Heiko: „ IVENA: Integriertes Vorgehen zur Erhebung nichtfunktionaler Anforderungen”. https://www.pst.ifi.lmu.de/Lehre/WS0102/architektur/VL1/Ivena.pdf [3] Teich, Irene: Tutorial PlanMan. Dokument roboczy Postbauer-Heng , Niemcy 2005. Dostępne na żądanie [4] Teich, Irene: Kontekst organizacji-modele Dokument roboczy Meschede, Niemcy 2020. Dostępne na żądanie.