Proszę się dokład­nie zapo­znać z poniż­szą tre­ścią, ten doku­ment opi­su­je stan­dar­do­wy spo­sób komu­ni­ka­cji w każ­dym moim pro­jek­cie. W tek­ście tym opi­su­ję dla­cze­go pra­cu­ję na doku­men­tach. Z uwa­gi na to, że rolą człon­ków zespo­łu Zamawiającego jest aktyw­ny udział w ana­li­zie i pro­jek­to­wa­niu, opi­su­ję tu tak­że pod­sta­wo­we typy i cele two­rze­nia sche­ma­tów blo­ko­wych. Rolą Zleceniodawcy tu jako recen­zen­ta w toku pro­jek­tu, jest potwier­dze­nie praw­dzi­wo­ści tre­ści każ­de­go roz­dzia­łu i sche­ma­tu blo­ko­we­go lub zgło­sze­nie do nich uwag. Wystarczającą umie­jęt­no­ścią jest tu czy­ta­nie sche­ma­tów wg. pro­stej legen­dy symboli.

Czym są analiza i modelowanie?

Słownik języ­ka pol­skie­go defi­niu­je ana­li­zę jako: roz­pa­try­wa­nie jakie­goś pro­ble­mu, zja­wi­ska z róż­nych stron w celu jego zro­zu­mie­nia lub wyja­śnie­nia; też: wyja­śnie­nie lub opis, będą­ce wyni­kiem takie­go roz­pa­try­wa­nia, tak­że meto­da badaw­cza pole­ga­ją­ca na wyod­ręb­nie­niu z danej cało­ści jej ele­men­tów i bada­niu każ­de­go z osob­na (https://​sjp​.pwn​.pl/​s​z​u​k​a​j​/​a​n​a​l​i​z​a​.​h​tml). Wynikiem ana­liz są wyja­śnie­nia i opi­sy. Z uwa­gi na zwię­złość, pre­fe­ro­wa­ne są opi­sy w posta­ci sche­ma­tów blo­ko­wych (mode­le), podob­nie w przy­pad­ku pro­jek­to­wa­nia (np. przy­szłe­go roz­wią­za­nia, sta­nu docelowego).

Metody doku­men­to­wa­nia wyni­ków ana­liz, tak­że spe­cy­fi­ko­wa­nia wyma­gań na opro­gra­mo­wa­nie, opar­te na samo­dziel­nym spi­sy­wa­niu swo­ich doświad­czeń, cha­rak­te­ry­zu­ją się powsta­wa­niem nie­kom­plet­nych i nie­spój­nych opra­co­wań, bar­dzo czę­sto zawie­ra­ją­cych wie­le szcze­gó­łów, nie­istot­nych w takich ana­li­zach .

Celem ana­liz biz­ne­so­wych orga­ni­za­cji, przed­się­biorstw itp. jest zro­zu­mie­nie mecha­ni­zmu ich dzia­ła­nia i tego jak powsta­ją ich pro­duk­ty oraz ich sfor­ma­li­zo­wa­ne mode­lo­wa­nie. Nie jest ich celem deta­licz­ne opi­sy­wa­nie pra­cy ludzi i maszyn. Dlatego od wie­lu lat prak­ty­ka i bada­nia poka­zu­ją, że wyso­ką jakość ana­liz – pro­ce­sów biz­ne­so­wych szcze­gól­nie – zapew­nia­ją meto­dy opar­te na two­rze­niu mode­li w opar­ciu o udo­ku­men­to­wa­ne fak­ty .

Dlatego, podob­nie jak wie­lu ana­li­ty­ków na świe­cie, zre­zy­gno­wa­łem z wywia­dów i cyklicz­nych gru­po­wych warsz­ta­tów w loka­li­za­cji klien­ta, na rzecz pra­cy opar­tej na prze­ka­za­nych mi mate­ria­łach (doku­men­tach) a tak­że (patrz: niska efek­tyw­ność spo­tkań i ich ogrom­ne kosz­ty).

Na pod­sta­wie doku­men­tów źró­dło­wych powsta­ją mode­le pro­ce­sów biz­ne­so­wych i mode­le struk­tur doku­men­tów operacyjnych/formularzy. Jeżeli jakiś ciąg wyda­rzeń wyka­zu­je luki na tych mode­lach, wte­dy wie­dza na ich temat jest uzu­peł­nia­nia w toku krót­kiej roz­mo­wy z oso­ba­mi odpo­wie­dzial­ny­mi za okre­ślo­ny obszar. Taka pra­ca odby­wa się obec­nie cał­ko­wi­cie zdal­nie (wymia­na doku­men­tów, roz­mo­wy, telekonferencje).

W efek­cie łącz­na pra­co­chłon­ność (szcze­gól­nie po stro­nie kadr zama­wia­ją­ce­go) i koszt pro­jek­tu ana­li­tycz­ne­go, są nawet o 70% niż­sze, w porów­na­niu z cyklicz­ny­mi spo­tka­nia­mi i uży­wa­niem opro­gra­mo­wa­nia biu­ro­we­go (ema­il, edy­tor tek­stu, arkusz kal­ku­la­cyj­ny) do komu­ni­ka­cji i wymia­ny tre­ści! (prze­czy­taj też: Dlaczego nie uży­wam pocz­ty elek­tro­nicz­nej do prze­ka­zy­wa­nia mate­ria­łów).

Poniżej sche­mat poka­zu­ją­cy zakres infor­ma­cji potrzeb­nych do wyko­na­nia Analizy Biznesowej i wyspe­cy­fi­ko­wa­nia Wymagań na opro­gra­mo­wa­nie:

Narzędzia i metody komunikacji w projekcie

Podstawowym celem komu­ni­ka­cji jest dostar­cza­nie mi mate­ria­łów źró­dło­wych i recen­zo­wa­nie (uwa­gi do tre­ści) powsta­ją­cej lub aktu­ali­zo­wa­nej doku­men­ta­cji ana­li­tycz­no-pro­jek­to­wej: jest nią Analiza Biznesowa i Opis Techniczny Rozwiązania (dalej Specyfikacja). Dostawcą mate­ria­łów źró­dło­wych jest zawsze zespół orga­ni­za­cji ana­li­zo­wa­nej (tu Recenzent). 

Powyższa pętla to nie raz tyl­ko kil­ka godzin. Analiza całej fir­my to zestaw kil­ku­na­stu, rza­dziej kil­ku­dzie­się­ciu takich pętli. Dokumentacja zarzą­dza­na jest w toku całe­go pro­jek­tu jako tak zwa­na ​„Żyjąca doku­men­ta­cja” .

W trak­cie pro­jek­tu nie uży­wam pakie­tów biu­ro­wych, nie two­rzę arku­szy kal­ku­la­cyj­nych ani doku­men­tów w edy­to­rach tek­stów. Produktem ​„do czy­ta­nia” (i do ewen­tu­al­ne­go dru­ku) jest doku­ment PDF sta­no­wią­cy peł­ną spe­cy­fi­ka­cję z dia­gra­ma­mi i opi­su­ją­cym je tek­stem. Jako pro­dukt pra­cy prze­ka­zu­ję tak­że edy­to­wal­ny plik źró­dło­wy (Visual-Paradigm oraz w uni­wer­sal­nym for­ma­cie XMI) zawie­ra­ją­cy wszyst­kie opi­sy, opra­co­wa­ne mode­le i struktury. 

Jeżeli Zamawiający orga­ni­zu­je spo­tka­nia i warsz­ta­ty są one roz­li­cza­ne jako dodat­ko­we zlecenia! 

Do zdalnej pracy wykorzystuję, i udostępniam klientom, jedno z najlepszych narzędzi wspierających takie projekty na rynku: oprogramowanie PostMania firmy Visual-Paradigm, z którego korzystają największe koncerny na świecie (lista i referencje wybranych użytkowników pakietu Visual-Paradigm, bezpieczeństwo wykorzystywanego repozytorium VP). Visual-Paradigm to narzędzie CASE (ang. Computer Aided System Engineering, komputerowe wspomaganie inżynierii systemów). Stosuję go w całym procesie analizy i modelowania, oraz w toku tworzenia dokumentacji projektowej i zarządzania nią. 

Wszystkie prze­sła­ne mi doku­men­ty są na ser­we­rze chro­nio­ne (kodo­wa­ne), ich kopie zapa­so­we są wyko­ny­wa­ne w try­bie dobo­wym. Powstające tre­ści są wer­sjo­no­wa­ne, wpro­wa­dza­ne zmia­ny są śle­dzo­ne i doku­men­to­wa­ne. Każda nowa treść lub jej zmia­na (zwa­na korek­tą – revi­sion) jest odno­to­wy­wa­na, ozna­czo­na w cza­sie i numerowana. 

Zapoznaj się z opi­sem: Visual Paradigm PostMania – Przewodnik Recenzenta.

Co jest produktem?

Na eta­pie trwa­nia prac ana­li­tycz­no-pro­jek­to­wych ope­ru­je­my dra­ftem opra­co­wa­nia. Zamawiający i recen­zen­ci mają dostęp ​„tyl­ko do odczy­tu”. Po prze­ka­za­niu doku­men­ta­cji Zamawiającemu (pra­wa mająt­ko­we wraz z pra­wem do two­rze­nia utwo­rów zależ­nych), może on two­rzyć jej kolej­ne wer­sje (prze­ka­zu­ją pra­wa do two­rze­nia utwo­rów zależ­nych) lub pra­ce te reali­zu­je autor doku­men­ta­cji w ramach zle­co­ne­go mu nad­zo­ru autor­skie­go i nad­zo­ru mery­to­rycz­ne­go nad pra­ca­mi dostaw­ców systemów. 

Przykładowe pro­duk­ty mojej pra­cy na stro­nie: Analiza Biznesowa i Opis Techniczny Oprogramowania.

Analiza biznesowa

Na tym eta­pie powsta­ją: opi­sy biz­ne­so­wych celów pro­jek­tu, model struk­tu­ry orga­ni­za­cyj­nej, mode­le pro­ce­sów biz­ne­so­wych, opi­sy doku­men­tów biz­ne­so­wych, biz­ne­so­wy słow­nik pojęć.

Biznesowy cel projektu

Zalecanym uzu­peł­nie­niem jest okre­śle­nie biz­ne­so­we­go celu pro­jek­tu na tle misji i wizji orga­ni­za­cji (patrz: Audyt spój­no­ści wizji i misji orga­ni­za­cji z jej dzia­ła­nia­mi):

• misja: (jak sobie wyobra­ża­my nasz przy­szły rynek), 
• wizja: (nasz wkład w osią­gnię­cie powyż­sze­go sta­nu rzeczy),
• cel biz­ne­so­wy orga­ni­za­cji: (pla­no­wa­na pozy­cja na ryn­ku, fuzja, inne), 
• klu­czo­wy pro­blem: (co jest głów­nym powo­dem ini­cja­cji projektu).

Struktura organizacyjna

Podstawą zro­zu­mie­nia dzia­ła­nia orga­ni­za­cji jest jej struk­tu­ra orga­ni­za­cyj­na. Jest ona tak­że pod­sta­wą okre­śla­nia ról i kom­pe­ten­cji na mode­lach pro­ce­sów biz­ne­so­wych. Dokumentowana jest poniż­szą metodą:

Powyższy sche­mat to sfor­ma­li­zo­wa­na struk­tu­ra orga­ni­za­cyj­na zobra­zo­wa­na jako ​„drze­wo zależ­no­ści prze­ło­żo­ny-pod­wład­ny” (lub komór­ka nad­rzęd­na podrzędna). 

Przepływ pracy czyli procesy biznesowe

Definicja pro­ce­su biz­ne­so­we­go brzmi: 

zde­fi­nio­wa­ny zestaw dzia­łań biz­ne­so­wych, któ­re repre­zen­tu­ją kro­ki wyma­ga­ne do osią­gnię­cia celu biz­ne­so­we­go, obej­mu­je prze­pływ i wyko­rzy­sta­nie infor­ma­cji oraz zasobów.

Notacja BPMN, Glossary 

Dlatego model pro­ce­sów to dia­gram obra­zu­ją­cy łań­cuch aktyw­no­ści i ich celów (doku­men­ty jako infor­ma­cje). Zasoby są repre­zen­to­wa­ne przez role wyko­naw­ców. Detale aktyw­no­ści, jeże­li są wyma­ga­ne, doku­men­to­wa­ne są osob­no jako pro­ce­du­ry (patrz opis: Proces a pro­ce­du­ra)

Na powyż­szym sche­ma­cie poka­za­no pro­ces biz­ne­so­wy: aktyw­no­ści oraz ich dane wej­ścio­we i wyj­ścio­we. Wszelkie dodat­ko­we deta­le nio­są doku­men­ty (sym­bo­le z zagię­ty­mi roga­mi na dia­gra­mie powy­żej), regu­ły biz­ne­so­we (spi­sy­wa­ne w posta­ci zesta­wie­nia w tre­ści opra­co­wa­nia lub na sche­ma­tach np. powy­żej: Budżetowanie. BR002).

Dokument i jego treść 

Struktury doku­men­tów nio­są naj­wię­cej deta­licz­nych infor­ma­cji o prze­twa­rza­nych danych i związ­kach mie­dzy nimi, są doku­men­to­wa­ne jako ich uprosz­czo­ne sza­blo­ny, np. jak ten poniżej:

Struktury te uzu­peł­nia­my regu­ła­mi ich popraw­no­ści (regu­ły biz­ne­so­we), defi­ni­cje pól i obsza­rów to ele­ment biz­ne­so­we­go słow­ni­ka pojęć (zawie­ra mię­dzy inny­mi nazwy wszyst­kich klu­czo­wych ele­men­tów na dia­gra­mach opi­su­ja­cych doku­men­ty i formularze). 

Biznesowy słownik pojęć – ontologia

Podstawą zro­zu­mia­ło­ści i jed­no­znacz­no­ści doku­men­ta­cji jest jed­no­li­ty, spój­ny i kom­plet­ny słow­nik pojęć dla całe­go pro­jek­tu (gene­ral­nie doty­czy całej orga­ni­za­cji). Celem jest zapew­nie­nie jed­no­znacz­no­ści tre­ści nie tyl­ko doku­men­ta­cji pro­jek­to­wej ale też wszyst­kich ele­men­tów na mode­lach pro­ce­sów, doku­men­tach (for­mu­la­rzach) i ekra­nach sys­te­mu jakim jest opro­gra­mo­wa­nie. Co do zasa­dy słow­nik ma postać alfa­be­tycz­nej listy, jed­nak klu­czo­we poję­cia dzie­dzi­no­we, dodat­ko­wo wery­fi­ku­je­my z pomo­cą tak zwa­ne­go mode­lu poję­cio­we­go (dia­gram klas UML, lub model fak­tów SBVR, ). Jest to sche­mat blo­ko­wy, na któ­rym umiesz­cza­my wybra­ne poję­cia i łączy­my je związ­kiem gene­ra­li­za­cji lub okre­ślo­nym fak­tem (pre­dy­kat). W ten spo­sób spraw­dza­my, czy poję­cia te two­rzą para­mi popraw­ne i praw­dzi­we zda­nia w języ­ku natu­ral­nym danej dzie­dzi­ny wie­dzy. Np. poniżej:

Powyższe czy­ta­my:

• kopia doku­men­tu i ory­gi­nał doku­men­tu to rodzaj (typ) dokumentu
• fak­tu­ra jest typem dokumentu
• sys­tem kan­ce­la­ryj­ny zapew­nia popraw­ny obieg dokumentów
• doku­ment jest przy­po­rząd­ko­wa­ny do sprawy

UWAGA! Ten dia­gram to nie jest pro­ces biz­ne­so­wy! To model onto­lo­gicz­ny sto­so­wa­ny do mode­lo­wa­nia i wery­fi­ka­cji słow­nic­twa dzie­dzi­no­we­go, podob­ny jak te budo­wa­ne w sys­te­mach sztucz­nej inteligencji.

Wymagania na oprogramowanie

Wymaganiem na opro­gra­mo­wa­nie jest treść opi­su jego dzia­ła­nia: Opis Techniczny Oprogramowania (patrz: pro­ces ICONIX). Poniżej jego klu­czo­we opi­sa­no ele­men­ty. Jednak gorą­co odra­dzam tu samo­dziel­ne spi­sy­wa­nie ​„co i jak sys­tem ma coś robić” albo, co gor­sza, samo­dziel­ne two­rze­nie nie­sfor­ma­li­zo­wa­nych sche­ma­tów blo­ko­wych i opi­sów pro­ce­sów czy sys­te­mów IT, gdyż przy­no­si to wię­cej szko­dy niż pożyt­ku: samo­dziel­ne opra­co­wy­wa­nie tych sche­ma­tów pro­sty­mi pro­gra­ma­mi biu­ro­wy­mi, przez nie­przy­go­to­wa­ne do tego i nie­do­świad­czo­ne oso­by, jest pra­co­chłon­ne a uzy­ska­ne efek­ty i tak zawsze wyma­ga­ją ana­li­zy i for­ma­li­za­cji przez ana­li­ty­ka .

Usługi systemu czyli Co system ma robić

Każde opro­gra­mo­wa­nie (apli­ka­cja) moż­na opi­sać skoń­czo­ną listą usług jakie to opro­gra­mo­wa­nie świad­czy ele­men­tom swo­je­go oto­cze­nia (użyt­kow­nik i inne apli­ka­cje). Jeżeli to opro­gra­mo­wa­nie jest dopie­ro pla­no­wa­ne do zaku­pu, to lista taka jest zbio­rem wyma­gań wobec tego nowe­go opro­gra­mo­wa­nia. Na tym eta­pie nie ma zna­cze­nia to czy będzie to opro­gra­mo­wa­nie stan­dar­do­we czy dedykowane.

Do zbu­do­wa­nia takiej listy moż­na użyć burzy mózgów, jed­nak z powo­dów opi­sa­nych na począt­ku, znacz­nie efek­tyw­niej­szą meto­dą jest ana­li­za biz­ne­so­wa i wska­za­nie na mode­lach pro­ce­sów aktyw­no­ści, któ­re chce­my wes­przeć opro­gra­mo­wa­niem (trans­for­ma­cja mode­lu pro­ce­sów na model wyma­ga­nych usług apli­ka­cji). W efek­cie powsta­je pro­sty dia­gram (dia­gram przy­pad­ków uży­cia UML), sta­no­wią­cy zobra­zo­wa­nie usług apli­ka­cji jakich ocze­ku­je­my od nowe­go oprogramowania:

Kolejny etap to zebra­nie listy potrzeb przy­szłych użyt­kow­ni­ków. Są to wyra­żo­ne języ­kiem biz­ne­so­wym (natu­ral­nym) ocze­ki­wa­nia wobec tych usług.

Potrzeby Zamawiającego czyli wymagania biznesowe

Kluczowe poję­cie na tym eta­pie to

potrze­ba: funk­cja, któ­rej bra­ku­je (jest ocze­ki­wa­na) do osią­gnię­cia celu lub wyko­na­nia działania

Wymagania biz­ne­so­we (tak­że capa­bi­li­ty requ­ire­ment) to zesta­wie­nie potrzeb wyra­żo­nych jako «potrze­by inte­re­sa­riu­szy». Zestawienie to nale­ży dostar­czyć w posta­ci tabeli:

Źródło wyma­ga­nia	Potrzeba (ocze­ki­wa­na zdol­ność systemu)	Obecny pro­blem
Dyrektor Logistyki	Zarzadzanie dosta­wa­mi nie­za­leż­nie dla każ­de­go zamówienia	Brak moż­li­wo­ści nad­zo­ru bie­żą­ce­go sta­nu czę­ścio­wej reali­za­cji zamówień
Dyrektor Handlowy	Dokumentowanie sprze­da­ży promocyjnej	Ręczne wsta­wa­nie do fak­tur cen innych niż katalogowe
Prezes	Bieżące śle­dze­nie war­to­ści przychodów	Brak wie­dzy o bie­żą­cej war­to­ści sprze­da­ży w okre­ślo­nym okresie

Mechanizm działania systemu

Każda usłu­ga apli­ka­cji cechu­je się okre­ślo­nym mecha­ni­zmem jej reali­za­cji. Standardowo przy­pi­su­je się jej okre­ślo­ny doku­ment z mode­lu pro­ce­sów. Na eta­pie doku­men­to­wa­nia usług apli­ka­cji mogą sie poja­wić inne, uzu­peł­nia­ją­ce sche­ma­ty blokowe: 

Poszczególne doku­men­ty mogą mieć sta­ny i sta­tu­sy, mode­lo­wa­ne jak poniżej:

Architektura systemu

Na eta­pie opi­su wyma­gań nie wia­do­mo, któ­re usług apli­ka­cji zre­ali­zu­je wybra­ne opro­gra­mo­wa­nie (np. ERP). Aplikacje dedy­ko­wa­ne wyma­ga­ją opi­sa­nia archi­tek­tu­ry HLD i LLD. Z uwa­gi na spe­cy­fi­kę każ­dej orga­ni­za­cji wyma­ga­ne jest tak­że zapro­jek­to­wa­nie inte­gra­cji sys­te­mów. Jednak adre­sa­tem tych doku­men­tów są inży­nie­ro­wie dostaw­ców, nie są one recen­zo­wa­ne przez Zamawiającego. 

Spotkania

W ramach reali­zo­wa­nej usłu­gi odby­wa­ją się spo­tka­nia sta­tu­so­we (usta­le­nia pla­no­wa­nych dzia­łań w pro­jek­cie). Wszelkie dodat­ko­we warsz­ta­ty ini­cjo­wa­ne przez Zamawiającego sta­no­wią dodat­ko­we płat­ne spotkania. 

Spotkania są reali­zo­wa­ne jako video- i tele- kon­fe­ren­cje. Standardowo wysy­łam link do spo­tka­nia on-line. Jeżeli macie Państwo w swo­jej fir­mie wdro­żo­ny swój wła­sny sys­tem wide­okon­fe­ren­cyj­ny, może być on uży­wa­ny w pro­jek­cie. Jedynym ogra­ni­cze­niem jest brak koniecz­no­ści insta­lo­wa­nia dedy­ko­wa­ne­go opro­gra­mo­wa­nia na moim komputerze. 

Etap realizacji po wyborze dostawcy

Po wybo­rze Wykonawcy, na pod­sta­wie doku­men­tu Analiza Biznesowa i Opis Techniczny Systemu (Analiza), Wykonawca opra­co­wu­je doku­ment Koncepcja Wdrożenia, któ­ry zawie­ra opis spo­so­bu speł­nie­nia wyma­gań opi­sa­nych w Analizie (pier­wot­nie sta­no­wi ona załącz­nik do Zapytania Ofertowego). Dotyczy to każ­de­go Wykonawcy z osob­na: mode­le inte­gra­cji są w Analizie. 

Wszelkie wąt­pli­wo­ści doty­czą­ce tre­ści Analizy (bra­ku­ją­ce deta­le, nie­jed­no­znacz­no­ści itp.) Wykonawca wyja­śnia zada­jąc pyta­nia do tre­ści Analizy (pyta­nia prze­ka­zu­je auto­ro­wi Analizy lub Zamawiającemu). Po wypra­co­wa­niu odpo­wie­dzi po stro­nie Zamawiającego Analiza jest aktu­ali­zo­wa­na i prze­ka­zy­wa­na wyko­naw­cy jako odpo­wiedź na zada­ne pyta­nia. Co do zasa­dy Analiza jest jedy­nym doku­men­tem źró­dło­wym dla Wykonawcy. 

Koncepcja Wdrożenia, sta­no­wi szcze­gó­ło­wy opis tego co wyko­na i dostar­czy Wykonawca. W toku reali­za­cji jeże­li Wykonawca pyta o kolej­ne potrzeb­ne mu deta­le, w odpo­wie­dzi dosta­je uszcze­gó­ło­wio­ną Analizę. Na tej pod­sta­wie aktu­ali­zu­je Koncepcję Wdrożenia o kolej­ne deta­le reali­zo­wa­nej imple­men­ta­cji (wdro­że­nia). W takim cyklu postę­pu­ją kolej­ne pra­ce wdrożeniowe.

W ten spo­sób, w dniu zakoń­cze­nia pro­jek­tu doku­ment Analiza sta­no­wi doku­ment opi­su­ją­cy fir­mę Zamawiającego na dzień zakoń­cze­nia wdro­że­nia, a doku­ment Koncepcja Wdrożenia sta­no­wi doku­men­ta­cję powy­ko­naw­czą dostar­czo­ne­go roz­wią­za­nia . W całym pro­jek­cie Analiza i Koncepcja Wdrożenia, to jedy­ne for­mal­ne doku­men­ty pro­jek­to­we. Pisemne wnio­ski o ich uzu­peł­nie­nie sta­no­wią wyłącz­nie histo­rię przy­czyn zmian, załączniki. 

W całym pro­jek­cie pod­sta­wo­wym narzę­dziem komu­ni­ka­cji jest sys­tem Postmania. Inne narzę­dzia wyma­ga­ją uzgod­nie­nia, jed­nak sam pro­ces nie ule­ga zmia­nie: jedy­nym źró­dłem infor­ma­cji dla Wykonawcy jest ana­li­za, wszel­kie inne robo­cze doku­men­ty (notat­ki ze spo­tkań i roz­mów) sta­no­wią mate­riał źró­dło­wy do aktu­ali­za­cji Analizy. 

Źródła