Dokument wymagań funkcjonalnych
Dokument wymagań funkcjonalnych (FRD) to formalne zestawienie wymagań funkcjonalnych aplikacji. Służy temu samemu celowi co umowa. W tym przypadku programiści zgadzają się zapewnić określone możliwości. Klient zgadza się uznać produkt za zadowalający, jeśli zapewnia możliwości określone w FRD.
Wymagania funkcjonalne odzwierciedlają zamierzone zachowanie systemu. Takie zachowanie może być wyrażone jako usługi, zadania lub funkcje, które system ma wykonać. Dokument powinien być dostosowany do potrzeb konkretnego projektu. Definiują takie rzeczy, jak obliczenia systemowe, manipulowanie i przetwarzanie danych, interfejs użytkownika i interakcja z aplikacją.
Dokument wymagań funkcjonalnych (FRD) ma następujące cechy -
Pokazuje, że aplikacja zapewnia wartość pod względem celów biznesowych i procesów biznesowych w ciągu najbliższych kilku lat.
Zawiera pełen zestaw wymagań dla aplikacji. Nie pozostawia nikomu miejsca na przyjęcie czegokolwiek, co nie zostało określone w FRD.
Jest niezależny od rozwiązania. ERD jest oświadczeniem o tym, co ma zrobić aplikacja, a nie jak to działa. FRD nie zobowiązuje programistów do projektowania. Z tego powodu jakiekolwiek odniesienie do użycia określonej technologii jest całkowicie nieodpowiednie w FRD.
Wymóg funkcjonalny powinien obejmować:
Opisy data do wprowadzenia do systemu
Opisy operations wykonywane na każdym ekranie
Opisy work-flows wykonywane przez system
Opisy system reports lub inne wyjścia
Kto może wejść do data do systemu?
Spełnienie systemu ma zastosowanie regulatory requirements?
Specyfikacja funkcjonalna jest przeznaczona do czytania przez wszystkich odbiorców. Czytelnicy powinni rozumieć system, ale do zrozumienia tego dokumentu nie jest wymagana wiedza techniczna.
Elementy dostarczane w zakresie wymagań funkcjonalnych
Dokument wymagań biznesowych (BRD) składa się z -
Functional Requirements- Dokument zawierający szczegółowe wymagania dotyczące opracowywanego systemu. Wymagania te definiują cechy funkcjonalne i możliwości, które musi posiadać system. Upewnij się, że wszelkie założenia i ograniczenia zidentyfikowane podczas uzasadnienia biznesowego są nadal dokładne i aktualne.
Business Process Model - Model aktualnego stanu procesu (model „jak jest”) lub koncepcja tego, czym proces powinien się stać (model „być”)
System Context Diagram - Diagram kontekstowy pokazuje granice systemu, elementy zewnętrzne i wewnętrzne, które oddziałują z systemem, oraz odpowiednie przepływy danych między tymi podmiotami zewnętrznymi i wewnętrznymi.
Flow Diagrams (as-is or to-be)- Diagramy graficznie przedstawiają sekwencję operacji lub przepływ danych dla procesu biznesowego. W zależności od złożoności modelu dołączony jest jeden lub więcej diagramów przepływu.
Business Rules and Data Requirements - Reguły biznesowe definiują lub ograniczają niektóre aspekty działalności i służą do definiowania ograniczeń danych, wartości domyślnych, zakresów wartości, liczności, typów danych, obliczeń, wyjątków, wymaganych elementów oraz integralności relacyjnej danych.
Data Models - Diagramy powiązań encji, opisy encji, diagramy klas
Conceptual Model - Przedstawianie na wysokim poziomie różnych podmiotów dla funkcji biznesowej i ich wzajemnych relacji.
Logical Model - Ilustruje konkretne jednostki, atrybuty i relacje związane z funkcją biznesową i przedstawia wszystkie definicje, cechy i relacje danych w środowisku biznesowym, technicznym lub koncepcyjnym.
Data Dictionary and Glossary - Zbiór szczegółowych informacji o elementach danych, polach, tabelach i innych jednostkach, które składają się na model danych stanowiący podstawę bazy danych lub podobnego systemu zarządzania danymi.
Stakeholder Map- Identyfikuje wszystkich interesariuszy, na których ma wpływ proponowana zmiana, oraz ich wpływ / uprawnienia w zakresie wymagań. Dokument ten został opracowany w początkowej fazie Metodologii Zarządzania Projektem (PMM) i jest własnością Kierownika Projektu, ale zespół projektowy musi go zaktualizować, ponieważ w trakcie procesu identyfikowani są nowi / zmienieni interesariusze.
Requirements Traceability Matrix - Tabela ilustrująca logiczne powiązania między indywidualnymi wymaganiami funkcjonalnymi i innymi typami artefaktów systemowych, w tym inne wymagania funkcjonalne, przypadki użycia / historie użytkowników, elementy architektury i projektu, moduły kodu, przypadki testowe i reguły biznesowe.