What's In a Name?
One of the products I offer that has been in most demand is software requirements training. A great course to deliver, with lots of information about the things that you could do (if the situation warranted) in software projects. Certainly not dogmatic or pitching a particular approach, one of the key messages is to consider your product, culture and environment, and choose accordingly. Over the years, though, I would sometimes get some pushback along the lines of “we do hardware (or firmware, or drivers…), this isn’t relevant for us”. I disagree.
Ah, the eternal hardware/software debate. Almost all of the books on requirements have ‘Software’ in the title, or are filled with examples from software applications, so there is a natural tendency for hardware (and firmware and drivers) developers to think that the content doesn’t apply.
Almost by definition, though, when we are talking about requirements we are talking about the essential, externally discernable behavior of a system, something that should be captured and expressed independently of the implementation to artificially constrain our options. We should be able to completely describe the needs of the stakeholders even before we decide whether to implement the solution in hardware, software, firmware, some combination thereof, or purchase the solution from an outside vendor (whether off the shelf or custom development). Capturing the requirements of the system helps us understand which direction we should take the solution, though in most shops the thinking is reversed – we already have the solution in mind, and it severely biases our thinking.
With that in mind, there is still much that can apply in these books and courses, even if the title suggests software. Use cases might diminish in value for hardware unless there is a rich sequence of steps involved in the device interacting with external systems (though there are some that would disagree), but other elements will definitely be relevant. An overall vision and scope for the project remains essential to set the bounding box and priorities for the project.
Some of the analysis techniques will be more relevant than others – state transition analysis will usually be important, often more important in embedded systems or drivers. Quality requirements will be essential (though, as with software, are often poorly expressed) and business rules (such as electrical standards) and interface requirements will need to be considered.
In hardware, the tradition seems to be that instead of detailed functional requirements, the equivalent information is captured in design documents, but I see that only as a terminology issue – call it what you will. Hardware developers are also far more comfortable with breadboards and other prototypes than their software peers, even if the practice provides great insight in either domain.
One of the key points is that on the hardware side, there is a stronger appreciation for the need to capture the requirements as effectively as possible, as the cost of errors is more readily apparent – throwing away a production run is much more tangible. But still, there has been pushback against the training.
I went through the ‘software requirements’ training material over the past year and removed all the references to software. It is seen as a more generic requirements course, even if there is no substantial change in content. Interestingly, I no longer get pushback from people suggesting that the information is not relevant to them. Hardware, firmware, and driver developers lap up the information, and comment that it is just what they were looking for! – JB