Re: Multiple specification of constraints

"ben brugman" <ben_at_niethier.nl> wrote in message news:4048b7c7$0$3677$4d4ebb8e_at_read.news.nl.uu.net...
> There are law, management or other instances do not allow for linkage,
this
> is no option. Requirements are not only dictated by ??? automation or
model
> rules, but also by laws, what people want and by economical constraints
> (money and time).

Either you can access the data (somehow), or you can't, in which case you can't validate against it. I'm not referring to direct, unfettered linkage - simply a way of getting data from elsewhere. Any RPC-style mechanism will do. If that data can't be accessed programatically, why could it be accessed manually?

> The example (a database were debts and 'bad' repayments are kept) is
> existing
> and governed by rules dictated in the law.
> I know this is a theory group, but the example is from the real world.
> (Sorry for that).
> (In the given example people explicitly wanted a non linked database.
Reason
> for
> that is that banks are allowed to check this registration if somebody
> applies for
> a loan or a mortgage, but banks can not check this registration just to
sell
> you a
> loan or mortgage.).

Again, you're saying they allow manual access, but not programmatic? Then that data can hardly be considered a constraint in the automated sense. A manually-enforced constraint is no constraint, at least for computer systems.

> Example of an economical constraint :
> If something has to be build before a certain time, within a certain
budget,
> it
> is often cheaper to use the skills which are at hand than to obtain skills
> for
> the 'best' solution.
> An example of this :
> A dropdown 'box' or 'window' was needed to display the names of 'members'
> of a department. (This is simple to model and simple to build). The
> programmer
> at hand did just include the department name to each 'member's name and if
> now a selection on the department was done the dropdown 'box' only
presented
> the 'members' of the given department. Offcourse also the 'members' which
> had
> the department name woven into their name became visible.
> (He just altered the names of the members at the given site).
> This was implemented in a very short time, the users where immediatly
happy
> with the
> solution. This solution did hardly cost anything, the users were
impressed.
> And at first I did think that the solution was totaly wrong and should be
> modelled
> and programmed correctly. But I think here a programmer made a very
creative
> solution for almost no cost at all. And the users were impressed and happy
> with
> the solution. (Probably more so than if we had given them a 'correct'
> solution to
> their problem but at a later time. This type off occurences problably
> generates
> more orders for us than a correctly modelled and build solution).
> (Modeling and building the solution and delivering this with the next
> release would
> take some time and cost some money.)
>
> I know this is practise and not theory, but I always tend to think in real
> life situations.
> My appologies for that in this theory newgroep.
>
> ben brugman

Meaning the UI had the entire data set of members and their departments, and "filtered" the set based on the selected department? If so, it's just another example where a relational language on the client side (too much to ask from most languages, much less the incoherent JavaScript) would have made this trivial.

• Eric