Zadávací dokumentace a její zpracování¶

Úvod¶

Tato kapitola zavádí Zadávací dokumentaci jako vstup analytické práce a její Zdroje, její zpracování jako řízený převod na strukturovaný výpis, a čtyři výsledky toho zpracování: Funkční požadavek, Nefunkční a technologický požadavek, Mimo a Neurčeno.

Všechny tyto pojmy tvoří oblast Požadavky, tedy první ze tří oblastí Analytické dokumentace.

Zpracování Zadávací dokumentace je řízený převod vstupních materiálů zadavatele na strukturovaný výpis, se kterým analytik dále pracuje místo původních zdrojů. Proces je podobný destilaci, kdy se z původního materiálu vyrobí sirup a ten se dál používá místo něj.

Ruční převod bývá pro analytika dlouhým úkolem; AAF ho formalizuje tak, aby se dal řídit pravidly.

Zadávací dokumentace¶

Zadávací dokumentace je souhrn všech vstupních materiálů od zadavatele, ze kterých analytik čerpá. Má libovolný formát, od jednostránkového e-mailu po rozsáhlou sadu dokumentů, tabulek a prezentací.

Je to evidovaný pojem, ne to, co přišlo. Mail, který dorazil a leží v poště, je řeč a je venku. Týž mail umístěný na dohodnutou pozici, odkud se má zpracovat, je evidovaná Zadávací dokumentace a patří dovnitř Analytické dokumentace, přesně tak jako Funkční požadavek, který z něj vznikne.

Rozhoduje tedy evidence, ne autorství. Že materiál vznikl u zadavatele a ne u analytika, je informace o původu, ne o příslušnosti. Je to týž vztah jako mezi papírovou fakturou na stole a evidovanou fakturou; podrobněji viz Zrcadlení pojmů.

Zadávací dokumentace je autoritativní zdroj pro zpracování. Po vzniku výpisu se k ní analytik dále nevrací; výpis, především Funkční požadavky, se stává jediným pracovním vstupem dalších etap AAF.

Rozlišující znaky¶

Externí původ, vnitřní umístění. Materiály vznikají mimo AAF a analytik je nevytváří, ale přebírá. Externí je původ, ne umístění. Případné úpravy probíhají v komunikaci se zadavatelem, ne přímou editací.
Heterogenita. Materiály mají různé formáty, různá období vzniku, různé autory a často různou míru aktuálnosti.
Nekonzistence. Materiály se mohou rozcházet, opakovat anebo si protiřečit. Spor, který nelze rozhodnout, se stává Neurčeno.
Smíšená rovina. Vedle analytických požadavků obvykle obsahuje i technologii, implementaci a organizaci. Oddělit je je právě úkolem zpracování.
Greenfield a Brownfield. V Greenfieldu Zadávací dokumentace vzniká pro daný projekt a obvykle drží novější informace. V Brownfieldu existuje historicky, bývá rozsáhlejší a část informací nese také živý systém.

Zdroj¶

Zdroj je jedna jednotka Zadávací dokumentace, ze které se při zpracování čerpá: konkrétní dokument, nebo jeho jednoznačně určená část. Zadávací dokumentace se skládá ze Zdrojů; Zdroj je její část, ne samostatný vstup.

Zdroj má vlastní identitu, a tou je dokument a místo v něm. Podle ní se pozná, že dvě položky vznikly z téhož místa, a podle ní se dá k původu položky vrátit. Zdroj nese také datum vzniku dokumentu, je-li známé.

Zdroj má také umístění, tedy dohodnutou pozici, na které evidovaný materiál leží a odkud se zpracovává. Dnes je to obvykle adresář a soubor, může to být i záznam v databázi; podoba pozice je věc technologického návrhu, její existence je věc analýzy. Umístění není součástí identity Zdroje: týž dokument může být přemístěn a zůstává týmž Zdrojem.

Zadávací dokumentace i Zdroj žijí nejdřív venku: jako maily, jako soubory na sdíleném disku se zadavatelem, jako zápisy ze schůzek. Zaevidováním, tedy umístěním na dohodnutou pozici, z nich vznikají evidované prvky. Je to totéž Zrcadlení pojmů jako u Zadávací dokumentace jako celku, jen o úroveň níž.

Rozlišující znaky¶

Část, ne celek. Zdroj je část Zadávací dokumentace. Zadávací dokumentace je celek, ze kterého se skládá.
Surovina, ne výsledek. Ze Zdroje se položky tvoří; Zdroj sám položkou není a zpracováním nevzniká.
Právě jeden Zdroj na položku. Každá položka výpisu nese právě jeden Zdroj. Říká-li totéž více Zdrojů, vznikne více položek, každá se svým Zdrojem; sloučení je pozdější rozhodnutí, ne součást zpracování.
Násobnost v řeči a v evidenci. Venku má Zadávací dokumentace vždy aspoň jeden materiál. Evidovaná Zadávací dokumentace se ale založí a Zdroje se do ní přidávají, takže smí být chvíli prázdná. Je to týž případ jako faktura bez řádku, viz Zrcadlení pojmů.
Umístění zní technicky, ale technologie to není. Že Zdroj někde leží, je vlastnost evidovaného pojmu; adresář, soubor nebo databáze je jen její dnešní podoba. Viz Úrovně abstrakce, chyba technicky znějící pojem vydaný za technologii.

Zpracování Zadávací dokumentace¶

Zpracování Zadávací dokumentace je řízený převod jejího obsahu na čtyři výsledky. Je to přechod z roviny řeči do roviny evidence: to, o čem zadavatel mluví, se rozhodnutím analytika stává evidovanou položkou. Prvky ve vstupu nejsou, vznikají až zpracováním. Viz Zrcadlení pojmů.

Postup ve čtyřech krocích¶

Pořadí kroků je závazné.

Krok 1. Rozlož formulaci na jednotlivá tvrzení. Jedno souvětí obvykle nese víc než jedno tvrzení.

Krok 2. U každého tvrzení se zeptej, zda je to o našem systému. Když s jistotou ne, je to Mimo a dál se neptáš. Rozhoduje se tu hranice prvku podle Objektového paradigmatu, položená jako otázka čí je věc, o které tvrzení mluví: kdo ji podle zadání eviduje a kdo s ní zachází. Vede-li ji jiný prvek než náš systém, je tvrzení Mimo s pokračováním ano, i když z něj později může plynout požadavek na náš systém; ten vznikne až v pozdější etapě jako vlastní tvrzení a tady se nepředjímá. Chybějící kanál k informaci hranici nerozhoduje: chybí-li našemu systému kanál k jeho věci, je to díra podle Zákona zachování informace a doplní se krok; chybí-li kanál k cizí věci, je to jen potvrzení, že věc je venku.

Krok 3. U zbylých tvrzení se zeptej: musel by analytik kvůli tomuto tvrzení něco přidat nebo změnit v analytickém modelu? Když ano, je to Funkční požadavek. Když ne, a tvrzení je přitom požadavkem na systém, je to Nefunkční a technologický požadavek.

Otázka se klade jednomu tvrzení a má jednu odpověď. Nese-li tvrzení obě, není rozložené a vrací se do kroku 1.

Hranice mezi oběma výsledky je hranice mezi Analytickým modelem IS a Technologickým návrhem IS, viz Úrovně abstrakce; otázka je její operační podoba, protože Analytický model IS je přesně to, co se Funkčním požadavkem mění. Nerozhoduje, jak tvrzení zní ani jakého je tématu, ale co mění.

Krok 4. Co nelze rozhodnout, jde do Neurčeno. Vzniká u obou otázek: když nelze říct, zda je tvrzení o našem systému, i když nelze říct, zda by se analytický model změnil. Totéž platí pro tvrzení, kterému chybí odpověď a bez ní nedrží.

Pořadí je zvolené tak, že kroky 2 a 3 zachovávají informaci a práce pokračuje, kdežto Neurčeno práci zastavuje a čeká na člověka. Neurčeno má být vzácné, jinak se přestane číst.

Rozlišující znaky¶

Jedna formulace dá vzniknout několika položkám. Počet není omezen. Jedno souvětí může vydat několik Nefunkčních a technologických požadavků, k tomu Funkční požadavek a ještě otázku, na kterou v zadání není odpověď.
Úplné zúčtování. Každá formulace skončí v právě jedné přihrádce. Nic se nezahazuje potichu a nic se potichu nepřijímá.
Původ se eviduje vždy. Každá položka nese právě jeden Zdroj. Plyne to ze Zákona zachování informace: nikdo není jasnovidný a každá použitá informace musí mít v modelu zdroj.
Nepředjímá se. Při zpracování se nesmí předjímat, jak se položka použije dál. Rozhoduje se jen z toho, co je ve vstupu.
Jednou a dál se z toho čerpá. Výpis se vytvoří jednou a další etapy pracují s ním, ne s původními materiály.

Funkční požadavek¶

Funkční požadavek je položka na straně čisté logiky užitku. Jedna položka vyjadřuje jednu schopnost systému anebo jedno omezení vůči systému, na úrovni Analytického modelu IS.

Souhrn Funkčních požadavků drží hrubé mantinely systému a slovní skicu toho, co má systém dělat. Nejsou úplným popisem chování. Konkrétní průběhy interakce, datové struktury, alternativní cesty a chybové stavy patří do dalších vrstev AAF.

Příklad: „Systém umí počítat výplaty lektorů automaticky." Vymezuje, co systém má dělat, tedy mantinel akceptace bez automatického výpočtu výplat systém neakceptujeme. Neříká ale jak: kolik vstupních polí, jaká pravidla zaokrouhlování, kdo formulář schvaluje.

Příklad, který zní technologicky: mobilní platba se odehrává v podmínkách nestabilní konexe. Mobil může být dočasně offline, platební brána může selhat, klient nemůže neomezeně čekat. Systém na to musí reagovat, a to mění analytický model: Funkční požadavek „Systém umí přijmout platbu" se v BPM rozloží na proces s gateway pro timeout, opakování a pokračování po obnovení spojení. Je to tedy Funkční požadavek, i když jeho příčina je technologická.

Rozlišující znaky¶

Mantinel, ne výčet. Vyjadřuje, co systém musí umět, aby byl akceptovatelný. Souhrn není výčtem všeho, co systém dělá.
Skica nahrubo. Vystihuje podstatu krátkou slovní formulací.
Analytický model IS. Popisuje užitky systému ve smyslu VBM. Realizace do Funkčního požadavku nepřechází, patří do Nefunkčního a technologického požadavku.
Byznysová podmínka je funkční, i když větví. Podmínka, kterou si systém sám vede (podpis smlouvy, storno, stav rezervace), je čistá logika, i když obsahuje pokud a větvení. Nespadá do Nefunkčního a technologického požadavku jen proto, že zní technologicky.
Ověřuje se funkčním testem. Splnění se ověří chováním systému z pohledu jeho okolí. Co se nedá ověřit funkčním testem, ale jen měřením nebo inspekcí, není Funkční požadavek.
Soběstačnost. Po potvrzení jsou Funkční požadavky autoritativním vstupem dalších etap.
Iterativnost upřesnění. Detaily, které chybí, se rozkrývají v dalších vrstvách. Chybějící detail není defekt, je to očekávaný stav.

Nefunkční a technologický požadavek¶

Nefunkční a technologický požadavek je položka, která je požadavkem na systém, ale analytický model nemění. Mění realizaci, provoz, prostředí nebo měřitelné vlastnosti řešení. Jedna položka vyjadřuje jeden takový požadavek.

Je to doplněk Funkčního požadavku: ostrost hranice nese Funkční požadavek, sem patří všechno ostatní, co je požadavkem na systém. Název jmenuje dva hlavní druhy, které se v něm potkávají: nefunkční, tedy měřitelná vlastnost (odezva, dostupnost, kapacita, škálovatelnost), a technologický, tedy předepsaný nebo vyloučený artefakt (platforma, jazyk, databáze, protokol, formát, prostředí, licence). Je to jedna přihrádka; spojka a je výčtová, ne výzva k dalšímu dělení.

Příklad: „Systém poběží jako třívrstvá aplikace; datová vrstva v Javě nebo v C#." Systém to musí splnit, ale žádný Use Case, proces ani třída se tím nemění. Příklad měřitelné vlastnosti: „Odezva do dvou sekund."

Subškatulky¶

Každý Nefunkční a technologický požadavek je zařazen do jedné nebo více subškatulek z pevného, řízeně rozšiřitelného výčtu. Subškatulky se navzájem nevylučují; o každé se rozhoduje zvlášť. Nefunkční a technologický požadavek, který nesedí do žádné, zůstává bez zařazení; je to ventil, ne chyba. Při nejistotě, zda subškatulka sedí, se do ní nezařazuje; bez zařazení je poctivější než falešně přesná volba. Výčet:

Výkon a kapacita — rychlost, odezva, SLA; objem a růst dat; limity CPU, RAM a I/O; škálovatelnost.
Dostupnost a spolehlivost — vysoká dostupnost, failover, redundance; odolnost proti chybám; zálohy a obnova.
Bezpečnost a soulad — šifrování, řízení identit a přístupu, auditní stopa, ochrana proti útokům; soulad s předpisy.
Integrace a konektivita — technický způsob propojení s okolními systémy; typy sítí a propustnost.
Architektura a nasazení — vrstvení a moduly, cloud versus on-premise, virtualizace a kontejnery, databázová architektura, způsob nasazení a migrace.
Provoz a prostředí — provozní režim, monitoring a logování, geografické a síťové rozmístění.
Kompatibilita prostředí — podporované operační systémy, prohlížeče a zařízení, responzivita, offline režim.
Kvalita a udržovatelnost — testovatelnost, udržovatelnost a modularita, verzování a rollback.
Ekonomické limity — náklady, licence, provoz; energetická náročnost; životnost a obměna.

Subškatulka říká, o čem požadavek je, ne jakého je druhu. Tvrzení o bezpečnosti, které mění analytický model, například auditní stopa změn nebo role a jejich oprávnění, je Funkční požadavek; subškatulka se přiřazuje až tomu, co krokem 3 prošlo jako Nefunkční a technologický požadavek.

Rozlišující znaky¶

Strana Technologického návrhu IS. Týká se realizace a provozního rámce, ne logiky užitku.
Mantinel akceptace. Podmínka, bez jejíhož splnění systém neakceptujeme.
Skica nahrubo. Konkrétní hodnoty, tedy limity, verze a prahy, jsou technologický detail, ne součást formulace.
Ověřuje se měřením nebo inspekcí. Nefunkční požadavek se ověří měřením, technologický inspekcí implementace a prostředí. Funkční test není potřeba, protože chování systému z pohledu okolí se nemění.

Mimo¶

Mimo je formulace, o které se s jistotou ví, že není konstrukcí našeho systému. Rozhoduje se tu hranice prvku podle Objektového paradigmatu, a je to otázka předřazená otázce, zda tvrzení mění analytický model.

Mimo není jen okolí systému. Patří sem i to, co se systémem souvisí, ale není jeho konstrukcí: logo, barevné schéma, inzeráty, obchodní podmínky, ceník. Mají v projektu svého majitele, jen tím majitelem není analytik. Patří sem i vlastnosti projektu, ne systému: kdo systém staví a jak, harmonogram, rozpočet, i to, zda jde o Greenfield.

Mimo je rozhodnutý výsledek, ne nevím. Z pohledu požadavků je to balast, ale balast, o kterém se s jistotou ví, že je balast. Formulace se nezahazuje: eviduje se se zněním a původem.

Pokračování¶

Každá položka Mimo nese rozlišení, zda se jí ještě někdo dotkne:

Pokračování ano — formulace se ještě někde použije. Dnes požadavkem není, ale může se jím stát v některém dalším kroku analytických prací, jakmile se okolí s touto věcí obrátí na náš systém. Ve výpisu požadavků položka zůstává, jak byla; místo, kde se to stalo, na ni odkazuje. Kde a kdy, to se rozhodne později a zpracování to nesmí předepisovat.

Pokračování ne — formulace nemá v projektu majitele a nikdo se k ní nevrátí. Eviduje se jen proto, aby bylo doložitelné, že nebyla přehlédnuta.

Tři pravidla:

Vztah nemusí být přímý. Tisk lístků z webu kina se v systému neprojeví přímo, ale okliku má: aby se dalo tisknout, musí být čím doložit zaplacení.
Při nejistotě se volí pokračování ano. Rozdíl mezi hodnotami neurčuje, co se s položkou stane v modelu, ani jedna se ve zpracování nestává požadavkem; určuje jen, jestli se k ní má někdo vrátit. Chybné ano stojí jeden zbytečný pohled navíc, chybné ne stojí ztracenou informaci.
Dvojí výskyt informace není závada. Popis okolí je zde Mimo s pokračováním a později se táž skutečnost objeví v HLA jako děj okolí. Je to týž fakt ve dvou různých časech a rolích.

Rozlišující znaky¶

Určeno, s jistotou. Patří sem jen to, co je mimo konstrukci systému s jistotou.
Není požadavek. Není Funkční ani Nefunkční a technologický požadavek.
Není zahozeno. Eviduje se znění, původ a krátký důvod.
Hranice s Neurčeno. Když si zpracování není jisté, zda věc patří dovnitř nebo ven, není to Mimo, ale Neurčeno.

Neurčeno¶

Neurčeno je otázka, u které zpracování poctivě neumí rozhodnout, a proto ji předává člověku. Je to výjimka algoritmu determinismu: slibuje se jednoznačný výsledek, a když ho dát nelze, nevymýšlí se, ale vyhodí se otázka.

Má dva důvody. První: zadání samo věc nechává otevřenou; v textu doslova stojí zatím nerozhodnuto, je otázkou, potřebujeme vyjádření. Nic nechybí, chybí rozhodnutí a zadavatel to ví. Druhý: v zadání chybí informace a zadavatel o tom neví; věta vypadá úplně, ale bez chybějícího kusu se nedá dopovědět a možností je víc než jedna. Sem patří i tvrzení, u kterého nelze říct, čí věc to je. Rozdíl mezi oběma důvody je v otázce, která jde ven: u prvního se čeká rozhodnutí, u druhého se hlásí díra v zadání.

Neúplná specifikace není Neurčeno. Tvrzení, které říká, co systém dělá, ale nechává detail otevřený, je Funkční požadavek s poznámkou; chybějící detail je očekávaný stav.

Neurčeno není formulace se zněním, je to otázka. Nese proto popis otázky, stav a původ pro dohledatelnost.

Rozlišující znaky¶

Nevím, ne balast. Liší se od Mimo, kde se ví, že věc do konstrukce systému nepatří.
Není požadavek. Do modelu nevstupuje, dokud ji člověk nerozhodne.
Determinismus se nefalšuje. Hraniční a sporné se nezařazuje náhodně jen proto, aby něco vyšlo.
Není totéž co Nefunkční a technologický požadavek bez zařazení. Ten říká, že věc je Nefunkční a technologický požadavek, jen nesedí do žádné subškatulky. Neurčeno říká, že nevíme, jestli je to vůbec požadavek. Jsou to dva ventily na různých úrovních a rozhodují se v různých okamžicích: Neurčeno při zařazování, subškatulky až poté, co je jasné, že jde o Nefunkční a technologický požadavek.

Nejčastější chyby¶

Zbytnělá Zadávací dokumentace. Velké množství vět mimo zadání. Zpracování je zachytí jako Mimo, ale jejich objem signalizuje chybu na straně zadavatele. Analytik upozorní a nechá zadání pročistit.
Funkční požadavek jako úplná specifikace. Pokus o úplný popis chování už v této fázi. Důsledek: předčasná detailizace vede k nesrovnalostem mezi prvky.
Míchání úrovní ve Funkčním požadavku. Realizace vepsaná do formulace Funkčního požadavku. Náprava: není to balast k zahození, patří do Nefunkčního a technologického požadavku.
Návrat k Zadávací dokumentaci v pozdějších etapách. Přichází se tak o výhodu zpracovaného vstupu a hrozí návrat do nekonzistencí zdrojů.
Předstírané rozhodnutí místo Neurčeno. Násilné zařazení sporné formulace, jen aby něco vyšlo.
Záměna Mimo a Neurčeno. Rozhoduje míra jistoty, ne podobnost formulace.
Zařazení podle tématu místo podle testu. Tvrzení o bezpečnosti, síti nebo výkonu se dá do Nefunkčních a technologických požadavků jen proto, jak zní. Rozhoduje, co tvrzení mění, ne o čem je.
Rozklad jen na dvě položky. Očekává se, že z jedné věty vyjde nanejvýš schopnost a k ní omezení. Počet položek není omezen.
Předjímání dalšího použití. Položka se zařadí podle toho, jak se to nejspíš použije dál, místo podle toho, co v zadání stojí.

Vazby¶

Zadávací dokumentace, její zpracování i všechny čtyři výsledky tvoří oblast Požadavky, jednu ze tří oblastí Analytické dokumentace.

Zpracování je přechod z roviny řeči do roviny evidence, což popisuje Zrcadlení pojmů; totéž zrcadlení stojí i za tím, že evidovaná Zadávací dokumentace a její Zdroje jsou něco jiného než materiály, které přišly. Řez mezi Funkčním a Nefunkčním a technologickým požadavkem vede po hranici mezi Analytickým modelem IS a Technologickým návrhem IS, viz Úrovně abstrakce; otázka mění tvrzení analytický model? je operační podobou té hranice; tatáž kapitola vysvětluje, proč umístění Zdroje zní technicky, a technologie to není. Rozhodnutí, zda je věc uvnitř nebo venku, je vedení hranice prvku podle Objektového paradigmatu. Požadavek na původ každé položky plyne ze Zákona zachování informace. Užitky, kterými jsou Funkční požadavky pojmenovány, drží Axiom Value Based Management. Rozlišení Greenfieldu a Brownfieldu popisuje Greenfield a Strategické modelování.

Z výsledků čerpají další etapy AAF, tedy HLA a LLA. Ty na této kapitole stojí, ne naopak.

Verze a změny¶

4.2 — Sekce Pokračování: položka Mimo s pokračováním ano dnes požadavkem není, ale může se jím stát v některém dalším kroku analytických prací, jakmile se okolí s touto věcí obrátí na náš systém; položka ve výpisu zůstává a místo, kde se to stalo, na ni odkazuje. Vypuštěna věta, že to nikdy nebude Funkční ani Nefunkční a technologický požadavek; platila jen pro okamžik zpracování (pravidlo o nejistotě to teď říká výslovně). Podnětem byl začátek kapitoly HLA na MTP: storno je ve výpisu Mimo s pokračováním ano a v Use Case Epicu se z něj stává cinknutí systému.
4.1 — Krok 2 zpřesněn otázkou čí je věc, o které tvrzení mluví; věc vedená jiným prvkem je Mimo s pokračováním ano, a chybějící kanál hranici nerozhoduje (u vlastní věci je to díra podle Zákona zachování informace, u cizí potvrzení, že je venku). Případy Neurčeno zúženy ze čtyř na dva důvody: zadání samo věc nechává otevřenou, nebo v zadání chybí informace; obecný případ nelze rozhodnout, zda mění model vypuštěn, protože byl následkem obou důvodů, ne třetím důvodem, a stával se odkladištěm. Podnětem byly tři testovací běhy na MTP, kde storno timeout skončilo třikrát v Neurčeno, ačkoli rezervaci vede kino.
4.0 — Krok 3 má jednu otázku místo dvou: musel by analytik kvůli tvrzení něco přidat nebo změnit v analytickém modelu? Ano je Funkční požadavek, ne je druhá přihrádka, definovaná jako doplněk. Neurčeno vzniká výslovně u obou otázek. Pojem Technologický požadavek přejmenován na Nefunkční a technologický požadavek (NTP) a definován jako doplněk Funkčního požadavku; subškatulky beze změny jako témata, ne kritérium. Příklad nestabilní konexe přesunut k Funkčnímu požadavku, protože mění analytický model. Doplněny znaky ověření (funkční test proti měření a inspekci), věta, že neúplná specifikace není Neurčeno, věta, že vlastnosti projektu jsou Mimo, a chyba zařazení podle tématu místo podle testu. Z výčtu případů Neurčeno vypuštěn spor mezi zdroji, protože zpracování po jednom tvrzení rozpor mezi Zdroji nevidí.
3.4 — Doplněno pravidlo pro nejistotu při zařazování do subškatulek: nezařazovat, bez zařazení je poctivější než falešně přesná volba.
3.3 — Technologický požadavek smí být zařazen do jedné nebo více subškatulek; o každé se rozhoduje zvlášť. Hodnota Nezařazeno z výčtu vypuštěna, stav „bez zařazení" je prázdné zařazení. V modelu je zařazení vzorem Vlak má svoje vagóny: Technologický požadavek vlastní seznam zařazení, každé ukazuje na jednu Subškatulku z číselníku.
3.2 — Vypuštěna přednost mladšího dokumentu v Brownfieldu. Zpracování položky do přihrádek zařazuje a nic dalšího z nich neodvozuje. Datum vzniku dokumentu nese Zdroj v Greenfieldu i v Brownfieldu, je-li známé; dosud bylo vázáno jen na Brownfield.
3.1 — Zaveden pojem Zdroj jako jednotka Zadávací dokumentace, ze které se čerpá: identita dokument a místo v něm, v Brownfieldu datum vzniku dokumentu, umístění jako dohodnutá pozice evidovaného materiálu. Doplněno, že Zadávací dokumentace i Zdroj žijí nejdřív venku a evidovanými prvky se stávají zaevidováním, tedy totéž Zrcadlení pojmů o úroveň níž; z toho plyne násobnost v řeči aspoň jeden, v evidenci nula a víc, jako u faktury bez řádku. Umístění Zdroje označeno za pojem analýzy, který jen zní technicky, s odkazem na Úrovně abstrakce. Rozlišující znak původu zpřesněn na právě jeden Zdroj na položku; říká-li totéž více Zdrojů, vznikne více položek. Zdroj doplněn do úvodu a do Vazeb.
3.0 — Kapitola přejmenována ze Zadávací dokumentace a její destilát; pojem destilace zůstává jako přirovnání, ne jako pojem, protože je obecnější než tato kapitola. Zavedena oblast Požadavky a příslušnost k Analytické dokumentaci. Doplněno, že Zadávací dokumentace je evidovaný pojem a že rozhoduje evidence, ne autorství. Zpracování dostalo závazný postup ve čtyřech krocích s předřazenou otázkou na Mimo. Dvojice schopnost a obálka nahrazena otázkami Logika a Technologie; zrušeno omezení na dvě položky z jedné formulace. Mimo rozšířeno o rozlišení pokračování ano a pokračování ne a o to, že sem patří i části projektu mimo konstrukci systému. Doplněn rozlišující znak, čím se Neurčeno liší od subškatulky Nezařazeno. Pojmosloví úrovní abstrakce sjednoceno na Analytický model IS a Technologický návrh IS. Doplněn Zákon zachování informace jako důvod evidence původu a pravidlo o nepředjímání. Vyplněna sekce Vazby. Vypuštěna zmínka o AI a Vibe Analysing.
2.0 — přechod na dvouúrovňovou logiku určeno a neurčeno. Pojem Technická okrajová podmínka nahrazen širším pojmem Technologický požadavek. Zavedeny pojmy Mimo a Neurčeno.
1.0 — první verze kapitoly, zavedení pojmů Zadávací dokumentace, Funkční požadavky a Technické okrajové podmínky.