Jaros aw kuchta dokumentacja i jako oprogramowania
This presentation is the property of its rightful owner.
Sponsored Links
1 / 28

Inżynieria wymagań PowerPoint PPT Presentation


  • 86 Views
  • Uploaded on
  • Presentation posted in: General

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Inżynieria wymagań. 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

Download Presentation

Inżynieria wymagań

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Jaros aw kuchta dokumentacja i jako oprogramowania

Jarosław Kuchta

Dokumentacja i Jakość Oprogramowania

Inżynieria wymagań


Cele in ynierii wymaga

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ń


Sk adniki systemu informatycznego

Składniki systemu informatycznego

System informatyczny

Sprzęt

Procedury

Oprogramowanie

Baza danych

Ludzie

Dokumentacja

Inżynieria wymagań


Alokacja wymaga przyk ad

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ń


Ustalenie os b zainteresowanych

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ń


Ustalenie udzia owc w

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ń


Ustalenie klienta

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ń


Proces pozyskiwania wymaga

Proces pozyskiwania wymagań

Wydobywanie informacji

Wstępna reprezentacja

Wstępna analiza

Ocena specyfikacji

Inżynieria wymagań


Podstawowy problem zrozumienie

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ń


Wydobywanie informacji

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ń


U wiadomienie potrzeb

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ń


Formu owanie potrzeb

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ń


Transformowanie potrzeb na wymagania systemowe

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ń


Zdobycie informacji potrzebnych do zrozumienia wymaga

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ń


Wst pna reprezentacja

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ń


Wst pna analiza

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ń


Rodki pomocnicze

Ś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ń


Rezultaty

Rezultaty

wymagania poprawnie wyspecyfikowane

wymagania niepoprawnie wyspecyfikowane

zakres projektu

Inżynieria wymagań


Trzy grupy wymaga

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ń


Specyfikacja wymaga systemowych

Specyfikacja Wymagań Systemowych

  • Wstęp

  • Opis informacyjny

  • Wymagania funkcjonalne

  • Wymagania niefunkcjonalne

  • Kryteria akceptacyjne

  • Bibliografia

  • Dodatki

Inżynieria wymagań


Sws wst p

SWS – Wstęp

  • Identyfikacja systemu

  • Skrócony opis organizacji

  • Cel wprowadzenia systemu (cel biznesowy)

  • Podstawowe ograniczenia

Inżynieria wymagań


Sws opis informacyjny

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ń


Sws wymagania funkcjonalne

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ń


Sws wymagania niefunkcjonalne

SWS – Wymagania niefunkcjonalne

  • Wymagania wydajnościowe

  • Wymagania niezawodnościowe

  • Wymagania dot. bezpieczeństwa

  • inne

Inżynieria wymagań


Sws kryteria akceptacyjne

SWS – Kryteria akceptacyjne

  • Klasy testów

  • Oczekiwane odpowiedzi systemu

  • Zastrzeżenia szczególne

Inżynieria wymagań


Sws bibliografia

SWS – Bibliografia

  • Inne dokumenty inżynierii oprogramowania

  • Instrukcje techniczne

  • Literatura pomocnicza

  • Standardy

Inżynieria wymagań


Sws dodatki

SWS – Dodatki

  • Słownik pojęć

  • Dane tabelaryczne

  • Wykresy

  • Specyfikacja szczególnych algorytmów

Inżynieria wymagań


Literatura

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ń


  • Login