Wpadł mi nie­daw­no do skrzyn­ki mailo­wej kolej­ny arty­kuł ser­wi­su Modern Analyst, cytat:

If you cre­ate only one view of the requ­ire­ments, you must belie­ve it. You have no other cho­ice. If you deve­lop mul­ti­ple views, tho­ugh, you can com­pa­re them to look for discon­nects that reve­al errors and dif­fe­rent inter­pre­ta­tions. (źr. Why Create Multiple Requirements Views? > Business Analyst Community & Resources | Modern Analyst > Business Analyst Articles & Systems Analysis Articles | Modern Analyst).

Autor suge­ru­je by łączyć wyma­ga­nia funk­cjo­nal­ne z przy­pad­ka­mi uży­cia, testa­mi, mode­la­mi. W dużym uprosz­cze­niu: jeże­li mamy tyl­ko jed­ną per­spek­ty­wę wyma­gań (np. w posta­ci listy wyma­gań funk­cjo­nal­nych i poza­funk­cjo­nal­nych) musi­my im wie­rzyć bo nie mamy ich wery­fi­ka­to­ra (nie mamy inne­go wyj­ścia). Troszkę to łącze­nie ​„każ­dy z każ­dym” chy­ba jed­nak nie ułatwia:

Problem kom­plet­no­ści i spój­no­ści wyma­gań jest dość trud­ny do roz­wią­za­nia. Wymagania nie­kom­plet­ne i nie­spój­ne potra­fią zaś zabić pro­jekt, wady spe­cy­fi­ka­cji (takie jak nie­kom­plet­ność i nie­spój­ność) skut­ku­ją odkry­wa­niem ich w trak­cie pro­jek­tu, rośnie w nie­kon­tro­lo­wa­ny spo­sób zło­żo­ność projektu.

Jeżeli wypra­cu­je­my wię­cej per­spek­tyw, może­my je skon­fron­to­wać i porów­nać, wykry­wa­jąc ewen­tu­al­ne nie­ści­sło­ści i błę­dy. Także [[BABoK]] (rodem z [[IIBA]]) zale­ca utrzy­my­wa­nie tak zwa­nej śla­do­wal­no­ści, to jest wywo­dze­nia np. wyma­gań na opro­gra­mo­wa­nie z wyma­gań biz­ne­so­wych, a tych z celu pro­jek­tu. Nadal jed­nak mamy tyl­ko jed­no źró­dło dla każ­de­go wyma­ga­nia. To rodzi pew­ne ryzy­ko, gdyż brak wery­fi­ka­to­ra powo­du­je, że ryzy­ko błę­du pozostaje.

Od kil­ku lat sto­su­je meto­dę pole­ga­ją­cą na testo­wa­niu lub spe­cy­fi­ko­wa­niu reli­za­cji wyma­gań. Rok 2008, na zakoń­cze­nie arty­ku­łu IEEE830-1998 ? czy pro­du­ku­je dobre wyma­ga­nia? napisałem:

Metodyka, któ­rą stosuję

1. Wymagania funk­cjo­nal­ne to przy­pad­ki uży­cia sys­te­mu; Przypadki uży­cia sys­te­mu to czyn­no­ści wyse­lek­cjo­no­wa­ne z mode­lu pro­ce­sów na bazie zakre­su projektu.
2. Wymagania nie­funk­cjo­nal­ne to ogra­ni­cze­nia nakła­da­ne na poszcze­gól­ne przy­pad­ki uży­cia (mogą być gru­po­wa­ne np. mak­sy­mal­ny czas odpo­wie­dzi sys­te­mu nie może prze­kro­czyć 1 s. z wyjąt­kiem rapor­tów, gdzie mak­sy­mal­ny czas odpo­wie­dzi to 1 minuta)
3. Wymagania dzie­dzi­no­we opi­sy­wa­ne są mode­lem dzie­dzi­ny sys­te­mu (dia­gram klas lub ERD)

c.d. kie­dyś nastąpi?

Tak więc mamy ciąg dal­szy :). Wspomniałem o wyma­ga­niach dzie­dzi­no­wych. Osobiście trak­tu­ję je wła­śnie jako ​„trze­cią nogę” wspie­ra­ją­cą model wyma­gań. Funkcjonalność (usłu­ga sys­te­mu) mówi nam cze­go ocze­ku­je użyt­kow­nik, jed­nak ​„usłu­ga sys­te­mu” opi­su­je sys­tem jako tak zwa­ną ​„czar­ną skrzyn­kę”. Jeżeli uzu­peł­ni­my opis wyma­gań ele­men­ta­mi mode­lu dzie­dzi­ny, doda­my wery­fi­ka­tor w posta­ci opi­su wnę­trza tej czar­nej skrzyn­ki (wyma­ga­my nie tyl­ko ​„two­rze­nia fak­tu­ry VAT” ale defi­niu­je­my jej struk­tu­rę, to się nazy­wa opis ​„bia­łej skrzynki”).

Jak wspo­mnia­łem swe­go cza­su, opra­co­wu­jąc wyma­ga­nia na goto­we i zaawan­so­wa­ne opro­gra­mo­wa­nie nie ma sen­su jego pro­jek­to­wa­nie. Zbyt szcze­gó­ło­wa spe­cy­fi­ka­cja zbli­ża nas do pro­jek­tu, a my chce­my jed­nak coś goto­we­go (ma być taniej i szybciej).

Standardowo, spe­cy­fi­ku­jąc wyma­ga­nia, nale­ży sku­pić się na tym do cze­go będzie­my uży­wa­li opro­gra­mo­wa­nia a nie na tym jak ono to robi. Jednak ​„do cze­go” ozna­cza ​„co będzie­my two­rzyć i prze­twa­rzać”. Co więc robić? Proszę popatrzeć:

Tak więc wymaganie:

1. koja­rzy­my z reali­zu­ją­cym je mode­lem (przy­pad­kiem uży­cia, pro­ce­sem, ele­men­tem dziedziny),
2. koja­rzy­my z testem spraw­dza­ją­cym czy zosta­ło speł­nio­ne (z pomo­cą dobra­ne­go sce­na­riu­sza testowego).

Powszechnie posłu­gu­je­my się wyma­ga­nia­mi funk­cjo­nal­ny­mi. Czym jest wyma­ga­nie dzie­dzi­no­we? Wyobraźmy sobie, że chce­my opi­sać wszyst­kie meto­dy i sce­na­riu­sze wysta­wie­nia fak­tu­ry VAT. Będzie ich bar­dzo dużo, zapew­ne moż­li­we będą takie, któ­rych nie ​„wymy­śli­li­śmy”. Bezpieczniej jest opi­sać fak­tu­rę VAT wraz z regu­ła­mi rzą­dzą­cy­mi jej poszcze­gól­ny­mi pola­mi, zamiast uznać ją za ​„czar­ną skrzyn­kę” i pró­bo­wać opi­sać meto­dą ​„jak moż­na jej użyć”.

Młotek moż­na opi­sać tym ​„do cze­go będzie uży­wa­ny” (przy­pad­ki uży­cia) lub ​„jak wyglą­da”. Nie raz dru­ga meto­da jest bez­piecz­niej­sza, jed­nak jest to już pro­jek­to­wa­nie i nale­ży to robić świa­do­mie. Czy to źle? Nie, bo nie raz zapro­jek­to­wa­nie jest mniej ryzy­kow­ne niż opis ​„do cze­go” (zamiast zło­żo­ne­go opi­su wie­lu zasto­so­wań młot­ka, pro­ściej jest go narysować).

Zawsze, przy każ­dym wyma­ga­niu, nale­ży pod­jąć decy­zję, czy reali­za­cja wyma­ga­nia przez dostaw­cę sta­no­wi ryzy­ko (i jakie). Sami pro­jek­tu­je­my reali­za­cję (two­rzy­my model) zawsze, gdy to ryzy­ko jest za duże by je akcep­to­wać. Podobnie trak­tu­je­my testy. Projektujemy je, gdy koszt nie­speł­nie­nia dane­go wyma­ga­nia prze­kra­cza dopusz­czal­ny poziom. Testem może być tak­że model (np. pro­ce­su biznesowego).

Takie podej­ście powo­du­je, że zanim jesz­cze dotknie­my goto­we­go pro­duk­tu (tu nie­ste­ty już po jego wybo­rze) może­my po pierw­sze: prze­te­sto­wać samą spe­cy­fi­ka­cję a po dru­gie prze­ka­zać poten­cjal­ne­mu dostaw­cy (na eta­pie zapy­ta­nia) peł­ną infor­ma­cję o tym, cze­go ocze­ku­je­my od pro­duk­tu i jak to sprawdzimy.

Powyższe podej­ście w posta­ci «full wypas” może być pra­co­chłon­ne, dla­te­go moż­li­we są warian­ty pośred­nie, czy­li tyl­ko dla wyma­gań ozna­czo­nych jako ryzy­kow­ne budu­je­my testy lub mode­le, jed­nak mamy narzę­dzie do pano­wa­nia nad tym ryzy­kiem. Po dru­gie zysku­je­my narzę­dzie do wery­fi­ka­cji, odbiór opro­gra­mo­wa­nia nie będzie spraw­dza­niem pokaź­nej i ryzy­kow­nej zara­zem listy dzie­sią­tek cech, będzie ​„jaz­dą prób­ną na sucho”, a więc rela­tyw­nie tanią i pew­ną meto­dą testów: dostaw­ca dekla­ru­je (ofer­ta na nasze zapy­ta­nie) zgod­ność z naszy­mi wyma­ga­nia­mi, a te są wery­fi­ko­wal­ne. Należy roz­wa­żać zawsze koja­rze­nie mode­li z testami.

Kiedy jesz­cze pisze­my reali­za­cję”? Gdy chce­my pozo­stać jej auto­ra­mi i chro­nić nasz know-how.