Wymagania Funkcjonalne

31 lipca, 2021 przez Stary Zgred

Wymagania Funkcjonalne

Większość osób formułujących wymagania po stronie biznesu na etapie Projektu skupia sowią uwagę na wymaganiach typu:
– Chcę aby system robił ….. i tu lista określonych funkcji.
– Chcę raportować z systemu ilości … i tu lista ważnych lub mniej ważnych wielkości,
– No i oczywiście raport ma mieć następującą strukturę ….

Oczywiście takich przykładów można podać więcej, a i tak pomysłowość ludzka przerośnie moje wyliczanki 🙂.
Takie wymagania określa się mianem Wymagań funkcjonalnych.
O niefunkcjonalizowanych będzie później, bo i Biznes zazwyczaj myśli o nich już po uruchomieniu 🙁.

Przetwarzanie

Każde z tych wymagań jest faktycznie Procesem, większym lub mniejszym. Zawsze taką samą strukturę, którą w największej ogólności można opisać w trzech krokach:

• Weź dane
• Przetwórz dane wejściowe
• Zaprezentuj wynik przetwarzania

Oczywiście każdy z tych kroków może mieć wiele różnych sposobów realizacji. Dodatkowo każdy z kroków może składać się z pod-procesów i tak dalej.

Struktura Drzewa

Opisując rozwiązania informatyczne, strukturę ich kosztów itp… zawsze trafimy na strukturę drzewa 😳.

Pojęcie drzewa już się pojawiło przy okazji opisu sposobu działania usługi WWW. A ogólnie sformułowane funkcji dla przeglądarki – wyświetlanie strony o adresie, kroki w tym przypadku są oczywiste … 🙂.
Dane – to adres strony,
Przetworzenie to pobranie zawartości i wszystkie akcje z tym związane,
I oczywiście prezentacja na ekranie 🙂.

Dekompozycja

Osoby tworzące rozwiązania informatyczne, muszą rozumieć co autor Wymagania chciał przekazać/osiągnąć poprzez określone sformułowania.
Zazwyczaj jest to proste 😛.
Czasami jednak konieczne są dodatkowe pytania, aby zdekomponować wymaganie na elementarne funkcje techniczne.

Zazwyczaj użytkownik nie ma pojęcia i oczywiście mieć nie musi znać aspektów technicznych.
Użytkownik Internetu nie musi wiedzieć, że następuje zmiana nazwy na adres IP .

Dlatego też duże znaczenie ma kompetencja osoby tłumaczącej Biznes na Technikę i odwrotnie:-). Może to odbyć się sprawnie lub powodować długie dyskusje co oznacza dane sformułowanie. W najgorszym przypadku może powstać rozwiązanie, które jest dalekie od oczekiwań.

To nie jest wyjątek 🙁

Dlaczego Problem

Jeżeli zdarzy się taka sytuacja i wykryjemy ją na etapie testów to musimy ponieś dodatkowe koszty usunięcia tego błędu.
Największy problem to czas, kasa zazwyczaj na dalszym miejscu 🙁.

Wykrycie tego dopiero w działającym systemie to już może być bardzo duży problem 👿 👿 …
Musimy zachować ciągłość procesów. a to jak zmiana lokomotywy w pędzącym pociągu 😳.

W jaki sposób minimalizować ryzyku takich sytuacji to duży temat więc będzie on poruszany wielokrotnie.

Przykłady wymagań funkcjonalnych w następnym wpisie. Zapraszam 🙂.

Komentarze |0|