Category Archives inżynier wymagań

Zmiany w wymaganiach wymaga ich wersjonowania.Wersje wymagań pomagają uzyskać dostęp do określonego stanu wymagania w trakcie życia oprogramowania. Najczęściej wersje wymagań określane są za pomocą kolejnych ich numerów. Najbardziej popularnym sposobem nadawania numerów wymagań jest złożenie numeru z wersji wymagania oraz przyrostu, oddzielonych znakiem kropki. Wersja 1.3 oznacza wtedy 1 wersję wymagania i 3 przyrost.

Trakcie życia oprogramowania zmiany wymagań są nieuniknione. Powodem zmian w wymaganiach mogą być wykryte błędy, nowe lub zmienione cele interesariuszy, zmiany prawne, udostępnienie nowych technologii, czy zmiany na rynku, w którym funkcjonuje organizacja klienta.

Zmiany w wymaganiach same w sobie nie są negatywne i mogą świadczyć o dużym zainteresowaniu interesariuszy tworzonym lub wdrożonym systemem.

Natomiast jeżeli zmiany do wymagań zgłaszane są zbyt często, to rozwój systemu, który będzie spełniał wymagania wszystkich interesariuszy jest praktycznie niemożliwy. Zbyt częste zgłaszanie zmian wskazuje na niewłaściwie przeprowadzone czynności w ramach inżynierii wymagań (akwizycję, dokumentację, walidację i negocjację).

Ważnym aspektem zarządzania wymaganiami jest możliwość zapewnienia śledzenia związków pomiędzy wymaganiami a innymi artefaktami (również innymi wymaganiami). Możliwość śledzenia relacji wspomaga proces tworzenia oprogramowania w następujących aspektach:

  • Sprawdzalność: Śledzenie relacji pomiędzy wymaganiami a innymi artefaktami pozwala na weryfikację, czy dane wymagania zostały zaimplementowane.
  • Identyfikacja pozłacanych rozwiązań w systemie: Śledzenie powiązań wymagań pozwala na identyfikację tzw. „pozłacanych” rozwiązań w tworzonym systemie, które identyfikują niepotrzebne właściwości tworzonego systemu.
  • Identyfikacja pozłacanych rozwiązań w wymaganiach: Śledzenie powiązań wymagań pozwala na zidentyfikowanie wymagań, które nie wpływają na realizację celów interesariuszy oraz nie są związane z żadnym źródłem.
  • Wpływ na analizę: Analiza relacji wymagań pozwala na analizę wpływu zmian w wymaganiach. Pozwala na zidentyfikowanie artefaktów, na które zmiana w wymaganiu będzie miała wpływ.
  • Ponowne użycie: Możliwość ustalenia powiązanych artefaktów z danym wymaganiem, pozwala na zidentyfikowanie artefaktów, które będą mogły być ponownie wykorzystane przy kolejnym projekcie, w którym wystąpi takie samo lub podobne wymaganie.
  • Zdolność obliczeniowa: Po implementacji wymagania istnieje możliwość prześledzenia wytworzonych artefaktów powiązanych z danym wymaganiem i na tej podstawie obliczenie pracochłonności implementacji tego wymagania.
  • Zarządzanie: Możliwość śledzenia powiązań wymagań pozwala na sprawniejsze zarządzanie tworzonym systemem. Na przykład w przypadku wykrycia błędu identyfikacja powiązań pomiędzy danym artefaktem a wymaganiami i innymi artefaktami pozwala na wstępne oszacowanie kosztów usunięcia błędu.

Dziś czas na opisanie technik nadawania priorytetów. Możemy je nadawać stosując szereg technik. Oto one.

Ranking

Technika rankingu polega na określaniu przez wybraną grupę interesariuszy dostępnych priorytetów dla wymagań według przyjętych kryteriów.

Top-Ten

Technika Top-Ten polega na wybraniu przez interesariuszy n najbardziej ważnych wymagań określonych według przyjętych kryteriów. Dla tych wymagań określanych jest ich ranking opisujący ważność wymagań z uwzględnieniem określonych kryteriów.

Dokumentowanie informacji o wymaganiach w sposób strukturalny pozwala na zapewnienie, że żadne potrzebne dane nie zostaną pominięte oraz zapewnia możliwość łatwego dotarcia przez analizującego wymagania do informacji mu potrzebnych.

Jednym ze sposobów strukturalnego dokumentowania wymagań jest przypisanie wymaganiom atrybutów mających określone znaczenie oraz ustalone możliwe wartości. Aby umożliwić jednolity strukturalny opis wymagań należy w projekcie stosować jeden schemat dla danego typu wymagań (funkcjonalnych, jakościowych, ograniczeń) zawierający definicję atrybutu, jego opis oraz możliwe wartości dla tego atrybutu. Zawartość atrybutów w schemacie powinna być dostosowana do aktualnie realizowanego projektu.

W zależności od wykorzystywanych narzędzi atrybuty wymagań mogą być określane w postaci tabeli lub formatek udostępnianych przez narzędzie wspierające inżynierię wymagań.

Jak pisałem kilka tygodni temu jakość wymagań przekłada się na jakość systemu. Z tego też powodu istotnym jest aby doprecyzować – wynegocjować te wymagania, które mogą destruktywnie wpłynąć na działanie systemu. Poniżej kilka porad (zasad) dla inżyniera wymagań.

Identyfikacja konfliktów

Konflikty mogą się pojawiać podczas wszystkich czynności podejmowanych podczas inżynierii wymagań. Konflikty pomiędzy wymaganiami i interesariuszami często nie są oczywiste. W związku z tym inżynierowie wymagań powinni zwrócić szczególną uwagę możliwość wystąpienie konfliktów wymagań, żeby mogły być zidentyfikowane i rozwiązane we wczesnych etapach.

Walidacja wymagań zazwyczaj odbywa się przez ich recenzję. Można wyróżnić trzy podstawowe techniki dla recenzji:

  • Komentowanie
  • Inspekcja
  • Spacer przez

Walidację wymagań poprzez recenzję można uzupełnić za pomocą technik:

  • Czytania perspektywicznego
  • Walidacji przez prototypy
  • List kontrolnych

Komentowanie

Komentowanie polega na przekazaniu wymagań przez ich autora do innych osób zaangażowanych w projekt celem uzyskania ekspertyzy wymagania dotyczącej jego jakości. Recenzenci analizują wymagania pod kątem problemów powodujących obniżenie jakości wymagania (np. niejednoznaczność).

Walidacja wymagań wymaga kilku czynników. Dziś przedstawię kilka zasad.

Zaangażowanie odpowiednich interesariuszy

Podczas wyboru interesariuszy do walidacji wymagań należy mieć na uwadze, aby wymagania nie były walidowane jedynie przez ich autorów. Można także rozważyć zatrudnienia do walidacji wymagań zewnętrznych audytorów, przy czym należy mieć na uwadze, że zatrudnienie zewnętrznych audytorów znacząco może podnieść koszty inżynierii wymagań. W związku z tym należy rozważać tą opcję w przypadku wymagań krytycznych i wymagają wysokiego poziomu jakości.

Po wakacyjnej przerwie wznawiam cykl artykułów dotyczących inżynierii wymagań. Tak jak przed wakacjami teksty będą pojawiać się co środę.

Walidacja i negocjacja wymagań służą przede wszystkim do poprawy ich jakości. Negocjacja i walidacja wymagań powinna być przeprowadzana podczas całego procesu inżynierii wymagań. Aby zapewnić możliwość systematycznej walidacji wymagań muszą zostać określone kryteria jakościowe pozwalające na określenie jakości tych wymagań.

Walidacja wymagań

Podczas walidacji wymagań należy określić, czy zdefiniowane wymagania posiadają wymagany poziom jakości oraz czy wymagania te mogą zostać zatwierdzone do dalszego wykorzystania w kolejnych fazach cyklu życia oprogramowania (np. projektowania, implementacji, czy testowania). Celem walidacji wymagań jest wykrycie potencjalnych błędów w dokumentacji wymagań. Do błędów tych mogą należeć niejednoznaczność, niekompletność lub sprzeczność z innymi wymaganiami.

W trakcie trwania projektu dokumentacja wymagań stanowi podstawę dla różnych zadań: Planowanie: Specyfikacja wymagań stanowi podstawę dla planowania pracy i punktów milowych w procesie tworzenia oprogramowania. Projektowanie architektury: Szczegółowy dokument wymagań, zawierający opis ograniczeń, stanowi podstawę dla projektowania architektury systemu. Implementacja: Podczas implementacji systemu (zgodnie z zaprojektowaną architekturą) deweloperzy wykorzystują specyfikację wymagań do implementacji rozwiązań zgodnych z wymaganiami klienta. Testowanie:…

Close