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 