When we sit down to a build a piece of software, how do we know what to build? In most cases, we know what to build because we've gathered a set of requirements, characteristics our software must have in order to be considered "complete" or "correct". The process of gathering requirements can be as time-consuming and complicated as we want to make it.
Sometimes, if we're building software for ourselves, we may even skip this step since the requirements are already in our heads (or we might quickly jot them down so we don't forget). In other cases it may take weeks or even months to identify what our software must do, particularly when we are unfamiliar with the problem our software will solve. For example, work for a company that makes software for accountants. I know very little about accounting, so when I'm asked to build a feature I have to ask a lot of questions first to make sure that what I end up with is useful to accountants.
Functional requirements deal with what the software in question does. You can think of a functional requirement as a "feature" without much loss of accuracy. Programming assignments in your CS course mostly specify functional requirements. For example, your program must print "Hello, World" when run. Or, "given a set of numbers, your program must print the numbers from the set that are prime". In a larger application, a functional requirement would probably include background information and additional detail, but the idea is the same, functional requirements are concerned with what the program does.
We will discuss non-functional requirements more later in the semester, but for now you can think of these as requirements that deal with how the program does something. For example, performance is generally a non-functional requirement. In the second example above, your assignment might specify that your program must be able to identify all the prime numbers in a set of 100 values within 10ms, or that the algorithm must have O(n) performance for larger input sets. These are non-functional requirements because they do not affect the answers / output produced by the program. However, this doesn't make them less important, non-functional requirements can be deal breakers in many cases (for instance, games).
Functional testing is probably the most obvious form of testing (doing it well requires some subtlety, though). In fact, every single one of us probably invented it independently for ourselves. Think of the first program you wrote, what did you do after you wrote it? You ran it, of course! And you probably verified that the output was what you expected. That is functional testing in a nutshell.
A functional test attempts to verify one or more functional requirements of the software in question. For example, a functional test for a "Hello, world" program simply verifies that, when run, the software prints the string "Hello, world".
We will discuss various forms of non-functional testing later in the semester. These will include performance testing and various forms of security analysis.