Now to touch on the requirements, we need to look at them because they come to us in various forms. We have the internal and external sources that they come from. We have the functional, which talks about the actions that they will take. And we have non-functional, which refers to states or conditions that must exist in the system. They typically will come in about three categories, some being mandatory, those things that the system absolutely must do without fail.

Some will be highly desirable, nice to haves and a higher priority. Not quite that of the mandatory ones, but it would be nice if we had these. Then we have the optional, the nice to haves, if you will. Good things, nice things, functional things, user pleasing things maybe, but they're optional. The mandatory and highly desirable are two top priorities.

Now the internal will typically come, and they will be employed by the system to protect internal data: audit logs, controls, other types of very sensitive and very important records. It'll protect the inter-process communications, and control traffic. And it will also make certain that alerts go through without tampering. Interference or alteration of these particular rules and requirements, are going to result in unauthorized operations, and data compromise, if they are not properly handled.

Now, typically the external requirements that we look for are those related to the external obligations we all face. And these will come in the source of regulations, compliance requirements, contract performance, and perhaps other forms of requirements that we must meet that may be based on industry standards. The thing that we are concerned with here is that interference with these may result in non-compliance, threat blindness, or a failed control or, other compromise, that would result in the systems being tampered with, and having been done in a way that we haven't been able to detect. Now to sum up where we are so far, we've discussed various elements from which the requirements are derived.

Now, the importance of requirements cannot be overstated. And the fact that they are needed from concept and design phases, and carried all the way through the system, realizing, of course, that reality being what it is, will cause various types of changes in these requirements, as we go through the process.

In the end, they're going to ensure that issues of operations, performance and compliance, are identified and validated as early as we can in the software development life cycle. Now from these sources requirements can be disassembled, analyzed and transformed into states, functions and products that satisfy the originating needs that drove this product's conception from its very beginnings.