O wymaganiach Kilka słów o wymaganiach w projektach informatycznych

3lis/090

Listy kontrolne dla wymagań

Po co nam listy kontrolne?

Zapisywanie wymagań, analiza problemu i rozwiązania wymaga często dużego skupienia oraz sporej ilości czasu - najlepiej jeśli uda nam się skoncentrować na kilka godzin i ze spokojem przelać na papier nasze myśli. Wiadomo - taka praca jest najefektowniejsza, szczególnie jeśli chodzi o czas, ma ona jednak również swoje wady - często zapominamy o niektórych istotnych informacjach, dochodzi do przeoczeń spraw oczywistych, skupiamy się wyłącznie na jednym aspekcie problemu, zapominając o pozostałych. Co wtedy zrobić? Jednym z rozwiązań jest skorzystanie z list kontrolnych (ang. checklist), które zawierają elementy, na które należy zwrócić uwagę przy swojej pracy (w naszym wypadku przy zapisywaniu wymagań). Listy takie mogą być wykorzystywane zarówno przez samych autorów dokumentów, jak również podczas zespołowych przeglądów (nie należy wówczas jednak ograniczać się jedynie do list kontrolnych).

Jak stworzyć listę kontrolną?

Powstaje pytanie skąd wziąć taką listę kontrolną? Najlepszym rozwiązaniem jest stworzenie listy przez siebie samego (lub wewnątrz zespołu/firmy) na podstawie zdobytego doświadczenia (sami wiemy najlepiej czego brakowało dokumentom w poprzednich projektach). Jako, że trudno jest zacząć tworzyć taką listę od podstaw, można na początku skorzystać w list już gotowych (np rozsianych po internecie -  tutaj, tutaj lub tutaj), które później poszerzamy o zdobyte przez nas doświadczenia. Należy jednak pamiętać o tym, że listy kontrolne powinny mieć rozsądną długość, gdyż zbyt duża liczba reguł powoduje, że lista staje się trudna do czytania i utrzymania, zatem jeśli widzisz, że któryś z punktów w Twojej specyfikacji wymagań jest zawsze spełniony to ze spokojem możesz go usunąć z listy.

Podstawowa lista kontrolna dla wymagań

Co powinno się znaleźć w każdej liście kontrolnej dla wymagań?

  • Czy wymagania są spójne? Czy żadne z wymagań nie zaprzecza innemu? Czy wszystkie terminy używane są zawsze w tym samym znaczeni?
  • Czy wymagania są kompletne? Czy występują sformułowania typu TBD (ang. to be determined)?
  • Czy każdemu wymaganiu nadany jest odpowiedni priorytet?
  • Czy wymagania są weryfikowalne?
  • Czy w wymaganiach pojawiają się elementy rozwiązania (np. szczegóły implementacji)?
  • Czy określone są założenia i zależności?
  • Czy nie występuje redundancja wymagań?
  • Czy wszystkie odnośniki są poprawne i aktualne?
  • Czy zostały wyspecyfikowane zarówno wymagania funkcjonalne jak i pozafunkcjonalne?
  • Czy każde wymaganie jest wyrażone w sposób precyzyjny?
  • Czy każde wymaganie jest wyrażone w sposób jednoznaczny?
  • Czy każde wymaganie wchodzi w zakres problemu?
  • Czy opisani są aktorzy systemu?
  • Czy opisani są użytkownicy końcowi systemu?
  • Czy wskazane jest źródło dla każdego wymagania?
  • Czy każde wymaganie ma nadany indywidualny identyfikator?
  • Czy każde zadanie jest możliwe do zapewnienia?
  • Czy jest (aktualny i poprawny) słownik terminów i skrótów?

A Wy korzystacie przy swojej pracy z list kontrolnych?

Podziel się:
  • Google Bookmarks
  • Twitter
  • del.icio.us
  • Wykop
  • Digg
  • Facebook
  • LinkedIn
  • StumbleUpon
  • FriendFeed
Komentarze (0) Trackbacks (0)

Brak komentarzy.


Dodaj komentarz


Brak trackbacków.

Get Adobe Flash playerPlugin by wpburn.com wordpress themes