Keith Collyer (email@example.com) wrote:Here is my response:
> System requirements define (but not design) the solution to the
> problem . . . . [T]hese requirements define what the system must
> do to provide the desired capability.
I agree with much of what you wrote in the rest of your message, Keith, but this particular statement highlights again how oxymoronic requirements terminology has become.
How is it possible for so-called "system requirements" to define but not design the solution to the problem?
Let's say one of my problems is that it takes me too long to do my taxes. I challenge you or anyone else to "define what the system must do" to solve this problem without introducing any design choices. Is there anything that the system truly MUST do to solve this problem, aside from create a condition in which it no longer takes me too long to do my taxes?
the way I think of this is quite old-fashioned, in terms of function, the business requirements define why a system should do something (what I want to achieve), the system requirements define what the system must do to deliver what I want to achieve, and the design defines how the system does it. Of course, quality / constraint / non-functional requirements need to be taken into account throughout.
So, if your business requirement is "reduce the time taken to do taxes", then I would say that you need to do some analysis to understand what this means, still in the business area. Let's say that it breaks down into three activities (please don't argue with these, they are intended just as examples):
- collect income and expense information
- calculate tax
- complete tax form
This system requirement happens to be a fairly simple restatement of the decomposed stakeholder requirement, changing the focus from what I want to achieve to what the system must do - and that is common, but not inevitable.