docAnaliza/Inżynieria wymagań Analiza/Inżynieria wymagań
download 
Reklamacja Transkrypt
Analiza/Inżynieria wymagań Analiza/Inżynieria wymagań
Znaczenie inżynierii wymagań Analiza/Inżynieria wymagań Definicja Requirements Engineering (RE) is a set of activities concerned with identifying and communicating the purpose of a software-intensive system, and the contexts in which it will be used. Hence, RE acts as the bridge between the real world needs of users, customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software intensive technologies. Definicja inżynierii Co to są wymagania Podstawowe zasady Warto rozróżniać sformułowanie problemu od jego rozwiązania Pełna separacja nie jest możliwa – rozwiązanie zmienia oryginalny problem „In nearly every software project which fails to meet performance and cost goals, requirements inadequacies play a major and expensive role in project failure”, Alford and Lawson Development of requirements specification „in many cases seems trivial, but it is probably the part of the process which leads to more failures than any other”, Schwartz Engineering is the development of costeffective solutions to practical problems, through the application of scientific knowledge Źródła trudności Klient z reguły nie wie dokładanie w jaki sposób osiągnąć założone cele. Cele te można osiągnąć na wiele sposobów. Duże systemy są wykorzystywane przez wielu użytkowników. Ich cele są często sprzeczne. Różni użytkownicy mogą posługiwać się inną terminologia mówiąc o tych samych problemach. Zleceniodawcy i użytkownicy to często inne osoby. 1 Problemy w zbieraniu wymagań Rozproszenie wiedzy dziedzinowej Niejawna wiedza Trudne obserwacje Nikt nie wie wszystkiego (co jest nam potrzebne) Cele przedsięwzięcia Wiem, ale nie umiem wytłumaczyć Czas Obserwator zmienia zachowanie Nie mogę powiedzieć Nie chcę powiedzieć Wzrost efektywności, spadek kosztów, rozszerzenie rynku, unikanie błędów Użytkownicy, nabywcy, różni partnerzy biznesowi mogą mieć różne cele Wykonawcy Ukierunkowanie (bias) Klienta, np. Biznesowe Techniczne Priorytety ! Rozwiązywany problem Cele warto też formułować w kategoriach rozwiązywania pewnych problemów Koszty są zbyt wysokie Jest zbyt wiele błędów Nie można tego zrobić w sposób tradycyjny Kontekst systemu Użytkownicy – role Istniejące oprogramowanie Specyficzny sprzęt Planner tras komunikacją miejską Użytkownicy Cele: szybko i wygodnie sprawdzić jak gdzieś dojechać, czy można/warto dojechać, o której wyjść Problemy: brak znajomości rozkładów, trudne planowanie trasy na podstawie rozkładów Planner tras komunikacją miejską Kontekst Systemy przewoźników Urządzeni z usługą lokalizacji Przewoźnicy Cel: pozyskać użytkowników Problem: użytkownicy nie wiedzą czy i jak skorzystać z komunikacji miejskiej 2 Internetowy system planowania wyjazdów (wycieczek) turystycznych Użytkownicy Indywidualni turyści Biura podróży Konsultanci – np. pracownicy biura informacji turystycznej Internetowy system planowania wyjazdów turystycznych Klienci Nabywcy – operatorzy instancji systemu Problem: planowanie wycieczki jest żmudne, a efekty często niezadowalające Cele: wygodne, szybkie planowanie udanych wyjazdów turystycznych Edytorzy Administratorzy Partnerzy biznesowi nabywców – pośredni użytkownicy – właściciele atrakcji turystycznych, hotele, przewoźnicy, operatorzy systemów rezerwacji, biura podróży, biura promocji turystyki Internetowy system planowania wyjazdów turystycznych Kontekst (poza użytkownikami) Użytkownicy Istniejący system optymalizacji wycieczek Istniejące systemy rezerwacji hoteli i biletów Istniejące systemy promocji turystyki Zleceniodawcy przewozów (to mogą być te same firmy) Elektroniczny rynek usług transportowych Administratorzy Siły i słabości wewnątrz organizacji: Cele: osiągnięcie zysku – zdobycie wielu klientów Kontekst istniejące systemy informatyczne przewoźników i zleceniodawców Problemy: nieprzewidywalność zleceń - nadmiar lub brak zleceń Cele: zdobycie opłacalnych zleceń zapewniających dobre wykorzystanie zasobów Analiza SWOT Problemy: wysokie koszty realizacji jednorazowych, zwłaszcza niewielkich zleceń, trudność znalezienia przewoźnika Cele: obniżenie kosztów, zapewnienie wysokiej jakości realizacji zleceń Firmy przewozowe Klienci – operatorzy systemu (wirtualna firma transportowa) Cel: uzyskanie klientów dla swoich usług Elektroniczny rynek usług transportowych Cele: osiągnięcie zysku, zdobycie dużej liczby użytkowników i partnerów biznesowych Strengths – silne strony Weaknesses – słabe strony Czynniki zewnętrzne Opportunities – szanse Threats – zagrożenia – zewnętrzne ryzyka 3 SWOT - Elektroniczny rynek usług transportowych Strengths Weaknesses •Dobra znajomość i kontakty na rynku przewoźników •Sprawność w zakresie wytwarzania oprogramowania •Słaba znajomość rynku zleceniodawców •Brak doświadczenia na rynku pośrednictwa w zakresie przewozów Opportunities Threats •Rosnąca konkurencja na rynku przewozów •Duże rozdrobnienie rynku przewoźników •Postępująca informatyzacja zleceniodawców i przewoźników •Konkurencyjne systemy ogłoszeniowe •Niezbędny efekt skali •Potrzebna integracja z dużą liczbą różnych systemów informatycznych Określanie wymagań Współpraca klienta i wykonawcy ! Źródła: Wywiady z przedstawicielami klienta materiałów dostarczonych przez klienta, przepisów prawnych Porównanie z innymi systemami Analiza Techniki zbierania wymagań Tradycyjne Introspekcja Analiza istniejących dokumentów Analiza danych Wywiady Otwarte Ustruktaralizowane Ankiety Spotkania Kognitywne Analiza zadań Techniki zbierania wiedzy Kontekstowe Techniki etnograficzne Analiza dyskusji Socjotechniczne Techniki grupowe (np. burze mózgów) JAD/RAD Prototypowanie Participatory design Zalety Duża ilość informacji Możliwość głębokiej analizy – kontynuacja ciekawych wątków Wady Soft systems analysis Zespołowe Wywiady Dużo nieuporządkowanych informacji jakościowych Trudne porównywanie odpowiedzi różnych osób Wymaga umiejętności i doświadczenia Uważaj na: Wiedzę niejawną Brak kontekstu Nastawienie rozmówcy Wskazówki dotyczące wywiadów Początek Umieść urządzenie w widocznym miejscu Powiedz, że rozmówca może zawsze wyłączyć nagrywanie Zacznij od łatwych pytań Kontynuuj interesujące wątki Zostaw otwarte pytania na koniec Zalety Pogoda, fotografia na biurku Zapytaj czy możesz nagrywać rozmowę Zacznij od ogólnych uwag rozluźniających atmosferę Ankiety Szybkie źródło dużych ilości informacji Mogą być zbierane zdalnie Dostarczają informacji o nastawieniu, przekonaniach, charakterystykach Wady Uważaj na Ograniczone, uproszczone Dobór próby ankietowanych Małe próby Otwarte pytania – trudne do analizy Pytania sugerujące odpowiedź „Czy chciałby Pan coś jeszcze dodać?” Ankietę należy prototypować i testować 4 Techniki grupowe Zalety Wady Bardziej naturalne niż formalne wywiady Wykorzystanie dodatkowych pomocy (tablica…) Sztuczne grupy Myślenie grupowe Wymaga dobrego moderatora Uważaj na Zły dobór grupy Zależności (służbowe) pomiędzy uczestnikami Diagramy przypadków użycia – use case diagrams Rodzaje wymagań Wymagania funkcjonalne – funkcje wspomagane przez oprogramowania przypadki użycia (use (use cases) cases) Wymagania niefunkcjonalne – ograniczenia Diagramy przypadków użycia – use case diagrams Użytkownik, klasa użytkowników, system zewnętrzny (ang. (ang. actor) actor) Grupa użytkowników wykorzystujących system w podobny sposób Korzystanie z funkcji (ang. (ang. actor flow) flow) Przypadek użycia, wymaganie funkcjonalne, funckja (ang. (ang. use case) case) Związki używania (use) i rozszerzania (extend) Przykład i związek generalizacji (generalization) Uzywane sporadycznie, podczas dodawania pojazdu, jezeli nie ma jeszcze danej kategorii Dodawanie kategorii pojazdow «extend» Uzytkownik Przewoznik Wydawanie opinii Zleceniodawca «use» Edycja pojazdów Dodawanie pojazdu Zarzadzanie pojazdami Optymalizacja Zarzadzanie uzytkownikami Zarzadzanie ladunkami «use» Przewoznik «use» Usuwanie pojazdow Edycja pojazdu Administrator 5 Hierarchia wymagań funkcjonalnych Przykład: Sposoby poszukiwania wymagań funkcjonalnych Z góry na dół Z dołu do góry Podejście mieszane Ewidencja klientów Dodawanie klienta Edycja danych klienta Usuwanie klienta Wyszukiwanie klientów Wyszukiwanie proste Wyszukiwanie złożone Wykorzystanie hierarchii wymagań Wykorzystanie informacji o rolach użytkowników Śledzenie procesów biznesowych Analiza scenariuszy Z góry na dół Z dołu do góry Metoda mieszana Wykorzystanie informacji o rolach użytkowników f4 f2 Kierownik Ksiegowy f1 f3 f6 f5 f7 f8 f9 Kasjer Magazynier 6 Cechy Zalety Śledzenie procesów biznesowych System może być stosunkowo prosty z punktu widzenia większości użytkowników Wady Punkty widzenia użytkowników mogą być niespójne Potrzeba integracji f1 f4 f6 U1 f2 U2 f7 U3 f3 f5 f8 Business process modeling notation - BPMN Wejście Wyjście (wynik) Cele Zadania Proces biznesowy – proces, którego wynik ma wartość biznesową Proces obsługi klienta półpółhurtowego Śledzenie procesów biznesowych Proces zbiór czynności wykonywanych przez różne osoby i działy organizacji scharakteryzowany przez: 1. Dział sprzedaży – wybór produktów, sformułowanie zamówienia połączone z weryfikacją dostępności produktów 2. Magazyn – ponowna weryfikacja, skompletowanie zamówienia 3. Księgowość – wystawienie faktury, rozliczenie finansowe 4. Magazyn – wydanie towarów BPMN przykład Standard OMG De facto standard przemysłowy © 1997-2007 Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka © 1997-2007 Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka 7 Analiza scenariuszy Analiza scenariuszy - przykład Scenariusz – słowny opis przykładowego sposobu (scenariusza) korzystania z systemu Z reguły obejmuje wiele funkcji Analiza scenariuszy – przykład c. d. Użytkownik podaje podstawowe informacje o planowanym wyjeździe. Chce odwiedzić Polskę, spędzić tam tydzień, wjedzie i wyjedzie od strony Czech. Interesują go ciekawe miasta, wykopaliska archeologiczne i wydarzenia muzyczne (muzyka klasyczna). Określa ograniczenia finansowe. System generuje proponowany plan podróży biorąc pod uwagę podane preferencje i ograniczenia. Analiza scenariuszy – przykład c. d. Użytkownik może szczegółowo przeglądać proponowaną trasę korzystając m. in. z prezentacji multimedialnych System proponuje użytkownikowi potencjalne modyfikacje trasy, biorąc pod uwagę położenie geograficzne poszczególnych atrakcji oraz wybory innych użytkowników o podobnych preferencjach Użytkownik modyfikuje trasę dodając do niej wizytę w Biskupinie i rezygnując z wizyty w Gnieźnie Użytkownik akceptuje trasę i otrzymuje jej szczegółowy opis (wydruk, plik) Użytkownik wybiera funkcję rezerwacji hoteli. Po dokonaniu niewielkiej opłaty system współpracując z zewnętrznym systemem rezerwacji hotelowej dokonuje odpowiednich rezerwacji Funkcje wynikające ze scenariusza Definiowanie ograniczeń i preferencji Generowanie planu podróży Przeglądanie trasy Wizualizacja geograficzna Prezentacja harmonogramu trasy Multimedialne prezentacje atrakcji Generowanie i prezentacja proponowanych zmian Funkcje wynikające ze scenariusza Modyfikowanie trasy Akceptowanie trasy Przygotowanie szczegółowego opisu trasy Rezerwacja hoteli Pobieranie opłaty Rezerwacja hotelu 8 Funkcje wynikające ze scenariusza Analiza scenariuszy Użytkownik wchodzi na naszą stronę i ponieważ korzystał z niej już wcześniej wybiera od razu opcję wyszukiwania. wyszukiwania. Najpierw określa kraj, który go interesuje – Szwajcaria, a następnie miasto – Zurich Zurich.. Użytkownik wybiera rodzaj oferty turystycznej – narty. narty. Ponieważ uprawianie narciarstwa w samym Zurichu nie jest możliwe otrzymuje listę kilku pobliskich stacji narciarskich. narciarskich. Użytkownik zapoznaje się z informacjami o kilku stacjach narciarskich – trasy, wyciągi, ceny, możliwość wypożyczenia sprzętu oraz aktualne warunki śniegowe. śniegowe. Użytkownik sprawdza możliwość dojazdu z Zurichu do stacji narciarskiej Flumsberg Flumsberg.. Sprawdza też możliwości zakwaterowania w (pobliżu) Flumsbergu.. Ostatecznie dokonuje rezerwacji biletu rail&ski i Flumsbergu pokoju w pensjonacie we Flumsbergu. Flumsbergu. Wybór obszaru zainteresowania Wybór rodzaju oferty turystycznej Przeglądanie ofert stacji narciarskich Wyszukiwanie możliwości dojazdu Wyszukiwanie możliwości zakwaterowania Rezerwacja Do magazynu zgłasza się klient, który złożył zamówienie w dziale sprzedaży. Klient podaje numer zamówienia, lub inną informację identyfikującą klienta. Magazynier odszukuje zamówienie w systemie i weryfikuje czy zamówiony towar został już zablokowany dla potrzeb klienta. Jeżeli tak, to potwierdza przyjęcie zamówienia do realizacji i prosi klienta o przejście do księgowości. Magazynier otrzymuje listę towarów do wydania wraz z ich lokalizacjami. Po skompletowaniu zamówienia potwierdza ten fakt w systemie. Po wydaniu towaru klientowi potwierdza ten fakt w systemie. Zalety Naturalne dla użytkowników Przydatne w wyjaśnianiu znaczenia systemu/funkcji Podstawa testów akceptacyjnych i dokumentacji użytkowej Realizacja zamówienia Identyfikacja zamówienia Weryfikacja zablokowania towaru Potwierdzenie przyjęcia zamówienia do realizacji Potwierdzenie skompletowania zamówienia Potwierdzenie wydania towaru Cechy Rezerwacja biletów Rezerwacja miejsc noclegowych Funkcje wynikające ze scenariusza Analiza scenariuszy Wybór kraju Wybór miasta Specyfikacja wymagań Język naturalny – 79% Metody formalne – 5% Formularze – 16% Wady Niepełne Niespójne 9 Elementy specyfikacji wymagań Nazwa Opis Dane wejściowe i ich źródła Wynik Warunki początkowe i końcowe Efekty uboczne Wyjątki Priorytet Źródło wymagania Wymagania powiązane Uzasadnienie Wymagania niefunkcjonalne Ograniczenia dotyczące Produktu Procesu Współpracy z systemami zewnętrznymi Problem specyfikacji wymagań niefunkcjonalnych w sposób weryfikowalny Specyfikacja wymagań niefunkcjonalnych w sposób weryfikowalny Wydajność Ostrzezenie Wykonanie tej operacji spowoduje utrate wszystkich wyników obliczen. Czy chcesz kontynuowac? Rozmiar Liczba transakcji obsłużonych w ciągu sekundy Czas odpowiedzi Szybkość odświeżania ekranu Wymagana pamięć RAM Wymagana pamięć dyskowa Łatwość użytkowania Nie Specyfikacja wymagań niefunkcjonalnych w sposób weryfikowalny Niezawodność Prawdopodobieństwo błędnego wykonania podczas realizacji transakcji Częstotliwość występowania błędnych wykonań Średni czas pomiędzy błędnymi wykonaniami Dostępność (procent czasu, w którym system jest dostępny) Odporność (ang. robustness) Czas restartu po awarii systemu Prawdopodobieństwo zniszczenia danych w przypadku awarii Przenośność Tak Czas niezbędny dla przeszkolenia użytkowników Liczba stron dokumentacji Zgodność ze standardami Procent kodu zależnego od platformy docelowej Liczba platform docelowych Koszt przeniesienia na nową platformę Zestaw praktyk Sommerville’a, Sawyera Dokument opisujący wymagania Zbieranie wymagań (requirements (requirements elicitation) elicitation) Analiza i negocjowanie wymagań Opis wymagań Modelowanie systemu Atestowanie wymagań (requirements (requirements validation) validation) Zarządzanie wymaganiami 10 Dokument opisujący wymagania - praktyki Ustandaryzuj strukturę dokumentu Wyjaśnij jak korzystać z dokumentu Dodaj podsumowanie wymagań Uzasadnij wartość biznesową systemu Zdefiniuj specjalistyczne terminy Zorganizuj dokument w czytelny sposób Pomóż czytelnikom znaleźć informacje Uczyń dokument łatwym z zmianach Ustandaryzuj strukturę dokumentu Lepsza czytelność Pomoc w opracowywaniu dokumentu Możliwość automatyzacji Struktura wg. IEEE/ANSI 8308301993 1. Introduction Dołącz sekcję „jak korzystać z dokumentu” Przede wszystkim w jaki sposób powinni z niego korzystać różni czytelnicy – użytkownicy, analitycy, wykonawcy, kierownicy 2.1 Product perspective 2.2 Product functions 2.3 User charactristics 2.4 General characteristics 2.5 Assumptions and dependencies 3. Specific requirement Appendices Index Uzasadnij wartość biznesową systemu Dodaj podsumowanie wymagań Standard powinien dopuszczać różne warianty Wyjaśnij jak korzystać z dokumentu 2. General description 1.1 Purpose of the requirements document 1.2 Scope of the product 1.3 Definitions, acronyms, abbreviations 1.4 References 1.5 Overview of the reminder of the document Zalety: Sekcja „Overview” – cel, założenia główne wymagania Odpowiednia sekcja w dokumencie 11 Zdefiniuj specjalistyczne terminy Np. sekcja „glossary” Zorganizuj dokument w czytelny sposób Także terminy używane w ramach dokumentu w zawężonym, specyficznym znaczeniu Dokument opisujący wymagania jest często czytany Ogólne zasady czytelności tekstu Np. printer Pomóż czytelnikom znaleźć informacje Indeks Czytelna organizacja Najlepsza forma elektroniczna - wyszukiwanie Zbieranie wymagań (requirements elicitation) - praktyki Oceń wykonalność systemu Weź pod uwagę względy organizacyjne i polityczne Zidentyfikuj i skonsultuj zainteresowane strony Zapisuj źródła wymagań Zdefiniuj środowisko pracy Kieruj procesem poszukiwania wymagań biorąc pod uwagę względy biznesowe Szukaj ograniczeń dziedzinowych Krótkie akapity Krótkie zdania Podział na sekcje Wyróżniki, wyliczenia Wykorzystanie prostych diagramów – wraz z dobrymi wyjaśnieniami Uczyń dokument łatwym z zmianach Wymagania będą się zmieniać Łatwiejsze w formie elektronicznej Zbieranie wymagań (requirements elicitation) - praktyki Zapisuj uzasadnienia wymagań Zbieraj wymagania z różnych punktów widzenia Prototypuj źle rozumiane wymagania Używaj scenariuszy do zbierania wymagań Zdefiniuj procesy, w których będzie wykorzystywany system Ponownie wykorzystuj wymagania 12 Weź pod uwagę względy organizacyjne i polityczne Oceń wykonalność systemu Studium wykonalności powinno zawsze poprzedzać intensywniejsze inwestycje w pracę nad systemem, w tym zbieranie szczegółowych wymagań Zarówno kwestie techniczne, jak i biznesowe Lęk przed utratą wpływów/pracy Konfliktowe cele Kultura współzawodnictwa Różne sposoby pracy Zidentyfikuj i skonsultuj zainteresowane strony Zainteresowane strony (stakeholders): Użytkownicy końcowi (różne klasy) Zarząd Klienci Wykonawcy Administratorzy Ciała zewnętrzne – urzędy, organizacje certyfikujące Zalety Pełniejszy zestaw wymagań Przekonanie do systemu wszystkich zainteresowanych stron Zapisuj źródła wymagań Platforma sprzętowa i programowa Interfejsy z innymi systemami Zależność od innych programów (np. założenie, że użytkownik ma dostęp do maila nawet jeżeli nasz system nie łączy się z nim bezpośrednio) ... , np. rozmieszczenie fizyczne Należy brać pod uwagę zmiany środowiska Osoba, grupa organizacja, od której pochodzi wymaganie Inne źródła – standardy, dokumenty, raporty W wielu wypadkach niezbędne okazuje się wyjaśnienie wątpliwości dotyczących wymagań Czasem sama informacja o źródle wyjaśnia te wątpliwości Kieruj procesem poszukiwania wymagań biorąc pod uwagę względy biznesowe Zdefiniuj środowisko pracy Czynniki organizacyjne i polityczne (często niejawne) mogą wpływać (np. utrudniać) proces zbierania wymagań Względy biznesowe (business concerns) concerns) ogólne biznesowe cele klienta Użyteczny system musi wspomagać realizację biznesowych celów klienta Wpływają na priorytet celów szczegółowych i wymagań 13 Szukaj ograniczeń dziedzinowych Ograniczenia, które występują obiektywnie (niezależnie od naszego systemu) w dziedzinie problemu Np. ograniczenia związane z bankowością, podatkami, itd. Zapisuj uzasadnienia wymagań Generują wymagania niefunkcjonalne Wykazanie zgodności z tymi wymaganiami może być niezbędne do wdrożenia systemu Zbieraj wymagania z różnych punktów widzenia Powinno być specyfikowane przez osobę (grupę) będąca źródłem wymagań Ułatwia zrozumienie wymagań Ułatwia nadawanie priorytetów Punkty widzenia (i zbiory wymagań) zainteresowanych strony, w tym różnych klas użytkowników Zalety Ułatwia proces zbierania wymagań Zapewnia pełniejszy obraz systemu Ułatwia nadawanie priorytetów – wymagania istotne dla wielu stron są z reguły ważniejsze Rodzaje punktów widzenia Interaktorów (interactors (interactors)) – użytkownicy, inne systemy Zainteresowanych stron nie będących bezpośrednimi użytkownikami Dziedziny problemu – wymagania wynikające z samej dziedziny problemu, a nie pochodzące od konkretnych osób lub organizacji Prototypuj źle rozumiane wymagania Ułatwia zrozumienie (efektu) wymagań Bardzo efektywne w przypadku wymagań związanych z interfejsem użytkownika Czasami pozwala zaniechać realizacji niepotrzebnego/niewykonalnego systemu Czasami prototyp może mieć dodatkowe zastosowania: Może być w jakimś stopniu wykorzystywany przez użytkownika Może zostać częściowo wykorzystany w pełnym systemie (choć z założenia jest porzucany) Może służyć do szkoleń, dalszych demonstracji Bardzo ważna jest krosowe sprawdzenie (cross (cross checking) checking) wymagań i ich integracja Techniki prototypowania Cel – szybko, tanio osiągnąć cel prototypowania Papier Czarodziej z Oz Programowanie Nie wszystkie wymagania można prototypować – np. efektywność, niezawodność 14 Używaj scenariuszy do zbierania wymagań Opis scenariusza Stosunkowo łatwe dla użytkownika Pozwala odkryć nowe wymagania Ma wiele zalet podobnych do prototypowania Z reguły nie opisują systemu w pełni Większe systemy mogą wymagać dużej liczby scenariuszy – kilkadziesiąt, kilkaset Stan systemu przed rozpoczęciem scenariusza Normalny przebieg wydarzeń Możliwe wyjątki Informacje o innych czynnościach, które mogą zachodzić w tym samym czasie Opis systemu po zakończeniu scenariusza Zwykle 33-4 strony + tabele, rysunki Często pewne części scenariuszy mogą być ponownie wykorzystane Zdefiniuj procesy, w których będzie wykorzystywany system Przeznaczenie systemu można często opisać jako wspomaganie jednego lub wielu procesów biznesowych Pozwala zidentyfikować: Role użytkowników i zainteresowanych stron Ponownie wykorzystuj wymagania W podobnych systemach nawet 80% wymagań może być ponownie wykorzystane Zalety Redukcja kosztów Redukcja ryzyka Może prowadzić do ponownego wykorzystania modelu, projektu, kodu i testów Procesy często będą już opisane: Modele biznesowe Modele dla systemów workflow Procesy są często bardzo skomplikowane, ich tworzenie od podstaw może być bardzo kosztowne Sposoby wykorzystania wymagań Bezpośredni – przeniesienie wymagań Analiza i negocjowanie wymagań Często niemożliwe Kwestia praw do wymagań Pośredni – wykorzystanie w procesie zbierania wymagań Np. poddanie krytyce istniejących wymagań dla podobnego systemu Cel – ustalenie kompletnego, niesprzecznego zbioru wymagań akceptowanego przez wszystkie zainteresowane strony Wykrycie brakujących wymagań Wykrycie konfliktowych wymagań Wykrycie niejasnych wymagań Wykrycie wymagań zachodzących na siebie Wykrycie nierealistycznych wymagań Analiza i negocjowanie przeplata się ze zbieraniem wymagań 15 Analiza i negocjowanie wymagań Zdefiniuj granice systemu Wykorzystaj listę kontrolną do analizy wymagań Wykorzystaj narzędzia wspomagające negocjacje Planując weź pod uwagę konflikty i ich rozwiązywanie Określ priorytety wymagań Stwórz wielowymiarową klasyfikację wymagań Wykorzystaj tablice interakcji (interaction (interaction matrices) matrices) do znalezienia konfliktów i nakładających się wymagań Oceń ryzyko wymagań Zdefiniuj granice systemu Przykłady wymagań spoza granic systemu Wymagania związane z podejmowaniem decyzji trudnych do zamodelowania Wymagania wymagające informacje niedostępnych systemowi Wymagania nieistotne z punktu widzenia głównych celów systemu Wymagania dotyczą funkcjonalności lub ograniczeń wobec zewnętrznych programów lub sprzętu Część wstępnie określonych wymagań może nie dotyczyć systemu lecz jego otoczenia Granice systemu powinny być określone już na podstawie ogólnych wymagań Wykorzystaj listę kontrolną do analizy wymagań Zestaw punktów/pytań, pod kątem których analizowane jest każde wymaganie Około 10 punktów Nie jest (pełną) weryfikacją jakości Ryzyko zbytniego skupienia się na liście i niedostrzegania innych problemów Wykorzystaj narzędzia wspomagające negocjacje Przykładowa lista Czy wymaganie wprowadza zbyt szybkich założeń co do projektu? Czy wymaganie nie powinno być rozbite na kilka oddzielnych? Czy wymaganie jest potrzebne? Czy wymaganie wymaga niestandardowego sprzętu? Czy wymaganie jest zrozumiałe/jednoznaczne? Czy wymaganie jest realistyczne? Czy wymaganie jest weryfikowalne/testowalne? Podstawowe narzędzia – e-mail, komunikatory, listy dyskusyjne, programy konferencyjne Zaawansowane – wspierające negocjacje – raczej etap badawczy Zalety Redukcja kosztu Redukcja barier osobowych Szybkie wyjaśnienie prostych wątpliwości 16 Planując weź pod uwagę konflikty i ich rozwiązywanie Określ priorytety wymagań Poważne wątpliwości i konflikty powinny być rozwiązywane podczas poświęconych temu spotkań Pojawienie się konfliktów nie jest błędem lecz sytuacja typową Wspomaga wybór wymagań do realizacji Ułatwia rozwiązywanie konfliktów Ułatwia projektowanie Priorytety powinny być nadawane wtedy, kiedy znany jest w miarę kompletny zestaw wymagań Różne zainteresowane strony mogą inaczej widzieć priorytety wymagań Stwórz wielowymiarową klasyfikację wymagań Określ priorytety wymagań Niewielka liczba klas, np.: Niezbędne Użyteczne Przydatne Wykrycie związków pomiędzy wymaganiami, w tym sprzeczności i nakładania się Ułatwia śledzenie (traceability (traceability)) wymagań i wprowadzanie zmian Ułatwia wykrycie brakujących wymagań Przydatne pytania: Co jeżeli implementacja tego wymagania podwoi koszty systemu? Co jeżeli implementacja tego wymagania uniemożliwi realizacja wymagania XYZ? Przykładowe klasy Systemowe – wydajność, niezawodność Interfejs użytkownika Baza danych Komunikacja (z zewnętrznymi systemami) Bezpieczeństwo Zalety: Wykorzystaj tablice interakcji (interaction matrices) do znalezienia konfliktów i nakładających się wymagań Może być trudne dla dużej liczby wymagań 17 Oceń ryzyko wymagań Dla każdego wymagania lub grupy wymagań: Potencjalne problemy Prawdopodobieństwo ich wystąpienia Możliwe efekty Pozwala przewidzieć problemy jakie mogą się pojawić w trakcie realizacji systemu Często prowadzi do wykrycia źle, np. niekompletnie opisanych wymagań Przykłady ryzyk Wydajność Bezpieczeństwo Ochrona Proces – konieczność zmian w procesie wytwarzania oprogramowania Technologia realizacji Baza danych – np. duże, niestrukturalne zbiory danych Harmonogram Ryzyka zewnętrzne – np. konieczność współpracy z zewnętrznymi kooperantami Stabilność/zmienność Zdefiniuj szablony dla opisu wymagań Opis wymagań - praktyki Zdefiniuj szablony dla opisu wymagań Pisz prosto, spójnie i krótko Używaj diagramów w miarę potrzeb Uzupełniaj opis słowny dodatkowymi formami opisu Specyfikuj wymagania w sposób ilościowy Zalety Ułatwiają zbieranie informacji – służą jako lista kontrolna Zwiększają przejrzystość opisu Usprawniają proces opisywania wymagań – skracają czas, zmniejszają liczbę błędów Wymagania są czytane częściej niż pisane Pisz prosto, spójnie i krótko Zalecenia Skraca czas czytania Zwiększa zbiór odbiorców wymagania Krótkie zdania Nigdy nie zamieszczać więcej niż jednego wymagania w jednym zdaniu Unikać: Unikać specjalistycznego żargonu Krótkie akapity Listy, tabele Spójne użycie terminologii Wyraźne rozróżnianie tego co konieczne od tego co pożądane Długich, złożonych zdań Długich akapitów Skomplikowanej terminologii System ma ... i ... Np. CASE w zarządzaniu to studium przypadku 18 Używaj diagramów w miarę potrzeb Zalecenia Unikaj zagnieżdżonych wyrażeń warunkowych Unikaj opisu skomplikowanych zaleźności w języku naturalnym – stosuj np. diagramy Forma aktywna Unikaj anonimowych odwołań do innych sekcji dokumentu, innych wymagań, rysunków, tabel I oczywiście dbaj o poprawność Przykłady Tablice decyzyjne Kod, pseudokod Zapis algebraiczny Diagramy przepływu danych Wykresy Gantt’a UML Notacje stosowane w ramach dziedziny problemu Z reguły należy unikać stosowania specjalistycznych notacji Ostrożne używanie kolorów i ikon Diagramy są bardzo przydatne w prezentacjach dla klienta Dotyczy zwłaszcza wymagań niefunkcjonalnych Ważną sprawą jest dobór odpowiednich metryk Większa precyzja Mniej błędów w zapisie i interpretacji Modelowanie systemu Specyfikuj wymagania w sposób ilościowy Zalety: Strukturę Zależności Sekwencje, np. zdarzeń, zadań Wykresy pokazujące zależności liczbowe Uzupełniaj! opis słowny dodatkowymi formami opisu Diagramy ilustrujące Np. jeżeli X, to jeżeli Y to R1a, w przeciwnym wypadku jeżeli Z, to R1b, a w przeciwnym wypadku R1c (kiedy R1c?) Jeżeli jest to niezbędne lepiej zastosować inny zapis niż język naturalny – formalizm matematyczny, diagram Zbuduj model systemu Zamodeluj otoczenie systemu Zamodeluj architekturę systemu Wykorzystuj metodykę modelowania Wykorzystuj słownik danych Dokumentuj powiązania pomiedzy wymaganiami a elementami modelu Atestowanie wymagań (requirements validation) - praktyki Zweryfikuj czy dokument wymagań jest zgodny ze standardami Zorganizuj formalne przeglądy wymagań Używaj specjalistów z różnych dziedzin do przeglądów wymagań Zdefiniuj listy kontrolne atestowania Używaj prototypów do animacji wymagań Napisz draft podręcznika użytkownika Zaproponuj przypadki testowe Opisz słownie model systemu 19 Cele Analiza dotyczy roboczych wersji wymagań Atestowanie dotyczy prawie gotowego dokumentu (final (final draft) draft) Zweryfikuj czy dokument wymagań jest zgodny ze standardami Szybkie sprawdzenie poprzedzające ogólny przegląd – jedna osoba Ułatwia i skraca czas ogólnego przeglądu Nie istnieje obiektywna informacja, względem której można weryfikować wymagania Zorganizuj formalne przeglądy wymagań Formalne przeglądy techniczne dotyczące wymagań W odróżnieniu od innych przeglądów technicznych często obejmują dyskusję nad rozwiązaniem problemów Typowe problemy: Niejasności Brakujące informacje Konflikty Nierealistyczne wymagania Używaj specjalistów z różnych dziedzin do przeglądów wymagań 40 wymagań / h ? Zdefiniuj listy kontrolne atestowania Użytkownicy Przedstawiciele klienta Eksperci dziedzinowi Inżynierowie Pozwalają skupić uwagę recenzentów na najważniejszych sprawach Wprowadzają strukturę do procesu oceny Wspomagają naukę osób początkujących Elementy listy kontrolnej Czy wymagania są kompletne (jako całość, cała grupa)? Czy wymagania są spójne, zgodne? Czy wymagania są zrozumiałe? Czy wymagania są niejednoznaczne? Czy opis wymagań ma odpowiednią strukturę (np. powiązania, grupowanie)? Czy można śledzić powiązania? Czy opis poszczególnych wymagań i cały dokument jest zgodny ze standardami? 20 Używaj prototypów do animacji wymagań Eksperymentalne sprawdzenie wymagań Atestowanie wymaga pełniejszego prototypu niż analiza. Powinien obejmować wszystkie wymagania Użytkownicy powinni pracować samodzielnie Odpowiedni dobór użytkowników Wskazówki dotyczące oceny, np. raport błędów Napisz draft podręcznika użytkownika Wymusza dokładną analizę wymagań Przydatne dla osób oceniających prototyp Podstawa ostatecznej dokumentacji użytkowej Zaproponuj przypadki testowe Dla każdego wymagania zaproponuj jeden lub kilka testów Zalety Ułatwia wykrycie problemów. Trudność w zaproponowaniu przypadków testowych często wynika z problemów z samymi wymaganiami. Podstawa przyszłych testów systemu. Jakie scenariusze mogą być przydatne przy opracowywaniu testów? Czy opis danego wymagania zawiera wystarczające informacje do opracowania testów? Może wskazywać na istotne powiązania pomiędzy wymaganiami. Czy potrzebnych jest jeden czy wiele testów? Czy możne zreformułować wymaganie, aby ułatwić jego testowanie. Zarządzanie wymaganiami (requirements management) - praktyki Opisz słownie model systemu Notacje graficzne, np. UML nie są zrozumiałe dla większości zaangażowanych stron – użytkowników, ekspertów dziedzinowych Nie zastępuje dokumentu wymagań Pytania Zalety Jednoznacznie zidentyfikuj każde wymaganie Zdefiniuj zasady (policy (policy)) zarządzania wymaganiami Zdefiniuj zasady śledzenia powiązań (traceability (traceability)) Utrzymuj podręcznik śledzenia powiązań (traceability (traceability manual)) manual Korzystaj z bazy danych wymagań Zdefiniuj zasady modyfikowania wymagań Zidentyfikuj globalne wymagania systemu Zidentyfikuj wymagania zmienne (volatile (volatile)) Zachowuj odrzucone wymagania 21 Zarządzanie wymaganiami Główne zagadnienia Jednoznacznie zidentyfikuj każde wymaganie Zarządzanie zmianami Błędy, nieporozumienia, zmiany w otoczeniu Zarządzanie powiązań pomiędzy wymaganiami Zarządzanie powiązań pomiędzy wymaganiami a innymi artefaktami przedsięwzięcia Zapewnienie realizacji wymagań Ocena kosztów proponowanych zmian Zdefiniuj zasady (policy) zarządzania wymaganiami Cele zarządzania wymaganiami Standardy i procedury postępowania Część systemu zapewniania jakości firmy Zasady (policy (policy)) mówią co należy zrobić, standardy i procedury mówią jak to zrobić w konkretnych sytuacjach Zdefiniuj zasady śledzenia powiązań (traceability) Przykłady powiązań: Wymagania- źródła WymaganiaWymagania – uzasadnienia Wymagania – wymagania Wymagania – składowe architektury Wymagania – składowe projektu Wymagania – interfejsy (do zewnętrznych systemów) Naturalne w systemach elektronicznych Elementy zasad zarządzania wymaganiami Niezbędne przy wprowadzaniu powiązań pomiędzy wymaganiami Pozwala śledzić wymagania, których opis się zmienił Cele i ich uzasadnienie Niezbędne raporty Niezbędne standardy Zasady zarządzania zmianami i kontroli realizacji wymagań Zasady przeglądów i atestowania wymagań Powiązania pomiędzy zasadami zarządzania wymaganiami a innymi obszarami zarządzania Zasady śledzenia powiązań Warunki, w których te zasady mogą zostać zaniechane Przykładowe typy powiązań Wymaga Jest wymagany przez Specyfikuje 22 Utrzymuj podręcznik śledzenia powiązań (traceability manual) Zasady śledzenia powiązań Jakie powiązania powinny być zapamietywane? Jak je reprezentować? Kiedy wprowadzać powiązania? Sytuacje wyjątkowe – możliwość zaniechania zasad Specyficzne czynniki dotyczące projektu brane pod uwagę Liczba wymagań Szacowany czas budowy i ewolucji systemu Poziom dojrzałości organizacji Rozmiar i skład zespołu Typ systemu Zasady proponowania, oceny, przeglądów i wprowadzania zmian Główne zalety: całościowa ocena wpływu zmian – lepsza kontrola kosztów możliwość śledzenia ewolucji wymagań możliwość proponowania zmian przez wszystkie zainteresowane strony Najlepiej, jeżeli jest dostępny ogólnie w formie elektronicznej Korzystaj z bazy danych wymagań Ogólnie korzystanie z narzędzi wspomagających zarządzanie wymaganiami Zalety: łatwiejsze przechowywanie powiązań pomiędzy wymaganiami oraz pomiędzy wymaganiami i innymi artefaktami praca równoległa przetwarzanie, np. raporty Zdefiniuj zasady modyfikowania wymagań Dodatek do dokumentu wymagań Specyficzne zasady śledzenia powiązań obowiązujące w danym projekcie Zidentyfikuj globalne wymagania systemu Wymagania globalne: definiują pożądane lub niezbędne wymagania wobec całego systemu nie dotyczą poszczególnych fragmentów systemu Zmiany w wymaganiach globalnych mogą być bardzo trudne/kosztowne do wprowadzenia. Wymagają w związku z tym szczególnej uwagi. 23 Identyfikacja wymagań globalnych Czy jest wyrażone w bardzo ogólny sposób? np. dane w bazie danych muszą zawsze pozostawać poprawne Identyfikacja wymagań globalnych Czy wyraża ogólną, niefunkcjonalną własność systemu? Czy jest to ogólne wymaganie dotyczące interfejsu użytkownika? Odpowiedzi „tak” wskazują na wymagania globalne system musi obsługiwać N transakcji na sekundę Zidentyfikuj wymagania zmienne (volatile) Należy identyfikować i w miarę możliwości przewidywać zmienne wymagania Zalety: zmienność wymagań można uwzględnić projektując system zmienność tych wymagań można uwzględnić w planie przedsięwzięcia Odpowiedzi „nie” wskazują na wymagania globalne Rodzaje zmiennych wymagań Czy wymaganie dotyczy konkretne funkcji/usługi systemu? Czy wymaganie można powiązać z konkretnym fragmentem systemu? Czy wymaganie można powiązać z konkretnymi danymi w systemie? Mutujące (mutable (mutable)) – zmienne w wyniku częstych zian w otoczeniu systemu Pojawiające/rozwijające się (emergent (emergent)) – nie mogą być w pełni zdefiniowane na początku przedsięwzięcia Wynikowe (consequential (consequential)) – wynikają z pewnych założeń co do sposobu korzystania z systemu, które mogą okazać się niewłaściwe Związane ze zgodnością (compatibility (compatibility)) – zależą od zewnętrznych systemów (oprogramowanie, sprzęt) Zachowuj odrzucone wymagania Odrzucone wymagania często pojawiają się ponownie może to oznaczać, że istnieją poważne powody, aby takie wymaganie jednak wprowadzić może to oznaczać, że ponownie proponowane wymagania można odrzucić ze znanych już powodów Odrzucone wymagania mogą być przydatne w innych systemach 24
