Po co zawracać sobie głowę rozróżnianiem wymagań funkcjonalnych od niefunkcjonalnych?

Rozumiem różnicę między nimi, ale koledzy pytają mnie o korzyści płynące z wymagań dotyczących etykietowania jako funkcjonalnych lub niefunkcjonalnych (lub przejściowych). Po co to robić? Spędził dwa dni, przeglądając listę wymagań dla jednego projektu, i nie widział w tym żadnej korzyści, ponieważ końcowym rezultatem było przekazanie dokumentu innemu podmiotowi gospodarczemu z edyktem „Zrób to wszystko”.

Obawiam się, że wymagania zostały zebrane w jednym dokumencie. Próbowałem wyjaśnić korzyści w praktyczny sposób, ale nie mogłem tego sprzedać. Jak sprzedać korzyść z udokumentowania, które wymagania są funkcjonalne, a które niefunkcjonalne.

Jawne oddzielenie wymagań ułatwi zaprojektowanie odpowiedniego systemu.

W przypadku niefunkcjonalnych wymagań (wolę atrybuty jakości koncepcji / terminu - powinny one zapewnić nowy wgląd poza funkcjonalny niż niefunkcjonalny), bardziej zależy Ci na właściwościach oprogramowania niż na funkcjonalności. W ten sposób system wykonuje jakąś funkcję, a nie tylko to, co robi system. Wymagania jakościowe mają znaczący wpływ na architekturę systemu w sposób, którego nie spełniają wymagania funkcjonalne iz tego powodu powinny być traktowane inaczej.

Oddzielenie atrybutów jakości od wymagań funkcjonalnych pozwala analizować, określać i ustalać priorytety różnych rodzajów wymagań na różne sposoby. Na przykład atrybuty jakości są zwykle określane przy użyciu scenariusza atrybutu jakości, podczas gdy wymagania funkcjonalne mogą przybrać formę opowieści, przypadków użycia, instrukcji oświadczeń lub dowolnej innej liczby formatów. Większość systemów, nad którymi pracowałem, miała mniej niż tuzin atrybutów jakości i wiele, wiele innych wymagań funkcjonalnych.

W rzeczywistości wprowadziłbym inny rodzaj wymagań - ograniczenia techniczne . Ponownie, wyraźne podzielenie wymagań na te trzy segmenty daje wskazówki, jak dokonać właściwych kompromisów podczas budowania systemu. Wymagania funkcjonalne są często dość negocjowalne, atrybuty jakości będą miały duży wpływ na twoją architekturę i wybrane przez ciebie konstrukcje, ograniczenia techniczne nie podlegają negocjacji.

Gdyby to był mój zespół, powiedziałbym im, że wymagania powinny być wyraźnie opisane według rodzaju, aby upewnić się, że nie umknie nam coś ważnego w architekturze. Pomyśl o sterownikach architektonicznych, a nie tylko o funkcjonalności.

Anthony Lattanze w oprogramowaniu architektonicznym Intensywne systemy: przewodnik dla praktyków daje praktyczny przegląd sterowników architektonicznych i dlaczego należy je traktować inaczej, znacznie bardziej kompleksowo niż moje streszczenie tutaj.

Kiedy każde wymaganie ma taki sam priorytet / wagę (szczególnie „Obowiązkowe”), prawdopodobnie masz więcej powodów do zmartwień niż tylko podział wymagań funkcjonalnych i niefunkcjonalnych.

Niemniej jednak istnieje kilka powodów, dla których należy rozdzielić Dwie kategorie wymagań:

Odpowiedzialność za implementację Przekonałem się, że wiele wymagań niefunkcjonalnych - szczególnie tych skoncentrowanych na wydajności, ma jedynie umiarkowane zastosowanie do programisty. Chociaż projekt może obsługiwać skalowalność i szybkość (a poszczególne sekcje kodu mogą być dostrojone), ogólnie możliwość spełnienia wszelkich wymagań wydajnościowych zależy od architektury i często od konfiguracji sprzętowej.

Odpowiedzialność za testowanie Jak sprawny jest użytkownik lub zespół ds. Kontroli jakości w sprawdzaniu, czy spełnione są wymagania w zakresie bezpieczeństwa, tolerancji błędów, bezpieczeństwa i niezawodności?

Nie powtarzaj się Dokumentacja powinna być oparta na tej samej zasadzie OSUSZANIA, co kod. Wspólne wymagania dotyczące stylizacji interfejsu użytkownika powinny być zgrupowane razem. Jeśli osoba odpowiedzialna za wymagania naprawdę tego chce, może odwoływać się do wymagań niefunkcjonalnych (indywidualnie lub jako grupa) w wymaganiach funkcjonalnych.

Wersjonowanie Jeśli pracujesz w środowisku korporacyjnym z wieloma „standardami” - możesz napisać konkretny interfejs użytkownika lub wymagania bezpieczeństwa (żeby wymienić kilka) dokumentów, które można wersjonować. W ten sposób możesz napisać w specyficznych wymaganiach aplikacji (głównie Wymagania funkcjonalne): „Aplikacja musi być zgodna z V2.3 wymagań bezpieczeństwa zdefiniowanych w XYZ-Company-SecReq-DocumnentNamingStandard.docx”.

Po co zawracać sobie głowę rozróżnianiem wymagań funkcjonalnych od niefunkcjonalnych?

Jednym z powodów różnicowania jest poziom abstrakcji między tymi dwoma typami. Niefunkcjonalne wymagania są na poziomie systemu i mówią, jak musi zachowywać się system jako całość. Wymagania funkcjonalne odnoszą się do konkretnej funkcji oraz tego, jakie funkcje i funkcje muszą być zapewnione klientom.

Wymagania niefunkcjonalne również ograniczają system, a wymagania funkcjonalne mówią, co system musi zrobić. Wymagania niefunkcjonalne ograniczają sposób projektowania i wdrażania wymagań funkcjonalnych w późniejszym terminie. Poprzez ich rozdzielenie staje się możliwe wyraźne zidentyfikowanie cech z ograniczeń i ograniczeń.

Obawiam się, że wymagania zostały zebrane w jednym dokumencie. Próbowałem wyjaśnić korzyści w praktyczny sposób, ale nie mogłem tego sprzedać. Jak sprzedać korzyść z udokumentowania, które wymagania są funkcjonalne, a które niefunkcjonalne.

Z moich doświadczeń wynika, że ​​wymagania funkcjonalne i niefunkcjonalne są zgrupowane w tym samym dokumencie lub śledzone w tym samym systemie. Dostają jednak własne, osobne sekcje dokumentu, a także kryteria powodzenia w spełnieniu każdego z nich.

Zasadniczo kategoryzujesz wymagania, aby pomóc zespołowi spełnić je. Jeśli istnieje wymaganie ukierunkowane konkretnie na potrzebę architektoniczną, nazwanie go wymogiem „Architektura” powinno pomóc zespołowi w pracy nad architekturą.

Duży pojedynczy dokument spełniający wszystkie wymagania niekoniecznie jest złą rzeczą ... Spędzenie 2 dni na jego sprawdzeniu również nie jest złe. Problem zwykle polega na tym, że gdy jedna osoba zapozna się z wymaganiami, - zrozumie je, ale nikomu innemu nie będzie łatwiej to zrobić. Dużym ułatwieniem może być rozpoczęcie etykietowania wymagań za pomocą metadanych, które pomogą innym osobom, które dołączą do projektu.

Może spróbuj opisać to jako problem abstrakcyjny. Jeśli musisz pracować w bazie kodu starszego typu, nie wystarczy przeczytać wszystkie istniejące wiersze kodu, a następnie zacząć działać. Postępujesz zgodnie ze strukturą kodu, aby ci pomóc. Posiadanie pewnej struktury wymagań pomaga w ten sam sposób.

Separacja ma wiele zalet.

1. Oszczędzaj czas na testowaniu (tj. Testuj tylko wymagania funkcjonalne)
2. Oszczędza czas na przyszłe zmiany wymagań (tj. Wymagania niefunkcjonalne zajmą mniej czasu na sprawdzenie / zatwierdzenie / wdrożenie / test)
3. W świecie regulowanym (tj. FDA itp.) Wymagania niefunkcjonalne wymagają 1/10 ilości dokumentów wymaganych przez wymagania funkcjonalne.
4. Daje zespołowi możliwość podziału pracy między starszych (funkcjonalnych) i młodszych (niefunkcjonalnych) członków zespołu.

Mógłbym kontynuować ...

Na pierwszy rzut oka dwa dni wydają się długim czasem, na dłuższą metę może zaoszczędzić tygodnie, a nawet miesiące przyszłej pracy.