Specyfikacja oprogramowania. Inżynieria wymagań [3 ed.] [PDF]

Zitiervorschau

Spis treści

Wstęp ...................................................................................................................19 Podziękowania .....................................................................................................25

CZĘŚĆ I

WYMAGANIA DOTYCZĄCE OPROGRAMOWANIA. CO, DLACZEGO I KTO?

Rozdział 1

Najważniejsze wymaganie dotyczące oprogramowania . ....................................29 Definicja wymagań dotyczących oprogramowania . ................................................................... 31 Niektóre interpretacje słowa „wymaganie” . ................................................................................. 32 Poziomy i rodzaje wymagań ........................................................................................................... 33 Praca na trzech poziomach ............................................................................................................. 37 Wymagania produktu a wymagania projektu . ............................................................................ 40 Opracowywanie wymagań i zarządzanie nimi . ........................................................................... 41 Opracowywanie wymagań .............................................................................................................. 41 Zarządzanie wymaganiami ............................................................................................................. 43 W każdym projekcie istnieją wymagania . .................................................................................... 43 Gdy złe wymagania trafiają na dobrych ludzi . ............................................................................. 45 Niewystarczające zaangażowanie użytkownika . .......................................................................... 45 Niedokładne planowanie ................................................................................................................ 46 Pełzające wymagania użytkowników . ........................................................................................... 46 Niejednoznaczne wymagania . ........................................................................................................ 46 Złocenie ............................................................................................................................................. 47 Przeoczeni interesariusze ................................................................................................................ 47 Korzyści płynące z wysokiej jakości procesu dotyczącego wymagań . ...................................... 47

Rozdział 2

Wymagania z punktu widzenia użytkownika . .....................................................49 Luka oczekiwań ................................................................................................................................ 50 Kim jest klient? ................................................................................................................................. 51 Partnerstwo klient-twórca oprogramowania . .............................................................................. 53 Wymaganiowa karta praw klienta oprogramowania . ......................................................... 55 Wymaganiowa karta obowiązków klienta oprogramowania . ............................................ 57

SPIS TREŚCI

Tworzenie kultury poszanowania wymagań . .............................................................................. 60 Identyfikowanie osób decyzyjnych . ............................................................................................... 62 Osiąganie porozumienia co do wymagań . ................................................................................... 62 Baza dla wymagań ..................................................................................................................... 63 Co zrobić, jeśli nie osiągnięto porozumienia? . ..................................................................... 64 Zgoda co do wymagań w projektach zwinnych . ................................................................... 65

Rozdział 3

Dobre praktyki w inżynierii wymagań . ................................................................67 Struktura procesu opracowywania wymagań . ............................................................................. 70 Dobre praktyki. Pozyskiwanie wymagań . .................................................................................... 72 Dobre praktyki. Analizowanie wymagań . .................................................................................... 74 Dobre praktyki. Specyfikowanie wymagań . ................................................................................. 76 Dobre praktyki. Walidacja wymagań . ........................................................................................... 77 Dobre praktyki. Zarządzanie wymaganiami . ............................................................................... 77 Dobre praktyki. Wiedza .................................................................................................................. 79 Dobre praktyki. Zarządzanie projektem . ...................................................................................... 80 Wdrażanie nowych praktyk ........................................................................................................... 82

Rozdział 4

Analityk biznesowy ..............................................................................................85 Rola analityka biznesowego . ........................................................................................................... 86 Zadania analityka biznesowego . .................................................................................................... 87 Najważniejsze umiejętności analityka . .......................................................................................... 88 Najważniejsza wiedza analityka . .................................................................................................... 92 Jak zostać analitykiem biznesowym? .............................................................................................92 Były użytkownik ............................................................................................................................... 92 Były programista albo tester ........................................................................................................... 93 Były (lub jednoczesny) menedżer projektu . ................................................................................. 94 Specjalista w swojej dziedzinie ....................................................................................................... 94 Żółtodziób ......................................................................................................................................... 94 Rola analityka w projektach zwinnych . ........................................................................................ 95 Rozwijanie współpracy w obrębie zespołu . .................................................................................. 96

CZĘŚĆ II

OPRACOWYWANIE WYMAGAŃ

Rozdział 5

Określanie wymagań biznesowych . ..................................................................101 Definiowanie wymagań biznesowych . ........................................................................................ 102 Identyfikowanie pożądanych korzyści biznesowych . ............................................................... 102 Wizja produktu i zakres projektu . ............................................................................................... 102 Sprzeczne wymagania biznesowe . ............................................................................................... 104 Dokument wizji i zakresu ............................................................................................................. 105 1. Wymagania biznesowe . ...................................................................................................... 107 2. Zakres i ograniczenia . ......................................................................................................... 112 3. Kontekst biznesowy ............................................................................................................ 114

8

SPIS TREŚCI

Techniki przedstawiania zakresu . ................................................................................................ 116 Diagram kontekstowy ................................................................................................................... 116 Mapa ekosystemu ........................................................................................................................... 117 Drzewo funkcjonalności ............................................................................................................... 118 Lista zdarzeń ................................................................................................................................... 119 Skupienie na zakresie .................................................................................................................... 120 Korzystanie z celów biznesowych podczas podejmowania decyzji dotyczących zakresu ... 121 Ocena wpływu zmian zakresu ...................................................................................................... 121 Wizja i zakres w projektach zwinnych . ....................................................................................... 122 Korzystanie z celów biznesowych, aby określić koniec projektu . ........................................... 123

Rozdział 6

Słuchanie głosu użytkownika . ...........................................................................125 Klasy użytkowników ...................................................................................................................... 126 Klasyfikowanie użytkowników . ................................................................................................... 126 Identyfikowanie klas użytkowników . .......................................................................................... 129 Personifikacje użytkowników . ..................................................................................................... 131 Nawiązywanie kontaktu z przedstawicielami użytkowników . ................................................ 132 Mistrz produktu ............................................................................................................................. 133 Zewnętrzni mistrzowie produktu . ............................................................................................... 134 Oczekiwania wobec mistrza produktu . ....................................................................................... 135 Wielu mistrzów produktu ............................................................................................................ 136 Informowanie o potrzebie zaangażowania mistrza produktu . ................................................ 137 Pułapki, na które należy uważać . ................................................................................................. 138 Przedstawiciele użytkowników w projektach zwinnych . ......................................................... 138 Godzenie sprzecznych wymagań . ................................................................................................ 140

Rozdział 7

Pozyskiwanie wymagań .....................................................................................143 Techniki pozyskiwania wymagań . ............................................................................................... 145 Wywiady .......................................................................................................................................... 145 Warsztaty ......................................................................................................................................... 146 Grupy fokusowe ............................................................................................................................. 148 Obserwacje ...................................................................................................................................... 149 Kwestionariusze ............................................................................................................................. 150 Analiza interfejsów systemu . ........................................................................................................ 151 Analiza interfejsu użytkownika .................................................................................................... 152 Analiza dokumentów .................................................................................................................... 152 Planowanie pozyskiwania wymagań . .......................................................................................... 153 Przygotowania do pozyskiwania wymagań . ............................................................................... 154 Czynności związane z pozyskiwaniem wymagań . ..................................................................... 156 Czynności po zebraniu wymagań . ............................................................................................... 158 Organizowanie i udostępnianie notatek . .................................................................................... 158 Dokumentowanie kwestii otwartych . ......................................................................................... 158 Klasyfikowanie informacji uzyskanych od użytkownika . ........................................................ 159 Skąd wiedzieć, że to już wszystko? . .............................................................................................. 162

9

SPIS TREŚCI

Na co uważać podczas pozyskiwania wymagań? . ..................................................................... 163 Wymagania oczywiste oraz pochodne . ....................................................................................... 163 Odnajdowanie pominiętych wymagań . ...................................................................................... 165

Rozdział 8

Zrozumieć wymagania użytkowników . .............................................................167 Przypadki użycia oraz opowieści użytkowników . ..................................................................... 169 Podejście bazujące na przypadkach użycia . ............................................................................... 172 Przypadki użycia i scenariusze użytkowania . ............................................................................ 173 Identyfikowanie przypadków użycia . .......................................................................................... 181 Badanie przypadków użycia ......................................................................................................... 182 Walidacja przypadków użycia . ..................................................................................................... 184 Przypadki użycia i wymagania funkcjonalne . ............................................................................ 185 Związane z przypadkami użycia pułapki, na które należy uważać . ........................................ 186 Korzyści płynące z wymagań zorientowanych na użytkowanie . ............................................ 187

Rozdział 9

Gra według reguł ...............................................................................................189 Systematyka reguł biznesowych . .................................................................................................. 191 Fakty ................................................................................................................................................. 192 Ograniczenia ................................................................................................................................... 192 Wyzwalacze działań ....................................................................................................................... 194 Wnioski ........................................................................................................................................... 195 Obliczenia ........................................................................................................................................ 195 Niepodzielne reguły biznesowe . .................................................................................................. 196 Dokumentowanie reguł biznesowych . ........................................................................................ 196 Odkrywanie reguł biznesowych . .................................................................................................. 198 Reguły biznesowe i wymagania . ................................................................................................... 200 Wiązanie wszystkiego w całość . ................................................................................................... 201

Rozdział 10

Dokumentowanie wymagań ..............................................................................203 Specyfikacja wymagań dotyczących oprogramowania . ............................................................ 205 Wymagania dotyczące etykiet . ..................................................................................................... 208 Postępowanie z brakami ............................................................................................................... 210 Interfejs użytkownika i SRS . ......................................................................................................... 210 Szablon wymagań dotyczących oprogramowania . ................................................................... 212 1. Wstęp .................................................................................................................................... 213 2. Opis ogólny .......................................................................................................................... 214 3. Funkcjonalności systemu . .................................................................................................. 215 4. Wymagania dotyczące danych . ......................................................................................... 216 5. Wymagania interfejsów zewnętrznych . ........................................................................... 217 6. Atrybuty jakościowe ........................................................................................................... 218 7. Wymagania międzynarodowe i lokalizacyjne .......................... 219 8. Pozostałe wymagania . ............................................................................................................................................................ 219 Dodatek A. Glosariusz . .................................................................................................................. 220 Dodatek B. Modele analityczne . .................................................................................................. 220 Specyfikacja wymagań w projektach zwinnych . ........................................................................ 220

10

SPIS TREŚCI

Rozdział 11 Pisanie doskonałych wymagań . ........................................................................223 Cechy doskonałych wymagań . ..................................................................................................... 224 Cechy wymagań ............................................................................................................................. 224 Cechy zbiorów wymagań .............................................................................................................. 226 Wskazówki dotyczące pisania wymagań . ................................................................................... 227 Perspektywa systemu czy perspektywa użytkownika . .............................................................. 227 Styl pisania wymagań .................................................................................................................... 228 Poziom szczegółowości ................................................................................................................. 231 Techniki przedstawiania wymagań . ............................................................................................ 232 Unikanie wieloznaczności ............................................................................................................ 233 Unikanie niekompletności ............................................................................................................ 236 Przykładowe wymagania — przed i po . ...................................................................................... 237

Rozdział 12

Jeden obraz wart jest 1024 słowa . ....................................................................241 Modelowanie wymagań ................................................................................................................ 242 Od głosu użytkownika do modeli analitycznych . ..................................................................... 243 Wybór właściwej reprezentacji . ................................................................................................... 244 Diagram przepływu danych ......................................................................................................... 246 Diagram torowy ............................................................................................................................. 250 Diagram przejść stanów i tabela stanów . .................................................................................... 251 Mapa dialogu .................................................................................................................................. 254 Tabele decyzyjne i drzewa decyzyjne . ......................................................................................... 257 Tabele zdarzenie-reakcja ............................................................................................................... 259 Kilka słów o diagramach UML . ................................................................................................... 261 Modelowanie w projektach zwinnych . ....................................................................................... 262 Ostatnie przypomnienie ................................................................................................................ 262

Rozdział 13

Specyfikowanie wymagań danych . ...................................................................265 Modelowanie relacji między danymi . ......................................................................................... 265 Słownik danych .............................................................................................................................. 268 Analiza danych ............................................................................................................................... 271 Specyfikowanie raportów . ............................................................................................................. 272 Pozyskiwanie wymagań dotyczących raportów . ....................................................................... 272 Co należy wziąć pod uwagę podczas specyfikowania raportów? . ........................................... 273 Szablon specyfikacji raportu . ........................................................................................................ 274 Kokpit zarządzania ........................................................................................................................ 277

Rozdział 14 Wykraczanie poza funkcjonalność . ....................................................................279 Atrybuty jakościowe oprogramowania . ...................................................................................... 280 Odkrywanie atrybutów jakościowych . ........................................................................................ 282 Definiowanie atrybutów jakościowych . ...................................................................................... 285 Zewnętrzne atrybuty jakościowe . ................................................................................................ 286 Wewnętrzne atrybuty jakościowe . ............................................................................................... 299 Specyfikowanie wymagań jakościowych w języku Planguage . ................................................ 304 Kompromisy związane z atrybutami jakościowymi . ................................................................ 305

11

SPIS TREŚCI

Implementowanie wymagań dotyczących atrybutów jakościowych . ..................................... 307 Ograniczenia ................................................................................................................................... 308 Atrybuty jakościowe w projektach zwinnych . ........................................................................... 310

Rozdział 15

Ograniczanie ryzyka z wykorzystaniem prototypowania . ..................................313 Prototypowanie. Co i dlaczego? . .................................................................................................. 314 Makiety i dowody koncepcji . ........................................................................................................ 315 Prototypy ewolucyjne i do wyrzucenia . ...................................................................................... 316 Prototypy papierowe i elektroniczne . ......................................................................................... 319 Praca z prototypami ....................................................................................................................... 321 Ocenianie prototypów ................................................................................................................... 323 Ryzyka prototypowania ................................................................................................................ 325 Presja skonstruowania prototypu . ............................................................................................... 325 Rozproszenie szczegółami ............................................................................................................ 326 Nierealne oczekiwania co do wydajności . .................................................................................. 326 Nadmierne nakłady ponoszone na prototypy . .......................................................................... 327 Czynniki decydujące o powodzeniu prototypowania . ............................................................. 327

Rozdział 16 Najpierw to, co najważniejsze — określanie priorytetów wymagań . ...............329 Dlaczego wymaganiom należy nadawać priorytety? . ............................................................... 330 Praktyczne podejście do nadawania priorytetów . ..................................................................... 331 Gierki z wymaganiami .................................................................................................................. 332 Niektóre techniki określania priorytetów . ................................................................................. 333 Wchodzi czy odpada? .................................................................................................................... 334 Porównywanie parami i szeregowanie rangowe . ...................................................................... 334 Skala trzypoziomowa ..................................................................................................................... 334 Metoda MoSCoW .......................................................................................................................... 336 100 złotych ...................................................................................................................................... 337 Nadawanie priorytetów na podstawie wartości, kosztu i ryzyka . ........................................... 338

Rozdział 17

Walidacja wymagań ...........................................................................................343 Walidacja i weryfikacja .................................................................................................................. 345 Przeglądy wymagań ....................................................................................................................... 345 Inspekcja .......................................................................................................................................... 347 Lista kontrolna defektów .............................................................................................................. 351 Wskazówki dotyczące oceniania wymagań . ............................................................................... 352 Wyzwania związane z ocenianiem wymagań . ........................................................................... 353 Prototypowanie wymagań ............................................................................................................ 355 Testowanie wymagań .................................................................................................................... 355 Walidacja wymagań z wykorzystaniem kryteriów akceptacji . ................................................ 359 Kryteria akceptacji .................................................................................................................. 359 Testy akceptacyjne .................................................................................................................. 361

12

SPIS TREŚCI

Rozdział 18

Ponowne wykorzystanie wymagań . ..................................................................363 Dlaczego powtórnie korzystać z wymagań? . .............................................................................. 364 Aspekty wielokrotnego korzystania z wymagań . ...................................................................... 364 Skala ponownego użycia ............................................................................................................... 365 Zakres modyfikacji ......................................................................................................................... 366 Mechanizm ponownego użycia . .................................................................................................. 366 Rodzaje informacji o wymaganiach, które można poddać powtórnemu użyciu . ................ 368 Najczęściej spotykane scenariusze wielokrotnego użycia . ....................................................... 369 Linia oprogramowania .................................................................................................................. 369 Reengineering i zastępowanie systemów . ................................................................................... 369 Inne okazje do wielokrotnego użycia . ......................................................................................... 370 Wzorce wymagań ........................................................................................................................... 371 Narzędzia wspomagające wielokrotne użycie . ........................................................................... 372 Przystosowanie wymagań do wielokrotnego użycia . ................................................................ 372 Przeszkody i czynniki sukcesu wielokrotnego użycia . .............................................................. 374 Przeszkody ............................................................................................................................... 374 Czynniki sukcesu .................................................................................................................... 376

Rozdział 19 Więcej niż tylko opracowywanie wymagań . .....................................................379 Szacowanie nakładów na wymagania . ........................................................................................ 380 Od wymagań do planów projektu . .............................................................................................. 383 Szacowanie wielkości projektu i niezbędnych nakładów na podstawie wymagań . .............. 383 Wymagania a harmonogram . ...................................................................................................... 385 Od wymagań do konstrukcji i kodu . ........................................................................................... 386 Architektura i alokacja .................................................................................................................. 387 Konstrukcja oprogramowania . .................................................................................................... 388 Konstrukcja interfejsu użytkownika . .......................................................................................... 389 Od wymagań do testów ................................................................................................................. 391 Od wymagań do sukcesu .............................................................................................................. 393

CZĘŚĆ III

WYMAGANIA W RÓŻNYCH KLASACH PROJEKTÓW

Rozdział 20 Projekty zwinne ..................................................................................................397 Ograniczenia procesu kaskadowego . .......................................................................................... 398 Zwinne podejście do programowania . ........................................................................................ 399 Najważniejsze aspekty zwinnego podejścia do opracowywania wymagań . .......................... 399 Zaangażowanie klienta .................................................................................................................. 399 Szczegółowość dokumentacji ....................................................................................................... 400 Rejestr wymagań i priorytety ....................................................................................................... 400 Właściwy czas ................................................................................................................................. 401 Epiki, opowieści użytkowników i funkcjonalności. O rany! . ................................................... 402 Spodziewaj się zmian ..................................................................................................................... 403 Dostosowywanie praktyk związanych z opracowywaniem wymagań do projektów zwinnych ... 403 Przejście na metodyki zwinne. I co teraz? . ................................................................................. 404

13

SPIS TREŚCI

Rozdział 21

Projekty ulepszające i zastępujące . ...................................................................407 Spodziewane trudności ................................................................................................................. 408 Techniki pracy nad wymaganiami, gdy system już istnieje . .................................................... 408 Nadawanie priorytetów przy wykorzystaniu celów biznesowych . ......................................... 410 Uwaga na lukę ................................................................................................................................ 411 Zachowanie poziomu wydajności . .............................................................................................. 411 Kiedy stare wymagania nie istnieją . ............................................................................................ 412 Które wymagania specyfikować? . ................................................................................................ 412 Jak odkrywać wymagania w istniejących systemach? . .............................................................. 414 Przekonywanie do przyjęcia nowego systemu . .......................................................................... 415 Czy możemy iterować? . ................................................................................................................. 416

Rozdział 22

Projekty bazujące na gotowych rozwiązaniach . ................................................419 Wymagania dotyczące wyboru produktów gotowych . ............................................................ 420 Opracowywanie wymagań użytkowników . ................................................................................ 420 Rozpatrywanie reguł biznesowych . ............................................................................................. 421 Identyfikowanie potrzeb związanych z danymi . ....................................................................... 421 Definiowanie wymagań jakościowych . ....................................................................................... 421 Ocenianie rozwiązań ..................................................................................................................... 422 Wymagania dotyczące implementacji gotowych produktów . ................................................ 424 Wymagania dotyczące konfiguracji . ........................................................................................... 425 Wymagania dotyczące integracji . ................................................................................................ 425 Wymagania dotyczące rozszerzeń . .............................................................................................. 426 Wymagania dotyczące danych ..................................................................................................... 426 Zmiany w procesach biznesowych . ............................................................................................. 426 Najczęściej spotykane problemy mające związek z gotowymi rozwiązaniami . .................... 427

Rozdział 23

Projekty zlecane na zewnątrz . ...........................................................................429 Odpowiedni stopień szczegółowości wymagań . ........................................................................ 430 Interakcje na linii zleceniodawca – wykonawca . ....................................................................... 431 Zarządzanie zmianami .................................................................................................................. 433 Kryteria akceptacji ......................................................................................................................... 433

Rozdział 24

Projekty automatyzacji procesów biznesowych . ...............................................435 Modelowanie procesów biznesowych . ........................................................................................ 436 Korzystanie z bieżących procesów w celu opracowania wymagań . ........................................ 437 Najpierw przyszłe procesy ............................................................................................................ 438 Modelowanie biznesowych miar wydajności . ........................................................................... 438 Dobre praktyki w projektach automatyzacji procesów biznesowych . ................................... 440

Rozdział 25

Projekty analityki biznesowej . ...........................................................................441 Przegląd projektów analityki biznesowej . .................................................................................. 441 Opracowywanie wymagań w projektach analityki biznesowej . .............................................. 443 Priorytetyzacja prac przy użyciu decyzji . ............................................................................. 444 Definiowanie sposobów korzystania z informacji . ............................................................ 445

14

SPIS TREŚCI

Specyfikowanie potrzeb danych . .................................................................................................. 446 Definiowanie analiz przekształcających dane . ........................................................................... 449 Ewolucyjny charakter analizy . ...................................................................................................... 450

Rozdział 26 Projekty systemów wbudowanych oraz innych systemów czasu rzeczywistego ...453 Wymagania, architektura oraz alokacja systemu . ..................................................................... 454 Modelowanie systemów czasu rzeczywistego . ........................................................................... 455 Diagram kontekstowy ................................................................................................................... 456 Diagram przejść stanów ................................................................................................................ 456 Tabela zdarzenie-reakcja ............................................................................................................... 457 Diagram architektury .................................................................................................................... 459 Prototypowanie .............................................................................................................................. 460 Interfejsy .......................................................................................................................................... 460 Wymagania czasowe ...................................................................................................................... 461 Atrybuty jakościowe dotyczące systemów wbudowanych . ...................................................... 462 Wyzwania związane z systemami wbudowanymi . .................................................................... 467

CZĘŚĆ IV Rozdział 27

ZARZĄDZANIE WYMAGANIAMI Praktyki zarządzania wymaganiami . .................................................................471 Proces zarządzania wymaganiami . .............................................................................................. 472 Baza dla wymagań .......................................................................................................................... 473 Kontrolowanie wersji wymagań . ................................................................................................. 474 Atrybuty wymagań ........................................................................................................................ 476 Śledzenie statusów wymagań ....................................................................................................... 477 Rozwiązywanie problemów związanych z wymaganiami . ....................................................... 479 Mierzenie nakładów ponoszonych na wymagania . .................................................................. 480 Zarządzania wymaganiami w projektach zwinnych . ................................................................ 482 Po co zarządzać wymaganiami? . .................................................................................................. 483

Rozdział 28

Zmiany się zdarzają ............................................................................................485 Po co zarządzać zmianami? .......................................................................................................... 485 Kontrolowanie pełzania zakresu . ................................................................................................. 486 Polityka kontrolowania zmian . .................................................................................................... 487 Podstawowe pojęcia związane z procesem kontrolowania zmian . ......................................... 488 Opis procesu kontrolowania zmian . ........................................................................................... 489 1. Cel i zakres ........................................................................................................................... 489 2. Role i odpowiedzialności . .................................................................................................. 489 3. Stany wnioskowanych zmian . ........................................................................................... 490 4. Kryteria początkowe ........................................................................................................... 490 5. Zadania ................................................................................................................................. 490 6. Kryteria końcowe ................................................................................................................ 492 7. Raportowanie statusu zmiany . .......................................................................................... 492 Dodatek. Atrybuty zapisywane dla każdego wniosku o zmianę . ..................................... 492

15

SPIS TREŚCI

Rada kontroli zmian ...................................................................................................................... 493 Skład rady ........................................................................................................................................ 494 Statut rady ....................................................................................................................................... 494 Renegocjowanie zobowiązań ........................................................................................................ 495 Narzędzia do kontrolowania zmian . ........................................................................................... 495 Pomiar aktywności dotyczącej zmian . ........................................................................................ 496 Analiza wpływu zmiany ................................................................................................................ 497 Procedura analizy wpływu ............................................................................................................ 498 Szablon analizy wpływu ................................................................................................................ 501 Zarządzanie zmianami w projektach zwinnych . ....................................................................... 501

Rozdział 29

Ogniwa w łańcuchu wymagań . .........................................................................505 Śledzenie wymagań ........................................................................................................................ 505 Argumenty przemawiające za śledzeniem wymagań . .............................................................. 508 Macierz śledzenia wymagań ......................................................................................................... 509 Narzędzie służące do śledzenia wymagań . ................................................................................. 512 Procedura dotycząca śledzenia wymagań . .................................................................................. 513 Czy śledzenie wymagań jest wykonalne? Czy jest konieczne? . ............................................... 514

Rozdział 30

Narzędzia inżynierii wymagań . .........................................................................517 Narzędzia do opracowywania wymagań . ................................................................................... 519 Narzędzia wspomagające pozyskiwanie wymagań . .................................................................. 519 Narzędzia do prototypowania ...................................................................................................... 519 Narzędzia do modelowania . ......................................................................................................... 520 Narzędzia do zarządzania wymaganiami . .................................................................................. 520 Korzyści płynące ze stosowania narzędzi do zarządzania wymaganiami . ............................. 520 Możliwości narzędzi do zarządzania wymaganiami . ................................................................ 522 Wybór oraz implementacja narzędzia do pracy z wymaganiami . .......................................... 524 Wybór narzędzia ..................................................................................................................... 525 Konfiguracja narzędzia i procesów . ..................................................................................... 525 Wspieranie adaptacji użytkowników . .................................................................................. 527

CZĘŚĆ V Rozdział 31

IMPLEMENTACJA INŻYNIERII WYMAGAŃ Ulepszanie procesów inżynierii wymagań . ........................................................531 Związek wymagań z innymi procesami projektu . ..................................................................... 532 Wymagania i różne grupy interesariuszy . .................................................................................. 534 Zachęcanie do angażowania się w zmiany . ................................................................................ 534 Podstawy usprawniania procesu programistycznego . .............................................................. 536 Analiza przyczyn źródłowych ...................................................................................................... 538 Cykl usprawniania procesu . ......................................................................................................... 539 Ocena bieżących praktyk . ...................................................................................................... 540 Planowanie działań ulepszających . ....................................................................................... 540

16

SPIS TREŚCI

Tworzenie, pilotowanie i wdrażanie procesów . ......................................................................... 542 Ocenianie wyników ....................................................................................................................... 542 Elementy procesu inżynierii wymagań . ...................................................................................... 543 Elementy procesu opracowywania wymagań . ........................................................................... 545 Elementy procesu zarządzania wymaganiami . .......................................................................... 546 Czy jesteśmy już na miejscu? ........................................................................................................ 546 Tworzenie planu usprawnienia procesu pracy z wymaganiami . ............................................ 548

Rozdział 32

Wymagania dotyczące oprogramowania a zarządzanie ryzykiem . ....................551 Podstawy zarządzania ryzykiem w oprogramowaniu . ............................................................. 552 Elementy zarządzania ryzykiem .................................................................................................. 552 Dokumentowanie ryzyka grożącego projektowi . ...................................................................... 553 Planowanie zarządzania ryzykiem . .............................................................................................. 556 Ryzyko związane z wymaganiami . ............................................................................................... 556 Pozyskiwanie wymagań ................................................................................................................ 557 Analiza wymagań ........................................................................................................................... 558 Specyfikacja wymagań ................................................................................................................... 558 Walidacja wymagań ....................................................................................................................... 559 Zarządzanie wymaganiami ........................................................................................................... 559 Zarządzanie ryzykiem to Twój przyjaciel . .................................................................................. 560

Epilog .................................................................................................................561

DODATKI Dodatek A

Samoocena bieżących praktyk dotyczących wymagań . .....................................565

Dodatek B

Poradnik usuwania problemów z wymaganiami . ..............................................571

Dodatek C

Przykładowe dokumenty wymagań . .................................................................591 Słowniczek .........................................................................................................613 Bibliografia .........................................................................................................621 Skorowidz ...........................................................................................................633

17

SPIS TREŚCI

18

Wstęp

Pomimo dziesięcioleci zdobywania doświadczeń w branży wiele organizacji nadal ma problemy ze zrozumieniem wymagań dotyczących swoich produktów, dokumentowaniem tych wymagań i zarządzaniem nimi. Niewystarczające informacje od użytkowników, niepełne albo zmieniające się wymagania i brak zrozumienia celów biznesowych są głównymi powodami, dla których tak wiele projektów związanych z technologiami informatycznymi nie odnosi sukcesów. Niektóre zespoły programistyczne nie są biegłe w pozyskiwaniu wymagań od klientów i z innych źródeł. Klienci często nie mają czasu ani cierpliwości, aby brać udział w czynnościach związanych z wymaganiami. W wielu przypadkach uczestnicy projektu nie osiągają nawet porozumienia co do znaczenia pojęcia „wymaganie”. Jak zauważył pewien autor, „inżynierowie woleliby raczej interpretować słowa klasycznej piosenki Kingsmenów »Louie, Louie« z 1963 roku niż wymagania użytkowników” (Peterson, 2002). Drugie wydanie Specyfikacji oprogramowania zostało opublikowane na 10 lat przed obecnym wydaniem. Dziesięć lat to w świecie technologii sporo czasu. Od tamtej pory wiele rzeczy się zmieniło, chociaż nie wszystkie. Do głównych trendów związanych w minionej dekadzie z wymaganiami można zaliczyć:  uznanie analizy biznesowej za dziedzinę zawodową oraz powstanie profesjonalnych certyfikatów i organizacji, takich jak International Institute of Business Analysis (Międzynarodowy Instytut Analizy Biznesowej) oraz International Requirements Engineering Board (Międzynarodowa Rada Inżynierii Wymagań),  udoskonalenie narzędzi zarówno do zarządzania wymaganiami w bazach danych, jak i do wspomagania czynności związanych z opracowywaniem wymagań, takich jak prototypowanie, modelowanie i prowadzenie symulacji,  rozszerzenie zakresu stosowania metod zwinnych oraz ewolucja technik związanych z wymaganiami w projektach zwinnych,  szersze użycie modeli wizualnych w celu reprezentowania wiedzy na temat wymagań. Co w takim razie nie uległo zmianie? Dwa czynniki sprawiają, że kwestia wymagań pozostaje ważna i aktualna. Po pierwsze, w wielu programach studiów licencjackich z zakresu inżynierii oprogramowania oraz informatyki nie przykłada się wagi do inżynierii wymagań (która obejmuje zarówno opracowywanie wymagań, jak i zarządzanie nimi). Po drugie, ci z nas, którzy działają w branży oprogramowania mają skłonność do zachwycania się technicznymi i procesowymi rozwiązaniami problemów, które napotykamy. Czasami nie dostrzegamy faktu, że pozyskiwanie wymagań — i w ogólności wiele pracy związanej z projektami oprogramowania i systemów — to przede wszystkim wyzwania dotyczące interakcji z innymi osobami. Nie pojawiły się żadne nowe sztuczki magiczne, które zautomatyzowałyby te czynności, chociaż istnieje wiele narzędzi wspomagających współpracę między osobami rozdzielonymi geograficznie.

WSTĘP

Sądzimy, że praktyki związane z opracowywaniem wymagań i zarządzaniem nimi, przedstawione w drugim wydaniu tej książki, nadal są aktualne i znajdują zastosowanie w wielu projektach programistycznych. Kreatywny analityk biznesowy, menedżer albo właściciel produktu w przemyślany sposób przystosuje te praktyki, aby najlepiej odpowiadały skali i potrzebom określonej sytuacji. Nowy w trzecim wydaniu jest rozdział poświęcony pracy z wymaganiami w projektach zwinnych oraz liczne podrozdziały opisujące, jak stosować i dostosowywać opisywane w danym rozdziale praktyki w środowisku zwinnym. Tworzenie oprogramowania wymaga komunikowania się przynajmniej w takim samym stopniu jak prowadzenia obliczeń, tymczasem w wielu programach szkoleniowych i czynnościach realizowanych w ramach projektów przedkłada się aspekt obliczeniowy nad komunikacyjny. Niniejsza książka oferuje dziesiątki narzędzi ułatwiających komunikację i wspomagających twórców oprogramowania, menedżerów, marketingowców i klientów w skutecznym stosowaniu metod inżynierii wymagań. Techniki te nie są egzotycznymi nowymi metodami ani wyszukaną metodologią, której celem jest rozwiązanie wszystkich Twoich problemów z wymaganiami, lecz pochodzą z głównego nurtu „dobrych praktyk” pracy z wymaganiami. Wiele anegdot i dygresji przedstawia historie (wszystkie prawdziwe), które ilustrują typowe doświadczenia związane z wymaganiami; być może byłeś świadkiem podobnych zdarzeń. Szukaj symboli „prawdziwych historii”, takich jak znak widoczny po lewej stronie, znajdujących się obok przykładów zaczerpniętych z wielu rzeczywistych doświadczeń. Od momentu pojawienia się pierwszego wydania tej książki w 1999 roku każde z nas pracowało nad wieloma projektami i prowadziło setki wykładów z zakresu wymagań dla osób z firm i agencji rządowych różnych wielkości i typów. Stwierdziliśmy, że praktyki te przydają się praktycznie we wszystkich projektach; małych i dużych, nowych i wzbogacających, z zespołami lokalnymi i rozproszonymi, a także korzystającymi zarówno z metod tradycyjnych, jak i zwinnych. Opisane praktyki mają zastosowanie nie tylko w projektach programistycznych, ale też w projektach związanych z inżynierią sprzętu i systemów. Tak samo jak w przypadku innych praktyk technicznych, w celu stwierdzenia, która metoda najlepiej sprawdzi się w Twoim przypadku, będziesz musiał poprawnie ocenić daną sytuację i odwołać się do własnego doświadczenia. Traktuj te praktyki jak narzędzia pomagające zagwarantować, że w ramach swojego projektu będziesz prowadzić skuteczne rozmowy z właściwymi osobami.

Korzyści płynące z tej książki Ze wszystkich zadań związanych z ulepszaniem procesów oprogramowania, których realizacji możesz się podjąć, usprawnione praktyki dotyczące wymagań należą do tych, które przynoszą największe korzyści. Opisujemy praktyczne i sprawdzone techniki, które pomogą Ci w:  pisaniu wysokiej jakości wymagań od chwili rozpoczęcia prac nad projektem, dzięki czemu zminimalizujesz liczbę poprawek i zmaksymalizujesz wydajność,  tworzeniu wysokiej jakości systemów informatycznych i produktów komercyjnych, które osiągają swoje cele biznesowe,  takim zarządzaniu pełzaniem zakresu i zmianami w wymaganiach, dzięki któremu będziesz je mieć pod kontrolą,  osiągnięciu wyższego stopnia zadowolenia klienta,  zmniejszeniu kosztów serwisu, aktualizacji i wsparcia produktu. Naszym celem jest udzielenie Ci pomocy w ulepszeniu procesu, z którego korzystasz podczas pozyskiwania i analizowania wymagań, pisania i weryfikowania specyfikacji wymagań oraz zarządzania wymaganiami w całym cyklu tworzenia produktu programistycznego. Techniki, które opisujemy, są pragmatyczne i realistyczne. Nasza dwójka korzystała z nich wiele razy i zawsze osiągaliśmy dzięki nim dobre wyniki. 20

WSTĘP

Kto powinien przeczytać tę książkę? Każda osoba mająca do czynienia z koniecznością definiowania albo rozumienia wymagań w dowolnym systemie zawierającym oprogramowania znajdzie w tej książce przydatne informacje. Główną grupą odbiorców są osoby pełniące funkcję analityka biznesowego albo inżyniera wymagań w projektach programistycznych, niezależnie od tego, czy są oni pełnowymiarowymi specjalistami, czy tylko członkami zespołu czasowo odgrywającymi rolę analityka. Drugą grupą odbiorców są architekci, projektanci, programiści, testerzy oraz pozostali techniczni członkowie zespołu, którzy muszą rozumieć i realizować oczekiwania użytkowników, a także brać udział w tworzeniu i ocenianiu wymagań. Marketingowcy i menedżerowie produktu, którzy są odpowiedzialni za specyfikowanie funkcji oraz atrybutów, dzięki którym program odniesie sukces komercyjny, także stwierdzą, że opisane w tej książce praktyki są cenne. Menedżerowie projektów dowiedzą się, jak planować i śledzić aktywności związane z wymaganiami i jak radzić sobie ze zmianami w wymaganiach. Kolejną grupą odbiorców mogą być interesariusze biorący udział w definiowaniu produktu, który ma spełniać ich potrzeby biznesowe, funkcjonalne i jakościowe. Książka ta pomoże użytkownikom końcowym, klientom nabywającym lub zamawiającym oprogramowanie, a także licznym innym interesariuszom zrozumieć ważność pracy z wymaganiami oraz ról, jakie w nim odgrywają.

Spojrzenie do przodu Książka ta podzielona jest na pięć części. Część I, „Wymagania dotyczące oprogramowania. Co, dlaczego i kto?”, rozpoczyna się od kilku definicji. Jeśli odpowiadasz za techniczną stronę projektu, podziel się rozdziałem 2., dotyczącym partnerstwa na linii klient – programista z Twoimi kluczowymi klientami. W rozdziale 3. streszczono kilkadziesiąt „dobrych praktyk” związanych z opracowywaniem wymagań i zarządzaniem nimi, a także opisano w zarysie proces opracowywania wymagań. Rola analityka biznesowego (która występuje także pod wieloma innymi nazwami) jest przedmiotem rozdziału 4. Część II, „Opracowywanie wymagań”, rozpoczyna się od technik definiowania wymagań biznesowych projektu. W pozostałych rozdziałach części II opisano, jak znaleźć odpowiednich przedstawicieli klienta, pozyskać od nich wymagania, a także jak udokumentować wymagania użytkowników, reguły biznesowe, wymagania funkcjonalne, wymagania dotyczące danych i wymagania pozafunkcjonalne. W rozdziale 12. omówiono liczne modele wizualne, uzupełniające opis w języku naturalnym, które prezentują wymagania z różnych perspektyw, natomiast w rozdziale 15. omówiono użycie prototypów w celu ograniczenia ryzyka. Pozostałe rozdziały części II poświęcone są sposobom priorytetyzowania, walidacji oraz powtórnego użycia wymagań. Część II kończy się opisem wpływu, jaki wymagania wywierają na inne aspekty pracy nad projektem. W niniejszym wydaniu część III zawiera rozdziały, w których zalecono najskuteczniejsze metody pracy z wymaganiami w rozmaitych klasach projektów: projektach zwinnych, w których tworzone są produkty różnych typów; projektach ulepszających i zastępujących, projektach bazujących na gotowych rozwiązaniach, projektach zlecanych na zewnątrz, projektach automatyzacji procesów biznesowych, projektach analityki biznesowej i projektach systemów wbudowanych oraz innych systemów czasu rzeczywistego. Zasady i praktyki zarządzania wymaganiami są przedmiotem części IV, w której położono nacisk na techniki związane ze zmianami w wymaganiach. W rozdziale 29. opisano, jak za pomocą śledzenia łączyć poszczególne wymagania zarówno z ich źródłami, jak i uzyskanymi na ich podstawie produktami. Część IV kończy się opisem narzędzi komercyjnych, które wzbogacają sposoby, w jakie Twój zespół opracowuje wymagania oraz nimi zarządza.

21

WSTĘP

Ostatnia, V część tej książki pomoże Ci przejść z koncepcji do praktyki. Dzięki rozdziałowi 31. włączysz techniki pracy z wymaganiami do procesu tworzenia, z jakiego korzysta Twój zespół. Najczęściej spotykane zagrożenia związane z wymaganiami zostały opisane w rozdziale 32. Samoocena z dodatku A pomoże Ci wybrać obszary domagające się usprawnienia. Dwa pozostałe dodatki zawierają przewodnik usuwania problemów oraz kilka przykładowych dokumentów związanych z wymaganiami, dzięki którym zobaczysz, jak poszczególne kawałki układają się w logiczną całość.

Studia przypadków W celu zilustrowania metod opisanych w niniejszej książce przedstawiamy przykłady zaczerpnięte ze studiów przypadków bazujących na rzeczywistych projektach, w szczególności na średniej wielkości systemie informatycznym o nazwie System śledzenia odczynników. Bez obaw, nie musisz mieć żadnej wiedzy o chemii, aby ten projekt zrozumieć. W książce są też porozrzucane przykładowe rozmowy prowadzone przez uczestników projektu. Bez względu na rodzaj oprogramowania, które tworzy Twoja organizacja, będziesz mógł odnieść do nich swoje doświadczenia.

Od zasad do praktyki Trudno jest zebrać energię potrzebną do pokonania przeszkód stojących na drodze ku zmianom i przełożyć nową wiedzę na działania. Pomocą w Twojej podróży do ulepszonych wymagań będą służyć zamieszczone pod koniec większości rozdziałów „Następne kroki”; czynności, które możesz wykonać, aby bezzwłocznie rozpocząć stosowanie w praktyce treści zawartych w danym rozdziale. W różnych rozdziałach znajdują się sugerowane szablony dokumentów wymagań, list kontrolnych, arkuszy służących do nadawania priorytetów wymaganiom, metod kontrolowania zmian i wielu innych elementów procesu. Pomoce te można pobrać ze strony z materiałami dodatkowymi do niniejszej książki: http://aka.ms/SoftwareReq3E/files Skorzystaj z nich w celu szybkiego rozpoczęcia stosowania nowych technik. Zacznij od niewielkich usprawnień, ale zrób to już dzisiaj. Niektóre osoby niechętnie wypróbowują nowe techniki pracy z wymaganiami. Skorzystaj z tej książki, aby doinformować swoich kolegów, klientów i przełożonych. Przypomnij im problemy związane z wymaganiami, na które natknęliście się we wcześniejszych projektach, i omówcie potencjalne korzyści płynące z wypróbowania nowych metod. Nie musisz startować z nowym projektem, aby rozpocząć stosowanie nowych technik. W rozdziale 21. omówiono sposoby stosowania omawianych technik w projektach wzbogacających i zastępujących. Stopniowe implementowanie technik pracy z wymaganiami jest procesem ulepszającym o niskim ryzyku, który przygotuje Cię na kolejny, poważniejszy projekt. Celem opracowywania wymagań jest zgromadzenie takiego ich zbioru, który będzie na tyle dobry, że pozwoli Twojemu zespołowi kontynuować projektowanie i konstruowanie następnego fragmentu produktu przy możliwym do przyjęcia poziomie ryzyka. Powinieneś poświęcić wymaganiom tyle swojej uwagi, aby ograniczyć ryzyko wprowadzania poprawek, otrzymania nieakceptowalnego produktu i przekroczonych harmonogramów. Książka ta da Ci narzędzia, przy których użyciu nakłonisz właściwe osoby do współpracy w opracowywaniu właściwych wymagań do właściwych produktów.

22

WSTĘP

Errata i wsparcie Dołożyliśmy wszelkich starań, aby książka ta oraz towarzyszące jej materiały dodatkowe były wolne od pomyłek. Wszelkie błędy, które mogły zostać zgłoszone już po opublikowaniu tej książki, zostały wymienione na stronie Microsoft Press w oreilly.com: http://aka.ms/SoftwareReq3E/errata Jeśli znajdziesz błąd, który nie jest tam wymieniony, możesz go zgłosić na tej samej stronie. Jeśli potrzebujesz dodatkowego wsparcia, wyślij wiadomość e-mail na adres Microsoft Press Book Support: [email protected]. Proszę mieć na uwadze, że za pośrednictwem powyższego adresu nie udzielamy wsparcia w związku z oprogramowaniem Microsoftu.

Potrzebujemy Twoich opinii W Microsoft Press naszym priorytetem jest Twoja satysfakcja, a najbardziej cenimy sobie Twoje opinie. Tutaj możesz nam powiedzieć, co myślisz o tej książce: http://aka.ms/tellpress Ankieta jest krótka, a my czytamy każdy Twój komentarz i wszystkie pomysły. Dziękujemy z góry za Twoją opinię!

Pozostań z nami w kontakcie Nie kończmy naszej rozmowy! Możesz znaleźć nas na Twitterze: http://twitter.com/MicrosoftPress.

23

WSTĘP

24

Podziękowania

Pisanie takiej książki jest zbiorowym wysiłkiem, który znacznie wykracza poza wkład wniesiony przez dwójkę jej autorów. Wiele osób poświęciło swój czas, aby przejrzeć cały rękopis i przekazać nam niezliczone sugestie dotyczące poprawek. Jesteśmy im głęboko wdzięczni. Szczególnie doceniamy bezcenne komentarze, które przekazali nam Jim Brosseau, Joan Davis, Gary K. Evans, Joyce Grapes, Tina Heidenreich, Kelly Morrison Smith i dr Joyce Statz. Dodatkowe komentarze przekazali Kevin Brennan, Steven Davis, Anne Hartley, Emily Iem, Matt Leach, Jeannine McConnell, Yaaqub Mohamed i John Parker. Część osób recenzowała określone rozdziały lub fragmenty, które miały związek z ich dziedziną wiedzy, często dzieląc się z nami bardzo szczegółowymi komentarzami. Na nasze podziękowania zasługują Tanya Charbury, Mike Cohn, dr Alex Dean, Ellen Gottesdiener, Shane Hastie, James Hulgan, dr Phil Koopman, Mark Kulak, Shirley Sartin, Rob Siciliano i Betsy Stockdale. Szczególnie pragniemy podziękować Roxanne Miller i Stephenowi Withallowi za ich głębokie przemyślenia i zaangażowanie. Rozmaite aspekty niniejszej książki omawialiśmy z wieloma osobami, czerpiąc wiedzę z ich osobistych doświadczeń oraz materiałów, które od nich otrzymaliśmy. Szczególnie cenimy sobie tego rodzaju informacje, które przekazali nam Jim Brosseau, Nanette Brown, Nigel Budd, Katherine Busey, Tanya Charbury, Jennifer Doyle, Gary Evans, Scott Francis, Sarah Gates, dr David Gelperin, Mark Kerin, Norm Kerth, dr Scott Meyers, John Parker, Kathy Reynolds, Bill Trosky, dr Ricardo Valerdi i dr Ian Watson. Dziękujemy też wielu osobom, które pozwoliły nam, abyśmy w naszych „prawdziwych historiach” przekazali ich anegdoty. Swój udział w tej książce mają liczne osoby w Seilevel. Oceniały one jej pewne fragmenty, brały udział w szybkich ankietach dotyczących opinii i doświadczeń, dzieliły się materiałami ze swoich blogów, edytowały końcowe rozdziały, rysowały ilustracje i pomagały nam w różnego rodzaju problemach operacyjnych. Na nasze podziękowania zasługują Ajay Badri, Jason Benfield, Anthony Chen, Kell Condon, Amber Davis, Jeremy Gorr, Joyce Grapes, John Jertson, Melanie Norrell, David Reinhardt, Betsy Stockdale i Christine Wollmuth. Ich praca sprawiła, że nasze zadanie stało się prostsze. Bardzo doceniamy redakcyjny wkład Candase Hokanson. Nasze podziękowania kierujemy do licznych osób w Microsoft Press, w tym redaktora pozyskującego Devona Musgrave’a, redaktorki projektu Carol Dillingham, redaktora projektu Christiana Holdenera z S4Carlisle Publishing Services, adiustatorki Kathy Krause, korektorki Nicole Schlutt, indekserki Maureen Johnson, zecera Sambasivama Sangarana i grafików M. Balaganesana, R. Srinivasana i G. Ganeshbabu. Karl szczególnie ceni swój długotrwały związek i przyjaźń z Devonem Musgrave i Benem Ryanem. Komentarze i pytania pochodzące od tysięcy uczestników biorących przez lata udział w naszych kursach bardzo pomagały nam stymulować nasze przemyślenia związane z wymaganiami. Nasze doświadczenia konsultantów i zmuszające do myślenia pytania, jakie otrzymywaliśmy od Czytelników, utrzymywały nas w kontakcie z problemami, z jakimi codziennie mierzyli się praktycy, i pomogły nam przemyśleć niektóre z tych trudnych tematów. Prosimy, abyście podzielili się z nami swoimi doświadczeniami, przesyłając korespondencję na adres [email protected] albo [email protected].

PODZIĘKOWANIA

Karl chciałby, jak zawsze, podziękować swojej żonie, Chris Zambito. Jak zwykle okazywała ona przez cały czas cierpliwość i dobry humor. Karl dziękuje także Joy za przekonanie go do pracy nad tym projektem i za ogromny wkład, który w nią włożyła. Praca z nią dała mu wiele radości i wniosła do tej książki ogromną wartość. Wspaniale było mieć kogoś, z kim można było wymieniać się pomysłami, liczyć na pomoc w podejmowaniu trudnych decyzji i kto wgryzał się w próbne wersje rozdziałów przed przekazaniem ich recenzentom. Joy jest szczególnie wdzięczna swojemu mężowi Tony’emu Hamiltonowi za tak wczesne wsparcie, którym ponownie obdarzył ją w jej marzeniach o pisaniu; swojej córce Skye za to, że dzięki niej łatwiej było równoważyć codzienne priorytety, a także Seanowi i Estelle za to, że stanowili centrum jej radosnych chwil z rodziną. Joy pragnie przekazać specjalne podziękowania wszystkim pracownikom Seilevel, z którymi współpracowała, aby pchnąć naprzód dziedzinę wymagań dotyczących oprogramowania. Szczególnie chce podziękować dwóm kolegom i przyjaciołom, Anthonemu Chenowi, którego wsparcie podczas pisania tej książki było wprost niewyobrażalne, oraz Robowi Sparksowi za jego nieustające zachęty do podejmowania tego typu przedsięwzięć. Na koniec Joy jest wdzięczna Karlowi za umożliwienie jej dołączenia do niego w charakterze współautorki, za uczenie jej czegoś nowego każdego dnia i czystą radość, jaką była współpraca z nim!

26

CZĘŚĆ I

Wymagania dotyczące oprogramowania. Co, dlaczego i kto?

Rozdział 1., „Najważniejsze wymaganie dotyczące oprogramowania”

29

Rozdział 2., „Wymagania z punktu widzenia użytkownika”

49

Rozdział 3., „Dobre praktyki w inżynierii wymagań”

67

Rozdział 4., „Analityk biznesowy”

85

CZĘŚĆ I  WYMAGANIA DOTYCZĄCE OPROGRAMOWANIA. CO, DLACZEGO I KTO?

28

ROZDZIAŁ 1

Najważniejsze wymaganie dotyczące oprogramowania

-Halo, Filip? Tu Maria z kadr. Mamy problem z systemem kadrowym, k Jedna z naszych pracownic zmieniła nazwisko na Iskierka Gwiezd żeby przyjął tę zmianę. Czy możesz nam pomóc? - Wyszła za faceta o nazwisku Gwiezdny?

�

nas napisałeś.

nz�e ��my skłonić systemu, '-.."""' •

�

� wiedziała Maria. - W tym problem. � Wygląda na to, że możemy zmienić nazwisko tylko wte ��toś zmienia swój stan cywilny. �u zmienić nazwisko. Nie przypominam -No tak, nawet nie pomyślałem, że ktoś może a � -Nie, nie wyszła za mąż; po prostu zmieniła nazwisko

a:

sobie, żebyś mówiła mi o takiej możliwości, kiedy r

aliśmy o systemie-powiedział Filip.

� ieniać swoje nazwiska, kiedy tylko zechcą -odpowiedziała Maria.-Musimy to wyp ��ać do piątku albo Iskierka nie dostanie wypłaty. -Założyłam, że wiesz, że ludzie mogą l

�0

Czy uda ci się do tego czasu naprawić błą -To nie błąd!-wycedził Fil p. Teraz jestem zajęty nowym system

�

Nfiwet nie wiedziałem, że potrzebujecie takiej możliwości. cowania wydajności. Prawdopodobnie poprawię to do końca

miesiąca, ale nie do piątku. Prz.1..._ o m . Następnym razem mówcie mi o tego typu rzeczach wcześniej

� co mam powie d�Tskierce?-zapytała Maria. -Jak nie dostanie wynagrodzenia, to się

i proszę, żebyście je zapisyw -A

zdenerwuje.

�

-Mario, przecież to nie moja wina-zaprotestował Filip. -Przede wszystkim, gdybyś mi powiedziała, że musisz mieć możliwość zmiany nazwiska w dowolnym momencie, cała ta sytuacja nie miałaby miejsca. Nie możesz mnie winić za to, że nie odczytałem twoich myśli. -To właśnie przez takie rzeczy nienawidzę komputerów. Zadzwoń do mnie, jak tylko to naprawisz, dobrze?-odpowiedziała ze złością wzburzona i zrezygnowana Maria.

Jeśli kiedykolwiek uczestniczyłeś w tego typu rozmowie jako klient, wiesz, jak bardzo frustrujące jest, gdy system nie pozwala Ci na wykonanie jakiegoś ważnego zadania. Nienawidzisz znajdować się na łasce programisty, który być może kiedyś weźmie się do wprowadzenia krytycznej dla Ciebie zmiany. Z drugiej strony programiści frustrują się, słysząc o oczekiwanej przez użytkownika funkcjonalności tuż po tym, jak system został zaimplementowany. Programista denerwuje się także wtedy, gdy jego bieżący projekt jest przerywany prośbą o zmodyfikowanie systemu, który w pierwszym rzędzie robi dokładnie to, co powinien robić.

29

CZĘŚĆ l

•

WYMAGANIA DOTYCZĄCE OPROGRAMOWANIA. CO, DLACZEGO l KTO?

Wiele problemów z oprogramowaniem powstaje w konsekwencji sposobów, w jakie obie strony dowiadują się o wymaganiach dotyczących produktu, dokumentują je, zgadzają się co do nich oraz je modyfikują. Tak samo jak to ma miejsce w przypadku Filipa i Marii, problematyczne kwestie najczęściej pojawiają się w wyniku nieformalnego zbierania informacji, przyjmowania domyślnych funkcjonalności, niewłaściwego rozumienia założeń, niedostatecznego specyfikowania wymagań i doraźnego wprowadzania zmian. Rozmaite badania wykazują, że błędy powstałe podczas czynności związanych z definiowaniem wymagań odpowiadają za 40 do 50% wszystkich usterek wykrywanych w oprogramowaniu (Davis, 2005). Niedostateczne informacje przekazywane przez użytkowników oraz braki w specyfikowaniu i zarządzaniu wymaganiami klienta w znacznym stopniu przyczyniają się do braku powodzenia projektów. Na przekór tym wszystkim przesłankom wiele organizacji nadal praktykuje nieefektywne metody zarządzania wymaganiami. W żadnym innym obszarze interesy wszystkich interesariuszy zaangażowanych w projekt nie krzyżują się w takim stopniu, jak to się dzieje podczas prac nad wymaganiami (więcej informacji " o interesariuszach znajdziesz w rozdziale 2., "Wymagania z punktu widzenia użytkownika ). Tymi interesariuszami mogą być klienci, użytkownicy, analitycy biznesowi, programiści i wielu innych. Krzyżujące się interesy, jeśli będą prawidłowo zarządzane, mogą prowadzić zachwytu klientów i spełnienia programistów. Jeżeli jednak zostaną potraktowane nieumiejętnie, ogą stać się źródłem . onieważ wymagania nieporozumień oraz tarć obniżających jakość produktu i jego wartość bizn stanowią podstawę aktywności związanych zarówno z tworzeniem o arp ania, jak i zarządzaniem · takich metod pracy projektem, wszyscy interesariusze powinni zobowiązać się do stoso jakości. z wymaganiami, o których wiadomo, że przynoszą produktY. naj

�

� �

$

� �i� �

��

Tworzenie wymagań oraz zarządzanie nimi jest jednak t . e ie ma tu szybkich dróg na skróty le organizacji zmaga się z takimi ani magicznych rozwiązań. Na plus można zaliczyć fa samymi problemami, że można szukać wspólnych tec re mają zastosowanie w wielu różnych sytuacjach. W książce tej omówiono dziesiątki tego t raktyk. Zostały one przedstawione w taki sposób, jakbyś budował całkowicie nowy system. ość z tych praktyk ma jednak zastosowanie również do ulepszania, zastępowania oraz towywania (tzw. reengineering) systemów " (patrz rozdział 21., "Projekty ulepszone i �ze ), a także jest przydatna podczas pracy nad związania bazujące na komercyjnych produktach prosto projektami, w których wykorzystano goto " z półki (patrz rozdział 22., "Projek y zu�ce na gotowych rozwiązaniach ). Zespoły programistów, sując procesy projektowania zwinnego, również powinny które tworzą produkty przyrosto rozumieć wymagania, które s z dniane w każdym przyroście (patrz rozdział 20., "Projekty zwinne").

�

�� � �b{

�� � �

�

i.� Rozdział ten pomożek_ �� Zrozumieć niek�kluczowych terminów używanych w związku z wymaganiami •

dotyczącymi oprogramowania.

•

Odróżniać wymagania produktu od wymagań projektu.

•

Odróżniać opracowywanie wymagań od zarządzania wymaganiami.

•

Zwracać uwagę na mogące się pojawić rozmaite problemy mające związek z wymaganiami.

" " " " Ważne. W książce tej używamy zamiennie terminów "system , "produkt , "aplikacja i "rozwiązanie w odniesieniu do wszystkich rodzajów oprogramowania oraz zawierających oprogramowanie obiektów, które tworzysz, bez względu na to, czy są one przeznaczone do użytku wewnętrznego w firmie, na sprzedaż, czy też są tworzone w ramach kontraktu.

30

ROZDZIAŁ 1.

•

NAJWAŻNIEJSZE WYMAGANIE DOTYCZĄCE OPROGRAMOWANIA

Zbadaj podejście do wymagań w swojej organizacji Aby szybko zorientować się w mających związek z wymaganiami praktykach, które są stosowane w Twojej organizacji, zastanów się, jak wiele z poniższych sytuacji można odnieść do najnowszego projektu, nad którym pracowałeś. Jeśli więcej niż trzy lub cztery sytuacje opisują Twoje doświadczenia, książka ta jest dla Ciebie: • •

•

• •

•

• •

•

•

•

Nigdy jasno nie zdefiniowano celów biznesowych, wizji ani zakresu projektu. Klienci byli zbyt zajęci, aby poświęcić swój czas na wspólną z analitykami lub programistami pracę nad wymaganiami. Twój zespół nie mógł bezpośrednio współpracować z przedstawicielem użytkowników, który wyjaśniałby ich potrzeby. Klienci twierdzili, że wszystkie wymagania są krytyczne, więc nie nadali im priorytetów. Podczas pisania kodu programiści napotkali niejednoznaczności i mieli do czynienia z brakującymi informacjami, w związku z czym musieli zgadywać.

�a wyglądzie

Komunikacja między programistami a interesariuszami była skupia i cechach interfejsu użytko�nika, a nie na tym, co użytkownicy p za pomocą oprogramowama.

�")1ą osiągnąć

' -�

Twoi klienci nigdy nie zatwierdzili wymagań.

!woi kli�n�i zatwierdzili wymagania w wydanej wer

_ Je zm1emah.

�• � R a

racji, po czym bez przerwy

�� ian w wymaganiach, a terminów nie �ch zasobów ani nie usunięto żadnych

Zakres projektu rozrastał się w miarę akceptow� udało się dotrzymać, gdyż nie przydzielono d� funkcjonalności. \....}

��ikt nie znał statusu określonego wniosku y � sć i programiści ją zrealizowali, ale nikt nigdy z niej nie skorzystał. A...'\._ • roj�ałożenia Pod koniec prac nad p�� jego specyfikacji zostały dotrzymane, ale nie Żąda�e zmiany wymagań zostały z o zm1anę. Klienci poprosili o pewną funkcjo ...., _

•

osiągnięto celów klien

.L

Definicja wy

i biznesowych.

�a� dotyczących oprogramowama

Kiedy grupa osób przystępuje do omawiania wymagań, często zaczyna od problemów z terminologią. Różni obserwatorawie mogą opisać to samo stwierdzenie jako wymaganie użytkownika, wymaganie oprogramowania, wymaganie biznesowe, wymaganie funkcjonalne, wymaganie systemowe, wymaganie produktu, wymaganie projektu, opowieść użytkownika, funkcjonalność albo ograniczenie. Pojęcia używane przez poszczególne osoby na określenie gotowych wymagań również mogą się różnić. Definicja wymagania podana przez użytkownika może brzmieć dla programisty jak wysokopoziomowa koncepcja produktu. Z kolei określenie wymagania przedstawione przez programistę może przywodzić na myśl użytkownikowi szczegółowy projekt interfejsu użytkownika. Taka różnorodność pojęć prowadzi do nieporozumień i frustracji.

31

CZĘŚĆ l

N

•

WYMAGANIA DOTYCZĄCE OPROGRAMOWANIA. CO, DLACZEGO l KTO?

iektóre interpretacje słowa wymaganie

"

"

Wiele dziesięcioleci po wynalezieniu programowania komputerów osoby zajmujące się oprogramowaniem " od strony praktycznej nadal prowadzą ożywione spory dotyczące tego, czym jest "wymaganie . Zamiast dołączać do tych debat, postanowiliśmy w tej książce przedstawić kilka definicji, które naszym zdaniem będą przydatne. Konsultant Brian Lawrence sugeruje, że wymaganie jest " wszystkim, co skłania do podejmowania " wyborów w projekcie (Lawrence, 1997). Jest to całkiem niezła potoczna definicja, ponieważ pasuje do niej wiele różnych rodzajów informacji. Wszak cały sens opracowywania wymagań sprowadza się do podejmowania odpowiednich decyzji dotyczących projektu, które w rezultacie doprowadzą do zaspokojenia potrzeb klienta. Inna definicja mówi, że wymaganie to właściwość, jaką powinien charakteryzować się produkt, aby przedstawiał wartość dla interesariusza-także niezła, chociaż niezbyt precyzyjna. Nasza ulubiona definicja pochodzi jednak od lana Sommerville'a i Pete'a Sawyera ( 1997): Wymagania stanowią specyfikację tego, co powinno zostać zaimplementowane.

�wości � M " Powyższa definicja uwzględnia różne rodzaje informacji, które w iee ��ane są "wymaganiami . Wymagania obejmują zarówno sposoby, w jakie użytkownicy postr�� zewnętrzne zachowania systemu, jak i pojmowanie przez programistów niektórych jego �rj trznych charakterystyk. Należą do nich zachowania systemu w pewnych specyficznych sytu �;Uaz właściwości sprawiające, że system nadaje się do użycia przez jego przewidywany� �ników, a korzystanie z niego być Opisują, jak powinien zachowywać się system, albo określają jego wł

lub atrybuty. Mogą nakładać ograniczenia na proces tworzenia sys

e

może nawet sprawia im radość.

'V

�

��

�------------------------------------��

----------------------------------�

Pułapka. Nie zakładaj, że wszyscy interesarius ją ten sam pogląd na to, czym są wymagania. Formułuj wyraźne definicje, abyście wsz wili o tym samym.

� � i_� ; � � �

�

"· Czysto słownikowe "wymag " Ludzie od oprogramowania n słowa "wymaganie w takim samym sensie, jaki niesie ze sobą jego definicja słownikowa maganego lub obowiązkowego, potrzeba albo konieczność. dają w wątpliwość potrzebę priorytetyzowania wymagań, ponieważ Niektóre osoby czasami wymagania o niskim cie mogą nigdy nie zostać zaimplementowane. Twierdzą one, że jeśli coś tak naprawdę nie jest potrzebne, nie stanowi wymagania. Być może, ale jak w takim razie nazwać taką informację? Czy jeśli przeniesiesz wymaganie z realizowanego obecnie projektu do edycji przewidzianej do wydania w bliżej nieokreślonej przyszłości, przestanie ono być wymaganiem? Oczywiście, że nie. Wymagania dotyczące oprogramowania zawierają wymiar czasowy. Mogą one dotyczyć teraźniejszości, gdy opisują aktualne możliwości systemu. Mogą też odnosić się do przyszłości najbliższej (wysoki priorytet), dalszej (średni priorytet) lub hipotetycznej (niski priorytet). Mogą nawet odwoływać się do przeszłości, gdy opisują potrzeby, które kiedyś zostały wyspecyfikowane, a następnie usunięte. Nie trać czasu na spory dotyczące tego, czy coś jest, czy nie jest wymaganiem, nawet jeśli wiesz, że z jakiegoś ważnego biznesowego powodu możesz nigdy tego nie zaimplementować. To jest wymaganie.

32

ROZDZIAŁ 1.

•

NAJWAŻNIEJSZE WYMAGANIE DOTYCZĄCE OPROGRAMOWANIA

Poziomy i rodzaje wymagań Ponieważ istnieje tyle różnych rodzajów informacji związanych z wymaganiami, będziemy potrzebować

spójnego zbioru modyfikatorów precyzujących przeładowany termin "wymaganie". W tym podrozdziale przedstawimy definicje, z których będziemy korzystać, posługując się niektórymi często spotykanymi w dziedzinie wymagań terminami (patrz tabela

1.1).

TABELA 1.1. Niektóre rodzaje informacji mających związek z

Nazwa

Definicja Rodzaj wymagania pozafunkcjonalnego, które opisuje usługi lub

atrybut jakościowy funkcjonalność

wymaganiami

wydajnościowe charakterystyki produktu. ------+-Jedna lub wiele logicznie powiązanych ze sobą możliwości systemu, które mają znaczenie dla użytkownika i są opisane w zestawieniu wymagań funkcjonalnych.

reguła biznesowa

� wyboru programista �tu.

�

Limit narzucony na możliwości, jakie m

ograniczenie

w kontekście projektu oraz konstrukcj ------+ - gullj Polityka, wytyczne, standardy

��

-

definiujące albo

�b"\nesu. Sama w sobie nie jest i źr� u typów wymagań dotyczących �V

ograniczające niektóre z aspekto

�

wymaganiem, a e stano oprogramowama.

wymaganie funkcjonalne

która tworzy pro --+- Opis zachow system

wymaganie pozafunkcjonalne

Opis zgod

V

� �

ści lub charakterystyki, z którymi system musi być

-

dź ograniczenie, którego system musi przestrzegać.

s