Edytuj stronę Odnośniki Fold/unfold all ODT export Ta strona jest tylko do odczytu. Możesz wyświetlić źródła tej strony ale nie możesz ich zmienić. ====== Analiza wymagań ====== **Analiza wymagań** – uzgodnienie wymagań klienta i ich analiza. Celem jest określenie zakresu prac, oszacowanie czasochłonności, kosztów i czasu wykonania. {{:zajecia:ppz:requirements-preview.jpg?400|}} ===== Wstępna analiza wymagań ===== * oszacować techniczne wymagania (środowisko działania, system operacyjny, wymagania sieciowe) * określić aplikacje, systemy z którymi musimy zintegrować system * wymagania funkcjonalne (spis oczekiwań klienta) * (przykładowe) scenariusze użycia ===== Wymagania funkcjonalne ===== Analiza wymagań funkcjonalnych umożliwia zidentyfikowanie i opisanie pożądanego zachowania systemu. Zgodnie z jedną z definicji, wymaganie funkcjonalne to „stwierdzenie, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach. W niektórych wypadkach wymagania funkcjonalne określają, czego system nie powinien robić. Jakie działania będzie mógł wykonać użytkownik ? Przykład: \\ // Użytkownik może się zalogować, wydrukować wynik, wyświetlić listę plików. \\ Po wciśnięciu przycisku OK okno się zamyka i następuje powrót do okna głównego. // Jakie działanie wykonuje system ? Przykład:\\ // Cyklicznie (codziennie) wysyłana jest poczta do wskazanych użytkowników. // * dane wejściowe -> działanie -> dane wyjściowe * ogólne – lista w języku naturalnym * szczegółowa specyfikacja – dokładna lista, UML, grafy działania (zrobimy w późniejszej fazie projektowania) Dobra dokumentacja wymagań nie powinna nadmiernie ograniczać projektu aplikacji, to znaczy narzucać konkretnego rozwiązania architektonicznego. Analityk powinien w taki sposób opisywać system, by prezentować dostępne funkcje i możliwości aplikacji bez zbędnego wnikania w szczegóły techniczne. Podczas opisywania wymagań funkcjonalnych (zarówno listy wymagań, jak i szczegółowej specyfikacji), należy posługiwać się prostymi, jednoznacznymi i zrozumiałymi stwierdzeniami ===== Wymagania niefunkcjonalne ===== Ograniczenia w jakich system ma pracować, standardy jakie spełnia, itp. Jaki ten system powinien być ?\\ Co jest interfejsem ? (strona www, GUI, konsola, inne aplikacje)\\ Czy jest przeznaczona dla pojedynczego użytkownika?\\ Na jakim systemie operacyjnym działa?\\ Jakie mam wymagania (dodatkowe oprogramowanie, dodatkowy sprzęt)?\\ * wydajność * sklalowalność * otwartość, możliwość rozbudowy * odporność na awarie * bezpieczeństwo ===== Metoda FURPS ===== * **Functionality** funkcjonalność w rozumieniu zestawu funkcji uwzględniająca również bezpieczeństwo, możliwości systemu * **Usability** użyteczność jako zestaw wizualnych aspektów oprogramowania, estetyka, dokumentacja * **Reliability** niezawodność, będąca mierzona np. częstością występowania błędów * **Performance** wydajność aplikacji określana również jako czas odpowiedzi lub użycie zasobów * **Supportability** przenosność, rozszerzalność, nie dająca się łatwo przetłumaczyć “wspieralność” uwzględniająca zdolność aplikacji do instalacji na różnych platformach, łatwość testowania itd. ===== Diagramy użycia ===== Przykładowy scenariusz uzycia: {{:zajecia:ppz:diagramy-uzycia3.jpeg?300|}} [[wppl>Przypadek użycia]] powinien przedstawiać podstawowy przebieg operacji, tzw. szczęśliwą ścieżkę wydarzeń ("basic flow", "happy flow") Przykład: - System prosi Użytkownika o zalogowanie - Użytkownik podaje swój numer identyfikacyjny oraz hasło - System stwierdza poprawność danych - Użytkownik zostaje zalogowany do systemu Ścieżki alternatywne - sytuacje, gdy nie zachodzi ścieżka optymalna.\\ Dla punktu 3 może zajść, np.: * System odrzuca podane dane * Powrót do kroku 1. ===== Przykład dokumentu ===== - Wprowadzenie – krótki opis celu systemu. - Słownik – definicja wszystkich technicznych i specyficznych terminów użytych w dokumencie. - Modele systemu – (np. graficzny) relacje między elementami systemu i środowiskiem systemu. \\ O ile uda się już na tym etapie taki model sporządzić. Na początek ogólny model (lub brak modelu). - Wymagania funkcjonalne – powinien się tu znaleźć możliwie pełny spis usług systemu, przy czym nie muszą one jeszcze być opisywane bardzo szczegółowo.\\ W tej sekcji można również zawrzeć informacje o danych, jakie system będzie przetwarzał: * Opis – krótki opis funkcjonalności. * Wejście – definicja danych wejściowych i ich ewentualnych ograniczeń. * Wyjście – definicja zwracanych rezultatów. * Efekty uboczne – określenie dodatkowych czynności, np. interakcji z innymi funkcjami. - Wymagania niefunkcjonalne – w tej sekcji przede wszystkim należy wypisać ograniczenia wynikające z oczekiwań klienta co do technologii, w której ma to być realizowane. - Dodatkowo można zawrzeć diagramy (przypadki) użycia