Inżynieria wymagań to kluczowa faza każdego projektu informatycznego. Od jej powodzenia zależy sukces całego przedsięwzięcia. Dobrze przeprowadzony proces zbierania, modelowania i zarządzania wymaganiami pozwala zredukować liczbę problemów z nimi związanych, a w rezultacie znacznie obniżyć koszty projektu. Niniejsza publikacja przedstawia doświadczenia wielu analityków biznesowych z pierwszej linii frontu ich walk na rzecz zapewnienia odpowiedniego poziomu jakości wymagań. Zgodnie z założeniami serii w praktyce, opisują oni nie tylko swoje sukcesy, ale także poniesione porażki.

Osoby które kupowały "Inżynieria wymagań. Studium przypadków", wybierały także:

• Przywództwo w Å›wiecie VUCA. Jak być skutecznym liderem w niepewnym Å›rodowisku 58,64 zÅ‚, (12,90 zÅ‚ -78%)
• Wieczne opóźnienie. ZarzÄ…dzanie projektami IT 58,64 zÅ‚, (12,90 zÅ‚ -78%)
• Szef, którego szukamy. Rzecz o odpowiedzialnoÅ›ci 58,64 zÅ‚, (12,90 zÅ‚ -78%)
• Scrum. O zwinnym zarzÄ…dzaniu projektami. Wydanie II rozszerzone 58,64 zÅ‚, (12,90 zÅ‚ -78%)
• Oprogramowanie szyte na miarÄ™. Jak rozmawiać z klientem, który nie wie, czego chce. Wydanie II rozszerzone 53,75 zÅ‚, (12,90 zÅ‚ -76%)

Spis treści

Inżynieria wymagań. Studium przypadków eBook -- spis treści

• OkÅ‚adka
• Strona tytuÅ‚owa
• Strona redakcyjna
• Spis treÅ›ci
• Od redaktorów
• Część I. Procesy i metody
  • 1. Planowanie i monitorowanie analizy
    • 1.1. WstÄ™p
    • 1.2. Projekt
    • 1.3. Problemy
    • 1.4. RozwiÄ…zanie
      • 1.4.1. Zaplanowanie podejÅ›cia do przeprowadzenia analizy biznesowej
      • 1.4.2. Zaplanowanie zaangażowania interesariuszy
      • 1.4.3. Planowanie zarzÄ…dzania analizÄ… biznesowÄ… i planowanie zarzÄ…dzania informacjami pozyskanymi w analizie biznesowej
      • 1.4.4. Identyfikacja usprawnieÅ„ w przebiegu analizy biznesowej
    • 1.5. Podsumowanie
  • 2. Od modelu do rozwiÄ…zania
    • 2.1. WstÄ™p
    • 2.2. Jak zapanować nad wymaganiami?
    • 2.3. O porażkach w projektowaniu systemów
    • 2.4. Propozycja
      • 2.4.1. NarzÄ™dzia
      • 2.4.2. Case study
      • 2.4.3. Dawno, dawno temu, czyli jak to drzewiej bywaÅ‚o
      • 2.4.4. Quo vadis World
      • 2.4.5. Tworzymy system
      • 2.4.6. Model rozwiÄ…zania systemowego
      • 2.4.7. Struktura modelu wymagaÅ„
      • 2.4.8. Przepis na powiÄ…zanie elementów zależnych w EA
      • 2.4.9. Przypadki użycia
      • 2.4.10. Åšledzenie zależnoÅ›ci
      • 2.4.11. Nie wyobrażaj sobie, zobacz
      • 2.4.12. Wykonaj z nami swój prototyp
    • 2.5. THE END
  • 3. Model modelowi nierówny, czyli Å‚amanie schematów w postrzeganiu modelowania procesów biznesowych w projektach firmy
    • 3.1. WstÄ™p
    • 3.2. Opis przypadku
    • 3.3. Problemy i wyzwania
    • 3.4. RozwiÄ…zanie problemu
      • 3.4.1. Wizualizacja procesu
      • 3.4.2. Model procesów podstawowych w notacji BPMN 2.0
      • 3.4.3. Proces wytwarzania wymagaÅ„
      • 3.4.4. Struktura zależnoÅ›ci zagadnieÅ„ i koncepcja zarzÄ…dzania projektem
    • 3.5. Rezultat
    • 3.6. Wnioski, zalecenia i rekomendacje
  • 4. Behaviour-Driven Development jako platforma komunikacji
    • 4.1. Wprowadzenie i cel rozdziaÅ‚u
    • 4.2. Domena jako fundament komunikacji
      • 4.2.1. Kruszenie wiedzy domenowej wÅ‚asnÄ… gÅ‚owÄ…
      • 4.2.2. Wspólny cel i model domenowy
    • 4.3. JÄ™zyk domenowy jako medium komunikacji
      • 4.3.1. Na poczÄ…tku byÅ‚ sÅ‚ownik
      • 4.3.2. Parafraza jako narzÄ™dzie do budowania zrozumienia
      • 4.3.3. WpÅ‚yw kultury pracy na komunikacjÄ™
    • 4.4. Komunikacja w rzeczywistym Å›rodowisku
      • 4.4.1. Zmiany widzÄ™ wszÄ™dzie zmiany!
      • 4.4.2. Wyjdź zza biurka analityk w terenie
    • 4.5. Przeniesienie komunikacji na wyższy poziom
      • 4.5.1. User Story jako format zapisu wymagaÅ„
      • 4.5.2. Jednoznaczne i czytelne testy kodu źródÅ‚owego
      • 4.5.3. Wykonywalna dokumentacja jako platforma komunikacji
    • 4.6. Podsumowanie
• Część II. Produkty prac
  • 5. Dokumentacja analityczna
    • 5.1. Dokumentacja byle jaka
      • 5.1.1. Przedmiot
      • 5.1.2. Problem
      • 5.1.3. RozwiÄ…zanie
      • 5.1.4. Zastosowane techniki
      • 5.1.5. Rezultaty
      • 5.1.6. Wnioski, zalecenia, rekomendacje
    • 5.2. Potrzebujemy tylko dokumentu
      • 5.2.1. Przedmiot
      • 5.2.2. Problem
      • 5.2.3. RozwiÄ…zanie
      • 5.2.4. Rezultat
      • 5.2.5. Wnioski, zalecenia, rekomendacje
    • 5.3. Dużo dokumentacji, maÅ‚o informacji
      • 5.3.1. Przedmiot
      • 5.3.2. Problem
      • 5.3.3. RozwiÄ…zanie
      • 5.3.4. Rezultat
      • 5.3.5. Wnioski, zalecenia, rekomendacje
    • 5.4. Wnioski wniosków
  • 6. Czy można byÅ‚o jeszcze coÅ› zepsuć?
    • 6.1. Przedmiot charakterystyka projektu/sytuacji i problemu do rozwiÄ…zania
    • 6.2. Stosowane definicje
    • 6.3. Opis zlecenia, terminy realizacji i otoczenie projektu
      • 6.3.1. IstniejÄ…ca aplikacja
      • 6.3.2. Stan udokumentowania wymagaÅ„ do obsÅ‚ugi urzÄ…dzeÅ„
      • 6.3.3. Wiedza merytoryczna zespoÅ‚u o zagadnieniu i wspieranych procesach u klienta
      • 6.3.4. Zespół
      • 6.3.5. OdpowiedzialnoÅ›ci poszczególnych ról w zespole
      • 6.3.6. ZamawiajÄ…cy
    • 6.4. Przebieg procesu analizy i powstaÅ‚e produkty w pierwszej fazie przed wstrzymaniem projektu
    • 6.5. Problemy, przed którymi stanÄ™liÅ›my
      • 6.5.1. Przekonanie, że wszystko jest gotowe, wystarczy zaimplementować
      • 6.5.2. Przeterminowane wymagania, brak wÅ‚aÅ›cicieli wymagaÅ„, zdefiniowanych interesariuszy
      • 6.5.3. Skupiono siÄ™ na szczegółach, pominiÄ™to główne zaÅ‚ożenia
      • 6.5.4. Nie zostaÅ‚ rozpoznany proces biznesowy klienta
      • 6.5.5. Duży zakres dostarczanych usÅ‚ug bez podziaÅ‚u na etapy realizacji. Trudność estymacji pozostaÅ‚ych prac
      • 6.5.6. PozostaÅ‚e problemy
    • 6.6. RozwiÄ…zanie podejÅ›cia, techniki i technologie, jakie wykorzystaliÅ›my w projekcie, by rozwiÄ…zać problem i zrealizować postawiony cel
      • 6.6.1. Ankiety
      • 6.6.2. Eksperci dziedzinowi, weryfikacja rozwiÄ…zaÅ„ i kontakt z klientem
      • 6.6.3. Lista wymagaÅ„
      • 6.6.4. PseudouporzÄ…dkowana logika biznesowa aplikacji
      • 6.6.5. Lista usÅ‚ug aplikacji
      • 6.6.6. PodziaÅ‚ na etapy i usÅ‚ugi dodatkowe
    • 6.7. Rezultat
    • 6.8. Wnioski, zalecenia i rekomendacje
• Część III. Zespół i umiejÄ™tnoÅ›ci miÄ™kkie
  • 7. Janusze analityki. Czy warto być samotnym wilkiem w zespole?
    • 7.1. Wprowadzenie
    • 7.2. Samotny wilk
    • 7.3. Zespół nadchodzi z odsieczÄ…
    • 7.4. Chaos: razem, ale osobno
    • 7.5. Konsekwencje
  • 8. Wprowadzanie Scruma problemy i korzyÅ›ci
    • 8.1. WstÄ™p
    • 8.2. O teorii autodeterminacji
    • 8.3. Praca w Scrumie
      • 8.3.1. Samoorganizacja zespoÅ‚u autonomia
      • 8.3.2. RozwiÄ…zanie
      • 8.3.3. Sens pracy i trudność wykonywanych zadaÅ„
      • 8.3.4. RozwiÄ…zanie
      • 8.3.5. Poczucie kompetencji ciÄ…gÅ‚y rozwój
      • 8.3.6. Możliwość wpÅ‚ywania na produkt
      • 8.3.7. RozwiÄ…zanie
      • 8.3.8. Relacje z innymi potrzeba przynależnoÅ›ci
      • 8.3.9. Współpraca a rywalizujÄ…ce Zosie samosie
      • 8.3.10. RozwiÄ…zanie
      • 8.3.11. Rola relacji z użytkownikami
      • 8.3.12. RozwiÄ…zanie
    • 8.4. Podsumowanie
  • 9. Outsourcing analizy. Jak siÄ™ przygotować
    • 9.1. Przedmiot charakterystyka projektu i problemu do rozwiÄ…zania
    • 9.2. Problemy, rozwiÄ…zanie i rezultat
      • 9.2.1. Koordynacja zależnoÅ›ci prac analitycznych
      • 9.2.2. Komunikacja w zespole
      • 9.2.3. NarzÄ™dzie CASE do modelowania
      • 9.2.4. Wspólne szablony wymagaÅ„
      • 9.2.5. Repozytorium. Gdzie przechowywać dokumenty?
      • 9.2.6. Odbiór produktów analitycznych
    • 9.3. Wnioski, zalecenia i rekomendacje
  • 10. Coaching w analizie
    • 10.1. WstÄ™p
      • 10.1.1. Coach i coaching
    • 10.2. Role w coachingu
      • 10.2.1. Coach
      • 10.2.2. Klient coachingu (inaczej: coachee)
      • 10.2.3. Sponsor coachingu
    • 10.3. Elementy coachingu
    • 10.4. Model coachingowy
    • 10.5. Przebieg procesu coachingowego
    • 10.6. UmiejÄ™tnoÅ›ci coachingowe
      • 10.6.1. Aktywne sÅ‚uchanie
      • 10.6.2. Pytania siÄ™gajÄ…ce sedna
      • 10.6.3. Ćwiczenie
      • 10.6.4. BezpoÅ›rednia komunikacja
      • 10.6.5. Ćwiczenie
      • 10.6.6. Obecność
      • 10.6.7. Ćwiczenie
      • 10.6.8. Tak, i 
      • 10.6.9. Ćwiczenie
    • 10.7. PodejÅ›cie coachingowe
• Część IV. Ewolucja
  • 11. Projektowanie nastawione na zmianÄ™
    • 11.1. WstÄ™p
    • 11.2. Ewolucja systemów informatycznych
    • 11.3. Inżynieria wymagaÅ„ w kontekÅ›cie ewolucji systemów
    • 11.4. Inżynieria wymagaÅ„ wspierajÄ…ca ewolucjÄ™ systemów
      • 11.4.1. Model CoRE
      • 11.4.2. Metody statystyczne
      • 11.4.3. Przewidywanie przyszÅ‚oÅ›ci
      • 11.4.4. Cztery podejÅ›cia do wymagaÅ„
      • 11.4.5. Wymagania w systemach eksperckich
      • 11.4.6. Podsumowanie metod
    • 11.5. Projektowanie nastawione na zmianÄ™
      • 11.5.1. Wiedza domenowa
      • 11.5.2. ModuÅ‚owość rozwiÄ…zaÅ„
      • 11.5.3. Uniwersalne interfejsy
      • 11.5.4. Konfigurowalność
      • 11.5.5. MyÅ›lenie o przyszÅ‚oÅ›ci
    • 11.6. Podsumowanie
• Bibliografia
• Przypisy
• O autorach