Sebastian Wojczyk wojczyk@math.uni.lodz.pl Inżynieria wymagań Sebastian Wojczyk wojczyk@math.uni.lodz.pl.

Prezentacja na temat: "Sebastian Wojczyk wojczyk@math.uni.lodz.pl Inżynieria wymagań Sebastian Wojczyk wojczyk@math.uni.lodz.pl."— Zapis prezentacji:

1 Sebastian Wojczyk wojczyk@math.uni.lodz.pl
Inżynieria wymagań Sebastian Wojczyk

2 Plan wykładu Podstawowe informacje Cel inżynierii wymagań
Trudności w pozyskiwaniu wymagań Sposoby zbierania informacji Opis wymagań Wymagania funkcjonalne Wymagania niefunkcjonalne Sposoby wspomagania opisu wymagań Dokument specyfikacji wymagań klienta Użytkownicy dokumentu specyfikacji wymagań klienta

3 Podstawowe informacje
Inżynieria wymagań – to etap realizacji projektu informatycznego związany z pozyskiwaniem, formułowaniem, analizą i zarządzaniem wymaganiami „klienta”. Etapy inżynierii wymagań: Studium wykonalności, Zebranie i analiza wymagań, Specyfikacja wymagań, Zatwierdzenie specyfikacji wymagań klienta. Niska jakość wymagań: przekonanie, że „programowanie jest najważniejsze!”, brak bezpośredniego efektu w postaci działających funkcji, Klient chce płacić za fizyczne oprogramowanie.

4 Cel inżynierii wymagań
Rozpoznanie dziedziny przedmiotowej projektu, Pozyskiwanie wymagań, Grupowanie, klasyfikacja, Wykrywanie i usuwanie sprzeczności, Priorytetowanie wymagań, Weryfikacja wymagań, Specyfikacja wymagań, Dokumentacja wymagań, Ostatecznie – Specyfikacja Wymagań Klienta

5 Trudności Cel powstania oprogramowania Terminologia Wymagania ukryte
Klient widzi cel, ale nie widzi ścieżki, Możliwe są różnie ścieżki osiągnięcia postawionych celów, Różni użytkownicy mają różne cele. Terminologia Uzgodnienie terminologii, Konieczność pogodzenia informatyków i użytkowników, Konfrontacja odległych grup zawodowych (analitycy, zarządy, kierownictwo, szeregowi pracownicy). Wymagania ukryte Użytkownicy nie są ich świadomi, Powstanie luk w dokumentacji. Niebezpieczeństwo uzyskania subiektywnych opinii

6 Trudności 2 Zleceniodawcy – cele ogólne
Zleceniodawcy decydują – użytkownicy obsługują, Problemy z uwzględnieniem rzeczywistych potrzeb docelowych użytkowników. Użytkownicy – cele i potrzeby szczegółowe Brak motywacji i chęci współpracy, Obawy przed zmianami, Obawa o możliwość utraty pracy, Ukrywanie posiadanej wiedzy praktycznej (świadome lub niezamierzone), Ważność wymagań – moje najważniejsze, Brak spojrzenia na system jako całość.

7 Pozyskiwania wymagań Oprogramowanie na zamówienie
Duże zaangażowanie klienta, Wspólne słownictwo, Iteracyjność procesu, Koszty i czas, Wydobywanie wymagań. Oprogramowanie gotowe Kontakt z potencjalnymi klientami, Analizy rynku, Spotkanie z ekspertami dziedzinowymi.

8 Sposoby pozyskiwania wymagań – źródła pisane
Wszelkie dokumenty wewnętrzne, Opis struktury organizacyjnej firmy, Zakresy obowiązków pracowników, Opisy stanowisk, Dokumentacja użytkowanych systemów informatycznych, Dokumenty generowane z używanych systemów informatycznych, Akty prawne związane z dziedziną przedmiotową.

9 Sposoby pozyskiwania wymagań - obserwacja
Oszacowania/pomiary (ilości dokumentów, klientów), Ilości i częstotliwość napływu danych, Wartości średnie i skrajne, Podział czasu pomiędzy różne czynności, Identyfikacji osób kompetentnych i komunikatywnych – potencjalnych ekspertów, Identyfikacja obecnego obiegu dokumentów (realnego), Identyfikacja powiązań/związków, Identyfikacja źródeł danych (bazy, „zbiory”, „archiwa”), Obserwacja zmienności w obciążeniu pracą.

10 Sposoby pozyskiwania wymagań - ankiety
Tylko gdy to konieczne, Nie mogą służyć innym celom (np. ocenie pracownika), Konieczne zabezpieczenie czasu na ich wypełnienie, Typy pytań Pytania zamknięte, Pytania otwarte, Miejsce na sugestie pracowników.

11 Sposoby pozyskiwania wymagań – wywiady
Od prezesa, do użytkowników bezpośrednich, Konieczność wiedzy merytorycznej, Precyzyjne określenie czasu i tematyki spotkań, Duża ilość czasu (wiele osób), Identyfikacja zagadnień otwartych (rzeczywista rozbudowa a nie odnowienie starego systemu), Konieczny raport/notatka z każdego spotkania Czas i miejsce, Skład osobowy, co ustalono, czego brakuje – ustalenie dodatkowych terminów spotkań i osób kompetentnych Weryfikacja raportu po jego sporządzeniu.

12 Opis wymagań Zamiana celów na konkretne wymagania,
Definicja wymagań jako proces, Ogóle sformułowanie, Doprecyzowanie wymagań, Etapy: Definicja wymagań Ogólny opis w języku naturalnym, Specyfikacja wymagań Ustrukturyzowanie wymagań, Mapa powiązań, Sformalizowane notacje (diagram przypadków użycia) Specyfikacja oprogramowania Formalny opis, ale tylko w planowaniu dużych systemów

13 Wymagania funkcjonalne
Usługi jakie ma oferować system, Spojrzenie z punktu widzenia użytkownika, Sposób reakcji na przykładowe dane wejściowe, Czego system nie powinien robić – odpowiedzialność użytkownika, Odpowiednia gradacja – często zbyt rozdrobnione na szczegółowe przypadki, Nie powinny narzucać sposobu rozwiązania problemów/osiągnięcia celów.

14 Wymagania niefunkcjonalne
Typy wymagań niefunkcjonalnych mierzalnych Szybkość, Rozmiar, Łatwość użytkowania, Niezawodność i bezpieczeństwo, Stabilność, Elastyczność/Przenośność, Typy użytkowników i uprawnienia, Definicja systemów zewnętrznych, Struktury organizacyjne, Przepisy prawne, zarządzenia, statuty, instrukcje, Ograniczenia systemu.

15 Przykłady wymagań niefunkcjonalnych
Szybkość Czas odpowiedzi (pożądany, maksymalny), Rozmiar Ilość użytkowników, urządzeń, Rozmiar danych, Dokładność Precyzja obliczeń i przechowywania danych, Ograniczenia systemu, Realia sprzętowe i komunikacyjne (sieć, wydajność, zabezpieczenia), Ograniczenia systemowe (wersje systemów operacyjnych i innego oprogramowania), Typ interfejsu użytkownika.

16 Przykłady wymagań niefunkcjonalnych 2
Adaptowalność, Podatność na zmiany, określenie punktów zmian i parametryzacji, Bezpieczeństwo, Zabezpieczenie, Szyfrowanie danych, Autoryzacja, Odporność na awarie, Standardy, Formaty plików, Wersje językowe, Zasoby Ograniczenia finansowe, Zasoby ludzkie, Skala czasowa Harmonogram prac Czas szkoleń, wdrożeń.

17 Miary wymagań niefunkcjonalnych
Szybkość, Ilość transakcji w jednostce czasu, Konkretny maksymalny czas realizacji bardziej złożonych operacji, Czas reakcji (zapisu danych, odświeżenia ekranu), Rozmiar, Kilobajty, Megabajty, Gigabajty, Konkretne wartości liczbowe, Łatwość użytkowania, Czas szkoleń, Liczba punktów pomocy kontekstowej, Liczba samouczków, Niezawodność i bezpieczeństwo, Średni czas bez awarii, Częstość błędów, Automatyzacja i częstotliwość wykonywania kopii zapasowych, Stabilność, Czas uruchomienia kopii systemy Prawdopodobieństwo utraty danych, Elastyczność/Przenośność, Liczba wspieranych systemów operacyjnych, przeglądarek internetowych, Procent funkcji systemu zależny od platformy, środowiska.

18 Wspomaganie opisu wymagań
Jeden obraz wart więcej niż tysiąc słów (przysłowie chińskie). Przejrzystość, Większa ilość informacji, Szybsza percepcja niż w przypadku ciągłego tekstu, Listy i wypunktowania, Ustalenie priorytetów, ważności elementów, Formularze, tabele Kojarzenie użytkowników i funkcji, Powiązania poszczególnych wymagań, Diagramy blokowe – przepływ informacji, Diagramy kontekstowe, Diagramy przypadków użycia, Wszelkie inne schematy i rysunki.

19 Specyfikacja wymagań klienta – struktura dokumentu
Wstęp / Ogólny opis, Słownik, Definicja wymagań funkcjonalnych, Definicja wymagań niefunkcjonalnych, Opis ewolucji systemu, Specyfikacja wymagań funkcjonalnych, Inne Wymagania sprzętowe, Opis istniejącej bazy sprzętowej, Wymagania odnośnie bazy danych, Indeksy spisy (tabel, schematów, kluczowych definicji, itp.)

20 Specyfikacja wymagań funkcjonalnych
Krótki opis funkcjonalności, Wejście, Definicja danych wejściowych, Określenie źródła danych (formularz, import, inna część systemu), Określenie ograniczeń (wartości skrajne, limity, ewentualne typy), Wyjście, Opis zwracanych rezultatów, Sposób ich zwracania (wartość, wydruk, dane w bazie, itp.) Interakcja z innymi częściami systemu, Blokowania działania innych funkcji, Wymuszenia kolejności pewnych funkcji.

21 Kto i do czego wykorzystuje?
Klienci systemu Określają wymagania i weryfikują względem ich potrzeb, Określają ewentualne zmiany wymagań, Wykonawcy/Inżynierowie Przygotowanie oferty budowy systemu, Planowanie procesu (harmonogramu) tworzenia, Planowanie architektury systemu, Przygotowanie testów systemu (m. in. akceptacyjne), Zrozumienie działania systemu, Wykrycie powiązań pomiędzy częściami systemu,

22 Co wpływa na sukces? Zaangażowanie klienta Pełne rozpoznanie wymagań,
Wszystkie szczeble decyzyjne, Przekonanie o sensowności procesu, Pełne rozpoznanie wymagań, Sytuacje typowe, Sytuacje skrajne i ograniczenia, Kompletność i spójność wymagań, Określenie wymagań niefunkcjonalnych Możliwość weryfikacji, Zdefiniowanie stosownych miar i określenie ich realnych wartości.