W czynnikach jakości wymagań rozpisano masę ważnych czynników. Oczywiście jest to super opcja i zawsze mam je zapisane w swoich notatkach i je stosuje w swojej codziennej pracy. Jednak odkryłem kolejną fajną konwencję która została skradziona z ustalania celów, czyli z reguły SMART. Takim sposobem powstały wymagania biznesowe SMART. Samo przedstawienie było mało optymalne w moich oczach więc trochę je zmodyfikowałem. Dzięki temu przedstawiam nowy sposób podchodzenia do jakości wymagań który wydaje mi się nieoklepany w naszej, polskiej społeczności. Zapraszam do lektury.

S czyli „Specyfic” czyli „Konkretne” a raczej niedwuznaczne, „Short” czyli Krótkie i „Simple” czyli „Proste”

Wymagania biznesowe SMART mają służyć konkretnemu celowi. Nie może być tak że tworzymy zdania które nie mają jakiegokolwiek celu. Wymagania mają być krótkie bo jak będziesz tworzyć opasłe dokumentacje to wpadniesz w pułapkę mema który ostatnio wrzucałem na mojego instagrama gdzie napracujesz się napracujesz a osoba która będzie to czytać jedyne co zrobi to stwierdzi.

TL;DR; O co tam chodzi?

No a abstrahując już od TL;DR to im więcej tekstu tym większe pole do błędnych interpretacji. Konkretne(czyli też niedwuznaczne), proste i krótkie wymagania są łatwiejsze do zrozumienia, prostsze w weryfikacji i łatwiej jest uzyskać ich akceptację. Dodatkowo tutaj zawiera się unikanie dwuznaczności takich jak „user-friendly”, „szybkie”, „łatwe” i itd.

M jak „Mesureable” czyli „Wymierne” a bardziej po ludzku „Mierzalne”

Wymagania biznesowe SMART muszą być zweryfikowane. Są różne metody weryfikacji. Weryfikacja musi być wykonana żeby upewnić się że system spełnia pokładane w nim nadzieje. Ale aby wymaganie było weryfikowalne(czy testowalne) to musimy umieć ze 100% pewnością stwierdzić że dane wymaganie jest zaimplementowane.

A żeby to zrobić to wymaganie musi być słowo klucz „Mierzalne”. Czyli znowu wracamy to tego że dwuznaczność nie pozwoli nam na zmierzenie. Każde wymaganie powinno mieć określenie w jaki sposób można je uznać za wdrożone a jak tego nie ma to nie ma dobrego wymagania.

A jak Agreed czyli „Uzgodnione” a nawet raczej „Zaakceptowane”

Wymagania muszą być zaakceptowane przez wszystkich interesariuszy. Wszyscy zawsze to powtarzamy na samym początku jakości wymagań biznesowych więc nie mogło tego zabraknąć w naszej wyliczance SMART.

R jak „Real” czyli realizowalne oraz „Required” czyli wymagany a bardziej „potrzebny”

Realizowalne czyli wymaganie musi być możliwe do implementacji biorąc pod uwagę ograniczenia w organizacji(takie jak ograniczenie prawne, techniczne, finansowe itd.) Dodatkowo należy pamiętać o zgodności ze wszystkimi standardami, procedurami w danej firmie. To oznacza że wymagania powinny być konsultowane z ludźmi odpowiedzialnymi za development i różne procedury organizacji aby ocenili oni czy dane wymaganie jest do zaimplementowania biorąc pod uwagę wszystkie ograniczenia. Często jest tak że interesariusze rezygnują z wymagań biorąc pod uwagę koszty.

Required czyli wymagane a bardziej po naszemu potrzebne. Wymaganie musi być zgodne z zaadresowanymi potrzebami biznesowymi. Muszą być dostosowane do obecnego kontekstu jak i otoczenia systemu. Nie mogą być oderwane od rzeczywistości co prowadzi do tego że będą niewykorzystywane.

T jak „Traceable” czyli możliwe do śledzenia ale także „Total” czyli synonim „kompletne”

Wymaganie ma być możliwe do śledzenia czyli jego pochodzenie, związek z jego realizacją oraz innymi dokumentami, procedurami ma być łatwe do prześledzenia. Można to zrobić za pomocą identyfikatorów, tagów, etykiet, linków. Obecnie metod jest masa ale zawsze trzeba pamiętać o możliwości śledzenia.

Ostatnia cecha trochę wepchnięta na siłę bo kompletność nie pasowała nigdzie a jest bardzo ważna(może zamiast SMART powinienem zrobić SMARK :D). Pamiętaj o tym żeby wymagania były kompletne. Niekompletne wymagania to autostrada do porażki projektu.

I jak wam się podoba takie podejście SMART? Dajcie znać. Dzięki za lekturę i do następnego!