top of page
  • Zdjęcie autoraKarolina Zmitrowicz

Skąd brać wymagania? Interesariusze to tylko jedna opcja.

Dość często pojawia się pytanie - skąd czerpać wymagania? Oczywiście, pierwszą pojawiającą się myślą będzie: od interesariuszy. To oczywiste, że nasi interesariusze stanowią w wielu przypadkach kluczowe źródło wymagań dla projektu. Wymagania możemy pozyskiwać od interesariuszy, stosując różnorodne techniki, takie jak na przykład wywiad czy techniki współpracy, wśród których wiodącą rolę odgrywa warsztat.

Jednak źródła wymagań nie ograniczają się tylko do interesariuszy. Oprócz nich istnieje cały szereg innych możliwych źródeł wymagań. Wymagania można czerpać z dokumentacji lub z innych istniejących systemów. Najogólniej źródeł wymagań szukamy w kontekście, inaczej otoczeniu systemu. Elementem kontekstu systemu są: interesariusze, systemy, z którymi nasz system integruje się, regulacje, przepisy, standardy, czy procesy biznesowe, które nasz system ma wspierać.

W zależności od rodzaju systemu, pewne źródła mogą mieć kluczowe znaczenie. I to wcale niekoniecznie interesariusze typu użytkownik końcowy muszą być głównym źródłem wymagań, tak jak to wielu analityków uważa. W przypadku niektórych systemów, działających w środowiskach silnie regulowanych, podstawowym źródłem wymagań mogą być standardy i regulacje - czyli dokumentacja. W takim przypadku pozyskiwanie wymagań opiera się na technikach opartych na artefaktach, poprzez systematyczne wyodrębnianie wymagań z właściwych dokumentów.

Innymi dokumentami, z których można pozyskać wymagania, są:

  • Dokumenty opisujące procesy biznesowe, które nasz system ma wspierać.

  • Dokumentacja celów biznesowych i strategii firmy.

  • Specyfikacja wymagań podobnych systemów.

  • Ogólnie przyjęte standardy i regulacje dotyczące danego obszaru biznesowego.

  • Raporty z badań rynkowych, dzięki którym możemy pozyskać informacje o potrzebach biznesowych.

Warto również mieć na uwadze, że proces pozyskiwania informacji obejmuje nie tylko pozyskiwanie wymagań, lecz także określanie ograniczeń oraz innych istotnych informacji niezbędnych do ustalenia ostatecznego zakresu naszego rozwiązania.

Dokumentacja stanowi jedno z źródeł wymagań, kolejnym są systemy. Systemy, z którymi nasz projekt się integruje, a także systemy konkurencji, które mogą stanowić inspirację dla naszego rozwiązania. Niekoniecznie musimy tworzyć wszystkie wymagania od nowa, istniejące na rynku systemy bardzo często rozwiązują problemy, które nasz system ma rozwiązać. W takim przypadku wymyślanie koła od nowa może okazać się co najmniej stratą czasu.

Warto również zwrócić uwagę na to, że analiza rozwiązań konkurencyjnych może dostarczyć cennych wskazówek dotyczących potencjalnych właściwości, jakie nasz system powinien posiadać. Te dodatkowe właściwości mogą uzupełnić te, które były pierwotnie zdefiniowane. Oczywiście, minimalnym warunkiem koniecznym do zastosowania tego podejścia jest znajomość rynku i wiedza o podobnych rozwiązaniach. Warto więc nie zamykać się tylko i wyłącznie na swój własny projekt i kontekst projektowy.

Podsumowując, podobnie jak w przypadku pozyskiwania wymagań, nie chodzi tylko o zadawanie pytań klientowi. Istnieje wiele innych źródeł, które warto uwzględnić, planując nasze działania związane z pozyskiwaniem wymagań.


38 wyświetleń0 komentarzy
Post: Blog2_Post
bottom of page