Tag: mock-up

Struktury formularzy jako forma wyrażania wymagań

1 komentarz

Wprowadzenie

Ten arty­kuł to uzu­peł­nie­nie opi­su: Dokument jako wyma­ga­nie.

Często jestem i ja pyta­ny o to ​„Jak wyja­śnić zło­żo­ne roz­wią­za­nie tech­nicz­ne inte­re­sa­riu­szom nie­tech­nicz­nym?” Jak wie­lu mi podob­nych odpo­wia­dam: roz­ma­wiaj doku­men­ta­mi. Sponsor pro­jek­tu, przy­szli użyt­kow­ni­cy, postrze­ga­ją swo­ją pra­cę poprzez doku­men­ty: ich treść i układ. Zauważyli to tak­że inni:

A Mock-up is a sli­gh­tly glo­ri­fied pic­tu­re, so you will be answe­ring with at least 1001 words ! 

Bardzo czę­sto widu­ję wyma­ga­nia spi­sy­wa­ne jako tak zwa­na lista funk­cji lub funk­cjo­nal­no­ści. Pojęcia te mają takie defi­ni­cje w języ­ku polskim: 

funk­cja ?zada­nie, któ­re speł­nia lub ma speł­nić jakaś oso­ba lub rzecz?, ?moż­li­wość wyko­na­nia okre­ślo­nej ope­ra­cji przez urzą­dze­nie lub pro­gram komputerowy?

Funkcjonalność jest defi­nio­wa­na jako funk­cja cze­goś w jakimś systemie. 

Czytaj dalej… ​„Struktury for­mu­la­rzy jako for­ma wyra­ża­nia wyma­gań” →

Dokument i jego struktura jako metoda zarządzania danymi

Dodaj komentarz

Wprowadzenie

Bardzo wie­le pro­ble­mów w toku wdro­żeń IT rodzą wadli­wie zapro­jek­to­wa­ne struk­tu­ry doku­men­tów. Dotyczy to w szcze­gól­no­ści zarzą­dza­nia dostę­pem do tre­ści, a patrząc sze­rzej: do infor­ma­cji. Ostatnie lata to mię­dzy inny­mi pro­ble­my urzę­dów z udzie­la­niem dostę­pu do infor­ma­cji publicz­nej, od dwóch lat dodat­ko­wo pro­ble­my stwa­rza RODO. Źródłem pro­ble­mów jest treść doku­men­tów, rozu­mia­na jako pyta­nie: ​„Czy te infor­ma­cje muszą być zawar­te w tym doku­men­cie”. Najpierw opi­szę mecha­nizm powsta­wa­nia przy­czyn pro­ble­mów i spo­sób ich roz­wią­za­nia. W pod­su­mo­wa­niu wska­żę jak i gdzie sobie z tym radzić. 

Czytaj dalej… ​„Dokument i jego struk­tu­ra jako meto­da zarzą­dza­nia dany­mi” →

Prototyp nie jest niczym ponad to, że jest tylko obrazkiem lub makietą

12 komentarzy

Swego cza­su pisa­łem, że

… opis ?co? sys­tem ma robić to sta­now­czo za mało, tak na praw­dę nie defi­niu­je on nicze­go poza tym, w jaki spo­sób może zostać wyko­rzy­sty­wa­ny. Przypadek uży­cia jest dosłow­nie ?przy­pad­kiem uży­cia sys­te­mu?, ale przy­pad­ków uży­cia jest nie­skoń­cze­nie wie­le. Na ile spo­so­bów wyko­rzy­stu­je­cie posia­da­ne oprogramowanie?

[…] Tak więc doku­ment wyma­gań to nie tyl­ko przy­pad­ki uży­cia [listy pól czy pro­to­ty­py ekra­nów] . Te są raczej testem popraw­no­ści roz­wią­za­nia, czy model jest popraw­ny (przy­po­mi­nam, że przy­pad­ki uży­cia, poza ich sce­na­riu­sza­mi, zawie­ra­ją stan począt­ko­wy i stan koń­co­wy akcji użyt­kow­ni­ka). Dokument wyma­gań to model (tu model dzie­dzi­ny), któ­ry po zaim­ple­men­to­wa­niu, będzie się zacho­wy­wał tak jak tego ocze­ku­je­my a przy­pad­ki uży­cia będą jedy­nie dowo­dem na to, że jest on popraw­ny. […] Jeśli model przy­pad­ków uży­cia to model tak zwa­nej czar­nej skrzyn­ki, to model dzie­dzi­ny (bo tak się on nazy­wa) to tak zwa­na bia­ła skrzyn­ka. (Czy wyma­ga­nia opi­su­ją tyl­ko to ?co? sys­tem ma robić? | Jarosław Żeliński IT-Consulting).

Ogólnie kon­klu­zja jest taka, że czar­na skrzyn­ka nie daje nie­mal­że żad­nej wie­dzy o tym ja ona dzia­ła. Niedawno wpadł mi przed oczy arty­kuł trak­tu­ją­cy o tym samym, kon­klu­zja auto­ra (wni­kli­wym pole­cam cały artykuł):

Sure, you put a lot of time into cre­ating a pro­to­ty­pe, a moc­kup, scre­en­shot, or wire­fra­me (are the­re any other names for the user inter­fa­ce dra­wing I?ve mis­sed?). You may have drawn it on a whi­te­bo­ard, in VISIO, or even used a requ­ire­ments tool to cre­ate it. At the end of the day, no mat­ter how much time you spend on it, it?s nothing more than a pic­tu­re. And tho­se of you who have wor­ked in IT know deve­lo­pers can­not code and cre­ate a solu­tion sole­ly from a pic­tu­re. (A Prototype is Nothing More Than a Picture > Business Analyst Community & Resources | Modern Analyst > Business Analyst Articles & Systems Analysis Articles | Modern Analyst).

(deve­lo­per nie jest w sta­nie stwo­rzyć żad­ne­go roz­wią­za­nia tyl­ko na bazie obrazków).

Trudno z tym arty­ku­łem pole­mi­zo­wać, a jed­nak rze­sze ana­li­ty­ków, i o dzi­wo deve­lo­pe­rów, chy­ba więk­szo­ści firm IT, jako pro­duk­ty ana­liz wyma­gań przed­sta­wia­ją tyl­ko owe pro­to­ty­py czy­li ​„user sto­ry”, mock-up’y ekra­nów, tabe­le itp. W środ­ku jest jakaś okre­ślo­na logi­ka i to ona jest klu­czo­wym wymaganiem.

W kwe­stii ryso­wa­nia vs. mode­lo­wa­nie pole­cam mój sta­ry tekst Modelowanie a ryso­wa­nie.