Analiza/Inżynieria wymagań

Znaczenie inżynierii wymagań Analiza/Inżynieria wymagań 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 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 Engineering is the development of costeffective solutions to practical problems, through the application of scientific knowledge 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 Ź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 Nikt nie wie wszystkiego (co jest nam potrzebne) Niejawna wiedza Wiem, ale nie umiem wytłumaczyć Trudne obserwacje Czas Obserwator zmienia zachowanie Ukierunkowanie (bias) Nie mogę powiedzieć Nie chcę powiedzieć Cele przedsięwzięcia Klienta, np. 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 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 Przewoźnicy Cel: pozyskać użytkowników Problem: użytkownicy nie wiedzą czy i jak skorzystać z komunikacji miejskiej Planner tras komunikacją miejską Kontekst Systemy przewoźników Urządzeni z usługą lokalizacji 2

Internetowy system planowania wyjazdów (wycieczek) turystycznych Użytkownicy Indywidualni turyści Biura podróży Konsultanci np. pracownicy biura informacji turystycznej Problem: planowanie wycieczki jest żmudne, a efekty często niezadowalające Cele: wygodne, szybkie planowanie udanych wyjazdów turystycznych Edytorzy Administratorzy Internetowy system planowania wyjazdów turystycznych Klienci Nabywcy operatorzy instancji systemu Cele: osiągnięcie zysku, zdobycie dużej liczby użytkowników i partnerów biznesowych 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 Cel: uzyskanie klientów dla swoich usług Internetowy system planowania wyjazdów turystycznych Kontekst (poza użytkownikami) Istniejący system optymalizacji wycieczek Istniejące systemy rezerwacji hoteli i biletów Istniejące systemy promocji turystyki Elektroniczny rynek usług transportowych Użytkownicy Zleceniodawcy przewozów (to mogą być te same firmy) 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 Problemy: nieprzewidywalność zleceń - nadmiar lub brak zleceń Cele: zdobycie opłacalnych zleceń zapewniających dobre wykorzystanie zasobów Administratorzy Elektroniczny rynek usług transportowych Klienci operatorzy systemu (wirtualna firma transportowa) Cele: osiągnięcie zysku zdobycie wielu klientów Kontekst istniejące systemy informatyczne przewoźników i zleceniodawców Analiza SWOT Siły i słabości wewnątrz organizacji: 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 Dobra znajomość i kontakty na rynku przewoźników Sprawność w zakresie wytwarzania oprogramowania Opportunities Rosnąca konkurencja na rynku przewozów Duże rozdrobnienie rynku przewoźników Postępująca informatyzacja zleceniodawców i przewoźników Weaknesses Słaba znajomość rynku zleceniodawców Brak doświadczenia na rynku pośrednictwa w zakresie przewozów Threats 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 Analiza materiałów dostarczonych przez klienta, przepisów prawnych Porównanie z innymi systemami Techniki zbierania wymagań Wywiady Tradycyjne Introspekcja Analiza istniejących dokumentów Analiza danych Wywiady Otwarte Ustruktaralizowane Ankiety Spotkania Zespołowe Techniki grupowe (np. burze mózgów) JAD/RAD Prototypowanie Participatory design Kognitywne Analiza zadań Techniki zbierania wiedzy Kontekstowe Techniki etnograficzne Analiza dyskusji Socjotechniczne Soft systems analysis Zalety Duża ilość informacji Możliwość głębokiej analizy kontynuacja ciekawych wątków Wady 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 Zacznij od ogólnych uwag rozluźniających atmosferę Pogoda, fotografia na biurku Zapytaj czy możesz nagrywać rozmowę 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 Czy chciałby Pan coś jeszcze dodać? Ankiety Zalety Szybkie źródło dużych ilości informacji Mogą być zbierane zdalnie Dostarczają informacji o nastawieniu, przekonaniach, charakterystykach Wady Ograniczone, uproszczone Uważaj na Dobór próby ankietowanych Małe próby Otwarte pytania trudne do analizy Pytania sugerujące odpowiedź Ankietę należy prototypować i testować 4

Techniki grupowe Zalety Bardziej naturalne niż formalne wywiady Wykorzystanie dodatkowych pomocy (tablica ) Wady 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 Rodzaje wymagań Wymagania funkcjonalne funkcje wspomagane przez oprogramowania - przypadki użycia (use cases) Wymagania niefunkcjonalne ograniczenia Diagramy przypadków użycia use case diagrams Użytkownik, klasa użytkowników, system zewnętrzny (ang. actor) Grupa użytkowników wykorzystujących system w podobny sposób Diagramy przypadków użycia use case diagrams Korzystanie z funkcji (ang. actor flow) Przypadek użycia, wymaganie funkcjonalne, funckja (ang. use case) Związki używania (use)) i rozszerzania (extend) Dodawanie kategorii pojazdow Uzywane sporadycznie, podczas dodawania pojazdu, jezeli nie ma jeszcze danej kategorii Przykład i związek generalizacji (generalization) Uzytkownik «extend» Przewoznik Wydawanie opinii Zleceniodawca «use» Edycja pojazdów «use» Dodawanie pojazdu Zarzadzanie pojazdami Optymalizacja Zarzadzanie uzytkownikami Zarzadzanie ladunkami Przewoznik «use» Usuwanie pojazdow Edycja pojazdu Administrator 5

Przykład: Hierarchia wymagań funkcjonalnych Ewidencja klientów Dodawanie klienta Edycja danych klienta Usuwanie klienta Wyszukiwanie klientów Wyszukiwanie proste Wyszukiwanie złożone Sposoby poszukiwania wymagań funkcjonalnych Wykorzystanie hierarchii wymagań Z góry na dół Z dołu do góry Podejście mieszane 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 f1 Ksiegowy f3 f6 f5 f9 f7 f8 Kasjer Magazynier 6

Zalety Cechy 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 Śledzenie procesów biznesowych Proces zbiór czynności wykonywanych przez różne osoby i działy organizacji scharakteryzowany przez: Wejście Wyjście (wynik) Cele Zadania Proces biznesowy proces, którego wynik ma wartość biznesową Śledzenie procesów biznesowych U1 f3 f1 f2 U2 f5 f4 U3 f8 f6 f7 Proces obsługi klienta pół- hurtowego 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 Business process modeling notation - BPMN Standard OMG De facto standard przemysłowy BPMN przykład 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 Scenariusz słowny opis przykładowego sposobu (scenariusza) korzystania z systemu Z reguły obejmuje wiele funkcji Analiza scenariuszy - przykład 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 Analiza scenariuszy przykład c. d. 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

Analiza scenariuszy Użytkownik wchodzi na naszą stronę i ponieważ korzystał z niej już wcześniej wybiera od razu opcję wyszukiwania. Najpierw określa kraj, który go interesuje Szwajcaria, a następnie miasto Zurich. Użytkownik wybiera rodzaj oferty turystycznej narty. Ponieważ uprawianie narciarstwa w samym Zurichu nie jest możliwe otrzymuje listę kilku pobliskich stacji 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. Użytkownik sprawdza możliwość dojazdu z Zurichu do stacji narciarskiej Flumsberg. Sprawdza też możliwości zakwaterowania w (pobliżu) Flumsbergu. Ostatecznie dokonuje rezerwacji biletu rail&ski i pokoju w pensjonacie we Flumsbergu. Funkcje wynikające ze scenariusza Wybór obszaru zainteresowania Wybór kraju Wybór miasta Wybór rodzaju oferty turystycznej Przeglądanie ofert stacji narciarskich Wyszukiwanie możliwości dojazdu Wyszukiwanie możliwości zakwaterowania Rezerwacja Rezerwacja biletów Rezerwacja miejsc noclegowych Analiza scenariuszy 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. Funkcje wynikające ze scenariusza Realizacja zamówienia Identyfikacja zamówienia Weryfikacja zablokowania towaru Potwierdzenie przyjęcia zamówienia do realizacji Potwierdzenie skompletowania zamówienia Potwierdzenie wydania towaru Zalety Cechy Naturalne dla użytkowników Przydatne w wyjaśnianiu znaczenia systemu/funkcji Podstawa testów akceptacyjnych i dokumentacji użytkowej Wady Niepełne Niespójne Specyfikacja wymagań Język naturalny 79% Metody formalne 5% Formularze 16% 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ść Liczba transakcji obsłużonych w ciągu sekundy Czas odpowiedzi Szybkość odświeżania ekranu Rozmiar Wymagana pamięć RAM Wymagana pamięć dyskowa Łatwość użytkowania Czas niezbędny dla przeszkolenia użytkowników Liczba stron dokumentacji Zgodność ze standardami Ostrzezenie Wykonanie tej operacji spowoduje utrate wszystkich wyników obliczen. Czy chcesz kontynuowac? Nie Tak 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ść 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 elicitation) Analiza i negocjowanie wymagań Opis wymagań Modelowanie systemu Atestowanie wymagań (requirements 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 Zalety: Ustandaryzuj strukturę dokumentu Lepsza czytelność Pomoc w opracowywaniu dokumentu Możliwość automatyzacji Standard powinien dopuszczać różne warianty Struktura wg. IEEE/ANSI 830-1993 1. Introduction 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 2. General description 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 Wyjaśnij jak korzystać z dokumentu 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 Dodaj podsumowanie wymagań Sekcja Overview cel, założenia główne wymagania Uzasadnij wartość biznesową systemu Odpowiednia sekcja w dokumencie 11

Zdefiniuj specjalistyczne terminy Np. sekcja glossary Także terminy używane w ramach dokumentu w zawężonym, specyficznym znaczeniu Np. printer Zorganizuj dokument w czytelny sposób Dokument opisujący wymagania jest często czytany Ogólne zasady czytelności tekstu Krótkie akapity Krótkie zdania Podział na sekcje Wyróżniki, wyliczenia Wykorzystanie prostych diagramów wraz z dobrymi wyjaśnieniami Pomóż czytelnikom znaleźć informacje Indeks Czytelna organizacja Najlepsza forma elektroniczna - wyszukiwanie Uczyń dokument łatwym z zmianach Wymagania będą się zmieniać Łatwiejsze w formie elektronicznej 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 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

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 Weź pod uwagę względy organizacyjne i polityczne Czynniki organizacyjne i polityczne (często niejawne) mogą wpływać (np. utrudniać) proces zbierania wymagań 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ń 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 Zdefiniuj środowisko pracy 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 Kieruj procesem poszukiwania wymagań biorąc pod uwagę względy biznesowe Względy biznesowe (business 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. Generują wymagania niefunkcjonalne Wykazanie zgodności z tymi wymaganiami może być niezbędne do wdrożenia systemu Zapisuj uzasadnienia wymagań Powinno być specyfikowane przez osobę (grupę) będąca źródłem wymagań Ułatwia zrozumienie wymagań Ułatwia nadawanie priorytetów Zbieraj wymagania z różnych punktów widzenia 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) 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 Bardzo ważna jest krosowe sprawdzenie (cross checking) wymagań i ich integracja 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 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ń 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 Opis scenariusza 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 3-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 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 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 Sposoby wykorzystania wymagań Bezpośredni przeniesienie 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 Analiza i negocjowanie wymagań 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 matrices) ) do znalezienia konfliktów i nakładających się wymagań Oceń ryzyko wymagań Zdefiniuj granice systemu 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ń 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 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 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? Wykorzystaj narzędzia wspomagające negocjacje 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 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ą Określ priorytety wymagań 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ń Określ priorytety wymagań Niewielka liczba klas, np.: Niezbędne Użyteczne Przydatne Przydatne pytania: Co jeżeli implementacja tego wymagania podwoi koszty systemu? Co jeżeli implementacja tego wymagania uniemożliwi realizacja wymagania XYZ? Zalety: Stwórz wielowymiarową klasyfikację wymagań Wykrycie związków pomiędzy wymaganiami, w tym sprzeczności i nakładania się Ułatwia śledzenie (traceability)) wymagań i wprowadzanie zmian Ułatwia wykrycie brakujących wymagań Przykładowe klasy Systemowe wydajność, niezawodność Interfejs użytkownika Baza danych Komunikacja (z zewnętrznymi systemami) Bezpieczeństwo 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ść 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 Zdefiniuj szablony dla opisu wymagań 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 Skraca czas czytania Zwiększa zbiór odbiorców wymagania Unikać: Długich, złożonych zdań Długich akapitów Skomplikowanej terminologii Zalecenia Krótkie zdania Nigdy nie zamieszczać więcej niż jednego wymagania w jednym zdaniu System ma... i... Unikać specjalistycznego żargonu Np. CASE w zarządzaniu to studium przypadku Krótkie akapity Listy, tabele Spójne użycie terminologii Wyraźne rozróżnianie tego co konieczne od tego co pożądane 18

Zalecenia Unikaj zagnieżdżonych wyrażeń warunkowych 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 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ść Używaj diagramów w miarę potrzeb Diagramy ilustrujące Strukturę Zależności Sekwencje, np. zdarzeń, zadań Wykresy pokazujące zależności liczbowe 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 Uzupełniaj! opis słowny dodatkowymi formami opisu Przykłady Tablice decyzyjne Kod, pseudokod Zapis algebraiczny Diagramy przepływu danych Wykresy Gantt a UML Notacje stosowane w ramach dziedziny problemu Zalety: Większa precyzja Mniej błędów w zapisie i interpretacji Specyfikuj wymagania w sposób ilościowy Dotyczy zwłaszcza wymagań niefunkcjonalnych Ważną sprawą jest dobór odpowiednich metryk Modelowanie systemu 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 draft) Nie istnieje obiektywna informacja, względem której można weryfikować wymagania 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 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 40 wymagań / h? Używaj specjalistów z różnych dziedzin do przeglądów wymagań Użytkownicy Przedstawiciele klienta Eksperci dziedzinowi Inżynierowie Zdefiniuj listy kontrolne atestowania 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 Zalety Napisz draft podręcznika użytkownika Wymusza dokładną analizę wymagań Przydatne dla osób oceniających prototyp Podstawa ostatecznej dokumentacji użytkowej Nie zastępuje dokumentu wymagań 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. Pytania 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. 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 Zarządzanie wymaganiami (requirements management) - praktyki Jednoznacznie zidentyfikuj każde wymaganie Zdefiniuj zasady (policy)) zarządzania wymaganiami Zdefiniuj zasady śledzenia powiązań (traceability) Utrzymuj podręcznik śledzenia powiązań (traceability manual) Korzystaj z bazy danych wymagań Zdefiniuj zasady modyfikowania wymagań Zidentyfikuj globalne wymagania systemu Zidentyfikuj wymagania zmienne (volatile) Zachowuj odrzucone wymagania 21

Zarządzanie wymaganiami Główne zagadnienia 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 Jednoznacznie zidentyfikuj każde wymaganie Niezbędne przy wprowadzaniu powiązań pomiędzy wymaganiami Pozwala śledzić wymagania, których opis się zmienił Naturalne w systemach elektronicznych Zdefiniuj zasady (policy) zarządzania wymaganiami Cele zarządzania wymaganiami Standardy i procedury postępowania Część systemu zapewniania jakości firmy Zasady (policy)) mówią co należy zrobić, standardy i procedury mówią jak to zrobić w konkretnych sytuacjach Elementy zasad zarządzania wymaganiami 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 Zdefiniuj zasady śledzenia powiązań (traceability) Przykłady powiązań: Wymagania- źródła Wymagania uzasadnienia Wymagania wymagania Wymagania składowe architektury Wymagania składowe projektu Wymagania interfejsy (do zewnętrznych systemów) Przykładowe typy powiązań Wymaga Jest wymagany przez Specyfikuje 22

Zasady śledzenia powiązań Jakie powiązania powinny być zapamietywane? Jak je reprezentować? Kiedy wprowadzać powiązania? Sytuacje wyjątkowe możliwość zaniechania zasad Utrzymuj podręcznik śledzenia powiązań (traceability manual) Dodatek do dokumentu wymagań Specyficzne zasady śledzenia powiązań obowiązujące w danym projekcie Najlepiej, jeżeli jest dostępny ogólnie w formie elektronicznej 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 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ń 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 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 Czy wyraża ogólną, niefunkcjonalną własność systemu? system musi obsługiwać N transakcji na sekundę Czy jest to ogólne wymaganie dotyczące interfejsu użytkownika? Odpowiedzi tak wskazują na wymagania globalne Identyfikacja wymagań globalnych 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? Odpowiedzi nie wskazują na wymagania globalne 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 Rodzaje zmiennych wymagań Mutujące (mutable) zmienne w wyniku częstych zian w otoczeniu systemu Pojawiające/rozwijające się (emergent) nie mogą być w pełni zdefiniowane na początku przedsięwzięcia Wynikowe (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) 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