Inżynieria wymagań

1. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

2. Cele inżynierii wymagań • Określenie celu biznesowego projektu • Cel biznesowy określa korzyści, jakie osiągną udziałowcy projektu dzięki jego realizacji • Identyfikacja wymagań • funkcjonalnych • niefunkcjonalnych • Alokacja wymagań do poszczególnych składników systemu informatycznego Inżynieria wymagań

3. Składniki systemu informatycznego System informatyczny Sprzęt Procedury Oprogramowanie Baza danych Ludzie Dokumentacja Inżynieria wymagań

4. Alokacja wymagań – przykład • Rejestracja opinii od klientów • Rozwiązanie pierwsze – pracownik działu reklamacji analizuje opinie przychodzące telefonicznie lub pocztą i wpisuje je do odpowiedniego formularza. Dane są rejestrowane w bazie danych. • Rozwiązanie drugie – serwis internetowy udostępnia formularz opinii. Klienci składający reklamacje muszą odpowiednio szczegółowo wypełnić formularz. Dane są rejestrowane w bazie danych. • Rozwiązanie trzecie – włącza się automatyczny serwis telefoniczny. System rozpoznawania głosu wyławia kluczowe słowa z wypowiedzi klienta i tworzy skróconą charakterystykę opinii. Dane są rejestrowane w bazie danych wraz z pełnym nagraniem wypowiedzi. Inżynieria wymagań

5. Ustalenie osób zainteresowanych • użytkownicy końcowi (wymagania funkcjonalne) • administrator systemu (szczególne wymagania funkcjonalne, niezawodność, dostępność, testowalność) • wyższe kierownictwo (cele biznesowe) • kierownik marketingu (cechy marketingowe) • kierownik finansowy (koszty) • kierownik ochrony (bezpieczeństwo) Inżynieria wymagań

6. Ustalenie udziałowców • Każda osoba zainteresowana może występować w kilku rolach (np. administrator może też być użytkownikiem końcowym). • Z każdą rolą jest związany określony punkt widzenia. • Osoba występująca w danej roli jest udziałowcemprojektu. • Każde urządzenie lub system współpracujący z projektowanym systemem również może mieć swoje wymagania i w tym sensie również jest udziałowcem projektu. • Punkty widzenia różnych udziałowców są różne. • Wszystkie punkty widzenia udziałowców są ważne, chociaż nie wszystkie w tym samym stopniu. • Wszystkie punkty widzenia powinny zostać wzięte pod uwagę. • Wszystkie punkty widzenia powinny zostać przeanalizowane. • Pojawiające się konflikty powinny zostać rozstrzygnięte. Inżynieria wymagań

7. Ustalenie klienta • Klientem jest osoba lub organizacja, która ma ostateczny wpływ na kształt projektu. Z klientem uzgadniamy specyfikację wymagań i podpisujemy kontrakt. • Klient powinien należeć do udziałowców projektu, w przeciwnym wypadku nie jest zainteresowany wprowadzeniem systemu, stąd szanse powodzenia są minimalne. • W organizacji musi być wyznaczona osoba odpowiedzialna reprezentująca klienta. Osoba ta musi mieć odpowiednią władzę nad innymi udziałowcami, aby zapewnić ich współpracę w fazie formułowania wymagań. • W przypadku klienta szerokiego (produkt przeznaczony dla masowego odbiorcy) trzeba znaleźć osobę lub grupę osób reprezentujących udziałowców (najczęściej użytkowników końcowych) i od nich pozyskiwać wymagania. Inżynieria wymagań

8. Proces pozyskiwania wymagań Wydobywanie informacji Wstępna reprezentacja Wstępna analiza Ocena specyfikacji Inżynieria wymagań

9. Podstawowy problem – zrozumienie Wiem, że sądzisz, iż rozumiesz to, co myślisz, że ja powiedziałem, ale nie jestem pewien, czy zdajesz sobie sprawę z tego, że to co słyszałeś nie jest tym, co ja myślałem... Inżynieria wymagań

10. Wydobywanie informacji • Uświadomienie sobie przez udziałowców ich potrzeb. • Sformułowanie potrzeb. • Transformowanie potrzeb na wymagania względem systemu. • Zdobycie informacji potrzebnych do zrozumienia wymagań. Inżynieria wymagań

11. Uświadomienie potrzeb • Udziałowiec może nie czuć potrzeby wprowadzenia systemu, a jedynie kierować się odgórnymi nakazami czy trendami. • Udziałowiec może być na tyle przyzwyczajony do dotychczasowego sposobu pracy, że nie potrafi zrozumieć zmian, które nastąpią po wprowadzeniu nowego systemu. • Udziałowiec prawie na pewno nie uświadamia sobie wszystkich swoich potrzeb. • W przypadku, gdy udziałowcem jest urządzenie lub system, jego wymagania może reprezentować osoba eksperta lub mogą być one zapisane w dokumentacji. Inżynieria wymagań

12. Formułowanie potrzeb • Udziałowiec może mieć kłopoty z formułowaniem jasnych wypowiedzi. • Udziałowiec może być niechętny do formułowania pewnych potrzeb, gdyż może uznać je za słabość swoją lub swojej organizacji i wstydzić się tej słabości. • Udziałowiec może uznać pewne swoje potrzeby za oczywiste i nie zdawać sobie sprawy z tego, że ktoś inny może ich nie znać. Inżynieria wymagań

13. Transformowanie potrzeb na wymagania systemowe • Nie każdą potrzebę jest w stanie zaspokoić system informatyczny. • Niektórych potrzeb nie da się zaspokoić bez zmiany organizacji. • Wymagania mogą być funkcjonalne i niefunkcjonalne. Istnieje konieczność klasyfikacji wymagań. • Wymagania powinny określać, co system ma robić, a nie w jaki sposób ma to robić. • Różne potrzeby mogą prowadzić do sprzecznych wymagań. Istnieje konieczność określenia priorytetów ważności wymagań. Inżynieria wymagań

14. Zdobycie informacji potrzebnych do zrozumienia wymagań • Informacje mogą być „przechowywane w głowach” pewnych osób, które mogą nie być zainteresowane w dzieleniu się nimi. • Informacje mogą być zapisane w trudno dostępnej dokumentacji. • Informacje mogą być niekompletne. • Informacje mogą być sprzeczne. • Informacje mogą być mylące. Inżynieria wymagań

15. Wstępna reprezentacja • Opis słowny – może mieć niejednoznaczną interpretację, może być niejasny (sformułowany językiem specjalistycznym), duże prawdopodobieństwo nadmiarowości i sprzeczności. • Opis graficzny – jest bardziej czytelny (notacja musi być znana dla udziałowców, np. diagramy blokowe, czytelne symbole), ułatwia precyzowanie faktów. • Opis matematyczny (naukowy, tabelaryczny) – stosuje się jedynie do niektórych wymagań • Opis kombinowany – problem spójności • Potrzeba logicznego uszeregowania wymagań – ujawnia luki, nadmiarowości i sprzeczności w wymaganiach. • Wymagania różnych udziałowców rejestruje się osobno i następnie tworzy ich kompilację. • Wymagania muszą być ponumerowane, tak aby w późniejszych fazach móc się do nich odwoływać. Inżynieria wymagań

16. Wstępna analiza • Cel – walidacja wymagań przez udziałowców. • Środek – analiza przez udziałowca wyspecyfikowanych przez siebie i zredagowanych przez analityka wymagań. • Pytania stawiane przez analityka: • Co takiego? • Dlaczego? • Czy istnieją inne możliwości? Inżynieria wymagań

17. Środki pomocnicze • prototypowanie • prototypem na etapie specyfikacji może być model systemu (rysunek szkicowy interfejsu użytkownika, wyszczególnienie najważniejszych pozycji menu, szkic najważniejszych raportów) • prototypem może być uproszczony program realizujący jedynie wybrane funkcje • podejście ewolucyjno-iteracyjne • realizacja projektu ze świadomie ograniczoną funkcjonalnością przy założeniu dalszego udoskonalania systemu w przyszłości. Inżynieria wymagań

18. Rezultaty wymagania poprawnie wyspecyfikowane wymagania niepoprawnie wyspecyfikowane zakres projektu Inżynieria wymagań

19. Trzy grupy wymagań • Wymagania jawnie wyspecyfikowane (dotyczące konkretnego projektu) • Wymagania domyślne – nie wyspecyfikowane jawnie, lecz konieczne dla realizacji celów projektu • Wymagania obligatoryjne – nie muszą być wyspecyfikowane jawnie, lecz występują ze względu na regulacje prawne lub wymogi rynku. Inżynieria wymagań

20. Specyfikacja Wymagań Systemowych • Wstęp • Opis informacyjny • Wymagania funkcjonalne • Wymagania niefunkcjonalne • Kryteria akceptacyjne • Bibliografia • Dodatki Inżynieria wymagań

21. SWS – Wstęp • Identyfikacja systemu • Skrócony opis organizacji • Cel wprowadzenia systemu (cel biznesowy) • Podstawowe ograniczenia Inżynieria wymagań

22. SWS – Opis informacyjny • Szczegółowy opis problemów do rozwiązania • Diagramy przepływu (sterowania lub danych) najwyższego poziomu • Reprezentacja zawartości informacyjnej • Opis interfejsów systemowych (użytkownika, softwerowych, sprzętowych) Inżynieria wymagań

23. SWS – Wymagania funkcjonalne • Lista funkcji (podział hierarchiczny) • Opis każdej funkcji • opis tekstowy • ograniczenia • wymagania wydajnościowe • zastrzeżenia projektowe • diagramy pomocnicze • Opis sterowania • specyfikacja sterowania • zastrzeżenia projektowe Inżynieria wymagań

24. SWS – Wymagania niefunkcjonalne • Wymagania wydajnościowe • Wymagania niezawodnościowe • Wymagania dot. bezpieczeństwa • inne Inżynieria wymagań

25. SWS – Kryteria akceptacyjne • Klasy testów • Oczekiwane odpowiedzi systemu • Zastrzeżenia szczególne Inżynieria wymagań

26. SWS – Bibliografia • Inne dokumenty inżynierii oprogramowania • Instrukcje techniczne • Literatura pomocnicza • Standardy Inżynieria wymagań

27. SWS – Dodatki • Słownik pojęć • Dane tabelaryczne • Wykresy • Specyfikacja szczególnych algorytmów Inżynieria wymagań

28. Literatura • Pressman R.S., Software engineering. A practitioner’s approach, McGraw-Hill, International Edition, 1992 • Górski J. et al., Inżynieria oprogramowania w projekcie informatycznym,wyd. Mikom, Warszawa, 2000 Inżynieria wymagań