Dlaczego śladowanie wymagań jest istotne w projekcie?

Wymagania to nie­wy­czer­pa­ny temat dys­ku­sji, blo­gów i spo­rów w pro­jek­tach. Ich śla­do­wa­nie już rza­dziej jest takim tema­tem, bo mało kto to robi, a to wła­śnie mię­dzy inny­mi brak śla­do­wa­nia pro­wa­dzi do pro­ble­mów w pro­jek­cie. Typowy pro­blem to utra­ta pano­wa­nia nad zakre­sem pro­jek­tu, utra­ta pano­wa­nia nad zło­żo­no­ścią doku­men­ta­cji i ilo­ści wyma­gań” (cudzy­słów celo­wo, póź­niej o powo­dach). W kon­se­kwen­cji jakość całe­go pro­jek­tu upa­da, zado­wo­le­nie spon­so­rów tak­że (pole­cam krót­ki wpis: Why is requ­ire­ments tra­ce­abi­li­ty impor­tant on a pro­ject?). Dlaczego? Bo sko­ro wyma­ga­nia mają być FURPS i SMART, to jak to osią­gnąć i jak skon­tro­lo­wać? Jak skon­tro­lo­wać w mie­rzal­ny spo­sób np. kompletność?

O wyma­ga­niach pisa­łem nie raz, dzi­siaj z per­spek­ty­wy ich śla­do­wa­nia i celu tego pro­ce­de­ru. Bardzo czę­sto spo­ty­ka się w doku­men­tach pro­jek­to­wych wyma­ga­nia funk­cjo­nal­ne i poza­funk­cjo­nal­ne, ale mało któ­ry z tych doku­men­tów zawie­ra defi­ni­cje tych pojęć, a wyma­gań tych są set­ki a nie raz tysią­ce. Są – te wyma­ga­nia” – zbie­ra­ne” naj­czę­ściej pod­czas wywia­dów, sesji burz mózgów, sesji warsz­ta­tów wyma­gań”. Ilość wyma­gań jest naj­czę­ściej pro­por­cjo­nal­na do cza­su trwa­nia tych sesji a ana­li­za wyma­gań” jest prze­ry­wa­na gdy wyma­gań jest wystar­cza­ją­co dużo” (widy­wa­łem doku­men­ty z ponad czte­re­ma tysią­ca­mi wymagań!).

W języ­ku pol­skim sło­wo wyma­ga­nie ma bar­dzo ści­słą i bar­dzo przy­dat­na definicję:

wyma­ga­nie ?waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpowiadać?

Popatrzmy co na to BABOK

PMBookRequirementDefiniction

Jest to defi­ni­cja bar­dzo bli­ska tej słow­ni­ko­wej: waru­nek lub moż­li­wość pro­duk­tu lub usłu­gi, speł­nia­ją­cy ocze­ki­wa­nia” (dość wol­ne tłumaczenie ;)).

A jak są kla­sy­fi­ko­wa­ne wyma­ga­nia? Tu jest bytów” jest więcej:

PMBookRequirementDefiniction2

Tu moim zda­niem zaczy­na się mała masa­kra, bo konia z rzę­dem temu, kto jed­no­znacz­nie podzie­li dłu­gą listę cech pro­duk­tu na powyż­sze sześć kuwe­tek”. Przypomnę, że popraw­ny słow­nik pojęć to poję­cia wza­jem­nie się wyklu­cza­ją­ce, czy­li jeże­li coś jest np. wyma­ga­niem, przej­ścio­wym to nie jest żad­nym innym. Dlatego ten (taki) podział jest moim zda­niem przy­czy­ną wie­lu pro­ble­mow w projektach.

Wymagania biznesowe

Rzadko spo­ty­ka­ne a wręcz koniecz­ne do popraw­nej kon­tro­li pro­jek­tu i zarzą­dza­nia jego zakre­sem. Inna defi­ni­cja, moim zda­niem lep­sza niż ta z BABOK’a:

Business Requirements

The pur­po­se of busi­ness requ­ire­ments is to defi­ne a project?s busi­ness need, as well as the cri­te­ria of its suc­cess. Business requ­ire­ments descri­be why a pro­ject is needed, whom it will bene­fit, when and whe­re it will take pla­ce, and what stan­dards will be used to eva­lu­ate it. Business requ­ire­ment gene­ral­ly do not defi­ne how a pro­ject is to be imple­men­ted; the requ­ire­ments of the busi­ness need do not encom­pass a project?s imple­men­ta­tion deta­ils. (Business Requirements – Requirements​.com).

To rza­dziej spo­ty­ka­na defi­ni­cja wyma­gań biz­ne­so­wych. W skró­cie: wyma­ga­nia biz­ne­so­we defi­ni­cją biz­ne­so­wy cel pro­jek­tu, kry­te­ria suk­ce­su (pomy­słu); wyma­ga­nia biz­ne­so­we opi­su­ją po co pro­jekt jest uru­cha­mia­ny; wyma­ga­nia biz­ne­so­we nie mówią nic o ich imple­men­ta­cji. I to jest pro­sta i bar­dzo sku­tecz­na w uży­ciu definicja.

Schody zaczy­na­ją się przy innych wyma­ga­niach, kolej­na wersja:

Functional requ­ire­ments are a type of solu­tion requ­ire­ments. According to BABOK, the­se descri­be the beha­vior and infor­ma­tion that the solu­tion will mana­ge.” Continuing with our far­ming illu­stra­tion, an exam­ple of a func­tio­nal requ­ire­ment would be: This sys­tem will deli­ver pro­du­ce from farms in our coope­ra­ti­ve and deli­ver it to par­ti­ci­pa­ting custo­mers.” (Requirements – Requirements​.com).

Wymagania funk­cjo­nal­ne. Najczęściej poda­je się jako wyma­ga­nia wobec roz­wią­za­nia” (i słusz­nie), jed­nak nie­ste­ty, defi­nio­wa­ne są poprzez przy­kład, np. stwier­dze­nie, że funk­cjo­nal­ność to zacho­wa­nie sys­te­mu i infor­ma­cje, któ­ry­mi sys­tem zarzą­dza” jest bar­dzo nie­for­tun­ne bo nie­zwy­kle pojem­ne, pro­wa­dzi wie­lu ana­li­ty­ków to wnio­sku, że sko­ro wysta­wie­nie fak­tu­ry wyma­ga nastu klik­nięć i wpro­wa­dze­nie nastu infor­ma­cji” to wyma­gań funk­cjo­nal­nych jest też naście”. Pojęcie funk­cjo­nal­ny” jest tak sze­ro­kie, że w zasa­dzie każ­da cecha pro­duk­tu do cze­goś słu­ży i jest jakąś funk­cjo­nal­no­ścią. Przeciętny samo­chód m ich set­ki a tak na praw­dę słu­ży do prze­miesz­cza­nia się.

Poszukajmy porząd­ku i spo­so­bu śladowania.

Wymagania biz­ne­so­we to cele uru­cha­mia­nia pro­jek­tu, to są cele orga­ni­za­cji (jej kadr kie­row­ni­czych). A resz­ta? Bardzo nie­pre­cy­zyj­ne defi­ni­cje wyma­gań pro­wa­dzą do setek ich inter­pre­ta­cji. Sam fakt, że te same wyma­ga­nia (jako nazwa i opis) są, przez róż­ne oso­by tego same­go zespo­łu pro­jek­to­we­go, róż­nie kla­sy­fi­ko­wa­ne, świad­czy o tym, że jest problem.

Z pomo­cą przy­cho­dzi śla­do­wa­nie, wymu­sza dopre­cy­zo­wa­nie defi­ni­cji. Dlaczego? Bo śla­do­wa­nie, by było moż­li­we do prze­pro­wa­dze­nia, wyma­ga prze­cho­dze­nia od jed­ne­go do dru­gie­go” w cało­ści (jeden do jed­ne­go lub jeden do wie­lu ale w cało­ści), nie moż­na przejść od jed­ne­go wyma­ga­nia np. biz­ne­so­we­go do dwóch i pół wyma­gań funk­cjo­nal­nych. To muszą być cał­ko­wi­te i jed­no­znacz­ne licz­by wymagań.

Jak widać wyma­ga­nia biz­ne­so­we to cele, cele lokal­ne (dzia­ły, pio­ny), więc będzie ich kil­ka­na­ście, kil­ka­dzie­siąt przy dużych pro­jek­tach, obej­mu­ją­cych cała orga­ni­za­cję. Jeden cel biz­ne­so­wy to jed­na lub kil­ka (rzad­ko wię­cej) usług jakich ocze­ku­je­my od nowe­go roz­wią­za­nia. Tak więc nale­ża­ło­by się spo­dzie­wać kil­ku­dzie­się­ciu usług roz­wią­za­nia a nie kil­ku tysię­cy wyma­gań”. Pomijając dłu­gie dywa­ga­cje o defi­ni­cjach (były już na tym blo­gu) poniż­szy sche­mat (model poję­cio­wy) poka­zu­je związ­ki pomię­dzy spo­ty­ka­ny­mi w lite­ra­tu­rze, wyma­ga­nia­mi i ich repre­zen­ta­cja­mi (tu przy­pad­ki uży­cia w UML).

Wymagania

Na dia­gra­mie zazna­czy­łem z pomo­cą tak zwa­ne­go dzie­dzi­cze­nia” (strzał­ka z nie­wy­peł­nio­nym gro­tem wska­zu­je uogól­nio­ne poję­cie, jej dru­gi zaś koniec poję­cie szcze­gó­ło­we). Zwykła linia to powią­za­nie pomię­dzy poję­cia­mi (fakt łączą­cy róż­ne poję­cia). Tak więc wyma­ga­nia wobec roz­wią­za­nia to pewien pod­zbiór wyma­gań biz­ne­so­wych (nie wszyst­kie cele biz­ne­so­we muszą wią­zać się z kon­kret­nym roz­wią­za­niem). Wymagania wobec roz­wią­za­nia to wła­śnie spor­ne, nie­jed­no­znacz­ne, poję­cia spo­ty­ka­ne w lite­ra­tu­rze. To co moż­na potwier­dzić, to podział wszyst­kich wyma­gań” wobec roz­wią­za­nia na funk­cjo­nal­ne i nie­funk­cjo­nal­ne. Mimo bra­ku ich ści­słych defi­ni­cji (czym jest moż­li­wość łatwe­go doda­wa­nia danych kon­tra­hen­ta z listy??) wie­my, że są tyl­ko te dwa. Wymagania nie­funk­cjo­nal­ne dzie­li się (mię­dzy inny­mi) na jako­ścio­we i dzie­dzi­no­we, te dru­gie to logi­ka biz­ne­so­wa i algo­ryt­my. Mamy jed­nak pre­cy­zyj­ną defi­ni­cję poję­cia przy­pa­dek uży­cia (mam na myśli defi­ni­cję w spe­cy­fi­ka­cji nota­cji UML), jest to usłu­ga sys­te­mu, świad­czo­na akto­ro­wi (na jego żąda­nie, a wiec ini­cjo­wa­na przez akto­ra), któ­rej pro­dukt ma war­tość dla akto­ra bo jest celem korzy­sta­nia z sys­te­mu przez tego akto­ra. Tak więc przy­pad­kiem uży­cia jest to, że sys­tem pozwa­la na wytwo­rze­nie fak­tu­ry VAT” a nie to, że pozwa­la wybrać kon­tra­hen­ta z listy po klik­nię­ciu myszą”. Każda usłu­ga sys­te­mu, jego przy­pa­dek uży­cia, zwią­za­ny jest ze kon­kret­ną logi­ką jego zre­ali­zo­wa­nia (wyko­na­nia) czy­li wyma­ga­niem dziedzinowym.

Śladowanie. Jak pomaga? 

Mając listę celów pro­jek­tu, okre­śla­my, któ­re pla­nu­je­my zre­ali­zo­wać z pomo­cą nowe­go opro­gra­mo­wa­nia – to wyma­ga­nia wobec roz­wią­za­nia. Wymagania wobec roz­wią­za­nia opi­su­je­my skoń­czo­ną licz­bą wyma­ga­nych usług sys­te­mu, do któ­rych jed­no­znacz­nie przy­po­rząd­ko­wu­je­my wyma­ga­nia jako­ścio­we (np. dostęp­ność) i dzie­dzi­no­we (np. wzór na war­tość podat­ku). Całość mode­lu­je­my jako przy­pad­ki uży­cia i model dzie­dzi­ny (przy­pad­ki uży­cia – usłu­gi sys­te­mu – są reali­zo­wa­ne ele­men­ta­mi mode­lu dzie­dzi­ny, kla­sa­mi lub kom­po­nen­ta­mi reali­zu­ją­cy­mi okre­ślo­ną logi­kę). Skąd brać przy­pad­ki uży­cia? Z warsz­ta­tów? Sesji burzy mózgów? Kiepski pomysł, co napi­sa­łem na począt­ku. Jeżeli już jed­nak to robi­my to śla­do­wa­nie pozwa­la pano­wać nad zakre­sem pro­jek­tu i zło­żo­no­ścią całej doku­men­ta­cji wyma­gań: po zatwier­dze­niu wyma­gań biz­ne­so­wych, odrzu­ca­my wszyst­kie zgła­sza­ne wyma­ga­nia funk­cjo­nal­ne i nie­funk­cjo­nal­ne, któ­re nie wspie­ra­ją (nie dają się zaadre­so­wać – śla­do­wać) wyma­gań biz­ne­so­wych. Skąd brać przy­pad­ku uży­cia? Najlepiej z mode­li pro­ce­sów, bo te są zwe­ry­fi­ko­wa­nym (tu śla­do­wa­nie aktyw­ność – przy­pa­dek uży­cia) mode­lem dzia­ła­nia orga­ni­za­cji. Śladowanie wyma­ga jed­nak ści­słych – jed­no­znacz­nych, defi­ni­cji. Skoro nie da się jed­no­znacz­nie zde­fi­nio­wać funk­cjo­nal­no­ści sys­te­mu”, nie sto­suj­my tego poję­cia. Pojęcie usłu­ga sys­te­mu jest dobrze zde­fi­nio­wa­ne, w UML jest to przy­pa­dek uży­cia, w SOA i archi­tek­tu­rze kor­po­ra­cyj­nej, usłu­ga apli­ka­cyj­na koja­rzo­na jest (mapo­wa­na, śla­do­wa­na) z ele­men­tar­ny­mi (ato­mo­wy­mi) pro­ce­sa­mi biz­ne­so­wy­mi (aktyw­no­ścia­mi). 

Tak więc wyma­gań biz­ne­so­wych może być kil­ka­dzie­siąt. Wymaganych usług sys­te­mu (przy­pad­ków uży­cia) w dużym pro­jek­cie tak­że może być kil­ka­dzie­siąt. Ale set­ki, czy tysią­ce wyma­gań” to wyraz utra­ty pano­wa­nia nad zakre­sem pro­jek­tu… Tu zwró­cę uwa­gę, że wyma­ga­niem (usłu­ga sys­te­mu) może być np. wytwo­rzo­na fak­tu­ra VAT zgod­na z prze­pi­sa­mi. Cechy tej fak­tu­ry (lista pól) to nie osob­ne wyma­ga­nia, to cechy (para­me­try, atry­bu­ty) jed­ne­go wyma­ga­nia. Żadna cecha fak­tu­ry VAT nie ma sama w poje­dyn­kę żad­nej war­to­ści, nie może więc być oddziel­nym przy­pad­kiem uży­cia, tak samo jak wyma­ga­niem naszym może być samo­chód, ale jego kolor czy auto­ma­tycz­na skrzy­nia bie­gów, to cechy samo­cho­du, nie ma sen­su wyma­gać czer­wo­ne­go kolo­ru” nie ocze­ku­jąc samo­cho­du (i jak uza­sad­nić, to że ten kolor wspie­ra cel biz­ne­so­wy). Przypadkiem uży­cia samo­cho­du jest podróż a nie wło­że­nie klu­czy­ka do sta­cyj­ki, bo to jest tyl­ko jeden z ele­men­tów sce­na­riu­sza roz­po­czę­cia podró­ży samochodem.

Czemu tak czę­sto jed­nak powsta­ją nie­we­ry­fi­ko­wal­ne spe­cy­fi­ka­cje na set­ki pozy­cji? Najczęściej sły­szę – z ust ana­li­ty­ka – głu­pie tłu­ma­cze­nie: bo tak mi poka­za­no na szko­le­niu (tak czy­ta­łem w jed­nej książ­ce, tak było napi­sa­ne na blo­gu XXX, tak robi się u mnie w fir­mie itp…). Warto sobie same­mu udo­wod­nić popraw­ność wytwo­rze­nia efek­tów swo­jej pra­cy, a dobra doku­men­ta­cja ana­li­tycz­na jest sama dla sie­bie dowo­dem popraw­no­ści. Tak, mój blog tak­że nale­ży weryfikować.

Produkty w procesie analizy wymagań

W arty­ku­le Inżynieria wyma­gań mię­dzy inny­mi opu­bli­ko­wa­łem tak­so­no­mię wyma­gań, jej roz­wi­nię­ta postać:

taksonomia wymagań

Temat wyma­gań regu­lar­nie wypły­wa na forach dys­ku­syj­nych i na kon­fe­ren­cjach. Ostatnio w podob­nej for­mie poja­wił się na pew­nym forum ser­wi­su LinkedIn i na dzi­siej­szej kon­fe­ren­cji. Na forum padło pyta­nie: co wybrać jako doku­men­ta­cje wyma­gań: SRS czy Use Case (odpo­wied­nio [[Software Requirements Specification]] czy­li [[spe­cy­fi­ka­cja wyma­gań na opro­gra­mo­wa­nie]] i Przypadki Użycia opro­gra­mo­wa­nia). Na dzi­siej­szej kon­fe­ren­cji zaś praw­nik, pod­czas swo­je­go refe­ra­tu, zwró­cił uwa­gę na fakt, że od stro­ny umów, pro­jek­ty – od ana­li­zy przed­wdro­że­nio­wej do dostar­cze­nia zamó­wio­ne­go opro­gra­mo­wa­nia – nale­ży dzie­lić pro­jekt na fazy będą­ce, zależ­nie od celu, umo­wą efek­tu (umo­wa o dzie­ło) i umo­wą sta­ran­ne­go dzia­ła­nia (umo­wa zlecenia).

Problem w tym, że SRS – czę­sto rozu­mia­ne jako doku­ment o struk­tu­rze opi­sa­nej w [[reko­men­da­cji IEEE830]], zawie­ra w pew­nej for­mie przy­pad­ki uży­cia (ale nie ich sce­na­riu­sze) rozu­mia­ne jako opis funk­cjo­nal­no­ści. Do tego reko­men­da­cja ta nie jest stan­dar­dem zawar­to­ści doku­men­tu a rekomendacją. 

SRS_IEEE830-1998Topics

Pojęcie przy­pad­ku uży­cia ma co naj­mniej dwie zupeł­nie róż­ne defi­ni­cje: jed­ną rodem z książ­ki Alistair’a Cockbourna Jak pisać efek­tyw­ne przy­pad­ki uży­cia”, dru­ga w spe­cy­fi­ka­cji nota­cji UML. Osobiście pre­fe­ru­ję te dru­gą i tyl­ko o nie będzie tu mowa (Cockbourn zresz­tą jaw­nie wyra­ża nie­chęć do UML w swo­jej książce).

Dla upo­rząd­ko­wa­nia dal­szej tre­ści przyj­mu­ję, że poję­cie przy­pa­dek uży­cia opro­gra­mo­wa­nia i funk­cjo­nal­ność opro­gra­mo­wa­nia są toż­sa­me (a kon­kret­nie przy­pa­dek uży­cia opi­su­je spo­sób reali­za­cji funk­cjo­nal­no­ści): obie okre­śla­ją to jaki efekt chce osią­gnąć (do cze­go użyć), w kon­kret­nym przy­pad­ku, użyt­kow­nik opro­gra­mo­wa­nia (kon­kret­na funk­cja jaką peł­ni opro­gra­mo­wa­nie, to jego moż­li­wy przy­pa­dek użycia).

Popatrzmy na eta­py pro­jek­tu, któ­re wyróż­nio­no na bazie tego, jakiej wie­dzy potrze­bu­je­my na każ­dym z tych eta­pów, by zapla­no­wać kolejny.

Etapy projektu

Jako pierw­sze powsta­ją wyma­ga­nia biz­ne­so­we opra­co­wa­ne na bazie oce­ny sytu­acji biz­ne­so­wej. Są one albo wła­snym pro­duk­tem Zamawiającego albo pro­duk­tem zatrud­nio­ne­go do tego celu eks­per­ta. Na bazie wyma­gań biz­ne­so­wych (celów biz­ne­so­wych) wyko­nu­je się ana­li­zę wyko­ny­wal­no­ści tych celów, powsta­je pomysł roz­wią­za­nia pro­ble­mu (osią­gnię­cia celu) w posta­ci wyma­gań wobec reko­men­do­wa­ne­go roz­wią­za­nia. Jeżeli ist­nie­je (zna­le­zio­no) na ryn­ku roz­wią­za­nie (pro­dukt lub stan­dar­do­wą usłu­gę) zosta­je ono zaku­pio­ne i wdro­żo­ne. Jeżeli nie (doty­czy nie tyl­ko cało­ści ale i czę­ści wyma­gań) nale­ży roz­wią­za­nie naj­pierw zapro­jek­to­wać a potem dopie­ro zle­cić wyko­na­nie i wdro­że­nie (a wcze­śniej na bazie pro­jek­tu wycenić).

Każdy z tych pro­duk­tów to przed­miot osob­nej umo­wy (lub jej eta­pu). Zależnie od stop­nia nie­wie­dzy” po stro­nie Zamawiającego, może to być umo­wa o dzie­ło lub zle­ce­nia. Jednak zale­ca się (praw­ni­cy zale­ca­ją) by, zawsze tam gdzie anga­żo­wa­ny jest eks­pert (usłu­go­daw­ca) zewnętrz­ny, sto­so­wać umo­wy o dzie­ło (umo­wa efek­tu), gdyż pozwa­la to pano­wać i nad cza­sem i nad budże­tem pro­jek­tu oraz w przy­pad­ku spo­ru sądo­we­go, moż­li­we było okre­śle­nie przed­mio­tu spo­ru (opis tego co mia­ło zostać wytwo­rzo­ne – dzieło).

Do zawar­cia umo­wy o dzie­ło koniecz­ny jest opis tego co ma powstać (opis dzie­ła). Patrząc od koń­ca: zawie­ra­jąc umo­wę z dostaw­cą opro­gra­mo­wa­nia mamy wyma­ga­nia wobec pro­duk­tu goto­we­go (w momen­cie zaku­pu speł­nia je lub nie) lub wyko­na­ny pro­jekt tego co ma powstać. Aby powstał pro­jekt musi­my mieć okre­ślo­ne wyma­ga­nia wobec roz­wią­za­nia i wyma­ga­nia (cele) biz­ne­so­we. Najtrudniej jest wyce­nić etap ana­li­zy sytu­acji biz­ne­so­wej bo tu w zasa­dzie nie wie­my jaka ta sytu­acja jest. Wymagania biz­ne­so­we, by powsta­ły, wyma­ga­ją pozy­ska­nia wie­dzy o tym jak funk­cjo­nu­je orga­ni­za­cja Zamawiającego i jakie zmia­ny pla­nu­je. To etap ana­li­zy biz­ne­so­wej (model moty­wa­cji biz­ne­so­wej i mode­le pro­ce­sów biz­ne­so­wych). W tym wypad­ku będzie to raczej umo­wa sta­ran­ne­go dzia­ła­nia z eks­per­tem, któ­ry tę ana­li­zę (i mode­le) wykona.

Pewnym roz­wią­za­niem pro­ble­mu ryzy­ka umo­wy czas i mate­riał” (nie wie­my kie­dy i jakim kosz­tem powsta­nie ocze­ki­wa­ny pro­dukt), jest okre­śle­nie tego jaki kon­kret­nie pro­dukt ma powstać (opis tego, jak stwier­dzi­my, że pra­ce wyko­na­no popraw­nie) i okre­śle­nia cza­su jaki sobie na to daje­my. Wymaga to pew­nej inwe­sty­cji, poświę­ce­nia cza­su na to, ale opła­ci się bo moc­no obni­ża­my ryzy­ko projektu.

Konkluzja praw­ni­ka, by zawie­rać umo­wy o dzie­ło jeże­li tyl­ko jest to moż­li­we, jest moim zda­niem słusz­na. Tam gdzie nie mamy wystar­cza­ją­cej wie­dzy by zawie­rać takie umo­wy, war­to zain­we­sto­wać czas by okre­ślić jed­nak przed­miot umo­wy, gdyż umo­wa zle­ce­nia z eks­per­tem (dostaw­cą opro­gra­mo­wa­nia) powo­du­je, że Zamawiający kom­plet­nie nie panu­je nad umo­wą: nie wie jakie­go pro­duk­tu ocze­ki­wać, satys­fak­cja z wyko­na­nej pra­cy może nadejść w trud­nym do prze­wi­dze­nia czasie.

Druga uwa­ga: jeże­li cały pro­ces, od pierw­szej ana­li­zy do dostar­cze­nia pro­duk­tu, reali­zu­je jed­na fir­ma, mamy do czy­nie­nia z sytu­acją, w któ­rej dostaw­ca sam kon­tro­lu­je sta­wia­ne mu wyma­ga­nia bo sam sobie defi­niu­je to co ma następ­nie wytwo­rzyć. Taki brak kon­tro­li rodzi poważ­ne ryzy­ko nierzetelności.