Sunday, February 17, 2008

Non functional requirement notes

Before proceeding to the code, let' s define some non functional requirements notes. Usually intelligent systems need to performe real time processing in a very fast "pseudo real time" way. It can be interesting to change this approach, but first of all it is fundamental to define the parameters to measure the quality of a non linear system response. If the non linear pseudo intelligent system is seen as a black box, let's try to point out the quality parameters for the results produced by this box. Some elegible, not "exotic" parameters for system response quality can be:

1 Time requested to produce an output, after that the system has succesfully received, validated , accepted the input data.

2 Assumed an IDEAL perfect answer for the input given at point 1, it is possible to define the difference between the perfect IDEAL answer and the REAL answer produced by the real system. The difference can be evaluated for simple systems whose values can be obtained in any metric reference system.

Let's assume that there is a functional dependency between the time taken to produce the answer and the answer quality:

Response Quality = f(time taken to produce the response)

As the target of this experiment is to obtain a sort of answer, let's slow down the system.

As the parameters to define the system response are two, it could be interesting to choose parameter 1 as quality parameter to reduce. Let's state: it is possible to have a system that takes a some time to produce a response.

Because the system works with some information correlation technology (building a virtual swarm of info elements that need correlation) let's reduce the response time and give time to the info correlation phase to build deeper links. Let's analize now for a while, what happens limiting the time used to performe information correlation. With less time to scan composable information unit chains, links that will be build will be mainly "surface" immediate links. Let's say simpler links. Giving more time to information unit/information chains correlation, the links produced will be "deeper", more in numer, more complex. This is interesting as it is possible to have a view of the meaning of the generally valid function:

Response quality = f(Time taken to produce the response)

expressed in the context of this real system engaged in the experiment:

if we state that:

(Time taken to produce the response) = (Number and depth of information unit links and associations)

accepting a response time decrease we should observe an increase in the response quality. This is a very simple and logic assumption that doesn't need a blog to be accepted. It is now simple to catch a sight of another important parameter, that could be more relevant then the other two. If this "f" correlation (or assumption) is correct, this means that it not only acceptable to have good system response in short times (at least for the system drawn up to now), but also it is not possible at all. Let's introduce a new quality parameter to enrich the metrics of system quality:

3 Number of guaranted and quality fixed responses per time unit

This because according to the needs of the system produced data consumer, it could be better to have a constant number of response per time unit, OR a constant response quality, no matter the response time. This, of course, is a matter of usage of the systemn designed. If the relation assumed is corrected, it should not be difficult for a system provide with a quality feedback agent, to auto-regulate the time spent to link information units, and the depth of links built. This in order to handle the oscillations of the two main parameters. Let's assume, so, another function (if hardware capacity is a fixed constant):

Number of guaranted and quality fixed response per time unit = f[(Response quality),(Time taken to produce a response)]

A sort of master quality controller can handle info unit processing depth and response time, to act as a feedback retro-active agent, to keep parameter 3 (how much constant is the way the system asnwer) stable. Well, in a certain way, let's keep in mind that sometimes system could need a sort of "nap" to have a complete full information linking phase for a quality best-effort answer, no matter the time :)

No comments: