When I was an intern at a local privately held company, I was asked to sit down and refine some requirements with one of the subject matter experts who happened to be a grain trader. As part of that refinement, I asked him what platforms the system needed to run on? He gave me a blank stare and return saying, '' I really don't know. That's your job" I'd actually confused a functional with a non-functional requirement. I was asking a business subject matter expert to essentially determine a non functional requirement, which has implications on the designer of the system. However, he's mostly responsible for functional requirements. So, in this video, we'll go into the difference between functional and non-functional requirements, and describe why it's important that we separate them. After this video, you'll be able to describe the purpose of separating requirements into functional versus non-functional categories, as well as lists the characteristics of a functional or non-functional requirement. Finally and perhaps most importantly, you'll be able to categorize the requirements as functional or non-functional, so that as you produce your documentation, you can be sure to put them in the right sections and deliver them to the right teams. As part of the analysis phase, we develop requirements and that is probably the most intense part of analysis phase. It is a multi-step process that we've been exploring in depth. This particular video focuses on the part of the process where we separate requirements into functional versus non-functional requirements. Let's talk a little bit about what a functional requirement is versus a non-functional requirement. We use each type of requirement in a different way as we proceed with development. Functional requirements relate to the process that a system has to perform. So, a specific calculation or a specific capability that it should have. Nonfunctional requirements on the other hand, relate to constraints of the system. The example I gave at the beginning of the video such as what platforms the system has to run on is one common example. Other common examples are the languages the system needs to support, or any performance requirements such as the number of transactions or the number of users. These all fall into the non-functional requirements category. Functional requirements describe capabilities or functions that the system must perform. Here's some textbook examples of functional requirements, such as the system will allow managers to view the current new vehicle inventory, or the system will enable a salesperson to create a customer offer. These refer to specific functions that the system must perform. Functional requirements are different than non-functional requirements, which describe constraints of the system. Such as what platforms the system must operate on, or specific time frames or performance requirements such as the number of users that it must support. Another common example that I discussed earlier was the languages the system should support. You can even see here some cultural or political implications such as maybe we have a contract in place to only purchase hardware from a specific provider. Separating these is important because the non-functional requirements are essentially inputs into the design phase. They're are forwarded to the developers who developed a system, or the team of people who might be making a build versus buy decision, so that they can make sure that the system meets the appropriate constraints. Functional requirements on the other hand are usually discussed with subject matter experts. So, people who perform the tasks or functions every day to make sure that the functional requirements are correct. We've talked a lot about what requirements are, how to write them, and what the best practices are. From here, we'll be talking about essentially how we go about gathering those requirements. There are lots of methods. At the beginning of this video, I described one popular method, which is the interview. Sit down with a subject matter and interview them. We'll also talk about other methods that you can use to develop and gather your requirements.
