ISTQB w pigułce
  • ISTQB w pigułce
  • AUTOR
  • PODSTAWY
    • Proces testowy
    • Testowanie a debagowanie
    • 7 zasad testowania
    • Weryfikacja i walidacja
    • Środowisko testowe a produkcyjne
    • Wymagania funkcjonalne niefunkcjonalne
  • ROLA TESTERA
    • Typy testerów
    • Tester
    • Zadania testera
      • Analiza dokumentacji
      • Tworzenie dokumentacji
      • Wykonywanie testów
      • Raportowanie incydentów
    • Nawyki skutecznego testera
    • Role w zespole testerów
    • Niezależność w testowaniu
  • PRZYPADEK TESTOWY
    • Przypadek testowy niskiego poziomu (konkretny)
    • Przypadek testowy wysokiego poziomu (logiczny)
    • Przegląd przypadku testowego
  • TYPY TESTÓW
    • Testowanie funkcjonalne
    • Testowanie niefunkcjonalne
    • Testowanie strukturalne (białoskrzynkowe)
    • Testowanie związane ze zmianami - testy regresji i retesty
    • Testowanie pielęgnacyjne
  • TECHNIKI TESTÓW
    • CZARNOSKRZYNKOWE
      • 1. Klasy równoważności
      • 2. Analiza wartości brzegowych
      • 3. Tablice decyzyjne
      • 4. Testowanie przejść między stanami
      • 5. Testowanie w oparciu o przypadki użycia
    • BIAŁOSKRZYNKOWE
      • 1. Pokrycie instrukcji
      • 2. Pokrycie decyzji
      • 3. Inne techniki oparte na strukturze
    • OPARTE NA DOŚWIADCZENIU
      • Zgadywanie błędów
      • Testowanie eksploracyjne
      • Testowanie w oparciu o listy kontrolne
  • POZIOMY TESTÓW
    • POZIOM 1. Testy modułowe (jednostkowe)
    • POZIOM 2. Testy integracyjne
    • POZIOM 3. Testy systemowe
    • POZIOM 4. Testy akceptacyjne
      • Testy Alfa, Beta
  • MODELE
    • Model wodospadowy
    • Model V – sekwencyjny.
    • Model iteracyjny / przyrostowy
  • PLANOWANIE TESTÓW
    • Kryteria wejścia - wyjścia
    • Podejścia do testów
    • Podejścia do szacowania pracochłonności testów
    • Metryki
    • Ryzyko projektowe/produktowe
    • Kierowanie testami
  • TESTY STATYCZNE
    • PRZEGLĄD
      • TYPY przeglądów
      • PODZIAŁ podstawowy
      • Przegląd formalny
      • Przegląd nieformalny
    • Analiza statyczna
    • TECHNIKI przeglądu indywidualnego
      • Listy kontrolne
  • NARZĘDZIA
    • Do zarządzania testowaniem i testami
    • Do testów statycznych
    • Do specyfikacji testów
    • Do wykonania testów oraz logowania
    • Do wydajności i monitorowania
    • Do różnych obszarów zastosowań
  • METODY WYTÓRCZE
    • METODY WYTWÓRCZE
      • Projekt - Proces - Działania rutynowe
        • Projekt
        • Dlaczego projekty upadają?
      • Etapy życia oprogramowania
      • PDCA
      • Planowanie
        • Analiza i specyfikacja wymagań
        • Planowanie projektu - metodyki KLASYCZNE
        • Planowanie projektu - metodyki ZWINNE
        • Ryzyko a niepożądane skutki
      • Narzędzia planowania - SMART - MoSCow...
        • SMART
        • Mapa myśli
        • MoSCoW
        • WSJF
        • Trójkąt celów
      • Role projektowe
        • Role projektowe – metodyki klasyczne
        • Role projektowe – SCRUM
    • AGILE - METODYKI ZWINNE
      • Manifest Agile
      • Podejście "cały zespół" i info zwrotne
      • Historyjki użytkownika
      • Planowanie wydania i iteracji
      • RETROSPEKTYWY
      • Rola i umiejętności testera w projekcie zwinnym
      • PODEJŚCIA
        • Programowanie ekstremalne (XP)
        • Test-driven development (TDD)
        • Scrum
        • Kanban
    • SCRUM
      • Szacowanie czasochłonności
    • KANBAN
  • Linki
    • e-Olak.pl
  • POLITYKA PRYWATNOŚCI
    • PRAWA AUTORSKIE
      • GitHub
Powered by GitBook
On this page
  • Specyfikacja wymagań
  • WIZJA
  • Kartka z przyszłości
  • Perspektywy analizy wymagań - oprogramowanie
  • Planowanie projektu – mapa drogowa projektu
  • Program Increment - PRZYKŁAD
  • Perspektywy analizy:

Was this helpful?

  1. METODY WYTÓRCZE
  2. METODY WYTWÓRCZE
  3. Planowanie

Analiza i specyfikacja wymagań

PreviousPlanowanieNextPlanowanie projektu - metodyki KLASYCZNE

Last updated 4 years ago

Was this helpful?

Specyfikacja wymagań

Jeżeli funkcje nowej aplikacji/serwisu stron WWW/rozwiązania są w pełni określone, a wymagania kompletne wówczas analityk wspólnie z klientem opracowuje specyfikację wymagań.

Jeżeli jest możliwe (lub konieczne) opracowanie pełnej specyfikacji wymagań to projekt może zostać zrealizowany z pomocą metodyk klasycznych (waterfall).

WIZJA

  • opisuje stan rozwiązania, które zostanie opracowane.

  • odzwierciedla potrzeby interesariuszy, a także funkcje i cechy niezbędne dla realizacji tych potrzeb.

  • odnosi się do stanu docelowego, ale jest osiągalna w określonym czasie.

  • motywuje i angażuje poprzez odwołanie do celów strategicznych biznesu i aspiracji zespołów.

Ludzie w pracy potrzebują kontekstu, pragnąc zrozumieć do czego wnoszą wkład jako większej całości

Daniel Pink

Kartka z przyszłości

Perspektywy analizy wymagań - oprogramowanie

  • Zakres funkcji systemu (problemy, które chcemy rozwiązać),

  • Architektura systemu,

  • Technologie IT wykorzystane w projekcie (systemy operacyjne, bazy danych, języki programowania, dodatkowe narzędzia i biblioteki),

  • Mechanizmy wymiany/przesyłania danych,

  • Etapy realizacji systemu,

  • Zasoby ludzkie niezbędne do zaprojektowania, wytworzenia, wdrożenia i utrzymania systemu,

  • Interesariusze projektu,

  • Czynniki ryzyka mające wpływ na projekt,

  • Infrastruktura niezbędna do działania systemu, — Wymagania niefunkcjonalne (np. odnoszące się do jakości, intuicyjności, stabilności, wydajności, bezpieczeństwa, itp.),

  • Możliwe alternatywy dla przyjętych założeń,

  • Inne – istotne dla projektu.

Planowanie projektu – mapa drogowa projektu

Aby zrealizować produkt zgodny ze zdefiniowaną wizją należy wydzielić podsystemy lub wskazać kluczowe obszary funkcjonalne.

Definiując możliwości (grupy funkcjonalne) należy pamiętać, że muszą one służyć wizji.

Mapa drogowa projektu powstaje poprzez zebranie cech i pogrupowanie ich w tzw. Program Increment (PI). Program Increment trwa 5 Sprintów.

Program Increment - PRZYKŁAD

Perspektywy analizy:

Wymagania funkcjonalne

  • Jakie funkcje powinno realizować nasze rozwiązanie?

Dla swojej mapy myśli sprawdź, czy funkcjonalności zostały zebrane w grupy funkcji. Funkcjonalności decydują o algorytmach przetwarzania danych.

Wymagania niefunkcjonalne

Jakie cechy powinno mieć projektowane rozwiązanie?

Dla swojej mapy myśli sprawdź, czy zostały określone grupy wymagań niefunkcjonalnych. Wymagania niefunkcjonalne decydują o architekturze rozwiązania.

Program Increment – 10 najważniejszych funkcji

Aby ustalić priorytety, zespół odpowiedzialny za zarządzanie produktem nadaje priorytety (np. lub )

https://en.wikipedia.org/wiki/Non-functional_requirement
MoSCoW
WSJF