Treść książki
Przejdź do opcji czytnikaPrzejdź do nawigacjiPrzejdź do informacjiPrzejdź do stopki
1.4.Kryteriajakościwymagań
35
jednostkowe–stwierdzeniewymagania(opis)niemożezawieraćwieluwyma-
gań.Przyopracowywaniutreściwymagańnależyupewnićsię,żeopisujemypo-
jedynczewymaganie;
zgodne–wymaganieniestoiwsprzecznościzinnymiwymaganiamilubpowią-
zanądokumentacją;
zrozumiałe–wymaganiejestzrozumiałewtedy,gdyjegoprzekaziznaczenie
sąjasnedlaodbiorcy.Skrótymyślowe,specjalistyczneterminyiniewyjaśnione
akronimypowodujątrudnościwHprawidłowym”(czylizgodnymzintencjąauto-
ra)zrozumieniuwymagania,wwynikuczegomogąpowstaćproblemynaskutek
różnejinterpretacjitreściwymagania;
abstrakcyjne–inaczejniezależneodsposobuimplementacji.Wymaganiepowin-
noopisywać,cochcemyosiągnąć,anie,jaktozrobić.Innymisłowy,wymaga-
nieniepowinnosugerowaćaninarzucaćsposóbimplementacji.Umieszczenie
wopisiewymaganiainformacjiwskazującychnasposóbrozwiązaniajestjednym
znajczęstszychbłędówpopełnianychwdokumentacjiwymagań,ponieważHmy-
śleniewkategoriirozwiązań”jestwwieluprzypadkachprostszeibardziejintu-
icyjneniżposługiwaniesięabstrakcyjnymiwyobrażeniami.
Niektóreźródładolistydodająteżkryteriumjakościowe:
aktualność–wymaganieniestarzejesięzupływemczasu.
Opisującwymagania,należyposługiwaćsięprostymi,jednoznacznymiizrozu-
miałymistwierdzeniami–językzbytzłożonylubzawierającyzadużoterminówfa-
chowychsprawia,żedokumentacjastajesiętrudnawodbiorze,amaonaprzecież
służyćnietylkojejautorowi,leczrównieżinteresariuszomzestronyklienta,kie-
rownikowiprojektu,zespołomdeweloperskimiQA(ang.
QualityAssurance
).Dobry
opiswymaganiacharakteryzujesięm.in.następującymicechami:
prostota–opiswymaganianiezawierazłożonychwarunkówistruktur(tobę-
dzieprzedmiotemdalszejanalizy);
spójność–terminologiaużywanawdokumentacjiwymagańjestspójnaima
tosamoznaczeniewróżnychczęściachdokumentacji–przykładowo,słowo
Hklient”użytewdokumentacjizawszeokreśladocelowegoklientazpunktuwi-
dzeniaorganizacjizamawiającejproduktIT;
zrozumiałość–autorwymaganianiezakłada,żeodbiorcaposiadarównąmu
wiedzędziedzinowączypostrzeganierzeczywistości.Wymaganiepowinnobyć
zrozumiałezarównodlaekspertadziedzinowego,testera,programisty,jakido-
wolnejinnejosobyzgrupyudziałowców.Najczęściejpopełnianymbłędemjest
zakładanie,żecośjesttakoczywiste,żeniewymagadokładnegoopisulubchoć-
bywzmiankiwdokumentacji.Oilepewnerzeczysąoczywistedlaanalitykabiz-
nesowegoiprzedstawicielibiznesuklienta,otylewcaleniemusząbyćznane
programistomproducentarozwiązania.Brakzrozumieniamożeskutkowaćnie-
poprawnąimplementacją;
zwięzłość–wmiaręmożliwościtekstwymagańpowinienbyćkrótkiiopisywać
wyłączniezakresdanegowymagania.
Wniektórychprzypadkachlistawymagańdefiniujerównieżosobyodpowiedzial-
nezadokumentacjęokreślonychwymagańisposóbichweryfikacjiwprojektowa-
nymsystemie.Ponadtoważnejestokreśleniepriorytetuikrytycznościdlakażdego
wymagania.
