Element typu Feature

Domyślna paleta (toolbox) dla diagramu wymagań zawiera obok podstawowego typu elementu, jakim jest wymaganie (requirement) również typ elementu zwany Feature.

W języku polskim słowo feature jest tłumaczone jako cecha, właściwość, aspekt, akcent. Istnieje nawet spolszczona wersja tego słowa: "ficzer". W związku z tym rzadko element tego typu jest stosowany w modelowaniu w narzędziu Enterprise Architect. Analityk dochodzi często do wniosku, że nie ma potrzeby zajmować się jakimiś "ficzerami", podczas gdy powinien skupić się na podstawowych kwestiach. W dodatku podstawowe metodyki zarządzania wymaganiami nie wspominają o pojęciu Feature.

Mimo to, chciałbym pokazać, że zastosowanie tego elementu jest zgoła inne niż to się wydaje na pierwszy rzut oka.A element Feature może on być bardzo przydatny na przykład na wczesnym etapie zarządzania wymaganiami, czyli w procesie gromadzenia / wydobywania wymagań (requirement elicitation) oraz analizy wymagań, gdy nie nie zostały jeszcze zidentyfikowane przypadki użycia.

Wykorzystanie Feature

Otóż etap gromadzenia wymagań w dużym uproszczeniu polega na stosowaniu określonych technik, takich jak wywiad, burza mózgów itd. Na tym etapie analityk próbuje formułować wymagania. W przypadku wymagań funkcjonalnych większość wymagań wiąże się z odnotowaniem potrzeby biznesowej implementacji jakiejś funkcji systemu, a ta funkcja operuje zwykle na danych.

Gdy analityk dokumentuje tylko same wymagania, wówczas lista ewentualnych funkcji pozostaje składowana wyłącznie w ulotnej pamięci analityka. Zacząłem zatem zastanawiać się nad wykorzystaniem elementu typu Feature do tego celu.
EA User Guide definiuje Feature następująco:

A Feature is a small, granular function or characteristic expressed in a client-valued terms as a satisfaction of a requirement; for example: 'content-sensitive Help', or 'ability to reverse-engineer VB.Net'.

Zatem można zrozumieć, że Feature to pojedyncza funkcja lub cecha, wyrażająca potrzebę klienta. Porównajmy to do zakupu samochodu. Klient przychodzi do salonu samochodowego i mówi, że chce, aby jego nowy samochód:

• miał duży bagażnik,
• oszczędny silnik,
• duże przyspieszenie.

Te cechy wyrażają oczekiwania klienta, mogą wynikać z jakichś jego przesłanek. Ale sprzedawca samochodów nie musi się zastanawiać nad tym, dlaczego klient chce mieć duży bagażnik. Zadaniem sprzedawcy jest znaleźć klientowi samochód, który najlepiej spełni jego potrzeby.
A w IT - zespół musi się dobrze zastanowić, jak zaimplementować każdą z funkcji, której klient oczekuje oraz, czy oczekiwania klienta nie są sprzeczne. Zresztą sprzedawca samochodów również może mieć problem ze znalezieniem samochodu, który jednocześnie ma duże przyspieszenie i oszczędny silnik. A w dodatku podobno klient zawsze ma rację...

Feature-driven development

W EA User Guide znaleźć można wyjaśnienie skąd się wzięło pojęcie Feature.  Pochodzi ono z metodyki Feature-driven development. Jest to jedna z metod "zwinnych", czyli Agile. Sama metodyka nie jest może zbyt odkrywcza, gdyż sprowadza się do iteracyjnego cyklu wytwarzania oprogramowania, z tym że skupia się przede wszystkim na funkcjach tworzonego rozwiązania.
Moim zdaniem w odróżnieniu od tradycyjnego cyklu iteracyjnego różni się jeszcze tym, że pozwala na skrócenie czasu i kosztów analizy, gdyż analiza sprowadza się do wyspecyfikowania cech tworzonego oprogramowania. Często wystarczy, że sam klient zdefiniuje, czym ma się cechować rozwiązanie. Analityk nie jest obarczany potrzebą żmudnej analizy i definiowania relacji pomiędzy celami biznesowymi, wymaganiami biznesowymi oraz wymaganiami szczegółowymi aż do przypadków użycia.
Takie podejście zakłada, że klient doskonale wie, czego chce od tworzonego rozwiązania. Warto mieć na uwadze, że to nie jest zawsze prawdziwe założenie. Wracając do przykładu z samochodem może się okazać, że klient nie miał wystarczającej świadomości, że duże przyspieszenie oraz oszczędny silnik nie chodzą ze sobą w parze. W przypadku projektów informatycznych o wiele częściej mamy do czynienia ze sprzecznymi wymaganiami klienta, a rozpoczęcie realizacji projektu obarczonego sprzecznymi wymaganiami jest najprostszą drogą do katastrofy.

Dodam, że jedną z lekcji Steve'a Jobsa jest to, że klient nie zawsze wie, czego chce:

"The customers today don’t always know what they want, especially if it’s something they’ve never seen, heard, or touched before." - Forbes

Przeprowadzenie procesu zarządzania wymaganiami wraz z utworzeniem odpowiednich relacji pomiędzy kategoriami wymagań począwszy od celów biznesowych stanowi wkład do dyskusji z klientem na tym, czy pierwotnie wyspecyfikowane przez niego funkcje przyczyniają się rzeczywiście do realizacji jego celów.

Feature w IIBA - BABOK®

Okazało się, że pojęcie Feature zostało zdefiniowane również przez liczącą się w świecie analityków organizację International Institute of Business Analysis (IIBA). Organizacja ta opublikowała "biblię analityków biznesowych", czyli Business Analysis Body of Knowledge® (BABOK®).
W dokumencie tym widnieje następująca definicja:

Feature -A cohesive bundle of externally visible functionality that should align with business goals and objectives. Each feature is a logically related grouping of functional requirements or non-functional requirements described in broad strokes.

A zatem według BABOK® feature to funkcjonalność, która jest dostrzegalna na zewnątrz (czyli znacząca, a nie pomniejsza), która jest zgodna z celami biznesowymi. Feature pozostaje w relacji z wymaganiami funkcjonalnymi i niefunkcjonalnymi.
Zastosowanie powyższego podejścia sprawia, że w polu widzenia pozostają nadal cele i wymagania klienta, a jednocześnie możliwe jest stworzenie katalogu funkcji (czy też funkcjonalności) oferowanych przez tworzone rozwiązanie.

Modelowanie Feature w Enterprise Architect

Poniższy diagram prezentuje zalecane relacje pomiędzy wymaganiami, features oraz obiektami na diagramie wymagań w Enterprise Architect.

Kolejną kwestią są relacje do przypadków użycia. Przypadek użycia definiuje funkcjonalność rozwiązania.
Przypadki użycia są częścią modelu dynamicznego definiującego sposób korzystania z funkcji systemu. Features jako funkcje czy cechy systemu nie należy traktować zamiennie z przypadkami użycia. Można przyjąć, że przypadki użycia specyfikują sposób korzystania z funkcji oferowanych przez system. A zatem pozostają w relacji zarówno z wymaganiami poprzez relację Realization, jak również z features poprzez relację Dependency.