A few days ago I was talk­ing about the bor­der between require­ments ana­lys­is and engin­eer­ing with Tom Gilb. The con­clu­sion is: that we have to sep­ar­ate the require­ments stage and the engin­eer­ing stage. A huge thank you to Karo­lina Zmitrow­icz for organ­iz­ing this meeting.

Someone will ask: why all this? The thing is that man­aging present­a­tion graph­ics (mod­el con­sist­ency, tra­cing, etc.) is prac­tic­ally impossible: any change requires inter­fer­ence with block dia­grams and labor­i­ous rein­ser­tion into the ana­lys­is report (I wrote about this in an art­icle about CASE tools). Such graph­ics are not trans­fer­able between tools oth­er than as uned­it­able bit­maps. How­ever, if someone feels that block dia­grams expressed in more «friendly» sym­bols add value to the pro­ject, they can do so. The UML provides for this and many tools allow it (I used Visual-Paradigm).

Source: UML mod­el and ste­reo­types as icons – Jarosław Żeliński IT-Con­sult­ing.

There are also simple and obvi­ous conclusions: 

• there is no point in design­ing an “inform­a­tion sys­tem” without fully under­stand­ing (i.e. also doc­u­ment­ing) the “inform­a­tion system, ”
• there is no point in pla­cing the ele­ments of the “inform­a­tion sys­tem” on “inform­a­tion sys­tem” mod­els (e.g. There is no point in put­ting the “inform­a­tion sys­tem” ele­ments on “inform­a­tion sys­tem” mod­els (e.g. sym­bols rep­res­ent­ing soft­ware on BPMN models)
• the rela­tion­ships between the “inform­a­tion sys­tem” ele­ments and the “inform­a­tion sys­tem” ele­ments are described with the help of the trace­ab­il­ity matrix
• Devel­op­ing the require­ments for the “inform­a­tion sys­tem” is about identi­fy­ing the “busi­ness needs” and devel­op­ing the logic of oper­a­tion and archi­tec­ture of the “inform­a­tion sys­tem” on their basis (MBSE, MDD), and not on col­lect­ing myth­ic­al “user require­ments”, who in fact have no idea about “inform­a­tion sys­tems”, but know very well if and when they need help in the busi­ness pro­cesses being imple­men­ted  this is why meth­ods based on design­ing an “inform­a­tion sys­tem” on the basis of inter­views (work­shops) with future users are doomed to fail­ure from the out­set (because even if some­thing sens­ible is finally cre­ated, it will take a lot of tri­al-and-error work)
• One thing we have known for years: one of the most dam­aging theses in IT is the one say­ing that a doc­u­ment is a report from a database.

Source: Architek­tura inform­acji, sys­tem inform­acyjny a informatyczny w organ­iz­a­cji – Jarosław Żeliński IT-Consulting

UML dia­grams and the way they are used, since the very begin­ning of this nota­tion, have aroused emo­tions and waves of con­flict­ing com­ments. The reas­on for this is the high level of abstrac­tion of the ana­lys­is stage and mod­el­ling as a dis­cip­line, and the fairly wide­spread mis­un­der­stand­ing of the essence of this nota­tion. This is com­poun­ded by the huge dif­fer­ence between what we call ana­lys­is and object-ori­ented design (OOAD) and object-ori­ented pro­gram­ming lan­guages (OOP).UML nota­tion is mis­takenly treated by many people as just anoth­er set of sym­bols for cre­at­ing illus­tra­tions. Most developers I know feel that these dia­grams do noth­ing to help them, and they are gen­er­ally right, because the qual­ity and con­tent of much of the doc­u­ment­a­tion pro­duced with UML, is poor, and such doc­u­ment­a­tion is actu­ally use­less to the soft­ware vendor.

Source: Dia­gramy w not­acji UML – Jarosław Żeliński IT-Consulting

The acronym VSM has also star­ted to appear in soft­ware engin­eer­ing for some time now, but it has an old ped­i­gree of more than 30 years. Value-stream Map­ping (VSM), known for 30 years, more recently also as mater­i­al- and inform­a­tion-flow map­ping. It is a meth­od with its ori­gins in Lean Man­age­ment, used to ana­lyse the cur­rent state and design the future state for the series of events that lead a product or ser­vice from order to deliv­ery to the customer.

Source: Value-stream map­ping czyli stru­mień war­tości jaki wyt­war­za firma tworząc swój produkt – Jarosław Żeliński IT-Consulting

Test­ing is check­ing, and here we have (should have) a clear divi­sion between the check­er and the checked. It is typ­ic­al of the IT mar­ket to tell cus­tom­ers that they have no com­pet­ence in ana­lys­is, test­ing, design, that all this will be done by the soft­ware sup­pli­er. Thus, the fol­low­ing are ordered from the same, single, soft­ware sup­pli­er: busi­ness ana­lys­is, require­ments ana­lys­is, design, imple­ment­a­tion, writ­ing accept­ance tests and test­ing. An entity like the Pur­chaser in essence just watches, and pays as much as the sup­pli­ers want (T&M pro­jects are out of con­trol). In effect, the check­er and checked are the same entity. Does this make sense?

Source: Czym są testy oraz kto i co tes­tuje – Jarosław Żeliński IT-Consulting