"Modern" Software Framework?
in [OOP]
|
Prev: Design by Contract vs Law of Demeter : Preconditions
Next: New England Patriot jerseys for men,worldwide express, paypal payment
From: philip_b_taylor on 2 Sep 2007 19:54 On 23 Aug, 02:26, Alexei Polkhanov <apolkha...(a)relic.com> wrote: > Hehehehehe!!! You have not listed even a SINGLE requirement in that > list. All these items are parts for proposed solution for problem that > have not been even articulated. When you see something like "System > should send customer information to server over XML protocol" - first > thing that should ring the bell is that it is not a requirement > because requirements should never suggest solution or have parts of > design embedded in it. "System should be able to submit customer > information to central shared storage and provide feedback to user in > 2 seconds". - this is requirement. > > Ironically I would excuse someone with little knowledge about Software > Development, but for someone who knows cool words like "CORBA and C++" > you should at least be aware of what User Requirements are and thing > that go in there and things that NOT. It even more amazing that most > people who participated in this thread did not even noticed that :-) > Funnily enough, in this instance these *are* requirements. It just happens that they include some required solutions. Unfortunately, in real large systems of this type, non-functional requirements involving politics, cost, legacy and prejudice are much more influential than things like a clean design or even a system that actually satisfies the functional requirements. At its worst, a feasible solution is first decided on, then you find someone who's willing to implement this solution. Eventually you see some User Requirements - so modify them to fit the solution... Philip
From: Phlip on 2 Sep 2007 20:19
philip_b_taylor wrote: > Funnily enough, in this instance these *are* requirements. It just > happens that they include some required solutions. I heard a really cool term for these situations recently; it applies here very well. The details you listed are "prosthetic goals". Your real goals - your _real_ requirements - are a system with such-and-so users, such-and-so throughput, and such-and-so costs. > Unfortunately, in > real large systems of this type, non-functional requirements involving > politics, cost, legacy and prejudice are much more influential than > things like a clean design or even > a system that actually satisfies the functional requirements. So, whoever added all these finished decisions to your "requirements" documents, do they have the authority to decree you all _must_ use them? If so, do they also have the responsibility to see the project finished? -- Phlip http://www.oreilly.com/catalog/9780596510657/ "Test Driven Ajax (on Rails)" assert_xpath, assert_javascript, & assert_ajax |