Często moż­na spo­tkać opi­sy wyma­gań w posta­ci tek­stu opi­su­ją­ce­go ?wyma­ga­nia funk­cjo­nal­ne? i ?jakieś inne? np. wydaj­no­ścio­we, sys­te­mo­we itp. Nie raz są to doku­men­ty opar­te na zale­ce­niach opi­sa­nych w doku­men­cie IEEE 830‑1998, któ­ry opi­su­je doku­men­to­wa­nie wyma­gań. Czy zale­ce­nia te są roz­wią­za­niem pro­ble­mu złych spe­cy­fi­ka­cji? Tylko troszkę.

Co znaj­dzie­my w tych zale­ce­niach? Otóż zapi­sa­no tam, że spe­cy­fi­ka­cja powin­na być:

• Poprawna: nie może być np. nie­zgod­na z prawem
• Jednoznaczna: o tym za moment
• Kompletna: o tym za moment
• Spójna: brak kon­flik­tów logicz­nych ale o tym tak­że za moment
• Uporządkowana wg ważności/stabilności: np. meto­dą tria­ge czy­li każ­de wyma­ga­nie ma jeden z trzech atry­bu­tów ? musi być, powin­no być, mogło by być (inna wer­sja to waga wyma­ga­nia dla całe­go pro­jek­tu: duża śred­nia, mała)
• Weryfikowalna: moż­na jed­no­znacz­nie stwier­dzić, że wyma­ga­nie zosta­ło zrealizowane
• Modyfikowalna: to doty­czy struk­tu­ry doku­men­tu i narzę­dzia jakim powstał doku­ment wymagań
• Umożliwiająca śle­dze­nie powią­zań: doty­czy struk­tu­ry doku­men­tu jak i jego for­ma­tu (doku­men­ta­cja html będzie lep­sza od doku­men­ta­cji tek­sto­wej do prze­glą­da­nia ale nie do druku).

A teraz ?ten moment?. Jednoznaczność, cóż to jest? Podczas pisa­nia spe­cy­fi­ka­cji wyma­gań za pomo­cą języ­ka natu­ral­ne­go, nigdy nie osią­gnie­my peł­nej jed­no­znacz­no­ści. Jedynie zapis wyma­gań za pomo­cą metod for­mal­nych pozwa­la w peł­ni unik­nąć wieloznaczności.

Dla sto­sun­ko­wo nie­du­żych pro­jek­tów poziom nie­jed­no­znacz­no­ści osią­ga­ny pod­czas pisa­nia wyma­gań języ­kiem natu­ral­nym jest wystar­cza­ją­cy. Jednak do ?poważ­niej­szych? zasto­so­wań (np. duże sys­te­my wspo­ma­ga­ją­ce zarzą­dza­nie np. CRM czy w szcze­gól­no­ści sys­te­my kry­tycz­ne) nale­ży spe­cy­fi­ko­wać wyma­ga­nia za pomo­cą metod for­mal­nych lub tak zwa­nych quasi-for­mal­nych. Metody for­mal­ne to mate­ma­tycz­ne zapi­sy, o któ­rych tu nie będzie­my pisać gdyż są rzad­ko sto­so­wa­ne z uwa­gi koszty.

Metody quasi-for­mal­ne to meto­dy zorien­to­wa­ne na mode­le. Modele moż­na prak­tycz­nie uznać za jed­no­znacz­ne choć obec­nie nie ma narzę­dzi to auto­ma­tycz­ne­go spraw­dza­nia ich jako­ści (są dla metod for­mal­nych). Poprawny model jed­nak wyko­na­ny jest za pomo­cą popraw­nej nota­cji a tu moż­na wery­fi­ko­wać auto­ma­tycz­nie jej gra­ma­ty­kę i słow­ni­ki (syn­tak­ty­kę i semantykę).

A jak odpo­wie­dzieć na pyta­nia: Czy wyma­ga­nia są kom­plet­ne (czy cze­goś nie pomi­nę­li­śmy)? Czy są logicz­nie spój­ne (może ich być kil­ka­dzie­siąt, kil­ka­set i wię­cej)? Czy wyma­ga­nia nie są redun­dant­ne (czy nie opi­su­ją tych samych zacho­wań róż­nym językiem)?

Na moment zmia­na dzie­dzi­ny. Wyobraźmy sobie, że mamy pro­jekt pole­ga­ją­cy na poma­lo­wa­niu ele­wa­cji domów w pew­nym mie­ście. Z ana­li­zy ren­tow­no­ści wyni­ka, że moż­li­we jest poma­lo­wa­nie tyl­ko domów mają­cych nie wię­cej niż czte­ry kon­dy­gna­cje. Potrzebny jest doku­ment z listą tych budyn­ków i ich adre­sów. Jaki doku­ment otrzy­ma­my jeże­li wyko­na­my go na bazie wywia­dów z pew­nym odset­kiem miesz­kań­ców tego mia­sta? A teraz dru­gie pyta­nie: czy doku­ment, któ­ry powsta­nie na pod­sta­wie mapy mia­sta z dany­mi o wszyst­kich budyn­kach będzie lepszy?

Dlatego moim zda­niem zale­ce­nie IEEE830-1998 jest bar­dzo dobrym spi­sem tre­ści doku­men­tu wyma­gań wraz z komen­ta­rza­mi ale abso­lut­nie nie opi­su­je jak taki, wyso­kiej jako­ści doku­ment stwo­rzyć (nie licząc spi­su tre­ści). Tu kła­nia się meto­dy­ka pozy­ski­wa­nia wyma­gań oraz spo­sób ich specyfikowania.

Pozyskiwanie wymagań

Podobnie jak w przy­pad­ku opi­sa­nej powy­żej listy budyn­ków kom­plet­ne i spój­ne wyma­ga­nia naj­ła­twiej zro­bić na bazie mode­lu orga­ni­za­cji, fir­my itp.. Zwracam uwa­gę, że plan mia­sta to nic inne­go jak jego model z per­spek­ty­wy topo­lo­gii. Należy więc naj­pierw wyko­nać model orga­ni­za­cji, a jest nim tu model pro­ce­sów biz­ne­so­wych. Na tym mode­lu (podob­nie jak budyn­ki na pla­nie) zazna­cza­my czyn­no­ści zakwa­li­fi­ko­wa­ne do zakre­su pro­jek­tu. Czynności te sta­ną się przy­pad­ka­mi uży­cia opro­gra­mo­wa­nia. Każdy taki przy­pa­dek ma auto­ma­tycz­nie swój kon­tekst (miej­sce na mapie pro­ce­sów) i akto­ra (rola na napie pro­ce­sów), wystar­czy opi­sać jego sce­na­riusz i zbu­do­wać pro­to­typ ekra­nu lub doku­men­tu. Lista taka wyko­na­na na bazie mode­lu pro­ce­sów z zasa­dy jest spój­na i kompletna.

Paradoksalnie wyko­na­nie takie­go mode­lu jest tu naj­więk­szą trud­no­ścią. Dlaczego? Tworząc go nale­ży bez­względ­nie pano­wać na jego zło­żo­no­ścią, pano­wać nad subiek­ty­wi­zmem osób z któ­ry­mi pro­wa­dzi­my wywia­dy, rozu­mieć stra­te­gię mode­lo­wa­nej fir­my i jej model biz­ne­so­wy, wie­le innych. Identyfikacja pro­ce­sów sama w sobie jest trud­na, wyma­ga posia­da­nia metod ich iden­ty­fi­ka­cji i wery­fi­ka­cji popraw­no­ści samej ana­li­zy i mode­lu, to jed­nak temat na książ­kę a nie na taki artykuł.

Wymagania pozafunkcjonalne i interfejsy

Tu poja­wia się pierw­szy roz­dź­więk pomię­dzy meto­dy­ką, któ­rą np. ja sto­su­ję (nie ja jeden!) a zale­ce­nia­mi IEEE. Otóż takie cechy jak wydaj­ność, nie­za­wod­ność czy bez­pie­czeń­stwo w kate­go­riach meto­dy­ki, któ­rą sto­su­ję sta­no­wią ogra­ni­cze­nia nakła­da­ne na funk­cjo­nal­no­ści. Jeżeli np. chce­my powie­dzieć, że raport X musi się wyko­ny­wać w cza­sie nie dłuż­szym niż N sekund to jest to nic inne­go jak ogra­ni­cze­nie nało­żo­ne na przy­pa­dek uży­cia Tworzenie rapor­tu X czyż nie? Podobnie nie­za­wod­ność np. dostęp­ność czyn­no­ści zwią­za­nych z two­rze­niem rapor­tów finan­so­wych nie może zejść poni­żej 99,99% cza­su w ska­li roku. I tak dalej?

Interfejsy to tak­że nic inne­go jak przy­pad­ki uży­cia. Np. sys­tem musi udo­stęp­niać dane maga­zy­no­we w posta­ci XML dla każ­de­go upraw­nio­ne­go zewnętrz­ne­go sys­te­mu (jest nawet aktor: zewnętrz­ny sys­tem). Przypadkiem uży­cia jest tu przy­pa­dek żąda­nia tych danych przez zewnętrz­ny sys­tem. Przykłady moż­na mno­żyć. Dzięki takie­mu podej­ściu uni­ka­my np. wyma­gań w rodza­ju: sys­tem ma być dostęp­ny co naj­mniej 99,99% cza­su w ska­li roku bo tą meto­dą wszyst­kie funk­cjo­nal­no­ści, nawet mało istot­ne, zrów­nu­je­my w górę czy­li po pro­stu pod­no­si­my kosz­ty sys­te­mu wła­ści­wie bez uzasadnienia.

A gdzie przetwarzane dane?

Powyższe zale­ce­nia nie wyma­ga­ją wyspe­cy­fi­ko­wa­nia mode­lu danych, pod­sta­wo­wej infor­ma­cji. Oczekiwanie, że model danych zapro­jek­tu­ją dopie­ro pro­gra­mi­ści to ocze­ki­wa­nie od ludzi nie zna­ją­cych zama­wia­ją­ce­go, że opi­szą jego biznes.

Tyle na dzisiaj, ale na zakończenie.

Nie jest to kry­ty­ka zale­ceń IEEE830-1998 a zwró­ce­nie uwa­gi na to, że same one nie sta­no­wią lekar­stwa podob­nie jak sam tytuł i spis tre­ści powie­ści nie czy­ni jesz­cze z pisa­rza kan­dy­da­ta do nagro­dy Pen Clubu.

Co piszą inni?

Powołam się tu na zawar­tość książ­ki Iana Sommervill?a ?Inżynieria opro­gra­mo­wa­nia?. Wymagania dzie­li­my na:

1. Funkcjonalne czy­li jakie usłu­gi ma ofe­ro­wać system
2. Niefunkcjonalne to ogra­ni­cze­nia usług i funk­cji systemu
3. Dziedzinowe, któ­re pocho­dzą z dzie­dzi­ny zasto­so­wa­nia systemu

?Standard IEEE nie jest ide­al­ny, zawie­ra jed­nak bar­dzo wie­le cen­nych rad, jak pisać wyma­ga­nia i uni­kać pro­ble­mów. Jest zbyt ogól­ny, aby sam mógł być stan­dar­dem fir­mo­wym? (Ian Sommerville ? Inżynieria opro­gra­mo­wa­nia, WNT Warszawa 2003).

Metodyka, którą stosuję

1. Wymagania funk­cjo­nal­ne to przy­pad­ki uży­cia systemu 
   1. 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…