Bartosz Chrabski Specjalista IT pracujący w grupie oprogramowania IBM Polska. Zajmuje się projektowaniem i wdrażaniem systemówzarządzania pracą zespołów programistów, testerów analityków oraz technincznym wspar-ciem sprzedaży rozwiązań z rodziny IBM Rational.Autor kilkunastu publikacji z obszaru inżynierii oprogramowania, zarządzania projektami oraz prelegent licznych konferencji międzynarodowych.

Karolina Zmitrowicz W branży IT niemal 10 lat. Posiada doświadczenie w zakresie analizy biznesowej i inży-nierii wymagań, zarządzania jakością i zarządzania projektami: pracowała dla wiodących organizacji finansowych w Republice Południowej Afryki, Holandii, Austrii, Słowacji, Włoszech i w Polsce. Podczas swojej kariery pełniła różne role, od testera, przez technical writera, po kierownika projektów R&D, co umożliwiło jej poznanie wielu aspektów realizacji projektów IT i nauczyło postrzegania podejmowanych tematów z różnych punktów widzenia. Praca w międzynarodowych, wielokulturowych zespołach projektowych wykształciła w Karolinie nie tylko umiejętności efektywnego planowania i koordynacji złożonych działań, ale i dosko-nałe umiejętności interpersonalne.W pracy analityka wykorzystuje doświadczenie zdobyte podczas kilku lat pracy w obszarze zapewnienia i kontroli jakości, by stale ulepszać jakość produktów swoich prac, jak i samego procesu ich powstawania.W latach 2010-2013 Karolina zaangażowała się we wsparcie i doskonalenie systemu certy-fikacji inżynierów wymagań REQB oraz była główną autorką programu IQBBA. Była także założycielką i redaktorem naczelnym magazynu c0re - kwartalnika dla testerów oprogramo-wania. Obecnie kontynuuje pracę redaktorską w Quale, kwartalniku traktującym o szeroko pojętej jakości w IT. W dalszym ciągu jest aktywnym członkiem kilku międzynarodowych organizacji mających na celu zwiększanie wiedzy i dojrzałości zawodowej testerów oprogra-mowania oraz inżynierów wymagań, wspiera również najważniejsze wydarzenia związane z jakością oprogramowania w Polsce i za granicą.Obecnie pracuje jako niezależny konsultant IT i trener w obszarze inżynierii wymagań i zarządzania jakością pomagając klientom usprawniać procesy inżynierii oprogramowania a tym samym osiągać lepsze wyniki biznesowe. Uważa, że podstawą do osiągnięcia jakości są efektywne procesy i odpowiednie podejście ludzi, a nie tymczasowe rozwiązania i modne trendy.Jest autorką szeregu specjalistycznych publikacji oraz książki obejmującej program certyfi-kacji w obszarze inżynierii wymagań, która wkrótce ukaże się nakładem wydawnictwa PWN.

SPIS TREŚCI

Od Autorów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1. Wprowadzenie do inżynierii wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.1. Wyzwania związane z projektami IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.1. 1.1.1. Cele i wizja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.1. 1.1.2. Złe planowanie projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.1. 1.1.3. Słaba komunikacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1. 1.1.4. Złe zarządzanie oczekiwaniami interesariuszy . . . . . . . . . . . . . . . . . . . . . . 204.1. 1.1.5. Problemy z wymaganiami i ich zakresem . . . . . . . . . . . . . . . . . . . . . . . . 214.1. 1.1.6. Brak umiejętności miękkich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.1. 1.1.7. Nierealistyczne oczekiwania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.1. 1.1.8. Brak zasobów ludzkich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.1. 1.1.9. Brak odpowiedniego wsparcia narzędziowego i metodycznego . . . . . . . . . . . . . 261.2. Podstawowe definicje oraz klasyfikacje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.1. 1.2.1. Wymagania biznesowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1. 1.2.2. Wymagania interesariuszy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1. 1.2.3. Wymagania rozwiązania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.1. 1.2.4. Wymagania przejścia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.3. Atrybuty wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311.4. Kryteria jakości wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341.5. Wymagania w procesie zapewnienia jakości oprogramowania . . . . . . . . . . . . . . . . . 361.6. Inżynieria wymagań oraz jej znaczenie w projekcie . . . . . . . . . . . . . . . . . . . . . . 371.7. Podstawowe role w procesie inżynierii wymagań . . . . . . . . . . . . . . . . . . . . . . . . 391.8. Koncepcja interesariuszy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401.9. Standardy oraz normy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.1. 1.9.1. ISO 9000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1. 1.9.2. ISO/IEC 25000 – Software Engineering – Software product Quality Requirements

and Evaluation (SQuaRE) – Guide to SQuaRE . . . . . . . . . . . . . . . . . . . . . 434.1. 1.9.3. ISO 9241 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1. 1.9.4. ISO 31000: Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.1. v1.9.5. IEEE 610:1990: Standard Glossary of Software Engineering Terminology . . . . . . . 444.1. 1.9.6. IEEE 828-2012: Standard for Configuration Management in Systems and Software

Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.1. 1.9.7. IEEE 830-1998: Recommended Practice for Software Requirements Specifications . . . 444.1. 1.9.8. IEEE 1233-1996: Guide for Developing of System Requirements Specifications . . . . 454.1. 1.9.9. IEEE 1362-1998: Guide for Information Technology – System Definition – Concept

of Operations (ConOps) Document . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.1. 1.9.10. IEEE 29148-2011 – Systems and software engineering – Life cycle processes –

Requirements engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.1. 1.9.11. IEEE 1028:2008 Standard for Software Reviews and Audits . . . . . . . . . . . . . . 45

6 SPIS TREŚCI

4.1. 1.9.12. SWEBOK: The Guide to the Software Engineering Body of Knowledge (ISO Technical Report 19759) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1. 1.9.13. CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.1. 1.9.14. BABOK – A Guide to the Business Analysis Body of Knowledge . . . . . . . . . . . 461.10. Słowniki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2. Proces inżynierii wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.1. Definicja procesu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.2. Inżynieria wymagań a analiza biznesowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562.3. Zasady tworzenia udanych wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.1. 2.3.1. Zrozum krytyczne cele najwyższego poziomu . . . . . . . . . . . . . . . . . . . . . . 594.1. 2.3.2. Koncentruj się na dostarczeniu wartości . . . . . . . . . . . . . . . . . . . . . . . . 604.1. 2.3.3. Zdefiniuj wymaganie jako „stan końcowy o wartości dla interesariusza” . . . . . . . . 604.1. 2.3.4. Wyrażaj wymagania ilościowo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.1. 2.3.5. Nie mieszaj środków z celami . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.1. 2.3.6. Skup się na pożądanej jakości systemu, nie tylko na jego funkcjonalności . . . . . . . . 654.1. 2.3.7. Zapewnij „bogatą specyfikację” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.1. 2.3.8. Wykonuj kontrolę jakości specyfikacji . . . . . . . . . . . . . . . . . . . . . . . . . . 684.1. 2.3.9. Uznaj, że wymagania się zmieniają . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3. Inżynieria wymagań a inne procesy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.1. Zarządzanie projektem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.2. Zarządzanie ryzykiem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773.3. Testowanie i zapewnienie jakości . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833.4. Wpływ wymagań na inne artefakty projektu . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4. Inżynieria wymagań w procesach tworzenia oprogramowania . . . . . . . . . . . 89

4.1. Model V jako przykład kaskadowego wytwarzania systemów . . . . . . . . . . . . . . . . . . 914.2. IBM Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944.1. 4.2.1. Zarządzania wymaganiami w IBM Rational Unified Process . . . . . . . . . . . . . . . 964.1. 4.2.2. Przepływ prac dla wymagań w IBM Rational Unified Process . . . . . . . . . . . . . . 974.1. 4.2.3. Role i artefakty w IBM Rational Unified Process . . . . . . . . . . . . . . . . . . . . . 994.3. Zwinne metodyki w zarządzaniu wymaganiami . . . . . . . . . . . . . . . . . . . . . . . . 1004.4. Programowanie ekstremalne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024.5. Scrum (według Scrum.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074.1. 4.5.1. Rejestr produktowy, czyli metoda na zorganizowanie wymagań . . . . . . . . . . . . . 1114.1. 4.5.2. Wyzwania związane z migracją do Scrum . . . . . . . . . . . . . . . . . . . . . . . . 1144.6. Disciplined Agile Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1154.7. Przypadek biznesowy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1164.1. 4.7.1. Informacja o firmie i sytuacja rynkowa . . . . . . . . . . . . . . . . . . . . . . . . . 1164.1. 4.7.2. Potrzeba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1164.1. 4.7.3. Rozwiązanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1164.1. 4.7.4. Zyski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

5. Identyfikacja wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

5.1. Źródła wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1225.2. Wizja oraz cel projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1225.3. Identyfikacja interesariuszy projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1285.4. Techniki identyfikacji wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304.1. 5.4.1. Warsztat wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314.1. 5.4.2. Wywiad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

7SPIS TREŚCI

4.1. 5.4.3. Ankieta – kwestionariusz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384.1. 5.4.4. Samodzielna rejestracja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424.1. 5.4.5. Reprezentant klienta po stronie dostawcy . . . . . . . . . . . . . . . . . . . . . . . 1444.1. 5.4.6. Identyfikacja na podstawie istniejących dokumentów . . . . . . . . . . . . . . . . . 1474.1. 5.4.7. Ponowne użycie specyfikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1504.1. 5.4.8. Obserwacja w terenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534.1. 5.4.9. Mentorowanie/praktykowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1564.1. 5.4.10. Burza mózgów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1584.1. 5.4.11. Prototypowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1634.1. 5.4.12. Przypadki użycia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1664.1. 5.4.13. Scenorys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715.5. Wymagania funkcjonalne i niefunkcjonalne . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

6. Analiza wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

6.1. Analiza problemu biznesowego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1866.2. Oganizacja wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1896.3. Powiązania i zależności między wymaganiami . . . . . . . . . . . . . . . . . . . . . . . . . 1906.4. Usuwanie konfliktów i duplikatów wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . 1946.5. Kontrola jakości . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1986.6. Szacowanie wysiłku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1984.1. 6.6.1. Techniki bazujące na algorytmach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2004.1. 6.6.2. Techniki bazujące na przybliżeniach . . . . . . . . . . . . . . . . . . . . . . . . . . . 2076.7. Priorytetyzacja wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2106.8. Modelowanie rozwiązania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2134.1. 6.8.1. Model dziedziny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2144.1. 6.8.2. Diagram przepływu danych (ang. Data Flow Diagram) . . . . . . . . . . . . . . . . . 2164.1. 6.8.3. Diagram związków encji (ang. Entity Relationship Diagram) . . . . . . . . . . . . . . 2164.1. 6.8.4. Modelowanie interfejsu użytkownika . . . . . . . . . . . . . . . . . . . . . . . . . . 2184.1. 6.8.5. Unified Modeling Language (UML) . . . . . . . . . . . . . . . . . . . . . . . . . . . 2194.1. 6.8.6. System Modeling Lanuage (SysML) . . . . . . . . . . . . . . . . . . . . . . . . . . . 2284.1. 6.8.7. Inne notacje do modelowania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2316.9. Akceptacja wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

7. Specyfikacja wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

7.1. Pojęcie specyfikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2417.2. Rodzaje specyfikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2414.1. 7.2.1. Specyfikacja wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2424.1. 7.2.2. Specyfikacja rozwiązania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2434.1. 7.2.3. Specyfikacja techniczna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2457.3. Szablony dla specyfikacji wymagań (na podstawie IEEE 830) . . . . . . . . . . . . . . . . . . 2464.1. 7.3.1. IEEE 830 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2464.1. 7.3.2. Wzorzec Volere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2514.1. 7.3.3. Historyjki użytkownika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2524.1. 7.3.4. Przypadki użycia jako sposób na wymagania funkcjonalne . . . . . . . . . . . . . . . 2527.4. Jakość specyfikacji wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Rozdział 8. Zarządzanie wymaganiami . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

8.1. Śledzenie wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2618.2. Zarządzanie Konfiguracją . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2688.3. Zarządzanie Zmianą . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2718.4. Zarządzanie wymaganiami dotyczącymi projektu oraz systemu . . . . . . . . . . . . . . . . . 275 8.5. Plan Zarządzania Wymaganiami . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

8 SPIS TREŚCI

8.6. Przypadek biznesowy – wdrożenie procesu zarządzania wymaganiami . . . . . . . . . . . . . 2784.1. 8.6.1. Informacja o firmie i sytuacja rynkowa . . . . . . . . . . . . . . . . . . . . . . . . . 2784.1. 8.6.2. Potrzeba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2784.1. 8.6.3. Rozwiązanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2794.1. 8.6.4. Zyski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

9. Wymagania a zarządzanie jakością . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

9.1. Planowanie jakości . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2899.2. Kontrola jakości . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2954.1. 9.2.1. Przeglądy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2964.1. 9.2.2. Inspekcje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3044.1. 9.2.3. Listy kontrolne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3079.3. Miary jakości wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3099.4. Doskonalenie procesu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

10. Narzędzia wspierające proces inżynierii wymagań . . . . . . . . . . . . . . . . . . . 315

10.1. Narzędzia w zarządzaniu wymaganiami . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3174.1. 10.1.1. IBM Rational Requirements Composer . . . . . . . . . . . . . . . . . . . . . . . . 3174.1. 10.1.2. Borland Caliber RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3194.1. 10.1.3. Serene Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3204.1. 10.1.4. Rational DOORS (Dynamic Object Oriented Requirements System) . . . . . . . . . 3214.1. 10.1.5. Blueprint Requirements Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3224.1. 10.1.6. Open Source Requirements Management Tool/aNimble Platform . . . . . . . . . . . 3234.1. 10.1.7. Cechy dobrego narzędzia do zarządzania wymaganiami . . . . . . . . . . . . . . . 3244.1. 10.1.8. Wdrożenie narzędzia do zarządzania wymaganiami . . . . . . . . . . . . . . . . . . 32510.2. Czynniki mające znaczenie przy doborze odpowiednich narzędzi . . . . . . . . . . . . . . . 32810.3. Narzędzia w obszarze modelowaniu wymagań . . . . . . . . . . . . . . . . . . . . . . . . 3294.1. 10.3.1. Sparx Enterprise Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3294.1. 10.3.2. IBM Rational Software Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . 3304.1. 10.3.3. StarUML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33110.4. Narzędzia w obszarze modelowania procesów biznesowych . . . . . . . . . . . . . . . . . . 3324.1. 10.4.1. Boc Group Adonis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3324.1. 10.4.2. iGrafx Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3334.1. 10.4.3. BizAgi Process Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3344.1. 10.4.4. Rational System Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33510.5. Narzędzia wsparcia dla zarządzania konfiguracją . . . . . . . . . . . . . . . . . . . . . . . 3364.1. 10.5.1. GIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3364.1. 10.5.2. Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3374.1. 10.5.3. IBM ClearCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33910.6. Narzędzia wsparcia dla zarządzania zmianami . . . . . . . . . . . . . . . . . . . . . . . . 3394.1. 10.6.1. Atlassian Jira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3394.1. 10.6.2. IBM Rational Team Concert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34010.7. Zarządzanie procesem testowania oprogramowania . . . . . . . . . . . . . . . . . . . . . . 3424.1. 10.7.1. HP Quality Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3424.1. 10.7.2. IBM Rational Quality Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3434.1. 10.7.3. Testia Tarantula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3444.1. 10.7.4. Requirements Testing Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3454.1. 10.7.5. TestLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34610.8. Ryzyko związane ze złym zakupem narzędzia . . . . . . . . . . . . . . . . . . . . . . . . . 347

Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

9SPIS TREŚCI

Przypadki biznesowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

Projekt 1 - Wdrażanie procesu inżynierii wymagań . . . . . . . . . . . . . . . . . . . . . . . . . 3554.1.Informacja o firmie i sytuacja rynkowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3554.1.Potrzeba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3554.1.Rozwiązanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3564.1.Zyski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361Projekt 2 – Integracja narzędzi w procesie wytwarzania . . . . . . . . . . . . . . . . . . . . . . . 3624.1.Informacja o firmie i sytuacja rynkowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3624.1.Potrzeba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3624.1.Rozwiązanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3624.1.Etap 1 – Integracja wymagań z procesem zarządzania testami . . . . . . . . . . . . . . . . . 3644.1.Etap 2 – Integracja wymagań z zarządzaniem konfiguracją . . . . . . . . . . . . . . . . . . . 3654.1.Etap 3 – Integracja wymagań z zarządzaniem zmianami . . . . . . . . . . . . . . . . . . . . . 3664.1.Zyski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368Projekt 3 – Kontrola jakości wymagań na wczesnych etapach projektu . . . . . . . . . . . . . . . 3704.1.Informacja o firmie i sytuacja rynkowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3704.1.Potrzeba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3704.1.Skutek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3714.1.Przyczyna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3714.1.Rozwiązanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371Projekt 4 – Zarządzanie wymaganiami przy użyciu historyjek użytkownika . . . . . . . . . . . . . 3724.1.Informacja o firmie i sytuacja rynkowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3724.1.Potrzeba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3724.1.Rozwiązanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3724.1.Zyski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

Spis rysunków . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

Spis tabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

Indeks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

W rozdziale wprowadzającym przedstawimy podstawowe informacje dotyczące wy-magań i różnych związanych z nimi aspektów. Oprócz zestawu pojęć i zagadnienień teoretycznych niezbędnych do zrozumienia istoty dziedziny inżynierii wymagań, opiszemy również tematy poboczne, umożliwiające zrozumienie znaczenia tej dzie-dziny dla sukcesu przedsięwzięcia.

Zacznijmy od problemów, których – przynajmniej częściowe – rozwiązanie zależy od jakości procesów mniej lub bardziej związanych z wymaganiami.

1.1. Wyzwania związane z projektami ITProblemy w realizacji projektów informatycznych są nieustannie wdzięcznym te-matem do dyskusji – omawia się je na konferencjach, szkoleniach, w prasie i innych publikacjach. Szczególnie „medialne” i interesujące są spektakularne porażki, odbi-jające się szerokim echem w środowisku IT.

Ilu z nas, najczęściej po fakcie, zadaje sobie pytanie, dlaczego projekty informa-tyczne tak często się nie udają? Ilu z nas deklaruje, że „następnym razem będzie lepiej”.... a następny raz okazuje się jeszcze gorszy...

W zasadzie wiadomo, co robimy nie tak. Badaniem przyczyn porażek projekto-wych zajmują się organizacje uznane na całym świecie (m.in. Standish Group i jej słynny już Chaos Report). Informują one, że głównymi powodami problemów są m.in. niekompletne wymagania, niedostateczne zaangażowanie użytkowników, brak zaso-bów i wsparcia kierownictwa, nierealistyczne oczekiwania, niedoszacowane estyma-cje oraz problemy z planowaniem. Czynniki te nie zmieniają się praktycznie od lat. Badania innych organizacji (w tym Gartnera) również wskazują część z tych czynni-ków jako wywierające największy negatywny wpływ na powodzenie projektów IT1.

Analizując statystyki i dostępną dokumentację, można wyciągnąć wniosek, że większość problemów występujących podczas realizacji projektów IT jest związana z samym zarządzaniem projektem. Czynniki technologiczne obciążone, zdawałoby się, najwyższym ryzykiem to zaledwie niewielki odsetek przyczyn niepowodzeń pro-jektów. Skąd taka rozbieżność? Dziedzina zarządzania projektem istnieje w IT od wielu lat – nie jest ani nowa, ani nieusystematyzowana. Istnieje wiele wytycznych, praktyk i standardów opisujących reguły dobrego zarządzania projektem. Dlaczego więc od lat tak wiele problemów występujących podczas realizacji projektów IT wy-nika z faktu zarządzania nimi? Czyżby odpowiedź brzmiała: „ponieważ nie uczymy się na błędach”? Może przyczyny problemów są wciąż te same, ponieważ nigdy po-ważnie ich nie zbadaliśmy. Często widzimy tylko skutki i w panice próbujemy gasić pożar, kiedy już wybuchnie, nie zastanawiając się, dlaczego pożary występują tak często i co je powoduje. Może lepiej nie budować kolejnego domu ze słomy i papie-ru, zamiast dziwić się, że znowu nie wytrzymał najmniejszej próby ognia?

Podsumowując informacje z różnych źródeł i statystyk, można wskazać kilkana-ście notorycznie powtarzających się czynników ryzyka.

1 http://www.gartner.com/technology/research.jsp.

16 WPROWADZENIE DO INŻYNIERII WYMAGAŃ

1.1.1. Cele i wizja

Projektów nie realizujemy po to, żeby wyprodukować dany produkt. Z biznesowego punktu widzenia wyprodukowanie produktu nie jest celem samym w sobie realizacji projektu, projekty mają dostarczyć klientowi konkretną wartość. Produkt jest jedy-nie środkiem do osiągnięcia celu, jakim jest wartość. Niestety w praktyce znaczna liczba projektów charakteryzuje się kompletnym brakiem przygotowania biznesowe-go – projekty inicjowane są bez uprzedniego zdefiniowania i analizy potrzeb, celów biznesowych oraz ryzyk. W wielu przypadkach brakuje planowania strategicznego, które pozwoliłoby organizacji określić cele i zaplanować ich realizację dzięki odpo-wiednim, często współzależnym projektom. Skutek? Klient nie wie, co chce osiągnąć za pomocą danego rozwiązania i jakim celom biznesowym ma ono służyć. Bardzo często projekty są realizowane po to, by „wytworzyć jakiś system”, choć celem pro-jektu informatycznego nie jest sam system, ale korzyści, jakie ma dostarczać, i cele biznesowe, które ma realizować. Te cele i korzyści powinny stanowić podstawę do zainicjowania projektu, ponieważ to właśnie one determinują przyczynę, dla której klient podejmuje się wytworzenia produktu informatycznego. Klient zamawia system po to, by zrealizować konkretne cele biznesowe – optymalizację jakiegoś procesu biznesowego, zwiększenie sprzedaży, czy redukcję pracowników administracyjnych. Te cele – niestety – bardzo często nie zostają zdefiniowane. Zarówno klient, jak i do-stawca, skupia się zatem na funkcjach i usługach produktu, nie zastanawiając się, czemu mają one służyć. W efekcie klient dostaje produkt o określonych funkcjach, dostawca otrzymuje wynagrodzenie za swe usługi, ale produkt nie realizuje żadnych istotnych celów biznesowych lub realizuje je w stopniu dla klienta niewystarczają-cym. Czy taki projekt – dostarczony w czasie, z funkcjami, jakie zostały zamówione, jedynie nie realizujący celów biznesowych – można określić jako udany?

Jednym z podstawowych problemów z projektami IT jest brak zrozumienia rze-czywistych potrzeb biznesowych organizacji zamawiającego. Podstawowe pytanie, jakie powinniśmy sobie zadać przy organizacji jakiegokolwiek projektu, brzmi: „co chcemy osiągnąć”, nie „jaki produkt wytworzyć”. Produkt, nawet zgodny z udoku-mentowanymi wymaganiami, niekoniecznie spełni potrzeby klienta. Wspomniane wyżej „co chcemy osiągnąć” wyjaśnia, dlaczego będziemy realizować dany projekt. To „dlaczego” jest wizją projektu, którą powinniśmy udokumentować w postaci określonego dokumentu (niektóre metodyki nazywają go po prostu dokumentem wizji), aby służył jako wysokopoziomowa deklaracja celu projektu.

Nie wystarczy posiadać dokument wizji i listę celów biznesowych. Dokumenty te powinny być używane podczas realizacji projektu i służyć jako wskazówki przy podejmowaniu dalszych decyzji, chociażby tych związanych z zakresem projektu – prace niesłużące spełnieniu wizji i celów projektowych można potencjalnie uważać za zbędne, jako że nie dostarczają żadnej wartości.

Dobrą praktyką realizacji projektów jest dopasowanie celów projektu do ogól-nych celów biznesowych i strategii organizacji.

1.1.2. Złe planowanie projektu

Kolejnym grzechem jest całkowite zaniechanie planowania. Niektóre, najczęściej niedojrzałe organizacje w usilnym dążeniu do jak najszybszego wytworzenia pro-

171.1. Wyzwania związane z projektami IT

duktu (bo przecież rynek czeka...) zapominają, że podstawą realizacji jakiegokolwiek projektu jest planowanie. Jeśli nie opracowano planu, nie można go później reali-zować (co ukierunkowuje prace) ani monitorować. Oznacza to brak możliwości wy-krycia potencjalnych problemów czy ryzyk na wczesnym etapie i odpowiedniego zareagowania, zanim problemy skumulują się do tego stopnia, że jedyną możliwą reakcją będzie już tylko gaszenie pożaru.

Następny błąd popełniany jest na tyle często, że powinien zdobyć miejsce na podium w konkursie na klasyczny błąd planowania. Niedoszacowanie złożoności – zakładamy, że prace związane z realizacją produktu albo i sam produkt są prost-sze, niż okazuje się w rzeczywistości. Skąd to wynika? Zasadniczo można wyróżnić trzy przyczyny: Brak wiedzy na temat realnej złożoności problemu. W przypadku projektów czy

produktów innowacyjnych lub takich, w których obszarze zespół projektowy nie ma doświadczenia, nie zawsze wiadomo, jak szacować złożoność. Przyjmuje się pewne założenia, bardzo często niedoszacowując. Kłania się stara zasada szaco-wania projektów: wynik szacowania należy pomnożyć przez 2 i dodać 50% bu-foru na możliwe problemy. Niestety, w obecnych warunkach rynkowych zasada ta jest często niemożliwa do zastosowania, ponieważ skutecznie zmniejszyłaby szanse producenta na realizację danego projektu.

Brak konsultacji ze specjalistami. Niektórzy kierownicy projektu zbyt mocno wierzą we własne siły i próbują szacować projekt samodzielnie, bez konsulta-cji z zespołem projektowym czy ekspertami dziedzinowymi. Skutki są łatwe do przewidzenia. Problem ten może wynikać z błędnego postrzegania kierownika projektu jako jedynej osoby odpowiedzialnej za jego planowanie i szacowanie, choć zgodnie ze sztuką jest to zadaniem zespołu – gdyż któż lepiej zaplanuje i wyceni np. testowanie w projekcie niż osoba odpowiedzialna za planowanie i realizację testów, czyli lider testów?

Świadome niedoszacowanie w celu obniżenia łącznego kosztu projektu. Praktyka ta jest spotykana dość często, zwłaszcza w sektorze administracji publicznej, gdzie kryterium wygrania przetargu na projekt jest cena. Cóż więc ma zrobić producent, któremu zależy na wygranej? Obniżyć koszty, najczęściej przyjmując założenia, że pewne elementy da się zrobić szybciej i łatwiej, niż wskazują na to wyliczenia. O efektach takich założeń możemy często poczytać w prasie.Kolejnym bardzo poważnym błędem popełnianym podczas planowania projektu

jest brak zarządzania oczekiwaniami klientów czy ogólnie interesariuszy. W prakty-ce przejawia się on brakiem zaplanowanych spotkań z interesariuszami, na których można omówić i zweryfikować wyniki już wykonanych prac, czyli upewnić się, czy podążamy w dobrym kierunku. Brak zaplanowania zaangażowania klienta i innych istotnych interesariuszy może skutkować problemami z wymaganiami, które oka-zują się być niekompletne czy nieprawidłowe (nie odzwierciedlają realnych potrzeb klientów), ponieważ zabrakło walidacji i komunikacji na bieżąco.

Jeśli już mowa o komunikacji – ten aspekt planowania również przysparza wie-lu kłopotów. Praktyka wskazuje, że w wielu projektach zaniedbuje się opracowa-nie planu komunikacji definiującego podstawowe zasady dzielenia się informacją w projekcie oraz określającego role i odpowiedzialności poszczególnych członków

18 WPROWADZENIE DO INŻYNIERII WYMAGAŃ

zespołu. Brak planu komunikacji i określenia odpowiedzialności skutkuje najczęś-ciej chaosem informacyjnym i problemami w realizacji podstawowych zadań. Rozważmy prosty przykład – co zrobi tester, jeśli nie wie, komu zgłosić błąd zauwa-żony w specyfikacji wymagań podczas przygotowywania przypadków testowych? 1. Poinformuje kierownika projektu, od którego dobrej woli i kompetencji będzie zależało przekazanie problemu do rozwiązania odpowiednim osobom. 2. Skonsultuje się z kolegą i wspólnie ustalą własną interpretację wymagań. 3. Zignoruje problem, na przykład wychodząc z założenia, że zgłoszenie błędu w wymaganiu i jego konse-kwencje będą go kosztować dodatkową pracę.

Złe zaplanowanie projektu często skutkuje nadmiernym, stałym lub czasowym, obciążeniem niektórych jego wykonawców, podczas gdy inne osoby (czy zespoły) są w tym samym czasie niemalże wolne. Przykładowo, projekty są często dzielone na etapy. Na etapie analizy i dokumentacji wymagań obciążeni są głównie analitycy (a nawet przeciążeni, ponieważ zwykle na analizę zakłada się zbyt mało czasu w stosunku do realnych potrzeb). W tym czasie testerzy i programiści są bezczynni albo pracują przy innym projekcie. Opcja druga z pozoru wydaje się całkiem rozsąd-na, jednakże w wyniku jej zastosowania po zakończeniu prac analitycznych testerzy i programiści rozpoczynają pracę nad projektem bez przygotowania i znajomości kontekstu. Powstają opóźnienia spowodowane faktem, że muszą się oni zapoznać z założeniami projektu i specyfikacjami produktu, zrozumieć, co mają do zrobienia, po czym dopiero zacząć pracę.

Jak więc rozwiązać ten problem? Bardzo prosto – programiści i testerzy są częś-cią zespołu projektowego, czyż nie? Celem zespołu jest dostarczenie produktu od-powiedniej jakości przy określonych założeniach (choćby czasowych). Członkowie zespołu powinni więc angażować się nie tylko w swoje zadania, jak na przykład samo kodowanie, lecz także wnosić wkład do czynności powiązanych z zadania-mi, które będą realizować. Bardzo dobrym sposobem wykorzystania potencjału programistów i testerów jest zaangażowanie ich do przeglądów wymagań i specy-fikacji produktu. Testerzy znakomicie zweryfikują, czy wymagania i projekty będą testowalne; programiści sprawdzą możliwości implementacji i doradzą optymalne sposoby spełnienia wymagań przy zastosowaniu dostępnych możliwości technicz-nych. Warto również dodać, że wiele problemów związanych z planowaniem wy-nika z przyczyn pośrednich. Przykładowo, źle wdrożony proces inżynierii wymagań może skutkować zaniedbaniem ustalenia priorytetów wymagań, co w konsekwencji może sprawić, że zespół skoncentruje się na wymaganiach mało istotnych, zamiast w pierwszej kolejności zająć się tymi najważniejszymi, które wprowadzają najwięk-sze ryzyko projektowe.

Innym błędem często spotykanym w obszarze inżynierii wymagań jest pomijanie pewnych czynności. Czasami producent pomija analizę biznesową wymagań i prze-chodzi od razu do projektowania rozwiązania. Przyczyn takiego stanu jest wiele – najczęściej presja czasu (wynikająca zazwyczaj z niedoszacowania projektu) oraz nieświadomość faktu, że analiza biznesowa jest koniecznym etapem wytwarzania rozwiązań informatycznych. Bez pełnej analizy biznesowej pojawia się ryzyko zmian projektu systemu w późniejszych etapach projektu (np. podczas implementacji i te-stów) – zostaną wykryte błędy, luki, brakujące funkcje czy ograniczenia, które zosta-łyby przewidziane na etapie analizy biznesowej.

191.1. Wyzwania związane z projektami IT

Kwestia zarządzania zmianami jest innym dowodem na to, że na problemy w planowaniu mogą się składać czynniki pośrednie. Wszelkie modyfikacje wnoszone do zakresu lub treści projektu powinny być obsługiwane za pomocą procesu zarzą-dzania zmianami, którego częścią jest analiza wpływu. Bez niej nie jesteśmy w sta-nie określić ryzyka implementacji danej zmiany i przewidzieć wpływu, jaki wywrze ona na różne elementy produktu oraz na sam projekt – nie wiemy na przykład, czy wdrożenie zmiany nie zepsuje dotychczas stabilnego produktu, co wpłynie na prze-bieg realizacji projektu, generując opóźnienia. Z tego powodu ważnym elementem planowania projektu jest nie tylko ustalenie etapów, obciążenia zasobów itp., ale również przewidywanie przebiegu samych procesów składających się na wytworze-nie projektu produktu (np. analiza wymagań, implementacja, testowanie) oraz pro-cesów pomocniczych, jak wspomniane już zarządzanie zmianą czy równie istotne zarządzanie konfiguracją.

1.1.3. Słaba komunikacja

Projekty informatyczne są realizowane przez ludzi, a sukces przedsięwzięcia w dużym stopniu zależy od ich umiejętności współpracy. Czynnikami niezbędnymi do osiągnięcia sukcesu są świadomość i zrozumienie celów, zadań, odpowiedzial-ności, oczekiwań, problemów, ryzyk. Za uzyskanie i utrzymanie tej świadomości odpowiada komunikacja.

Komunikacja to nie tylko dyskusje – to również wszelkiego typu dokumenty, pro-cedury, raporty i inne elementy umożliwiające dzielenie się informacją.

Aby skutecznie zaplanować projekt i dalej go realizować, niezbędny jest częsty kontakt ze sponsorami i użytkownikami biznesowymi oraz końcowymi, gdyż tylko w taki sposób możemy poznać ich oczekiwania i potrzeby, jak również na bieżąco sprawdzać, czy wyniki realizowanych prac dążą do ich spełnienia.

Raporty statusu i spotkania zarządcze nie są zbędną biurokracją, ale środkiem umożliwiającym monitorowanie postępów projektu i szybką reakcję na potencjalne problemy. Bez nich nie byłoby wiadomo, czy projekt podąża w dobrym kierunku i czy wszystko przebiega zgodnie z planem – nie jesteśmy w stanie bowiem rozwią-zać problemu, nie mając świadomości jego istnienia.

Kolejny ważny element komunikacji to spotkania. Dojrzałe zespoły i organizacje nie organizują spotkań dla zasady, lecz w celu wymiany informacji i wyjaśnienia wszystkim członkom spotkania stanu spraw, problemów, szans, statusu prac oraz dalszych czynności. Zebrania dają możliwość nie tylko zrozumienia celu i przebiegu projektu, ale i szansę wyjaśnienia na bieżąco wszelkich wątpliwości czy zareagowa-nia na problemy. Spotkania są ważne, istotna jest jednak również umiejętność ich organizowania. Dość powszechna niechęć do uczestnictwa we wszelkiego rodzaju spotkaniach często wynika z faktu ich fatalnej organizacji i realizacji – braku planu, moderacji, podsumowania – co skutkuje poczuciem straconego czasu.

Organizację spotkania należy zacząć od opracowania i przekazania uczestni-kom agendy, która wyszczególnia kwestie podejmowane na spotkaniu, pozwala też kontrolować przebieg i zakres dyskusji. Samo spotkanie powinno być moderowa-ne, aby uniknąć schodzenia z zaplanowanych wątków i zapewnić dyscyplinę dys-kusji. W trakcie spotkania wyznaczona osoba (sekretarz) powinna notować główne

20 WPROWADZENIE DO INŻYNIERII WYMAGAŃ

decyzje, ustalenia, elementy dyskusji, które posłużą do opracowania notatki ze spo-tkania. Notatka ta powinna podsumowywać przebieg spotkania, decyzje (co ustalo-no), kwestie otwarte (czego nie ustalono), dalsze kroki i podział odpowiedzialności. Notatkę należy przesłać uczestnikom spotkania do akceptacji, a po jej uzyskaniu przekazać szerszemu gronu odbiorców.

Ważnym elementem komunikacji, w tym także spotkań, są prezentacje i demon-stracje wymagań, rozwiązań, produktu lub jego części. Ta forma komunikacji nie tylko znakomicie ułatwia przekazywanie wiedzy, lecz także ponieważ wykorzystuje-my wizualizacje, które są łatwiejsze do przyswojenia niż tekst, umożliwia uzyskanie cennej informacji zwrotnej na temat prezentowanych obiektów.

W celu przedstawienia alternatywnych sposobów implementacji ich wymagań i wyboru optymalnej opcji można prezentować interesariuszom koncepcje rozwią-zań czy prototyp produktu. Przedmiotem prezentacji mogą być same wymagania, co umożliwia ich walidację i zaakceptowanie przez wybraną grupę interesariuszy, a tym samym obniża ryzyko niepowodzenia projektu spowodowanego wytworzeniem produktu na podstawie błędnie udokumentowanych lub niezrozumianych wymagań.

Jak widać, opcji skutecznej komunikacji jest wiele – wystarczy jedynie je poznać i wdrożyć jako stały element każdego przedsięwzięcia informatycznego.

1.1.4. Złe zarządzanie oczekiwaniami interesariuszy

Bardzo ważnym czynnikiem powodzenia projektu jest zbudowanie wzajemnego za-ufania i porozumienia między interesariuszami odnośnie do celów i pożądanych wy-ników przedsięwzięcia. Jest to szczególnie istotne w przypadku, gdy interesariusze pochodzący z różnych organizacji mają sprzeczne oczekiwania i interesy – co, jak wiadomo, ma miejsce w większości projektów komercyjnych, mających na celu wy-tworzenie produktu przez dostawcę na życzenie zewnętrznego klienta.

Aby osiągnąć sukces i wytworzyć produkt spełniający oczekiwania interesa-riuszy, należy po pierwsze znać ich oraz ich potrzeby. Po drugie, należy zbudować świadomość dążenia do wspólnego celu, niezależnie od organizacji, z której po-chodzi dany interesariusz. Pierwszy warunek, mimo że pozornie oczywisty i pro-sty, w praktyce może nastręczać sporych problemów. Identyfikacja interesariuszy i ich potrzeb – zasadniczy warunek początkowy dla czynności określania wyma-gań – w wielu projektach jest wykonywana nieprawidłowo. Ze względu na presję czasu, brak świadomości, a czasem zwyczajną ignorancję, zaniedbuje się pełną identyfikację interesariuszy, ograniczając się jedynie do tych znanych i najbardziej oczywistych – jak sponsor, kierownik projektu, biznes itp. Skutkiem takiej beztro-ski są często luki w analizie, gdyż każdy pominięty interesariusz oznacza ryzyko pominiętego wymagania czy ograniczenia, które może w zasadniczy sposób wpły-nąć na koncepcję produktu lub samego projektu (chociażby kwestia wymaga-nej dokumentacji projektowej, która może być różnie postrzegana przez różnych interesariuszy).

211.1. Wyzwania związane z projektami IT

Kolejnym problemem jest samo zarządzanie oczekiwaniami interesariuszy. Wspomniano już, że różne grupy interesariuszy mają różne wymagania i potrzeby. Klasycznym przykładem jest różnica interesów na linii biznes – użytkownicy końco-wi. Biznes żąda spełnienia wszelkich procedur i wymagań wynikających z dziedziny biznesowej (często kosztem użyteczności produktu), natomiast użytkownicy z reguły pragną najprostszego rozwiązania.

Nierozwiązane konflikty interesów między interesariuszami mogą sprawić, że gotowy produkt nie będzie spełniać oczekiwań określonej grupy czy grup odbior-ców. W sytuacjach ekstremalnych producent może wytworzyć produkt kompletnie nieprzydatny użytkownikom końcowym lub niezgodny z wymaganiami biznesu.

1.1.5. Problemy z wymaganiami i ich zakresem

Wymagania tworzą podstawy dla organizacji i planowania projektu IT oraz opra-cowania produktu; stanowią one jeden z najważniejszych czynników sukcesu lub porażki projektu. Słabe wymagania mają niejednoznaczny zakres, co przekłada się na słaby projekt produktu, w efekcie – na słaby produkt.

Wyzwania związane z wymaganiami – nieprecyzyjnymi, niemierzalnymi, niepeł-nymi czy niemożliwymi do implementacji w danych warunkach biznesowych i tech-nologicznych – to już klasyczny problem podczas realizacji większości projektów IT.

Najbardziej typowym błędem jest brak precyzji i niemierzalność wymagań. Pojawia się on zazwyczaj już na samym początku projektu. Ileż to razy doświadczal-nie przekonaliśmy się, że klient nie umie sformułować swoich potrzeb? Jak często wymagania opisane są stwierdzeniami: „system powinien być użyteczny”, „system ma umożliwiać zarządzanie raportami” itp.? Klientowi (zamawiającemu) często bra-kuje kompetencji i wiedzy, jak przedstawić wymagania w sposób zrozumiały dla wykonawcy, aby jednocześnie były one precyzyjnymi kryteriami odbioru gotowego produktu. Doprecyzowanie wymagań leży w interesie dostawcy, gdyż pozostawienie ich bez wyjaśnienia spowoduje, że planowanie projektu zostanie wykonane na bar-dzo niedokładnych założeniach.

Jak wygląda praktyka? Z różnych przyczyn, w tym z powodu błędów proceso-wych lub braku wiedzy, ale i w wyniku świadomego działania, dostawca często nie precyzuje wymagań przed podjęciem się realizacji danego projektu. Z nieprecyzyj-nym opisem wymagań trudno realistycznie i wiarygodnie oszacować wysiłek, zakres i koszt projektu. Takie projekty są najczęściej niedoszacowane (ponieważ zakłada się mniej pracy, niż należy wykonać w rzeczywistości) albo przeszacowane (dodanie pewnego bufora „na zapas”). Ponadto, przy takim sformułowaniu wymagań niemal niemożliwe staje się stwierdzenie, kiedy i czy w ogóle wymaganie zostało zaimple-mentowane. Brak mierzalności i kryteriów akceptacji powoduje, że odbiór gotowego rozwiązania opiera się na wierze, nie faktach.

Początkowe problemy z wymaganiami skutkują często dalszymi konsekwencja-mi. Wstępnie ustalone harmonogramy projektów oszacowanych i zaplanowanych na

22 WPROWADZENIE DO INŻYNIERII WYMAGAŃ

podstawie nieprecyzyjnych wymagań są zazwyczaj niemożliwe do realizacji. Brakuje czasu na wykonanie wszystkich czynności związanych z poprawnym wytworzeniem produktu. Jaki jest skutek? Próbuje się „oszczędzić” nieco czasu, maksymalnie skra-cając pewne etapy procesu wytwórczego. Jak można się domyślić, z reguły skra-ca się czas przeznaczony na szczegółową analizę wymagań lub/i testy, ponieważ w obiegowej, aczkolwiek całkowicie błędnej opinii procesy te mają najmniejszą war-tość dodaną dla wytworzenia produktu. Analiza nie tworzy przecież kodu, czyż nie?

Skracanie czasu analizy oznacza ryzyko pominięcia wymagań, ważnych ograni-czeń czy reguł biznesowych, a w konsekwencji – nieprawidłowy lub niepełny pro-jekt rozwiązania. Idąc dalej – poważne problemy przy odbiorze produktu, ponieważ, co jest całkowicie uzasadnione, klient nie wyrazi zgody na odbiór systemu i zapła-tę za jego dostarczenie, jeżeli produkt nie spełni jego oczekiwań. Warto dodać, że w takim przypadku jedynym rozsądnym rozwiązaniem jest poprawienie produktu zgodnie z zastrzeżeniami klienta – czyli wprowadzenie zmian w wytworzonym, sta-bilnym oprogramowaniu. Skutki późnych zmian są oczywiste – wysokie ryzyko de-stabilizacji systemu i związana z nim konieczność wzmożonych testów regresyjnych i poprawek.

1.1.6. Brak umiejętności miękkich

Komunikacja w zespole i dobrze dobrane kompetencje jego członków są zazwyczaj podstawą sukcesu przedsięwzięcia, jednak ich brak bywa równie często przyczyną klęski. Kompetencje miękkie, często określane w ogłoszeniach o pracę jako umie-jętność pracy zespołowej, stanowią podstawę do zrozumienia, dialogu, budowania zaufania podczas realizacji projektu oraz na etapie jego utrzymania.

Brak umiejętności nawiązywania kontaktu, odpowiedniego zadawania pytań czy wzbudzania zaufania może skutecznie utrudniać budowanie relacji z klientem, a w rezultacie tak istotną komunikację w projekcie. Jej zaniedbanie możemy utożsa-miać z jednoczesnym odcięciem od informacji na temat tego, co dzieje się u naszego klienta, albo sposobu, w jaki postrzega on realizację samego projektu. Przykładem problemu z nawiązywaniem kontaktu mogą być zespoły handlowe, których podsta-wowym zadaniem jest poszukiwanie klientów. Jeśli sprzedawca przyklei na kompu-terze kartkę z napisam „Zadzwoń do klienta jutro”, po dwóch tygodniach zadanie często nadal nie jest wykonane bo karteczka przecież mówi „jutro”. Często kierują nami lęki, odruchy i przyzwyczajenia, w tym przypadku strach przed podniesieniem słuchawki i kontaktem z nieznaną osobą.

Kompetencje te należy wykształcić. W zespole, który jest silnie ukierunkowany na zadania techniczne, często nie są one ćwiczone lub wyuczone. Stała techniczna praca z komputerem zamyka nas w małym świecie, w którym koncentrujemy się na realizacji zadania, skutecznie odcinając się od ludzi, którzy nas otaczają. Rezultatem tego są stereotypy informatyków, którzy głównie programują lub wykonują inną pracę na komputerze, jednak nie są w stanie nawiązać relacji z innymi ludźmi.

W wielu krajach system edukacji nie obejmuje przemawiania, nawiązywa-nia kontaktu, dyplomacji czy dyskusji. Polska nie odbiega pod tym względem od światowej średniej. Cierpimy na tym później, kiedy stajemy przed zarządem firmy

231.1. Wyzwania związane z projektami IT

i prezentujemy korzyści z wdrożenia naszego rozwiązania, wiedząc, że od jakości wystąpienia zależy kontrakt lub jego brak. Bez odpowiedniego przygotowania staje się to nie lada wyzwaniem.

Istotnym składnikiem poprawnej komunikacji są spotkania, prowadzenie rozmów czy zwykłe zadawanie pytań w celu otrzymania informacji, które z perspektywy re-alizacji projektu interesują nas najbardziej. W wielu projektach znajdujemy nieja-sne wymagania typu „system ma być ładny” i zachodzimy w głowę, co autor miał na myśli. Zawsze możemy przyjąć, że wiemy lepiej i zrealizować zadanie zgodnie z naszą najlepszą wiedzą. Praktyka wskazuje jednak, że najpewniej nie uda nam się stworzyć dokładnie tego, co miał na myśli klient. Z pomocą przychodzą nam kompe-tencje miękkie, które pomagają zadawać odpowiednie pytania precyzujące: Dlaczego system ma być ładny (powód problemu z wyglądem)? Po co system ma być ładny (jak ma wygląd pomóc w dalszej pracy)? Jak wyobrażasz sobie idealne rozwiązanie tego problemu (zmusza klienta do my-ślenia o szczegółach)?Po takiej serii pytań może się okazać, że stary interfejs systemu był mało czy-

telny, klientowi zależy głównie na poprawieniu jego przejrzystości i użyteczności, a chce to zrealizować za pomocą dynamicznie generowanych tabel. Jeśli nie zada-jemy pytań lub nie wiemy, o co pytać, stajemy przed wyzwaniem zdobycia szczytu góry, zdając się na ślepy los. Zwiększamy w ten sposób ryzyko, liczba niewiado-mych rośnie niewiarygodnie, a wymarzony szczyt się oddala. Analogia ta sprawdza się we wszystkich dziedzinach, które wymagają współpracy z innymi ludźmi, nie tylko w projektach IT.

Istnieje wiele technik miękkich i należy pamiętać, że często odgrywają one dużą rolę w projektach. Liczą się nie tylko kompetencje techniczne, ale często także for-ma przekazania lub pozyskania informacji oraz utrzymanie relacji z klientem. Brak takich umiejętności może skutecznie utrudnić pracę nad projektem i zdobywanie informacji, które mogą pomóc w jego efektywniejszej realizacji. Jeżeli jednak uda się nam zrealizować go z sukcesem, utrzymanie dobrych relacji i zrozumienie klien-ta to klucz do następnych kontraktów i zleceń.

1.1.7. Nierealistyczne oczekiwania

Wszystkie realizowane projekty wykorzystują pewne wstępne wyobrażenia goto-wych produktów oraz założenia, jakie przyjmujemy na początku ich realizacji. W oczach zamawiającego gotowy produkt jest często bliski ideału i wykracza daleko poza realne możliwości technologiczne lub oczekiwania rynku. Warunki przyjęte podczas realizowanych projektów często wymykają się spod kontroli, a od klienta słyszymy – „to jest to, czego chcieliśmy, ale…”. Co gorsza mogą one generować koszty nieadekwatne do wartości wytwarzanego rozwiązania.

Podczas pracy nad projektami możemy spotkać osoby, które stawiają niere-alistyczne wymagania bez uzasadnionej przesłanki biznesowej lub wybiegają z oczekiwaniami daleko w przyszłość. Oczywiście wszystko jest kwestią środków przeznaczonych na realizację projektów, jednak z praktyki wynika, że budżet projek-tu jest zawsze jest za mały, ponieważ projekty często są niedoszacowane.

24 WPROWADZENIE DO INŻYNIERII WYMAGAŃ

Doświadczenie wskazuje, że nie istnieją projekty, w których przy ustalonym za-kresie prac możemy dowolnie zmniejszyć budżet lub wymagać dużo większej jako-ści. Jak w anegdocie o szewcu, usługa może zostać wykonana: szybko i dobrze, ale nie tanio, tanio i szybko, ale jakości próżno się doszukiwać, tanio i dobrze, jednak w bardzo długim czasie.

Z przedstawionych refleksji wyłania się problem ustalenia realnych priory-tetów w projektach i przypisania ich do zebranych wymagań. W projektach we-wnętrznych często można spotkać sytuację, w której wszystkie wymagania mają zostać zrealizowane, a nikt nie jest w stanie wskazać najważniejszych z nich. Przykładem może być przygotowanie prototypu produktu na konferencję, podczas gdy z góry wiadomo, że nie jesteśmy w stanie przygotować pełnej funkcjonalno-ści na podany termin. Dyrektor naciska, zespół informuje, że produkt będzie go-towy w kwietniu roku następnego, a konferencja ma odbyć w grudniu. Sytuacja patowa – bez podjęcia odpowiednich kroków i decyzji, co pokazać i realnie wyko-nać, strata zaistnieje zarówno po stronie biznesowej, jak i technicznej – dla sa-mego zespołu rozwoju, który dostanie zadanie nie do wykonania. Bez podjęcia działań spotkamy się z typowym „marszem ku klęsce” – zespół będzie pracował nad produktem dnie i noce, choć z góry wiadomo, że nie wywiąże się z realiza-cji zadania.

Nierealne wymagania są często formułowane jako oczekiwania. Niestety na wczesnym etapie projektu nie są one weryfikowane, ponieważ często nie ma takiej możliwości, a następnie generują wysokie koszty realizacji projektu lub tworzą nie-potrzebne opóźnienia i utrudnienia. Najczęściej dotyczy to wymagań niefunkcjonal-nych, których natura uniemożliwia ich łatwe opisanie. Stanowią one najtrudniejszą w realizacji część projektów.

Praktyka pokazuje, że w takich sytuacjach musimy przedyskutować priorytety w projekcie z klientem oraz przedstawić mu obiektywne zalety oraz wady decyzji. Stała współpraca z biznesem ma znaczący wpływ na powodzenie projektu i należy ją doceniać. Szczególny nacisk na obecność interesariuszy możemy zaobserwować w popularnych metodykach zwinnych, np. Scrum, gdzie do reprezentowania bizne-su klienta dedykowana jest odrębna rola o pełnej dostępności dla dostawcy.

1.1.8. Brak zasobów ludzkich

Trudno jest znaleźć osobę z wymaganymi kompetencjami, a jednocześnie odpo-wiednio zmotywowaną do wykonywania aktywności związanych z realizacją projek-tu informatycznego. Ponieważ w obszarze testowania problem kadrowy jest dużym wyzwaniem, stanowiska często są obsadzane przez osoby z kwalifikacjami odbiega-jącymi od wymaganych, co skutkuje nieodpowiednim lub nieefektywnym prowadze-niem projektów. Ostatnie badania przeprowadzone wśród dyrektorów IT w Polsce wykazały, że największymi problemami, z jakimi spotykają się podczas wykonywa-

251.1. Wyzwania związane z projektami IT

nia codziennych zadań, są brak odpowiednich środków finansowych oraz zasobów ludzkich2. W dzisiejszych czasach projekt obejmuje wiele systemów w zróżnico-wanych technologiach i wymaga od zespołu różnego rodzaju kompetencji. Nie jest możliwe pokrycie całego zakresu kompetencji jedną osobą lub małym interdyscy-plinarnym zespołem – to najlepsza droga do dalszego zmniejszenia dostępnych zasobów.

Mimo popularności metodyk zwinnych wykorzystujących małe interdyscypli-narne zespoły realizacja przez taki zespół wszystkich możliwych zadań w organi-zacji nie jest możliwa. Skalując takie zespoły i metodyki w organizacji, zyskujemy wymieszanie kompetencji i doświadczeń, jednak nie zawsze umożliwamy zespo-łom specjalizację, ponieważ nie idzie ona w parze z metodykami zwinnymi, jak np. Scrum.

Aby określić szacowane koszty realizacji projektu, zasoby w projekcie powinny być zapewnione już na etapie powołania i definiowania wymagań. Niedoszacowanie kosztów zasobów to taki sam błąd jak pominięte wymagania czy brak odpowiednich środków finansowych na zakup wymaganych licencji na oprogramowanie.

Specyficzne wymagania, normy lub metodyki mogą generować potrzebę zatrud-nienia lub wynajęcia specjalisty. Sytuacja komplikuje się, jeżeli jego kompetencje są tak unikalne, że zasobów musimy szukać w innym kraju lub wręcz na innym kon-tynencie. Brak zasobów może przejawiać się jako różne typy potrzeb, czasem może wymagać dużej liczby osób do wykonania prostych prac, np. „przeklikania” scena-riuszy testowych, lub częściej zadań wymagających specjalistycznych kompetencji metodycznych lub technologicznych. Brak specjalistów – w zespole brak osób o kompetencjach potrzebnych do reali-

zacji konkretnych zadań lub elementów wymaganych w projekcie. Zatrudnienie odpowiedniej osoby w ramach kontraktu „Fixed-Term” jest bardzo kosztowne, ponieważ wąska specjalizacja będzie generować wysokie koszty. Z pomocą przy-chodzą płatne usługi firm specjalizujących się w realizacji wykwalifikowanych zadań.

Brak zasobów ludzkich do realizacji prac – brak osób do realizacji zbyt dużej liczby zadań niekoniecznie wymagających wyspecjalizowanych kompetencji. Szczęśliwie na rynku istnieje wiele firm specjalizujących się w usługach typu „body leasing”, w których możemy wynajmować osoby do wykonywania dużej liczby zadań, ponosząc relatywnie niewysokie koszty.Należy pamiętać że zwiększenie liczby pracowników nie zawsze przyśpieszy wy-

konywanie pewnych czynności, a wręcz może je czasem skomplikować i wydłużyć czas realizacji. Przykładem ze świata przyrody może być ciąża u słonic, która trwa

2 III Krajowa Konferencja Inżynierii Oprogramowania „Inżynieria oprogramowania w procesach integracji systemów informatycznych” – Cezary Orłowski, Paweł Madej, Łukasz Szczygielski, Bartosz Chrabski – Zarządzanie przedsięwzięciami informatycznymi z wykorzystaniem centrów kompetencyjnych dużych firm informatycznych (12–15 września 2011).

26 WPROWADZENIE DO INŻYNIERII WYMAGAŃ

22 miesiące. Jeżeli dodamy kolejnych 21 słonic, nie uzyskamy małego słonia w mie-siąc. Niektóre procesy w organizacji zajmują określony czas i z perspektywy zaso-bów nie mamy większego wpływu na ich przyspieszenie. W tym obszarze możemy jednak wpłynąć na jakość zasobów, które wykonują dla nas pracę, aby zapewnić odpowiednią realizację tego procesu.

Odpowiednie zasoby i ich kompetencje są istotne dla projektu, ponieważ to właśnie pracownicy tworzą produkt dla klienta. Są one jednak zależne od pozosta-łych elementów ważnych dla projektu – komunikacji w projekcie, oczekiwań czy zakresu, mając na nie znaczący wpływ. Dobór osób do projektu powinien zawsze być zdeterminowany przez ich kompetencje, wartość, jaką wnoszą, i doświadczenia z wcześniejszych projektów.

1.1.9. Brak odpowiedniego wsparcia narzędziowego i metodycznego

Podstawą opracowania procesu prowadzenia projektów dopasowanego do organi-zacji są odpowiednio dobrane dobre praktyki, metody zarządzania oraz efektywne narzędzia wspierające. Ich wybór dla wielu organizacji stanowi wyzwanie i poważny problem. Analizując środowiska, w których obecnie prowadzone są projekty, może-my stwierdzić, że zespoły analityków, programistów i testerów zwykle nie komuni-kują się ze sobą w sposób efektywny, co negatywnie wpływa na wydajność pracy, koszty i jakość finalnego produktu.

Powszechnie używane narzędzia wspierające prowadzenie projektu nie potra-fią wymieniać informacji między sobą, co prowadzi do powielania funkcjonalności i konieczności żmudnego i narażonego na błędy przenoszenia danych między nimi. Wybór narzędzi dokonywany jest zwykle pod kątem zaspokojenia potrzeb każdego zespołu z osobna, co z czasem całkowicie blokuje rozwój strategii departamentu odpowiedzialnego za rozwój IT. Oczywistym wnioskiem jest konieczność dążenia do konsolidacji dyscyplin w ramach projektu na poziomie integracji repozytoriów danych i ujednolicenia narzędzi, przy jednoczesnej eliminacji powielania ich podsta-wowych funkcji.

Zgodnie z tą koncepcją, efektywne narzędzia wspierające pracę zespołów projek-towych powinny obsługiwać cały zintegrowany cykl produkcyjny (ang. Application Lifecycle Management – skrót ALM). ALM ma za zadanie zintegrować najważniej-sze dyscypliny projektowe, jak zarządzanie wymaganiami, zarządzanie zmianami i konfiguracjami oraz zarządzanie procesami zapewnienia jakości. Dla osiągnięcia jak najlepszych efektów, narzędzia ALM powinny wspierać się na solidnych funda-mentach, które zapewnią możliwość pomiaru efektywności procesów wytwarzania oraz współpracy między wszystkimi uczestnikami projektu.

Każda organizacja profesjonalnie zajmująca się wytwarzaniem oprogramowania lub systemów pracuje według ustalonych procesów. Mogą być one dokumentowa-ne w postaci metodyk, jak Scrum, OpenUP, EclipseWay, T-Map Next czy Rational Unified Process, lub przyjęte jako nieformalne zbiory dobrych praktyk. Adaptacja posiadanych narzędzi do przyjętych procesów jest wyzwaniem dla wielu organizacji, szczególnie gdy procesy te są nowe lub specyficzne dla dziedziny przedsięwzięcia. Wybierając narzędzie, zawsze powinniśmy się kierować jego wsparciem dla aktu-

271.2. Podstawowe definicje oraz klasyfikacje

alnych lub przyszłych procesów używanych w organizacji. W idealnej sytuacji pro-ducent udostępnia w narzędziu różne szablony metodyk, jak również umożliwia ich edycję i tworzenie własnych szablonów od podstaw.

Ocena aktualnego stanu projektu, zarządzanie ryzykiem czy budżetem są po-ważnym wyzwaniem w każdym przedsięwzięciu. Dzięki opcji wglądu w rzeczywi-ste dane projektowe możliwe jest wczesne podejmowanie decyzji pozwalających ograniczyć wiele ryzyk. Z perspektywy kadry zarządzającej czy kierownika projektu szczególnie istotny staje się element raportowania i planowania prac z uwzględnie-niem bieżących danych z przebiegu prac, ewentualnych opóźnień czy danych histo-rycznych z zakończonych wcześniej projektów. Wszelkie zmiany w wymaganiach, problemy technologiczne, odstępstwa od planu, urlopy, przeciągające się zadania czy rozwiązania błędów zgłoszonych przez klientów powinny być możliwe do śle-dzenia i weryfikowania w czasie rzeczywistym.

Wyciągane wniosków ze zrealizowanych projektów pomaga znacznie obniżyć koszty i zwiększać produktywność. Narzędzia powinny gromadzić ważne dane pro-jektowe i wspierać kadrę zarządzającą w procesie ich analizy. Oczywistym przy-kładem zastosowania takich informacji jest weryfikacja poprawności szacowania pracochłonności. Innym przykładem użycia danych archiwalnych do retrospekcji jest analiza głównych źródeł błędów i problemów napotkanych w projektach.

Większość organizacji korzysta już z różnego rodzaju narzędzi wspierających różne dyscypliny procesu tworzenia oprogramowania rozwiązujące specyficzne potrzeby organizacji. Rezygnacja z nich wiązałaby sie ze stratami jakości obsługi procesów, dlatego narzędzia takie powinny być zintegrowane, aby cały proces wy-twarzania był efektywny, mierzalny i przewidywalny.

Podsumowując czynniki wpływające na sukces projektu, można pokusić się o stwierdzenie, że spora część z nich w mniejszym lub większym stopniu dotyczy inżynierii wymagań. Potwierdzają to przeróżne statystyki opracowywane przez organizacje profesjonalnie zajmujące się badaniami rynku, na przykład Standish Group czy Gartner. Ich opracowania od lat wskazują w przybliżeniu te same przy-czyny niepowodzeń projektów, wśród których niezmiennie czołowe pozycje zajmują zagadnienia związane z wymaganiami i celami biznesowymi.

1.2. Podstawowe definicje oraz klasyfikacjePunktem startowym dla inżynierii wymagań jest tak zwany problem biznesowy. Opisuje on potrzebę czy cel biznesowy, które będą rozwiązane przez docelowy pro-dukt. Problem biznesowy – jak nazwa wskazuje – w ujęciu biznesowym opisuje, „co chcemy osiągnąć”. Na tym etapie nie ma mowy o szczegółach planowanego produk-tu czy aspektach implementacyjnych. Koncentrujemy się na potrzebie. Przykładem problemu biznesowego jest potrzeba optymalizacji procesu obsługi klienta.

Problem biznesowy jest likwidowany przez tak zwane rozwiązanie. Jest nim dowolny produkt, usługa czy proces lub ich elementy umożliwiające spełnienie wymagań związanych z realizacją danego problemu biznesowego. Rozwiązanie de-finiowane jest jako zmiana w obecnym stanie organizacji wykonana w celu osią-

Premiera książki - listopad 2014.