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)

ECM i EOD czyli od mody do realiów

Obydwa te, spo­ty­ka­ne czę­sto w pra­sie, skró­ty mają wie­le wspól­ne­go: ozna­cza­ją apli­ka­cje zarzą­dza­ją­ce obie­giem infor­ma­cji i jej maga­zy­no­wa­niem (ECM – Electronic Content Management czy­li zarzą­dza­nie tre­ścią w posta­ci elek­tro­nicz­nej oraz EOD – Elektroniczny Obieg Dokumentów). Cechą zawar­tą nie wprost” w tych nazwach jest zarzą­dza­nie tak­że skła­do­wa­niem i prze­pły­wem tej infor­ma­cji. Osiem lat temu pisa­łem o kwe­stiach poję­cio­wych (czym jest wie­dza, jej prze­twa­rza­nie, czym są dane):

Problematyka infor­ma­cji w fir­mach, jej kolek­cjo­no­wa­nia i prze­twa­rza­nia jest czę­stym tema­tem arty­ku­łów w pra­sie spe­cja­li­stycz­nej jak i opi­sem zakre­sów pro­jek­tów IT. Termin ten jest jed­nak nie raz nad­uży­wa­ny. W pra­sie moż­na pozwo­lić sobie na pew­ną dowol­ność jego inter­pre­ta­cji jed­nak w opi­sie zakre­su pro­jek­tu ana­li­tycz­ne­go pozy­cja o nazwie ?Zdefiniowanie potrzeb infor­ma­cyj­nych fir­my? może rodzić poważ­ne kło­po­ty z odbio­rem tej czę­ści pro­jek­tu gdyż tu na dowol­ność inter­pre­ta­cji nie powin­no być miej­sca. (Źródło: Zarządzanie Wiedzą | Jarosław Żeliński IT-Consulting)

Niedawno, 26 stycz­nia 2016, mia­łem refe­rat na kon­fe­ren­cji pod hasłem Business Process Management:

W trak­cie refe­ra­tu zwró­ci­łem uwa­gę na to, że to co czę­sto nazy­wa­my zarzą­dza­niem pro­ce­sa­mi (popu­lar­ny skrót [[BPM]]) biz­ne­so­wy­mi, tak na praw­dę jest zarzą­dza­niem prze­pły­wem pra­cy, zarzą­dza­niem infor­ma­cją i nad­zo­ro­wa­niem tych aktyw­no­ści. Tu zwró­cę uwa­gę na to, że prze­pływ pra­cy odwzo­ro­wy­wa­ny jest w apli­ka­cji jako ciąg rapor­tów i notatek:

prze­ło­żo­ny dowia­du­je się o wyko­pa­niu rowu nie z wła­snej obser­wa­cji a z rapor­tu swo­je­go podwładnego 

dla­te­go opro­gra­mo­wa­nie może ope­ro­wać wyłącz­nie udo­ku­men­to­wa­ny­mi fak­ta­mi a nie zja­wi­ska­mi w real­nym świe­cie: to są zapi­sy jaki­mi zarzą­dza opro­gra­mo­wa­nie zarzą­dza­ją­ce sze­ro­ko poję­tą tre­ścią. Tak więc

zarzą­dza­nie pro­ce­sa­mi biz­ne­so­wy­mi to nic inne­go jak zbie­ra­nie infor­ma­cji, prze­twa­rza­nie ich i decy­do­wa­nie o kolej­nych pra­cach do wyko­na­nia, infor­mu­jąc o tym wyko­naw­ców tych kolej­nych prac.

Aplikacja wspie­ra­ją­ca prze­pływ pra­cy to opro­gra­mo­wa­nie, któ­re pozwa­la na two­rze­nie for­mu­la­rzy (i zasad wery­fi­ka­cji ich popraw­no­ści) spe­cy­ficz­nych dla każ­de­go zada­nia, reguł biz­ne­so­wych narzu­ca­ją­cych opcjo­nal­ność i kolej­ność reali­za­cji zadań (aktyw­no­ści), kate­go­ry­zo­wa­nie tre­ści i zadań, udo­stęp­nia­nie powsta­łych treści:

ECM EOD Przypadki Użycia

Powyższy dia­gram przy­pad­ków uży­cia moż­na w zasa­dzie uznać za refe­ren­cyj­ny”, każ­da apli­ka­cja tego typu tak mogła by wyglą­dać, czy to wystar­czy dostaw­cy opro­gra­mo­wa­nia? Nie, bo cała wie­dza o kon­kret­nym wdro­że­niu tkwi w szcze­gó­łach. Gdzie one są? Pisałem o tym pra­wie rok temu:

Tu war­to na począ­tek wró­cić do kla­sy­fi­ka­cji wyma­gań. W arty­ku­le Inżynieria wyma­gań opi­sa­łem trzy ich rodza­je: (1) funk­cjo­nal­ne czy­li usłu­gi apli­ka­cji (przy­pad­ki uży­cia tej apli­ka­cji), (2) poza-funk­cjo­nal­ne czy­li cechy jako­ścio­we, (3) dzie­dzi­no­we czy­li logi­ka biz­ne­so­wa. I teraz bar­dzo waż­na rzecz: któ­re ele­men­ty archi­tek­tu­ry opro­gra­mo­wa­nia, za reali­za­cję któ­rych wyma­gań odpo­wia­da­ją? (Źródło: Gdzie są te cho­ler­ne szcze­gó­ły | | Jarosław Żeliński IT-Consulting)

Jak widać, klucz tkwi w mode­lu dzie­dzi­ny sys­te­mu czy­li w spe­cy­fi­ce bran­ży, kon­kret­nej fir­my lub orga­ni­za­cji. Powyższe przy­pad­ki uży­cia, jak wyżej, to opis dowol­ne­go ECM/EOD”. Referencyjna archi­tek­tu­ra takie­go sys­te­mu mogła by mieć taką postać:

EOD BPM Architektura referencyjna

Dlaczego tak? Komponent zarzą­dza­ją­cy pro­ce­sa­mi odpo­wia­da za logi­kę kolej­no­ści prze­twa­rza­nia tre­ści. Repozytorium odpo­wia­da za zacho­wy­wa­nie i udo­stęp­nia­nie tre­ści. Dodano tu kom­po­nent Filesystem, gdyż oso­bi­ście jestem zwo­len­ni­kiem podej­ścia, w któ­rym doku­men­ty elek­tro­nicz­ne są skła­do­wa­ne nie w bazie danych (tak zwa­ne BLOB) a na dys­kach, a logi­ka zarzą­dza­nia nimi to odręb­ne opro­gra­mo­wa­nie (patrz euro­pejk­sie zale­ce­nia Moreq). Dzięki temu utra­ta lub zmian apli­ka­cji (i bazy danych) nie powo­du­je utra­ty zasobów.

Na czym więc pole­ga ana­li­za biz­ne­so­wa przed wdro­że­niem EOD/ECM? Czym są tu wyma­ga­nia? Są nimi regu­ły biz­ne­so­we, wzo­ry doku­men­tów i słow­ni­ki pojęć (danych). To tu tkwi naj­więk­sze ryzy­ko wdro­że­nia, klu­czem jest tu zawsze tak zwa­ny model poję­cio­wy. Powyższa archi­tek­tu­ra jest prze­ze mnie trak­to­wa­na jako refe­ren­cyj­na, gdyż gwa­ran­tu­je moż­li­wość odwzo­ro­wa­nia dowol­ne­go sys­te­mu zarzą­dza­nia infor­ma­cją”, taką lub podob­ną zale­ca­ną archi­tek­tu­rę moż­na spo­tkać w wie­lu opra­co­wa­niach na temat ECM.

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ć.

Gdzie są te cholerne szczegóły

Regularnie na moich szko­le­niach oraz w toku pro­jek­tów, dosta­je pyta­nia o wali­da­cje”. Z regu­ły spo­ty­kam spe­cy­fi­ka­cje wyma­gań (albo ocze­ki­wa­nia na takie), zawie­ra­ją­ce zesta­wie­nia doku­men­tów (i for­ma­tek ekra­no­wych), dla każ­de­go zesta­wie­nie pól, dla każ­de­go pola wali­da­cje”. Problem w tym, że:

  • mie­sza­ją się tu tak zwa­ne typy pro­ste danych (zna­ko­we, licz­bo­we, itp.), tak zwa­ne maski” (data, ema­il, itp.), oraz regu­ły biz­ne­so­we (np. wła­ści­wy rabat),
  • z uwa­gi na to, że doku­men­tów jest wie­le, a pola mogą się na nich powta­rzać, powsta­je duża licz­ba powtó­rzo­nych zapi­sów wali­da­cji”, nie­jed­no­krot­nie nie­spój­nych a bywa, że sprzecznych.
  • typy pro­ste oraz regu­ły biz­ne­so­we (logi­ka biz­ne­so­wa) to dwa zupeł­nie inne obsza­ry systemu.

Jak definiować wymagania na walidacje”

Tu war­to na począ­tek wró­cić do kla­sy­fi­ka­cji wyma­gań. W arty­ku­le Inżynieria wyma­gań opi­sa­łem trzy ich rodzaje:

  1. funk­cjo­nal­ne czy­li usłu­gi apli­ka­cji (przy­pad­ki uży­cia tej aplikacji),
  2. poza-funk­cjo­nal­ne czy­li cechy jakościowe,
  3. dzie­dzi­no­we czy­li logi­ka biznesowa.

I teraz bar­dzo waż­na rzecz: któ­re ele­men­ty archi­tek­tu­ry opro­gra­mo­wa­nia, za reali­za­cję któ­rych wyma­gań odpo­wia­da­ją? W arty­ku­le Gdzie się reali­zu­ją wyma­ga­nia opi­sa­łem ogól­nie wzo­rzec pro­jek­to­wy MVC. Pomijając sam wzo­rzec, istot­ne jest to, że tak zwa­ne wali­da­cje” są doko­ny­wa­ne w dwóch róż­nych ele­men­tach archi­tek­tu­ry. Tak zwa­ne typy pro­ste danych (np. pole zna­ko­we Nazwisko) są (mogą być) spraw­dzo­ne w momen­cie ich wpro­wa­dza­nia (np. for­mat­ka ekra­no­wa nie przyj­mu­je cyfr w polu nazwi­sko). Cała logi­ka biz­ne­so­wa jest wyko­ny­wa­na wewnątrz apli­ka­cji (infor­ma­cje o ewen­tu­al­nych błę­dach poja­wią się po zatwier­dze­niu for­mu­la­rza), np. upust może być spraw­dzo­ny (albo nali­czo­ny) dopie­ro po skom­ple­to­wa­niu danych wyma­ga­nych do jego wyli­cze­nia, czy­li będzie to kil­ka róż­nych pól (naj­mniej dwa :)). Bywa, że do wyli­cze­nia cze­goś potrzeb­ne będą dane nie wpro­wa­dza­ne do danej for­mat­ki fak­tu­ry, np. sal­do klienta.

Jedną z naj­gor­szych prak­tyk pro­gra­mi­stów jakie spo­ty­kam, jest umiesz­cza­nie logi­ki biz­ne­so­wej (a są nią np. meto­dy nali­cza­nia upu­stów) w for­mu­la­rzach ekra­no­wych. Po pierw­sze pro­wa­dzi to duże­go obcią­ża­nia kodu tych for­ma­tek, po dru­gie przy dużej ilo­ści doku­men­tów (for­ma­tek ekra­no­wych) logi­ka biz­ne­so­wa jest powie­la­na, co pro­wa­dzi do dużych pro­ble­mów z utrzy­ma­niem spój­no­ści spraw­dza­nych reguł biz­ne­so­wych w apli­ka­cji. Po trze­cie pró­by pisa­nia inter­fej­sów (API) do tych apli­ka­cji (np. przyj­mo­wa­nie doku­men­tów wysta­wio­nych poza apli­ka­cją) jest nie­moż­li­we bez kolej­ne­go powie­le­nia logi­ki biz­ne­so­wej w API (jeże­li chce­my wali­do­wać” przyj­mo­wa­ne tą dro­gą dane a z raczej chce­my). Jednym sło­wem masakra.

Sprawdzoną meto­dą sku­tecz­ne­go (spój­ność, kom­plet­ność, nie­sprzecz­ność) zapi­sy­wa­nia wyma­gań dzie­dzi­no­wych (w tym wali­da­cje”) jest wydzie­le­nie w dokumentacji:

  1. słow­ni­ka pojęć
  2. słow­ni­ka reguł biznesowych 
    1. spe­cy­fi­ka­cji tablic decy­zyj­nych jako uzu­peł­nie­nia reguł biznesowych.

Słownik pojęć powi­nien obej­mo­wać wszyst­ko to co stwa­rza ryzy­ko nie­jed­no­znacz­no­ści. Reguły biz­ne­so­we, wraz z tabli­ca­mi decy­zyj­ny­mi (jeże­li są wyma­ga­ne) zebra­ne w jed­nym miej­scu (spe­cy­fi­ka­cja reguł), są niczym innym jak wyma­ga­nia­mi dzie­dzi­no­wy­mi. Tak opra­co­wa­na doku­men­ta­cja ana­li­tycz­na pozwa­la deve­lo­pe­ro­wi na łatwe poru­sza­nie się po doku­men­cie, mamy moż­li­wość wery­fi­ka­cji wyma­gań, ich spój­no­ści i kom­plet­no­ści. Załączając spe­cy­fi­ka­cje wzo­rów doku­men­tów (mock-up’y ekra­nów czy­li for­mat­ki ekra­no­we) każ­dy obszar takie­go wzo­ru albo jest oczy­wi­sty, albo jest zde­fi­nio­wa­ny (jako nazwa) w słow­ni­ku pojęć. Cała nie­try­wial­na logi­ka dzia­ła­nia jest opi­sa­na regu­ła­mi biz­ne­so­wy­mi. Ogólne zasa­dy two­rze­nia takiej dokumentacji:

  1. W toku ana­li­zy opra­co­wu­je­my mode­le pro­ce­sów biz­ne­so­wych zawie­ra­ją­ce wyłącz­nie aktyw­no­ści i ich pro­duk­ty (czy­li pro­ce­sy biz­ne­so­we) i nic ponad to (dodat­ko­we szcze­gó­ły to albo pro­ce­du­ry albo sce­na­riu­sze przy­pad­ków uży­cia, to inne dokumenty).
  2. Na mode­lach pro­ce­sów zazna­cza­my wszyst­kie aktyw­no­ści zwią­za­ne ze sto­so­wa­niem reguł biz­ne­so­wych (kon­wen­cja doku­men­to­wa­nia reguł na mode­lach zale­ży od uży­te­go narzę­dzia CASE). Reguły biz­ne­so­we uzu­peł­nia­my o ewen­tu­al­ne kry­te­ria decy­zyj­ne (np. w posta­ci tablic decyzyjnych).
  3. Równolegle pro­wa­dzi­my słow­nik pojęć dla dokumentacji.
  4. Nie defi­niu­je­my (jako biz­nes, a nawet ana­li­tyk biz­ne­so­wy, zgła­sza­ją­cy wyma­ga­nia) typów pro­stych, one są albo oczy­wi­ste, albo wyni­ka­ją z defi­ni­cji pojęć (w razie wąt­pli­wo­ści pisze­my czym jest nazwi­sko w słowniku).

Ważna rzecz. Decyzje o tym jaki­mi typa­mi danych ope­ru­je apli­ka­cja, to decy­zje deve­lo­pe­ra (pro­gra­mi­sty). Moim zda­niem pro­gra­mi­sta żąda­ją­cy w wyma­ga­niach poda­nia mu typów danych, jest nie­ukiem albo leni­wym sabo­ta­ży­stą (uży­cie – wybór typów danych, w tym typów zło­żo­nych, to decy­zje i kom­pe­ten­cje developera!).

Poniżej opi­sa­ne ele­men­ty umiesz­czo­ne na jed­nym sche­ma­cie blokowym:

Logika biznesowa

Tak więc, war­to roz­wa­żyć sto­so­wa­nie reguł biz­ne­so­wych i słow­ni­ków pojęć (Semantics Of Business Vocabulary And Rules), gdyż jest to spraw­dzo­na i bar­dzo przy­dat­na tech­ni­ka ana­li­zy i doku­men­to­wa­nia logi­ki biz­ne­so­wej. Polecam tak­że stro­nę The Business Rules Group i zamiesz­czo­ny tam Manifest Reguł Biznesowych. Tworzenie mon­stru­al­nych doku­men­tów wyma­gań, zawie­ra­ją­cych dzie­siąt­ki razy powie­la­ne wali­da­cje” pro­wa­dzi do wie­lu kło­po­tów z utrzy­ma­niem spój­no­ści i kom­plet­no­ści takich spe­cy­fi­ka­cji. Pomijam już ich uciąż­li­wą obję­tość. Jako mate­riał dla pro­gra­mi­sty są one wte­dy trud­ne w uży­ciu, do tego skła­nia­ją do naj­gor­szych prak­tyk, jaki­mi jest mię­dzy inny­mi umiesz­cza­nie logi­ki biz­ne­so­wej w kodzie for­ma­tek ekranowych.

Na koniec pole­cam książ­kę Building Business Solutions poświę­co­na temu zagadnieniu.

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).

Analiza wymagań – zrozumienie

Dzisiaj krót­ki arty­kuł o wyma­ga­niach dzie­dzi­no­wych. W jed­nym z poprzed­nich arty­ku­łów pisa­łem o wyma­ga­niach, że pro­blem tkwi w ich zro­zu­mie­niu i o tym, że przy­szły użyt­kow­nik nie powi­nien pisać jaki ma być ten pro­gram”, bo popy­cha pro­jekt w stro­nę cha­otycz­nych oczekiwań.

I tu jest sed­no: ana­li­za nie powin­na być tyl­ko pasmem wywia­dów, któ­re­go pro­duk­tem będę set­ki stron zapi­sów z ankiet i prze­pro­wa­dzo­nych roz­mów. Analiza, to duża pra­ca, któ­rej celem powin­no być zro­zu­mie­nie a nie tyl­ko opi­sa­nie. (Analiza wyma­gań na opro­gra­mo­wa­nie czy­li opi­sa­nie czy zro­zu­mie­nie).

Wymagania naj­czę­ściej dzie­li­my na funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Warto jed­nak upo­rząd­ko­wać pro­jekt i ukie­run­ko­wać ana­li­zę naj­pierw na wyma­ga­nia biz­ne­so­we a potem do już wymie­nio­nych dodać wyma­ga­nia dzie­dzi­no­we. Te ostat­nie są tak na praw­dę wydzie­le­niem z cha­osu ocze­ki­wań cze­goś co nazwę jak to jest robio­ne” ale nie w kon­tek­ście opro­gra­mo­wa­nia (pro­gra­mi­ści wie­dzą jak pro­gra­mo­wać), a w kon­tek­ście reguł biz­ne­so­wych i decy­zyj­nych (wie­dzy o tym jak się rze­czy dzieją).

Oprogramowania bez­po­śred­nio doty­czą tyl­ko wyma­ga­nia funk­cjo­nal­ne, poza-funk­cjo­nal­ne i dzie­dzi­no­we. Wymagania biz­ne­so­we to cele jakie ma przed sobą orga­ni­za­cja, dla któ­rej ma powstać (ma zostać jej dostar­czo­ne) opro­gra­mo­wa­nie. Zresztą, nie nale­ży o tym zapo­mi­nać, że może ist­nieć inne roz­wią­za­nie pro­ble­mu orga­ni­za­cji, niż oprogramowanie.

Oprogramowanie pro­jek­to­wa­ne meto­da­mi obiek­to­wy­mi wg. naj­lep­szych prak­tyk i wzor­ców ma nastę­pu­ją­ca strukturę:

Model systemu wymagania

Aktor to oczy­wi­ście jego użyt­kow­nik. Oprogramowanie, jako narzę­dzie pra­cy, świad­czy usłu­gi jego użyt­kow­ni­kom – akto­rom, jest ich narzę­dziem pra­cy. Oprogramowanie zawiera:

  1. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za jakość świad­czo­nych usług, to kla­sy reali­zu­ją­ce przy­pad­ki uży­cia tego oprogramowania,
  2. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za logi­kę biznesową,
  3. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za utrwa­la­nie infor­ma­cji (obiek­ty biznesowe).

Wymagania to warun­ki jakie ma speł­niać opro­gra­mo­wa­nie by było przy­dat­ne. Tak więc Analityk biz­ne­so­wy powi­nien zro­zu­mieć jak dzia­ła orga­ni­za­cja, zde­fi­nio­wać narzę­dzie jakie jej pomo­że, opi­sać wyma­ga­nia na to narzę­dzie. Jak? Powiem ina­czej, nie jest rolą pro­gra­mi­stów odkry­wa­nie” logi­ki biz­ne­so­wej, pro­gra­mi­sta odpo­wia­da za jej imple­men­ta­cję. Dlatego war­to pamię­tać o wyma­ga­niach dzie­dzi­no­wych… nie jest to nie­ste­ty miej­sce na szcze­gó­ło­wy ich opis, tu zapra­szam na szko­le­nie o wyma­ga­niach, któ­re pro­wa­dzę.

Praktyka nie­ste­ty poka­zu­je, że zapis ocze­ki­wań użyt­kow­ni­ka i prze­ka­za­nie ich pro­gra­mi­stom to dro­ga na manow­ce… Oczekiwania w rodza­ju roz­wi­ja­ne listy, mysz­ko­lo­gia”, łatwe w uży­ciu ekra­ny” i cała masa innych szcze­gó­łów nijak się ma do tego jak to opro­gra­mo­wa­nie ma dzia­łać. To tyl­ko cechy użyt­ko­we inter­fej­su użyt­kow­ni­ka, te jed­nak bez wewnętrz­nej logi­ki po pierw­sze o niczym nie mówią, a po dru­gie i tak są efek­tem goto­wych ele­men­tów z jakich budu­je się inter­fejs użyt­kow­ni­ka. Warto o ich wspo­mnieć by zama­wia­ją­cy miał ich świa­do­mość ale nie oszu­kuj­my się, opi­su­je­my tak tyl­ko to co zna­my już z innych apli­ka­cji a to w pew­nym sen­sie stan­dard (np. doty­ko­wy ekran smart­fo­na czy tabletu).

Zapisanie zaś, że sys­tem ma pozwa­lać na dobór pro­mo­cji dla klien­tów o róż­nych pozio­mach zaku­pów, po pierw­sze nic nie mówi, po dru­gie wyma­ga ana­li­zy o co cho­dzi” i są to wła­śnie wyma­ga­nia dzie­dzi­no­we­go. Wymaganiem funk­cjo­nal­nym będzie tu to: System pozwa­la na zarzą­dza­nie listą upu­stów. W języ­ku pol­skim i nie tyl­ko funk­cja to zada­nie, któ­re speł­nia lub ma speł­nić jakaś oso­ba lub rzecz. Innymi sło­wy wyma­ga­nie funk­cjo­nal­ne to to do cze­go ma słu­żyć opro­gra­mo­wa­nie a nie to jak ma to robić.

Przypomnę na zakoń­cze­nie: powyż­sze to tyl­ko pew­ne dobre prak­ty­ki 🙂 bazu­ją­ce na meto­dach obiek­to­wych (a w zasa­dzie takie głów­nie są teraz a w uży­ciu) i wzor­cach projektowych.