Dear Onyeka

I am afraid I don't understand the question. Can you clarify, perhaps with an example?

Are you talking about decision trees, that is programs that emulate the human decision making process?

That's a really interesting research question! I'll try to rephrase it the way I understood it.

Is it possible for a machine to infer implicit requirements based on a set of explicit requirements?

In my opinion this is dealing a lot with knowledge representation and engineering, and how to discover tacit knowledge from domain experts.

I think the answer might be yes, if you mean, at least partly, incomplete requirements recovered. Explicit requirements often miss logic or data, so I use a requirements validation method that ferrets that information out. I have attached a white paper that explains how to validate use cases using an extended UML approach. I think that approach could be applied by a machine, but I've not tried to automate it. I have used the approach in this white paper in my projects as a standard for removing defects in the requirements before construction starts.

Abductive reasoning aims at finding a causing explanation for observed effects given a background domain theory (set of rules). One way is to try to prove a theorem (explicit) by resolution type of calculus where the process uses rule premisses to explain rule heads and use the explanations that can not be further reduced as candidates for the final implicit explaining knowledge that caused the observations( explicit). Of the possible candidate explanations that are implicit knowledge one can accept as hypothesis of possible causes the ones that are most plausible being minimal or having some other characteristics. You might want to check if abduction could serve your needs also in the requirements analysis world. I guess this way you could build a kind of reverse engineering tool answering the question: given the system specification and design rules what where the original system requirements. (An other thing would be to learn the design rules given the requirements and system specification).

I think that apart from rules, you must have access to a knowledge. It can be an organizational knowledge (to discover with various techniques), experience from similar projects or a formalized knowledge previously gathered and voted up by a group of experts.

For the last case, a good example is the Common Criteria standard, which defines about 300 requirements related to security functions. Some of them are linked by dependency relations (e.g. function A depends on B). Hence, if one selects A (explicitely), B should be also added to the model (as an implicit requirement).

With rules I was referring to the formal logical representation of the domain knowledge. As they are formal they most likely are also explicit. But as Alan Cline above states explicit requirements often miss logic or data. These can be collected as Piotr Szwed suggest from similar cases or like François Christophe states by knowledge engineering. So let us assume A (explicit) is logically implied by (implicit) B, and we observe A , then we can assume B or some alternative way to meet requirement A holds. One could discuss the terminology here also. The direction of logical implication is interesting in A => B. If B is a requirement then to me it looks more natural to refer to A as a requirement if it is the way to ensure that B holds. In this discussion however it is the A that is the requirement and as it holds as a sufficient condition B must hold too. Are all things that follow logically from a requirement also requirements or just things that the design must have to meet requirement A? Often the question has been that some of the early parts of the dependency chain are not documented and we want to answer the question does this design meet the requirements and how does it do it. The other quite different question would be that of changing the design, say changing B so that it does not hold. Then if we have A and know that A => B we have a logical conflict. So are we interested in fishing implicit requirements as the primary problem or as a part of change management problem? The original question seems to indicate the former. The question concerning similarity/difference in implicit/explicit requirements is interesting too. One could perhaps produce multipurpose tools by having similar implicit requirements for two sets of different explicit requirements (say user requirements) or produce competing products for similar explicit requirements with different implicit requirements (functionalities)? The point is that the classical automated reasoning mechanisms and abduction in particular might have some use as a conceptual backbone in looking at the problem and even in the design of requirement management system applications.

@François Christophe... You captured what I was saying but I still haven't gotten ur suggestion on how to go about it.

@ Vitor C Zimmerer... As an example, let us consider the scenario of creating a portal system for a publishing company that was extracted from [5] in which an important implicit requirement was omitted while capturing the explicit requirement.

Explicit requirement 1: A Publisher should be able to create an article, send it for approval and finally publish the article on the portal.

Explicit Requirement 2: A Portal user should be able to search articles published on the Portal.

The objective was to develop a system that will cater to both requirements, so that the publisher could create and publish an article and the end user could search the articles using the search functionality. However, the search result displayed articles, which were published, under approval and in draft state. This was unsatisfactory for the end-user of the system. This was as a result of an uncaptured (unspoken) implicit requirement, which was never mentioned, and thus was not catered for prior to the development of the system.

Implicit Requirement: The articles in draft state and under approval should not be displayed in search result.

@ Simon Bulgacs... your talking about decision trees looks like a possible route to take. I haven't done any work on that. If you have somethings u've worked on in this direction looking at the above example. I will be most grateful.

If I hope I understand properly your question. As well as a decision tree, I would suggest grammatical evolution. It has an implicit set of rules included during the decoding phase of the codons. These rules include the grammatical rules in such way an order of elements can be specified. Also the preferred operations can also be encoded statistically.

I hope it helps

Patricia

As already noted, two approaches can be combined:

Requirements capture: use language and logic to build requirements trees.

Requirements analysis: map requirements to explicit or implicit models.

http://caminao.wordpress.com/how-to-implement-symbolic-representations/requirements/requirements-capture/

http://caminao.wordpress.com/how-to-implement-symbolic-representations/requirements/requirements-weaver/

I agree with mr Fannader, when eliciting requirements one should foucus all the effort in user needs, and as stated in the swebook chapter of requirements http://www.computer.org/portal/web/swebok/html/ch2, using a matrix to match each requirement with typical NFR or a requirements dependency tree to see if all the needs are covered.