documents and paper computer

documents and paper computer

In addition to "use cases" and "data fields (data points)", another key word is "documentation". I treat "documentation" as if it were source code, and as a result, it corresponds to the real system directly -- I treat it as a "paper computer".

By doing this, there is no "process". Note that "use cases/business rules" and "data fields (data points)/technical approaches" (I believe "implementation strategies" is too difficult to say quickly in meetings, so, I traded the phrase with "technical approaches") are the top-most level of the structure ("architecture") of a system.

Note that we can talk some "technical approaches" to users. All those are key words in software support/development.

Also note that "technical approaches" includes technical items in "use cases/business rules", for example, "transactions", "newwork (web services, report server, eim, remote)", "security", and "audit" are "use cases/business rules".

the wording I am using: "use cases" and "data points"

I know I change a lot, and I play with words a lot.

Now, again, I am changing the wording of the top level thinking “formula”. They are "use cases" and "data points".

Yes, I am putting “rules” and “implementation strategy” back to where they belong – low level.

I changed “common data” to “data points”, because “common data” is too abstract to users. I want the wording easy to understand, intuitively.

Also, “points” kind of intuitively leads people into details, closer to implementation. This is especially true when you use "screens" for "use cases".

I guess I will keep using them for a while.

Now, you may say, why, why are you paying attention to the wording so much? It is important. Without a good wording, you will not say them that often, then, you will be misled, or, worse, you will mislead. Saying something, saying something aloud, saying something aloud in front of a team, are a very powerful action, and that action definitely affect your other actions and behaviors.