Recently I am studying an important topic regarding system development, called requirement engineering. A great book covering this topic is from Sommerville, Software Engineering (version 8).
What I find fascinating is that, from a developer perspective, it is hard to tell if what you’re creating is actually that what the customer wants. Although I am used to using Functional Design’s, which cover the requirements, there are always multiple filters applied to those requirements (and their documents). And, even when finally a developer is building the software, the developer has its own filter applied as well.
The so called ‘gap’ that exists can be minimized by making the language, used for writing requirements, more abstract. Even so, there is simply not enough time to formally write requirements, like how it is done with formal specifications. Unless you’re writing requirements and the needed systems for critical systems (like a nuclear powerplant, aircraft, etc), there will always be gaps.
Something I’ve noticed is that it is also hard to verify if the end-result is actually what the customer defined in their requirements. Or, sometimes it could be that 2 or more requirements simply conflict with eachother. It should not be a problem, when these requirements are discovered early in the process. The real fun begins when these conflicting requirements are discovered later.
The good thing is there are always solutions around the corner, a little agile software development can do miracles and speed up the discovery of ‘gaps’. Using short(er) iterations to confirm your design has proven quite effective. Even when creating ‘just’ requirement specifications.
I’ve had the pleasure of following a process of discovering requirements and I’ve learned a lot from it. Although I am not an Information Analist, nor a requirement elicitator expert, I did find something interesting about the whole requirement specification process. In one word i could define it as scope.
Somehow determining the scope of the requested functionality versus the requirements it has effect on is easily widened. This is not nescesarily a bad thing, because it is good to know what requirements are effected by a new requirement, or a change in requirement(s).
The problem lies within the complexity which is introduced by cristalizing all the details for all requirements that are ever hit. In my opinion there is a role for the company that actually creates the requirements documents, and the stakeholder(s) who continiously have new, or changed, requirements for their system.
The role of the company, responsible for creating the system and the requirement documents, should make clear to the stakeholders what effects their requirements have on other requirements on a high-level. Even though there will be effects on the lower level(s), it should be possible to ask for faith, and trust, in your work. It should be possible to ask for an approval on high level requirements, in order to ‘drill down’ to the details. Whenever every detailed question needs to be answered in order to have the high-level requirements being accepted, it will cause multiple (unwanted) effects:
– the requirements remain unclear, and can still change. The context is not defined.
– because no decisions are being made, discussing details could be a waste of time.
– when taking all details into account, the complexity increases significantly. Making it even harder to decide what effect is acceptable for a needed change.
Again, I am no expert. But this is the vision I have built up the past few weeks. I am wondering what others think. If you have any comments then I’d like to hear them.