Projekt okładki i stron tytułowych Grzegorz Laskowski

Zdjęcie na okładce amgun, RYGER/Shutterstock

Wydawca Łukasz Łopuszański

Koordynator produkcji Anna Bączkowska

Skład wersji elektronicznej na zlecenie Wydawnictwa Naukowego PWN Michał Nakoneczny / 88em.eu

Książka, którą nabyłeś, jest dziełem twórcy i wydawcy. Prosimy, abyś przestrzegał praw, jakie im przysługują. Jej zawartość możesz udostępnić nieodpłatnie osobom bliskim lub osobiście znanym. Ale nie publikuj jej w internecie. Jeśli cytujesz jej fragmenty, nie zmieniaj ich treści i koniecznie zaznacz, czyje to dzieło. A kopiując jej część, rób to jedynie na użytek osobisty.

Szanujmy cudzą własność i prawo

Więcej na www.legalnakultura.pl

Polska Izba Książki

Copyright © by Wydawnictwo Naukowe PWN SA

Warszawa 2015

eBook został przygotowany na podstawie wydania papierowego z 2015 r., (wyd. I)

Warszawa 2016

ISBN 978-83-01-18049-2 (ePub)

ISBN 978-83-01-18050-8 (Mobi)

Wydanie I

Wydawnictwo Naukowe PWN SA

02-460 Warszawa, ul. Gottlieba Daimlera 2

tel. 22 69 54 321, faks 22 69 54 288

infolinia 801 33 33 88

e-mail: pwn@pwn.com.pl

www.pwn.pl

SPIS TREŚCI

Od Autorów

1. Wprowadzenie do inżynierii wymagań

1.1. Wyzwania związane z projektami IT

1.1.1. Cele i wizja

1.1.2. Złe planowanie projektu

1.1.3. Słaba komunikacja

1.1.4. Złe zarządzanie oczekiwaniami interesariuszy

1.1.5. Problemy z wymaganiami i ich zakresem

1.1.6. Brak umiejętności miękkich

1.1.7. Nierealistyczne oczekiwania

1.1.8. Brak zasobów ludzkich

1.1.9. Brak odpowiedniego wsparcia narzędziowego i metodycznego

1.2. Podstawowe definicje oraz klasyfikacje

1.2.1. Wymagania biznesowe

1.2.2. Wymagania interesariuszy

1.2.3. Wymagania rozwiązania

1.2.4. Wymagania przejścia

1.3. Atrybuty wymagań

1.4. Kryteria jakości wymagań

1.5. Wymagania w procesie zapewnienia jakości oprogramowania

1.6. Inżynieria wymagań oraz jej znaczenie w projekcie

1.7. Podstawowe role w procesie inżynierii wymagań

1.8. Koncepcja interesariuszy

1.9. Standardy oraz normy

1.9.1. ISO 9000

1.9.2. ISO/IEC 25000 – Software Engineering – Software Product Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE

1.9.3. ISO 9241

1.9.4. ISO 31000: Risk Management

1.9.5. IEEE 610:1990: Standard Glossary of Software Engineering Terminology

1.9.6. IEEE 828-2012: Standard for Configuration Management in Systems and Software Engineering

1.9.7. IEEE 830-1998: Recommended Practice for Software Requirements Specifications

1.9.8. IEEE 1233-1996: Guide for Developing of System Requirements Specifications

1.9.9. IEEE 1362-1998: Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document

1.9.10. IEEE 29148-2011 – Systems and software engineering – Life cycle processes – Requirements engineering

1.9.11. IEEE 1028:2008 Standard for Software Reviews and Audits

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

1.9.13. CMMI

1.9.14. BABOK – A Guide to the Business Analysis Body of Knowledge

1.10. Słowniki

2. Process inżynierii wymagań

2.1. Definicja procesu

2.2. Inżynieria wymagań a analiza biznesowa

2.3. Zasady tworzenia udanych wymagań

2.3.1. Zrozum krytyczne cele najwyższego poziomu

2.3.2. Koncentruj się na dostarczeniu wartości

2.3.3. Zdefiniuj wymaganie jako „stan końcowy o wartości dla interesariusza”

2.3.4. Wyrażaj wymagania ilościowo

2.3.5. Nie mieszaj środków z celami

2.3.6. Skup się na pożądanej jakości systemu, nie tylko na jego funkcjonalności

2.3.7. Zapewnij „bogatą specyfikację”

2.3.8. Wykonuj kontrolę jakości specyfikacji

2.3.9. Uznaj, że wymagania się zmieniają

3. Inżyniera wymagań a inne procesy

3.1. Zarządzanie projektem

3.2. Zarządzanie ryzykiem

3.3. Testowanie i zapewnienie jakości

3.4. Wpływ wymagań na inne artefakty projektu

4. Inżynieria wymagań w procesach tworzenia oprogramowania

4.1. Model V jako przykład kaskadowego wytwarzania systemów

4.2. IBM Rational Unified Process

4.2.1. Zarządzanie wymaganiami w IBM Rational Unified Process

4.2.2. Przepływ prac dla wymagań w IBM Rational Unified Process

4.2.3. Role i artefakty w IBM Rational Unified Process

4.3. Zwinne metodyki w zarządzaniu wymaganiami

4.4. Programowanie ekstremalne

4.5. Scrum (według Scrum.org)

4.5.1. Rejestr produktowy, czyli metoda na zorganizowanie wymagań

4.5.2. Wyzwania związane z migracją do Scrum

4.6. Disciplined Agile Delivery

4.7. Przypadek biznesowy

4.7.1. Informacja o firmie i sytuacja rynkowa

4.7.2. Potrzeba

4.7.3. Rozwiązanie

4.7.5. Zyski

5. Identyfikacja wymagań

5.1. Źródła wymagań

5.2. Wizja oraz cel przedsięwzięcia

Przykład struktury i zakresu tematycznego wizji

5.3. Identyfikacja interesariuszy projektu

5.4. Techniki identyfikacji wymagań

5.4.1. Warsztat wymagań

5.4.2. Wywiad

5.4.3. Ankieta – kwestionariusz

5.4.4. Samodzielna rejestracja

5.4.5. Reprezentant klienta po stronie dostawcy

5.4.6. Identyfikacja na podstawie istniejących dokumentów

5.4.7. Ponowne użycie specyfikacji

5.4.8. Obserwacja w terenie

5.4.9. Mentorowanie/Praktykowanie

5.4.10. Burza mózgów

5.4.11. Prototypowanie

5.4.12. Przypadki użycia

5.4.13. Scenorys

5.5. Wymagania funkcjonalne i niefunkcjonalne

6. Analiza wymagań

6.1. Analiza problemu biznesowego

6.2. Oganizacja wymagań

6.3. Powiązania i zależności między wymaganiami

6.4. Usuwanie konfliktów i duplikatów wymagań

6.5. Kontrola jakości

6.6. Szacowanie wysiłku

6.6.1. Techniki wykorzystujące algorytmy

6.6.2. Techniki wykorzystujące przybliżenia

6.7. Priorytetyzacja wymagań

6.8. Modelowanie rozwiązania

6.8.1. Model dziedziny

6.8.2. Diagram przepływu danych (ang. Data Flow Diagram)

6.8.3. Diagram związków encji (ang. Entity Relationship Diagram)

6.8.4. Modelowanie interfejsu użytkownika

6.8.5. Unified Modeling Language (UML)

6.8.6. System Modeling Language (SysML)

6.8.7. Inne notacje do modelowania

6.9. Akceptowanie wymagań

7. Specyfikacja wymagań

7.1. Pojęcie specyfikacji

7.2. Rodzaje specyfikacji

7.2.1. Specyfikacja wymagań

7.2.2. Specyfikacja rozwiązania

7.2.3. Specyfikacja techniczna

7.3. Szablony specyfikacji wymagań (na podstawie IEEE 830)

7.3.1. IEEE 830

7.3.2. Wzorzec Volere

7.3.3. Historie użytkownika

7.3.4. Przypadki użycia jako sposób na wymagania funkcjonalne

7.4. Jakość specyfikacji wymagań

8. Zarządzanie wymaganiami

8.1. Śledzenie wymagań

8.2. Zarządzanie konfiguracją

8.3. Zarządzanie zmianą

8.4. Zarządzanie wymaganiami dotyczącymi projektu oraz systemu

8.5. Plan zarządzania wymaganiami

8.6. Przypadek biznesowy – wdrożenie procesu zarządzania wymaganiami

8.6.1. Informacja o firmie i sytuacja rynkowa

8.6.2. Potrzeba

8.6.3. Rozwiązanie

8.6.4. Zyski

9. Wymagania a zarządzanie jakością

9.1. Planowanie jakości

9.2. Kontrola jakości

9.2.1. Przeglądy

9.2.2. Inspekcje

9.2.3. Listy kontrolne

9.3. Miary jakości wymagań

9.4. Doskonalenie procesu

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

10.1. Narzędzia służące do zarządzania wymaganiami

10.1.1. IBM Rational Requirements Composer

10.1.2. Borland Caliber RM

10.1.3. Serena Dimensions

10.1.4. Rational DOORS (Dynamic Object Oriented Requirements System)

10.1.5. Blueprint Requirements Center

10.1.6. Open Source Requirements Management Tool/aNimble Platform

10.1.7. Cechy dobrego narzędzia do zarządzania wymaganiami

10.1.8. Wdrożenie narzędzia do zarządzania wymaganiami

10.2. Czynniki istotne przy doborze odpowiednich narzędzi

10.3. Narzędzia do modelowania wymagań

10.3.1. Sparx Enterprise Architect

10.3.2. IBM Rational Software Architect

10.3.3. StarUML

10.4. Narzędzia służące do modelowania procesów biznesowych

10.4.1. Boc Group ADONIS

10.4.2. iGrafx Process

10.4.3. BizAgi Process Modeler

10.4.4. Rational System Architect

10.5. Narzędzia do zarządzania konfiguracją

10.5.1. GIT

10.5.2. Subversion

10.5.3. IBM ClearCase

10.6. Narzędzia do zarządzania zmianami

10.6.1. Atlassian Jira

10.6.2. IBM Rational Team Concert

10.7. Zarządzanie procesem testowania oprogramowania

10.7.1. HP Quality Center

10.7.2. IBM Rational Quality Manager

10.7.3. Testia Tarantula

10.7.4. Requirements Testing Hub

10.7.5. TestLink

10.8. Ryzyko związane ze złym zakupem narzędzia

Podsumowanie

Przypadki biznesowe

Projekt 1 – Wdrażanie procesu inżynierii wymagań

Informacja o firmie i sytuacja rynkowa

Potrzeba

Rozwiązanie

Zyski

Projekt 2 – Integracja narzędzi w procesie wytwarzania

Informacja o firmie i sytuacja rynkowa

Potrzeba

Rozwiązanie

Etap 1 – Integracja wymagań z procesem zarządzania testami

Etap 2 – Integracja wymagań z zarządzaniem konfiguracją

Etap 3 – Integracja wymagań z zarządzaniem zmianami

Zyski

Projekt 3 – Kontrola jakości wymagań na wczesnych etapach projektu

Informacja o firmie i sytuacja rynkowa

Potrzeba

Skutek

Przyczyna

Rozwiązanie

Projekt 4 – Zarządzanie wymaganiami przy użyciu historii użytkownika

Informacja o firmie i sytuacja rynkowa

Potrzeba

Rozwiązanie

Zyski

Bibliografia

Spis rysunków

Spis tabel

Przypisy

OD AUTORÓW

Skąd wziął się pomysł napisania książki o inżynierii wymagań? Dlaczego zajęliśmy się tematem tak pozornie oczywistym i niewymagającym głębszej analizy? Powody wynikają bezpośrednio z naszych doświadczeń projektowych, wskazujących na to, że wbrew pozorom inżynieria wymagań nie jest dziedziną prostą i oczywistą, w projekcie nie „zrobi się sama” i wymaga pewnego usystematyzowania oraz porządku. Można by zapytać, po co? Otrzymaliśmy od klienta wymagania (lub wydaje nam się, że je mamy), to wystarczy, by rozpocząć wytwarzanie produktu. Otóż nie do końca.

Wyobraźmy sobie następującą sytuację – planujemy budowę domu. Co robimy najpierw? Oczywiście ustalamy budżet, planowany czas odbioru itp. – określamy ograniczenia. Następnie definiujemy parametry domu – liczbę pięter, okien, pomieszczeń itd. Teraz zadajmy sobie pytanie – czy powyższe informacje wystarczą do zbudowania domu? Każdy rozsądnie myślący człowiek odpowie, że nie – potrzebny jest dokładny projekt. W innym przypadku mogłoby okazać się, że zaczynamy budowę od komina czy okien, ponieważ wydają się najłatwiejsze do wytworzenia. Możemy też zacząć od stawiania ścian i po pewnym czasie dojść do wniosku, że udały nam się one wspaniale, jednak zapomnieliśmy o fundamentach… Kuriozalne, prawda? Dla większości osób i z pewnością dla wszystkich inżynierów logiczne jest, że wytworzenie czegokolwiek wymaga analizy danych, jak również opracowania dokładnych założeń i kształtu projektu. Dlaczego więc zastosowanie takiego sposobu myślenia w przypadku oprogramowania nastręcza takie trudności? Oprogramowanie to też produkt, z reguły nawet bardziej złożony i skomplikowany niż inne typy produktów. Czemu tak często neguje się potrzebę zastosowania inżynierii wymagań w projektach informatycznych? Typową przyczyną takiego postępowania jest bezmyślne dążenie do oszczędzania czasu trwania i budżetu projektu kosztem prac analitycznych. Działanie takie przynosi szczególnie szkodliwe skutki, jeśli jest spowodowane brakiem znajomości dziedziny inżynierii wymagań i jej wpływu na prace projektowe oraz nieznajomością podstawowych zasad wytwarzania produktu.

Jakie są tego konsekwencje? Według wielu źródeł (np. Standish Group) najczęstszymi powodami niepowodzeń projektów są ciągłe zmiany wymagań wynikające ze zmieniających się celów klienta, brak definicji potrzeb klienta, wymagania niekompletnie udokumentowane lub niekompletne[1]. Problemy te wynikają w równej mierze z nieznajomości dziedziny, jak i pewnego rodzaju ignorancji przejawiającej się w upartym powtarzaniu błędów popełnionych przez inne organizacje, z wiarą, że „nam się uda”. Częstym problemem jest również fakt, że w produkcję oprogramowania zaangażowane są wyłącznie osoby z podłożem technicznym, bez znajomości realiów biznesu, otoczenia klienta, jego rzeczywistych potrzeb. Takie osoby rzadko będą miały chęć, odwagę, potrzebę czy możliwość poznania realnych potrzeb klienta (nie informacji, co klientowi wydaje się, że chce otrzymać), a następnie ich systematycznego uszczegóławiania w trakcie często czasochłonnych uzgodnień i dyskusji. W przypadku wielu projektów osoby bezpośrednio odpowiedzialne za wymagania nie są odpowiednio przygotowane do pełnienia tych obowiązków i nawet mimo najlepszych intencji ciężko im sprostać postawionym wyzwaniom bez odpowiednich szkoleń, doświadczeń i wsparcia. Efekt takiego stanu rzeczy jest zapewne znany wszystkim Czytelnikom, a podsumować go można padającym ze strony klienta po przedstawieniu mu zbudowanego produktu stwierdzeniem – „to nie jest to, o co nam chodziło”.

Inżynieria wymagań była i nadal pozostaje istotnym i aktualnym tematem w obszarze wytwarzania wielu produktów, w tym informatycznych, i oprogramowania. Jest to szczególnie widoczne w organizacjach, które – nauczone doświadczeniem ciągłego wytwarzania kolejnych produktów – zdały sobie sprawę z tego, że prawdziwy sukces nie jest możliwy bez zorganizowanej inżynierii wymagań.

Jeśli w procesie tworzenia oprogramowania zaniedbamy aspekt biznesowy (a takim jest inżynieria wymagań) oraz sprawną komunikację, to okaże się, że kwestie typowo techniczne mają drugorzędne znaczenie. Uporządkowanie stanu wiedzy w dziedzinie inżynierii wymagań oraz rozwijanie umiejętności analitycznych i nauka systematycznego podejścia do pracy z wymaganiami były głównymi przesłankami dla stworzenia tej książki, która ma być kompendium wiedzy dla osób zaangażowanych w procesy wytwarzania oprogramowania oraz zainteresowanych tematyką inżynierii wymagań.

Publikacja powstała dzięki spotkaniu dwóch osób zafascynowanych zagadnieniami inżynierii wymagań oraz wytwarzania oprogramowania. Jest rezultatem miesięcy cieżkiej pracy, sporów oraz wyjaśniania zagadnień, które były różnie definiowane i interepretowane w publikacjach specjalistycznych oraz przez ekspertów. Wynikiem tej współpracy jest książka opisująca proces i zagadnienia inżynierii wymagań oraz dostarczająca praktycznych przykładów, które pozwalają zrozumieć bardziej skomplikowane zagadnienia. Nie stanowi ona przeglądu wszystkich metod, technik i narzędzi wspierających inżynierię wymagań i nie taki były cel jej powstania. Zamiast opisywać niemal nieskończony zbiór środków wspomagających proces, skupiliśmy się na wyjaśnieniu samego procesu, jako że to proces inżynierii wymagań jest istotnym czynnikiem sukcesu przy wytwarzaniu produktu.

Warszawa–Szczecin, wrzesień 2014

Przypisy