Systems Engineering Fundamentals by United States Government

Tak, taką książ­kę moż­na nabyć na Amazonie ;). Streszczenie na stro­nach sprze­daw­cy odda­je dobrze jej treść:

This book pro­vi­des a basic, con­cep­tu­al-level descrip­tion of engi­ne­ering mana­ge­ment disci­pli­nes that rela­te to the deve­lop­ment and life cyc­le mana­ge­ment of a sys­tem. For the non-engi­ne­er it pro­vi­des an ove­rview of how a sys­tem is deve­lo­ped. For the engi­ne­er and pro­ject mana­ger it pro­vi­des a basic fra­me­work for plan­ning and asses­sing sys­tem development.

Ogólnie książ­ka opi­su­je pod­sta­wo­wy kon­cep­cyj­ny etap inży­nie­rii sys­te­mów (i nie nale­ży tego utoż­sa­miać tyl­ko z bran­żą IT). Jest napi­sa­na przy­stęp­nym języ­kiem, adre­so­wa­na głów­nie dla mana­ge­rów (pierw­sze czę­ści) by zapo­znać ich z inży­nie­rią sys­te­mów i sys­te­mo­wym podej­ściem. Kierownikom pro­jek­tów poka­zu­je” czym (ewen­tu­al­nie ;)) zarządzają.

Tu tyl­ko kil­ka słów. Najpierw po raz kolej­ny cytat:

Problemy, w któ­rych roz­wią­za­niu mają pomóc budo­wa­ne zło­żo­ne sys­te­my są zwy­kle ?pro­ble­ma­mi zło­śli­wy­mi? (Rittel i Webber, 1973). ?Problem zło­śli­wy? to taki skom­pli­ko­wa­ny pro­blem, w któ­rym jest tak wie­le powią­za­nych ze sobą bytów, że nie ist­nie­je jego osta­tecz­na spe­cy­fi­ka­cja. Prawdziwy cha­rak­ter pro­ble­mu obja­wia się dopie­ro w mia­rę opra­co­wy­wa­nia rozwiązania.

A teraz dia­gram obra­zu­ją­cy pro­ces inży­nie­rii sys­te­mo­wej” na bazie jed­nej z ilu­stra­cji w tej książce:

Proces inżynierii systemowej

Mamy tu trzy klu­czo­we eta­py, powią­za­ne iteracyjnie:

  1. Analiza wyma­gań, cho­dzi tu o wyma­ga­nia biznesowe.
  2. Analiza funk­cjo­nal­no­ści, cho­dzi tu o usta­le­nie do jakich rze­czy» sys­tem jest potrzeb­ny (prze­zna­czo­ny).
  3. Projektowanie czy­li pró­ba opra­co­wa­nia kon­struk­cji, mecha­ni­zmu dzia­ła­nia tego systemu.

Trzeci punkt to wła­śnie klucz do suk­ce­su: zanim zacznie­my kon­stru­owa­nie (np. pisa­nie kodu) war­to opra­co­wać to roz­wią­za­nie «na papie­rze”. To po pierw­sze pozwa­la unik­nąć ogrom­nych kosz­tów roz­po­zna­nia bojem” a po dru­gie daje jako pro­dukt bar­dzo dobrą (na wyso­kim pozio­mie abs­trak­cji ale kom­plet­ną) doku­men­ta­cję dzia­ła­nia systemu.

Niedawno cyto­wa­łem arty­kuł o poraż­ce sys­te­mu e‑border, tym razem innych cytat:

The Home Office had a con­cept, not a well-deve­lo­ped set of requ­ire­ments. Concepts need a reali­ty check; other­wi­se, you could be cha­sing a dre­am! Even tho­ugh the pro­gram ran a pilot to eva­lu­ate the feasi­bi­li­ty of the con­cept, the National Audit Office report (2015) cla­ims that it did not cover all aspects of the solu­tion. Consequently, the pro­gram­me was exe­cu­ted with an unte­sted con­cept and unk­nown requ­ire­ments, which led to dispu­tes. (Źródło: Blueprints Are Not Requirements!)

Jedną z głów­nych przy­czyn poraż­ki było roz­po­czę­cie reali­za­cji pro­jek­tu wyłącz­nie na bazie wizji, bez jakich­kol­wiek ana­liz i pro­jek­to­wa­nia tego co na praw­dę ma powstać i w jakich warun­kach”. Patrząc na zobra­zo­wa­ny powy­żej pro­ces inży­nie­rii sys­te­mo­wej wyko­na­no wyłącz­nie pierw­szy etap (wyma­ga­nia biz­ne­so­we) i przy­stą­pio­no do reali­za­cji pro­jek­tu bez jakich­kol­wiek ana­liz i pro­jek­to­wa­nia, od razu zaczę­ły powsta­wać pro­to­ty­py… Projekt e‑border zakoń­czył się spek­ta­ku­lar­ną porażką.

Jedną z nota­cji OMG jest SysML. Jest to dedy­ko­wa­ny dla inży­nie­rii sys­te­mów pro­fil UML. Odnosząc się do pro­ce­su inży­nie­rii sys­te­mo­wej powy­żej, powsta­ją w tej nota­cji kolej­ne diagramy:

  1. dia­gram wyma­gań (lub ich specyfikacja),
  2. dia­gram przy­pad­ków uży­cia i ich specyfikacja,
  3. model dzie­dzi­ny (mecha­nizm dzia­ła­nia sys­te­mu: dia­gra­my kom­po­nen­tów, klas i obiek­tów) oraz mode­le zacho­wa­nia sys­te­mu (dia­gra­my sekwen­cji, komu­ni­ka­cji, sce­na­riu­sze przy­pad­ków użycia).

Powyższe to wyma­ga­ne mini­mum dla popraw­ne­go wyspe­cy­fi­ko­wa­nia sys­te­mu zanim powsta­nie choć jeden wiersz kodu czy wykop pod fundament.

Z infor­ma­cji jakie posia­dam, od lat rząd USA nie pono­si takich spek­ta­ku­lar­nych pora­żek pro­jek­to­wych jak euro­pej­skie rzą­dy, jed­nak w przy­pad­ku pro­jek­tów kor­po­ra­cyj­nych już tak różo­wo nie jest :), wpad­ki mają wszystkie:

According to an often-quoted stu­dy from the Gartner Group, 75% of IT pro­jects fail. The Standish Group con­ducts an annu­al survey of IT pro­jects. Their latest report shows a decre­ase in pro­ject suc­cess rates.

  1. 32% of all pro­jects suc­ce­eded: deli­ve­red on time, on bud­get, with requ­ired features.
  2. 44% were chal­len­ged: late, over bud­get, and/or with less than the requ­ired features.
  3. 24% failed: can­cel­led prior to com­ple­tion or deli­ve­red and never used.

When we look back, we not only see failu­res but can cle­ar­ly see the boom the softwa­re indu­stry has been given with its suc­cess. But the wor­ry­ing aspect is that the­re are failu­res that are recur­ring eve­ry year, may­be in a dif­fe­rent orga­ni­za­tion but mostly with com­mon cau­ses. (Źródło: Blueprints Are Not Requirements!)

Polecam książ­kę 😉

Systems Engineering Fundamentals Kindle Edition by United States Government US Army (Author) (Źródło: Amazon​.com: Systems Engineering Fundamentals eBook: United States Government US Army: Kindle Store)

Nowoczesne metody inżynierii systemów

Bardzo cie­ka­wa książ­ka, przy­dat­na każ­de­mu kto zaj­mu­je się nie tyl­ko inży­nie­rią opro­gra­mo­wa­nia (ale tą tak­że). Analiza sys­te­mo­wa, pro­jek­to­wa­nie sys­te­mów, to szer­sza dzie­dzi­na niż tyl­ko IT. O ogól­nej teo­rii sys­te­mów następ­na książka.

Modern Methods of Systems Enginieering to rodzaj pod­ręcz­ni­ka. Kolejne roz­dzia­ły opi­su­ją meto­dy i narzę­dzia sto­so­wa­ne w pro­jek­tach z obsza­ru sze­ro­ko poję­tej inży­nie­rii sys­te­mów. Można tu zna­leźć opis pro­ce­sów ana­li­zy sys­te­mo­wej, spis tre­ści klu­czo­wych doku­men­tów w kolej­nych eta­pach prac. Co nie­co o nota­cji SysML (Systems Modeling Language).

Opisana tu meto­da i narzę­dzia pra­cy są zgod­ne (kom­pa­ty­bil­ne) z [[DoD Systems Engineering Fundamentals]], [[NASA Systems Engineering Handbook]] i [[INCOSE Systems Engineering Handbook]].

Książka jest adre­so­wa­na zarów­no do począt­ku­ją­cych (pozna­ją meto­dę ana­li­zy) jak i do doświad­czo­nych ana­li­ty­ków (porów­na­ją opi­sa­ne tu meto­dy ze tymi któ­re sami stosują).

Końcowe roz­dzia­łu nawią­zu­ją do nota­cji UML i SysML. Książkę pole­cam jako opis meto­dy a nie jako boga­ty opis ana­li­zy. Bliżej jej do takich pozy­cji jak PMBook czy BABook niż do boga­tych opi­sów teo­rii i prak­ty­ki analizy.

Tytuł: Modern Methods of Systems Enginieering: With an Introduction to Pattern and Model Based Methods

Autorzy: Joe Jenney (Author), Mike Gangl (Contributor), Rick Kwolek (Contributor), David Melton (Contributor), Nancy Ridenour (Contributor), Martin Coe (Contributor)

Inżynieria wymagań

W grud­niu 2011 roku napi­sa­łem na zakoń­cze­nie pew­ne­go arty­ku­łu o wymaganiach:

Większość pro­jek­tów takich jak np. wdra­ża­nie nowych metod kon­tro­lin­gu, zrów­no­wa­żo­nej kar­ty wyni­ków, nowych sys­te­mów IT itp. cier­pi głów­nie z powo­du posia­da­nia nad­mia­ru infor­ma­cji z jed­nej stro­ny i kom­plet­ne­go jej nie­zro­zu­mie­nia z dru­giej. Sławne już w bada­niach ?złe i nie­kom­plet­ne wyma­ga­nia? czy ?zmia­ny zakre­su pro­jek­tu w trak­cie jego trwa­nia? to kla­sycz­ne skut­ki złej (a czę­sto pomi­ja­nia!) ana­li­zy biz­ne­so­wej. Koszty tych pora­żek wie­lo­krot­nie prze­wyż­sza­ją koszt takich ana­liz. (Analiza biz­ne­so­wa ? sku­tecz­ne mode­lo­wa­nie a ryzy­ko pro­jek­tu).

Specyfikowanie wyma­gań, zarzą­dza­nie wyma­ga­nia­mi, inży­nie­ria wyma­gań, to jak widać bar­dzo trud­ny etap pro­jek­tu. Trudność bie­rze się stad, że dostęp­ne zale­ce­nia okre­śla­ją, że wyma­ga­nia maja być np. spój­ne i kom­plet­ne ale zupeł­nie nie opi­su­ją jak to osią­gnąć (a nawet jak to spraw­dzić).

Często moż­na się spo­tkać z poję­ciem inży­nie­ria wyma­gań”. Budzi ono mój opór z dwóch powo­dów: zna­cze­nie sło­wa inży­nie­ria w j.polskim i nie­ade­kwat­ność tego sło­wa do dzie­dzi­ny jaką jest spe­cy­fi­ko­wa­nie wyma­gań, któ­re są po pro­tu listą warunków.

Zajrzyjmy do słow­ni­ka języ­ka polskiego:

inży­nie­ria ?pro­jek­to­wa­nie i kon­stru­owa­nie obiek­tów oraz urzą­dzeń technicznych?

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

Więc jak rozu­mieć zło­że­nie inży­nie­ria wyma­gań”? Ja nie wiem, chy­ba, że ktoś uwa­ża, że wyma­ga­nia się kon­stru­uje”, i że są to zagad­nie­nia tech­nicz­ne. Za to ma sens inży­nie­rii sys­te­mów”. Mamy def. poję­cia system:

sys­tem ?układ ele­men­tów mają­cy okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?

Gdyby defi­ni­cje sło­wa inży­nie­ria” okro­ić z tech­nicz­nych” albo uznać, że sys­te­my są tak­że nie tech­nicz­ne (bo są np. spo­łecz­ne) to mamy wdzięcz­na definicję:

inży­nie­ria sys­te­mów ?pro­jek­to­wa­nie i kon­stru­owa­nie ukła­dów ele­men­tów mają­cych okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?

Jeden z moich ulu­bio­nych auto­rów aka­de­mic­kich, Ian Sommeville (lubię go tak­że za to, że książ­ki pisze w pubach popi­ja­jąc piwo ;)) defi­niu­je inży­nie­rię wyma­gań tak:

Requirements engi­ne­ering (RE) refers to the pro­cess of for­mu­la­ting, docu­men­ting and main­ta­ining softwa­re requ­ire­ments (źr. Kotonya G. and Sommerville, I. Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley & Sons)

(poję­cie inży­nie­rii wyma­gań odno­si do pro­ce­su for­mu­ło­wa­nia, doku­men­to­wa­nia i zarzą­dza­nia wymaganiami)

Tak więc uzna­jąc, że wyma­ga­nia na sys­te­my to ele­ment inży­nie­rii tych sys­te­mów, niniej­szym godzę się uży­wać poję­cia inży­nie­ria wyma­gań” w zna­cze­niu jakim opi­sał to Sommerville :).

Po co tyle glę­dze­nia o sło­wach i ich zna­cze­niach? Poza szu­ka­niem” ali­bi dla ist­nie­nia poję­cia inży­nie­ra wyma­gań” chcę poka­zać, że sło­wa mają zna­cze­nie, zanie­dby­wa­nie tego pro­wa­dzi do wie­lu nie­po­ro­zu­mień (nie­jed­no­znacz­ność) a po dru­gie zwra­cam uwa­gę, że ana­li­za poję­cio­wa to jeden z klu­czo­wych ele­men­tów ana­li­zy w ogó­le (i czę­sto zaniedbywana).

Skoro wyma­ga­nia to warun­ki, to aż pro­si się by te warun­ki spraw­dzać. Patrzmy do słownika:

spraw­dzać ?skon­tro­lo­wać, zba­dać, czy coś jest zgod­ne z praw­dą, czy coś zosta­ło zro­bio­ne prawidłowo?

Tak więc wnio­sek jest pro­sty: wyma­ga­nie (każ­de!) powin­no być spraw­dzal­ne! Bez tego nie jeste­śmy w sta­nie okre­ślić czy coś” speł­nia te wyma­ga­nia, czy­li czy zda­nie: dostar­czo­ny pro­dukt jest zgod­ny z wyma­ga­nia­mi” jest praw­dzi­we czy nie (a nie chce­my oddać roz­strzy­ga­nia tego prawnikom ;)).

Inżynieria wymagań

Skoro więc ugią­łem się i uzna­łem poję­cie inży­nie­rii wyma­gań, popa­trz­my na to sys­te­mo­wo. Jak zawsze pro­ste jest pięk­ne więc co ana­li­zu­je­my w inży­nie­rii sys­te­mo­wej i inży­nie­rii wymagań:

Granice systemu

matrioszkaPojęcie sys­tem” to tak­że super­sys­tem (sys­tem nad­rzęd­ny) i pod­sys­tem (sys­tem pod­rzęd­ny, część sys­te­mu). To trosz­kę jak zna­ne wam, być może, matriosz­ki 🙂 (figur­ki jed­na w drugiej…).

Jest to, nazew­nic­two, bar­dzo waż­ne, bo w jed­nym pro­jek­cie (doku­men­ta­cji) nale­ży zacho­wać bez­względ­ną dys­cy­pli­nę poję­cio­wą, czy­li sło­wo System powin­no się odno­sić wyłącz­nie do kon­kret­ne­go pozio­mu opi­su, resz­ta to ele­men­ty sys­te­mu nad­rzęd­ne­go lub podrzędnego.

Mianem sys­tem okre­śla się zwy­cza­jo­wo spe­cy­fi­ko­wa­ne opro­gra­mo­wa­nie, jed­nak pro­blem poja­wi się natych­miast, gdy dotknie­my takich pojęć jak wyma­ga­nia funk­cjo­nal­ne na opro­gra­mo­wa­nie i wyma­ga­nia biz­ne­so­we. To ostat­nie nie­sie pew­ną nie­ja­sność. Bo nie wiem czy cho­dzi o wyma­ga­nia wobec (w sto­sun­ku do) biz­ne­su (np. popra­wa jako­ści obsłu­gi klien­ta o 5% w naj­bliż­szym bada­niu jako­ści ISO) czy wyma­ga­nia biz­ne­su wobec (w sto­sun­ku do) opro­gra­mo­wa­nia (np. mini­ma­li­za­cja do zera otrzy­ma­nych i zagu­bio­nych zapy­tań ofertowych).

Popatrzmy na powyż­szy dia­gram. Mamy tu dwa Systemy:

  1. Organizacja jest pod­sys­te­mem, jest ele­men­tem sys­te­mu, któ­rym tu jest rynek na jakim ta orga­ni­za­cja funkcjonuje.
  2. Organizacja jest ana­li­zo­wa­nym sys­te­mem, opro­gra­mo­wa­nie jest jed­nym z zaso­bów tej orga­ni­za­cji (opro­gra­mo­wa­nie jest tu podsystemem).

Wymagania może­my tu odno­sić w sto­sun­ku do Organizacji i w sto­sun­ku do Oprogramowania. To dla­te­go jasno wyod­ręb­nia­my ana­li­zę biz­ne­so­wą (pro­duk­tem są mode­le biz­ne­so­we i wyma­ga­nia biz­ne­so­we) od ana­li­zy wyma­gań na opro­gra­mo­wa­nie (mode­le i wyma­ga­nia na opro­gra­mo­wa­nie). Jak widać wyma­ga­nia na opro­gra­mo­wa­nie to wyma­ga­nia, któ­rych źró­dłem jest biz­nes, któ­ry ma kon­kret­ne cele do osią­gnię­cia. Nie powin­ny być one poboż­ny­mi życze­nia­mi użyt­kow­ni­ków, aż do momen­tu gdy spon­sor pro­jek­tu nie powie np.: moim celem jest wygo­da pra­cy moich pra­cow­ni­ków. Oczywiście, ta wygo­da jest zawsze wyma­ga­na ale nie musi ona być celem samym w sobie i nie musi mieć naj­wyż­sze­go priorytetu.

Wymagania inte­re­sa­riu­szy. Moja defi­ni­cja inte­re­sa­riu­sza (jed­na z wie­lu): oso­ba (pod­miot) zain­te­re­so­wa­na zaist­nie­niem pro­duk­tu, na któ­rą poja­wie­nie się pro­duk­tu ma wpływ. Nie raz jestem pyta­ny czy inte­re­sa­riusz ma pra­wo zgła­sza­nia wyma­gań. Jeżeli ma coś do powie­dze­nia pod­czas odbio­ru pro­duk­tu to zna­czy, że ma wyma­ga­nia. One mogą być jed­nak nie­jaw­ne czy­li taki inte­re­sa­riusz nie zgła­sza wyma­gań ale ma wpływ na odbiór pro­duk­tu, nale­ży go koniecz­nie ziden­ty­fi­ko­wać. Jeżeli zaś ktoś nie ma nic do gada­nia przy odbio­rze pro­duk­tu nie jest inte­re­sa­riu­szem (ang. sta­ke­hol­der, klu­czem jest tu «hol­der» czy­li dys­po­nent mają­cy coś do powie­dze­nia, mają­cy wpływ). Tak wiec inte­re­sa­riusz to ktoś kto, na swo­im pozio­mie ogól­no­ści, tak­że musi umieć okre­ślić, kie­dy uzna, że pro­dukt speł­nia jego wyma­ga­nia. Jak nie potra­fi, ktoś musi mu pomóc…analityk :)).

I tu rola ana­li­ty­ka. Interesariusz spi­su­je co mu przyj­dzie do gło­wy swo­im języ­kiem, ana­li­tyk upew­nia się, że zro­zu­miał, dopro­wa­dza je do posta­ci testo­wal­nej i kla­sy­fi­ku­je wyma­ga­nia” jako źró­dło: kon­kret­ny inte­re­sa­riusz” (bo każ­de wyma­ga­nie musi mieć wła­ści­cie­la). Proszę zwró­cić uwa­gę, że inte­re­sa­riu­szem jest tak­że użyt­kow­nik jeże­li tyl­ko ma coś go powie­dze­nia w projekcie :).

Popatrzmy na wymaganie:

Wymagania

Wymaganie jest jed­no (waru­nek jaki coś musi speł­nić) ale może ono mieć wie­le atry­bu­tów i tu widzę zło­żo­ność” wyma­gań (ich [[tak­so­no­mia]]). Zarówno wysta­wia­nie fak­tur VAT” jak i dostęp­ność 99,99% cza­su” to rów­no­praw­ne wyma­ga­nia bo opro­gra­mo­wa­nie np. wspo­ma­ga­ją­ce sprze­daż jest bez­war­to­ścio­we zarów­no gdy nie pozwa­la wysta­wiać fak­tur jak wte­dy, gdy czę­sto się psu­je. Owszem, jed­no jest funk­cjo­nal­ne dru­gie jest poza-funk­cjo­nal­ne ale jed­no i dru­gie to rów­no­praw­ny waru­nek przy­dat­no­ści” czy­li Wymaganie wobec oprogramowania.

Jak wspo­mnia­łem, wyma­ga­nia są (war­to tak robić) kla­sy­fi­ko­wa­ne za pomo­cą atry­bu­tów. Najczęściej spo­ty­ka­ne to: rodzaj (Kind), źró­dło wyma­ga­nia (Source), pole­cam tak­że prio­ry­tet, meto­dę wery­fi­ka­cji (np. test, audyt zgod­no­ści z opi­sem w doku­men­ta­cji), sta­tus (pla­no­wa­ne, zaakc­pe­to­wa­ne, odrzu­co­ne, …) i inne, zależ­nie od wyma­gań i typu projektu.

Ważna uwa­ga i zale­ce­nie IIBA: zarzą­dza­nie wyma­ga­nia­mi zabra­nia” ich usu­wa­nia (albo renu­me­ra­cji po usu­nię­ciu). usu­wa­nie powo­du­je to nie­spój­ność wer­sjo­no­wa­nej doku­men­ta­cji, któ­ra tak­że ma swój cykl życia. Ja od dłuż­sze­go cza­su sto­su­ję dodat­ko­wy sta­tus odrzu­co­ne”, co daje mi cią­głość doku­men­ta­cji a tak­że pozwa­la na odwie­sze­nie” wcze­śniej zde­fi­nio­wa­ne­go wyma­ga­nia, gdy ktoś jed­nak uzna, że coś co było zbęd­ne nagle zno­wu sta­je się konieczne :).

Liczba pytań i suge­stii (tak­że na kil­ku forach dys­ku­syj­na) skło­ni­ła mnie do pod­ję­cia pró­by zbu­do­wa­nia tak­so­no­mii wyma­gań. Jak już wspo­mnia­łem wyżej, zale­ce­nia takie jak FURPS to nie­ste­ty tyl­ko pła­ska lista cech” (i nie wszyst­kich). Wydaje mi się, że struk­tu­ra wyma­gań, ich tak­so­no­mia wza­jem­ne zależ­no­ści oraz rela­cje do udzia­łow­ców pro­jek­tu (inte­re­sa­riu­sze) i przy­szłych użyt­kow­ni­ków roz­wią­za­nia, wyma­ga­ją bar­dziej for­mal­ne­go podej­ścia. Celem jest uzy­ska­nie moż­li­wo­ści spraw­dza­nia czy wyma­ga­nia – jako przed­miot inży­nie­rii wyma­gań – speł­nia­ją jakieś, trze­ba je stwo­rzyć, wymagania.

Taksonomia wymaganPowyżej pró­ba usys­te­ma­ty­zo­wa­nia wyma­gań” na bazie wyżej cyto­wa­nych defi­ni­cji tego pojęcia.

Na koniec jesz­cze kolej­na waż­na rzecz. Warto wska­zy­wać, któ­re ele­men­ty logi­ki biz­ne­so­wej (Model) odpo­wia­da­ją (są powią­za­ne) z danym wyma­ga­niem bo np. szcze­gó­ło­wo opi­su­ją wyma­ga­ny spo­sób reali­za­cji dane­go wyma­ga­nia (np. sys­tem upu­stów albo kon­kret­ny przy­pa­dek uży­cia, tak­że Model). Warto tak­że, jeże­li opis wyma­ga­nia nie jest testem, zapro­jek­to­wać test (przy­pa­dek testo­wy), któ­ry potwier­dzi speł­nie­nie wyma­ga­nia np. opro­gra­mo­wa­nie ma pozwa­lać na wyli­cza­nie pier­wiast­ków dru­gie­go i trze­cie­go stop­nia”. Tu war­to podać kil­ka kon­kret­nych danych wej­ścio­wych wraz z pra­wi­dło­wy­mi wyni­ka­mi (może to doty­czyć nap. tabe­li upu­stów, sys­te­mu sko­rin­gu klien­tów itp.).

Tego typu meto­dy maja nazwę deklaratywnych:

Programowanie dekla­ra­tyw­ne ? rodzi­na para­dyg­ma­tów pro­gra­mo­wa­nia, któ­re nie są z natu­ry impe­ra­tyw­ne. W prze­ci­wień­stwie do pro­gra­mów napi­sa­nych impe­ra­tyw­nie, pro­gra­mi­sta opi­su­je warun­ki, jakie musi speł­niać koń­co­we roz­wią­za­nie (co chce­my osią­gnąć), a nie szcze­gó­ło­wą sekwen­cję kro­ków, któ­re do nie­go pro­wa­dzą (jak to zro­bić). Programowanie dekla­ra­tyw­ne czę­sto trak­tu­je pro­gra­my jako pew­ne hipo­te­zy wyra­żo­ne w logi­ce for­mal­nej, a wyko­ny­wa­nie obli­czeń jako ich dowo­dze­nie. Programowanie dekla­ra­tyw­ne jest szcze­gól­nym przed­mio­tem zain­te­re­so­wa­nia naukow­ców, gdyż dzię­ki mini­ma­li­za­cji lub eli­mi­na­cji skut­ków ubocz­nych może zna­czą­co upro­ścić two­rze­nie pro­gra­mów współ­bież­nych. Paradygmat pro­gra­mo­wa­nia dekla­ra­tyw­ne­go obej­mu­je sze­ro­ką gamę języ­ków pro­gra­mo­wa­nia i bar­dziej szcze­gó­ło­wych para­dyg­ma­tów pod­rzęd­nych. (Programowanie dekla­ra­tyw­ne ? Wikipedia, wol­na ency­klo­pe­dia).