I’m a techie. I like technology, and ask me to solve a problem that involves something with a computer, and usually I’ll get it solved. My boss seems to know that, and it’s one of the reasons why I get pulled in to projects that require hands-on.
I like to talk about technology. It’s one of the reasons that I enjoy being in my current pre-sales role so much. I enjoy taking a technology, trying to simplify what it does, and then talking to a customer to see if a technology can add value in their setup, or solve one or more specific problems they might be having.
The one doesn’t work without the other for me. I need stick time with something before I’m really able to effectively communicate about it. I’m not the kind of guy to go over a PowerPoint presentation and then deduce how a product works in real life. I can do that up to a certain degree, but I won’t feel really confident without having some form of hands-on.
In comes the design part
In one of my previous posts, I asked how you learn to speak design. There are design methodologies that can help you uncover goals, and it will be up to you to identify the CARR, or written out:
- Constraints
- Assumptions
- Risks
- Requirements
And this is where the hard part is for me. I don’t deal with this terminology, in a design environment, on a day-to-day basis. And it makes it hard to actually categorize these in a correct fashion, without a lot of practice.
There is a good document on the VMware Community page that goes in to detail on “Functional versus Non-functional” requirements. The document states the following:
Functional requirements specify specific behavior or functions, for example:
“Display the heart rate, blood pressure and temperature of a patient connected to the patient monitor.”…..
Non-functional requirements specify all the remaining requirements not covered by the functional requirements. They specify criteria that judge the operation of a system, rather than specific behaviors, for example: “Display of the patient’s vital signs must respond to a change in the patient’s status within 2 seconds.”
Which makes it relatively simple. Those are simple examples, and when you keep in mind that a non-functional requirement usually is a design constraint, you should be all set to identify constraints and requirements, right?
Maybe not so much?
Along comes something in a different form, and then the over-thinking starts:
- “You must re-use existing server hardware”.
- That’s great. I “must” do something, so it’s a requirement, right? But does this change the way that “my heart rate is displayed”? Well, since I’m a techie, depending on the server model, this might influence the way it’s displayed. Do I need to change my design because I’m re-using the hardware? Well, you may need to. But normally your design shouldn’t depend on the hardware you are re-using. But what if it’s not allowing me to create a cluster, or run certain workloads, or is so old that it won’t allow me to use certain features?
And the rambling goes on, and on, and on.. At least, I think this is where a lot of folks can go wrong. My gut feeling is that we perhaps over-think what is being said/asked. If we know nothing about the environment at all, but the customer tells us that we need to re-use the hardware that is already in place, then that is a?
- Requirement? We are after all required to re-use the hardware?
- Constraint? We are constrained from bringing in any other hardware?
What would be your take on this? And what do you use to actually differentiate and remember what is what?
BasRaayman's Technical Take 
The biggest challenge for me in determining functional vs non-functional requirements is understanding the project perspective.
For example if your project is to implement some infrastructure then the functional requirements may well be ‘N+1 resiliency should be factored in’ or ‘resources should be guaranteed according to internal SLAs’. In a prior job however the project was often run at the application level and almost all infrastructure concerns were put into the ‘non-functional’ requirements. In that case the functional requirements specified what the application should do – the infrastructure merely affected the behaviour of the application and was therefore non-functional.
For something common sense says is easy this sure does get complicated!
Agreed, and where in real life, you may be able to (or actually, should!) ask questions to your customer in a different way, and further define what the functional and non-functional requirements are, during tests this is not an option.
Also, some folks mentioned the Cloud Infrastructure Architecture Case Study (http://www.vmware.com/resources/techresources/10255) as an example, and while I think it’s a great document, it’s limited in the rationale behind the constraint and requirement categorisation. And while I assume that these are obvious to someone who has been doing design for a long time, there’s probably quite a curve for someone who is new to this.
Great posting Bas and as Steve said on twitter him and I had the same question and discussion in our vSphere 5 Design Workshop last week and the lecturer battled also stating if it is a constraint then it is a non-functional requirement but they way I’ve learn it in prep for my VCAP-DCD is that functional is when something should DO something & non functional is HOW that something should be done. Scott Lowe covers them nicely in his vSphere Design Trainsignal videos so I’m sure he could shed some light on it also for us as that’s where I’ve learnt my understanding
What I found during my preparation to VCAP-DCD exam is it fits both Requirement and Constraint.
Requirment – customers sais it should be done this way
Constraint – this requirment limits your design choises.
Constantin, that is what everyone says. But with my example, isn’t it both? The customer tells you that you have to use the existing hardware, there is no other way, thus it also limits your design choice.
I actually like Gregg’s explanation, as it’s relatively simple to remember, and I feel that this could work for folks struggling with this.
With your example it`s correct. Gregg`s explanation is really great. In my previous comment I lost one more phrase: for me this question was cleared in Managing and Optimizing VMware vSphere Deployments book, I strongly recommend it for VCAP-DCD preparation.
=) I hope it’s right, I’ve been applying it to a project I’m working on at the moment and it seems to apply perfectly. I always think there are many way to meet a requirement so choosing FC over NFS is non functional but having shared storage is functional for example