In the September/October issue of IEEE Software, I came across an article titled “Why Context Matters” which gets to the difference between functional and non-functional requirements and how the two interact and are interdependent.
Functional requirements are normally taken to be those hard and fast rules like “the speedometer must accurately report speed to the user.” Everyone in the industrialized world has a pretty solid idea of what it should do or how it should work. Therefore, there isn’t much room to wiggle.
Non-functional requirements are much more “squishy” and open to interpretation of the people capturing the requirements, the users, and those actually implementing the functionality. A rule like “the speedometer must report speed in an easily discernible manner”. Wow, now we have lots of room to wiggle, which way do we go?
This is where the Context comes into play.
We need to know how the user expects to interact with the component, how important it is to them, and what the connection is between our system requirements and our business rules. The worst part is that this is an ongoing process. It never ends… even if the customer is sitting next to you slapping your hands when you make a bad decision.
Of course, there are some Project Management methodologies – such as Waterfall – that can do a poor job of this effort while there are others – such as various Agile Methods – that involve the customer early and often in the process. This serves as an outside review of the overall system. By no means should you expect the customer to perform Validation or Verification of the system, but this can catch some of the big glaring oddities in the system prior to release and much earlier in the development cycle.
Communication and a certain amount of understanding of the customer is vital. You need to determine how they’re using the existing comparable functionality, why they do it a particular way, and what they expect to happen afterwards. If the customer sees something unexpected, it doesn’t matter how fast/efficient/error-free/nifty a system is . By their standards, the system is “wrong” and now you have to “fix” it.
In case you didn’t detect the “squishiness” in the initial functional requirement for the speedometer, here are a few variables to play with:
- US company exporting to the EU
- EU company exporting to the US
- The display which must read the same regardless of the viewing angle
- It’s for an aircraft
- It’s for an golf cart
- It’s for an Formula-1 car
It doesn’t take much thought to see how any of those scenarios which could radically change the implementation. Our requirements are not complete until we capture this information.