Inżynieria wymagań

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

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 • 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łapisane • 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 • 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.