Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: XML As Fall Guy
 On 11/28/2013 1:46 AM, Stephen Cameron wrote: The problem of writing requirements up front is that one often can't know all the important aspects of the problem until one gets well into trying to solve it. Same with quoting a project - early on, you can't quote with precision unless the job is very similar to others you have done. But a contractor has to know what it's bidding on in good detail, so you can't just leave lots of details until later.My theory is that the idea of issuing tenders, which is based on defining requirements up front, is just plain wrong for complex software systems, that are essentially part of the culture of an organisation. And right here is a good example of the confusion many people and agencies have, one that often causes no end of difficulties. There are requirements, and there are specifications. And they are not the same. Requirements are what the end user/agency needs to accomplish, specifications are testable statements of behavior that, if passed, help to show that the system will accomplish the requirements.The only solution is to get people with the expertise to do ALL the work, including writing a specification if necessary, and to take ALL the risk. They are not the same. The builder can only design and build a system to meet a set of specifications - because they are what can be tested. The requirements - needs of the customer - ideally will mesh with the specifications (or the other way around). Let's say, for example, that you are the buyer of a car to be developed, and one of your requirements is that the car has to be able to transport a family of four at least 400 miles between refueling stops. Fine. The vendor will have to say "well, a family of four, we will take that to mean two adults weighing an average of 160 lb apiece, and two teenage children, height 5 ft 6 inches, weight 130 lb (sorry, metric users!). "transport" we will take to mean drive at an average speed of 55. Good. Off we go to design and prototype. We estimate the weight of the vehicle, then we can estimate the amount of fuel, and by iteration we converge on a workable design. But now the customer comes back and says that the adult weights must be 170 lb, the teens will need more room, and oh, yes, the customer forgot about baggage. OK, fine, maybe the changes can be accommodated, maybe they can't. But the vendor can't now accept all the risk for failure. The vendor quoted the job, but now the basis for the original quoted design has been changed. Maybe the changes make for an overall system that's no longer feasible. Maybe a complete redesign is called for. Now there are lots of risks, and the vendor can't know how much to charge to account for them. Though this is a very simplified example, it's realistic in the sense that this kind of change goes on all the time, and ordinary contracting practices just aren't up to handling it. "The" government (whichever one you want to talk about) can be pretty bad about it, but not just government buyers. 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
