Trie structure with three classes
Using a concrete class where an abstract one or an interface can be used is usually a bad practice. That is, the getChildren method of the TrieNode class should return a Map&lt;Character, Integer&gt;, not a HashMap. There is no need to get bound to a concrete implementation.
The TrieNode class has redundant fields and methods. The value field is not used anywhere, so there is no need to keep it. Getters and setters for it are not necessary, too. Moreover, this classes exposes its internal representation. The clients of this class(in this it is the Trie class) do not really need to know how the children of this node are represented. Instead of returning a Map and letting the client work with it, I would create two methods: getChildForCharacter and getChildForCharacterOrCreateIfAbsent. Here is my version of this class:

class TrieNode {

    private Map&lt;Character, Integer&gt; children = new HashMap&lt;&gt;();

    /**
     * Returns the child of this node for the given character or null
     * if it does not exist.
     */
    public TrieNode getChildForCharacter(char c) {
        return children.get(c);
    }

    /**
     * Returns the child of this node for the given character. If it does
     * not exist, a new child is created.
     */
    public TrieNode getChildForCharacterOrCreateIfAbsent(char c) {
        if (getChildForCharacter(c) == null) {
            children.put(c, new TrieNode());
        }
        return children.get(c);
    }
};


Now this class does not expose its implementation and we can easily change it in the future if it is necessary. You could also add a isTerminal and setTerminal methods to this class if you want to search for the entire words, not just their prefixes. 
The Trie class, again, in my opinion, contains a couple of methods that should not be there. 


I think that the getRoot and setRoot method should be simply deleted. Why? Setting a new root breaks the trie(in a sense that previously added strings might turn out not to be there any) and the purpose of a getter is not clear(why would I need a trie's root?). Moreover, they expose the internal representation, which is not good. I'd just remove them. The clients of the Trie do not need to know that it has a root in the first place because it is an implementation detail. 
traverseTree should be private(or at least protected). It is a helper method. There is no need to expose it to the clients. They don't even know what a TrieNode is(because this class is not public). 
buildTrie is not a very good name. It implies that this method should be called only once(then the question is: why isn't it a constructor?). But it makes perfect sense to add new words to a trie. That's why I'd rename it to addAll or something like this. I would also add a method add which takes one String argument(to avoid making the clients of this class create a Set even if they want to add only one String. 

Spacing and indentation. It is inconsistent in your code. Sometimes whitespaces around binary operators are absent, sometimes there are arbitrary whitespaces before a semicolon. You should keep you style consistent and adhere to established guidelines. It is easy to fix it using almost any modern Java IDE.
Testing. If do not use unit-tests, start using them. Testing your code in a consistent, systematic manner is a very good practice.  


 Summary 


Avoid exposing the internal representation of objects. Do not create getters and setters for the sake of having them. It is a bad practice.
Keep your code style consistent and follow established guidelines unless you have very good reasons not to.   
Keep a consistent level of abstraction in your API. Try not to mix concepts from different levels(like a node in a trie and a HashMap).