Product Management
What is the point of high level software requirements?
- Details
- Category: pm
- Published Date
- Written by angusf
- Hits: 581
I was asked today by a client to explain why I think that in producing high level software requirements, its important not to pre-define the technology or constrain the person answering the requirement with a specification.
Consider the original BBC iPlayer. It had, I believe, an unnecessary technical constraint in its requirements. This was that it was wrongly (in my personal opinion) stipulated that it must work with Microsoft DRM technology. This meant that the iPlayer could only work on quite specific versions of Microsoft Windows, which as the EU pointed out four years later and tens of millions of pounds of development cost later would be illegal for an organisation like the BBC. I think that qualifies as quite a good example of a bad requirement which forced a technology choice upon developers! Not to mention lost opportunity costs and TV Licence payers money down the drain.
By way of contrast, in the early 90's Windows 3.0 and OS/2 2.1 were both examples of answers to the high level requirement ‘Windows Icon Mouse and Pointer User Interface based multitasking operating system implementing a File Manager, Program Manager, Calculator, Notepad, Control Panel and Command Prompt and various other standard applets and providing an environment upon which applications can be written and run conforming to the Common User Access Guidelines of the Systems Applicaton Architecture’ Im paraphrasing but that’s basically it.
Nowhere in that kind of high level requirement should it state how and in what way were they to be built. Windows 3.0 was written in Assembler. OS/2 2.1 in C++, they had vastly different use and performance envelopes. They were written by different teams to the same set of requirements in order to make sure there was internal competition at Microsoft. OS/2 famously was beaten by the 'B' team who brought us Windows 3.0 - They did a better job it seems of interpreting the high level requirements.
Microsoft also had the foresight to have more than one bet running in case their teams didnt make the right choices. Good advice. If possible always consider more than one technology approach and conduct an open review of your technlogy decision making process. Otherwise you'll be constrained by what your developers are comfortable with rather than what you need to be successful.
Disclosure: The author worked at Microsoft in the mid 90's and was a member of the BBC trust accountability council for BBC London for almost 8 years from 2000 and wrote a paper for the BBC on how crap the initial iPlayer was after it took him only a couple of hours to use google to assemble tools to defeat the Microsoft DRM technology and play iPlayer content nicely on his Apple TV in DRM free H.264. The iPlayer team initially didnt respond. Eventually the EU forced them to make iPlayer Mac and Linux capable although the Adobe software used for this is completely different to the original iPlayer technology.