software requirements again, take 483
in [Perl]
|
From: Dr.Ruud on 5 Apr 2010 06:30 Shmuel (Seymour J.) Metz wrote: > IMHO, if the business process owner signs off on the specifications then > it's his responsibility if they're wrong. Do they really still exist, these environments where they write up specifications and sign them off and such? What a waste! Go and work in a communicative environment, where the "business" and the "developers" continuously share and improve the business knowledge, and help each other to get results, with noticeable improvements every day. Most goals should never be defined, they should just remain a general idea to works towards to. *Why try to fork reality?* Adapt to it, and reality will work for you. -- -- -- When I look back on successful changes of a larger scale, there was often an Idea-A, -B and -C. The Idea-C approach was worked on in the early stages, gets labeled as "research", and remains available as both a reference and still an alternative. Idea-B is there for if Idea-A is achieved much quicker than anticipated. The Idea-A is about 60% of Idea-B (or even less). The funny thing is that when work on Idea-A is started, there is also work started on parts of Idea-B that are not in Idea-A. That superfluous part of the work has its role, but gets postponed with the first signs of trouble. Then it is firmly decided to get Idea-A done first. But of course, the "Idea-A" at that moment is different from the "Idea-A" at the start. It has evolved and matured. That it still gets called by the same name, is important too. -- Ruud
From: ccc31807 on 5 Apr 2010 10:06 On Apr 5, 6:30 am, "Dr.Ruud" <rvtol+use...(a)xs4all.nl> wrote: > Do they really still exist, these environments where they write up > specifications and sign them off and such? What a waste! I work with many clients to whom ordering a script or a report is like ordering a desk or a chair. You submit a purchase order, and the item when delivered does what it should. I often get requests for reports asking for "all" of something, for example, "all" people matching a specific criteria. The client, who expects a list of several dozen at most, screams and hollers when I deliver a list of 350,000 plus. The client's problem is that he hasn't fully specified all relevant criteria. My problem is that I don't know his relevant criteria -- he might very well want "all" of something. I think of this as the "don't touch a hot stove" lesson. You can tell a child many, many times that, if he touches a hot stove, he will get burned, and it doesn't do any good. However, let him touch a hot stove once, and the lesson is learned forever. (I used to call this the "don't play in the street" lesson until my wife told me that wasn't humorous at all.) > Go and work in a communicative environment, where the "business" and the > "developers" continuously share and improve the business knowledge, and > help each other to get results, with noticeable improvements every day. In this day, having a job can be a lot more important that the communicativeness of the environment. > Most goals should never be defined, they should just remain a general > idea to works towards to. *Why try to fork reality?* Adapt to it, and > reality will work for you. I agree with this totally. I think that the requirements should be defined precisely ('total' equals the product of 'quantity' of each line item and 'cost' of each line item for all line items). Software is infinitely malleable, unlike a physical item, and I totally agree that recognition and acceptance of this malleability is essential to writing good software. CC
From: J�rgen Exner on 5 Apr 2010 18:44 "Dr.Ruud" <rvtol+usenet(a)xs4all.nl> wrote: >Shmuel (Seymour J.) Metz wrote: > >> IMHO, if the business process owner signs off on the specifications then >> it's his responsibility if they're wrong. > >Do they really still exist, these environments where they write up >specifications and sign them off and such? What a waste! I most definitely want something in writing, even if it is for my own purposes only. Maybe you have a memory like an elephant but I can't remember what was discussed or agreed upon or even what I was thinking at the time when a month later that part of the project is due for implementation. And I cannot imagine how email or the Internet or Usenet would work without any written specs and protocols. jue
From: Dr.Ruud on 6 Apr 2010 15:09 J�rgen Exner wrote: > And I cannot imagine how email or the Internet or Usenet would work > without any written specs and protocols. Most of them document long standing practice. -- Ruud
From: Charlton Wilbur on 4 Apr 2010 17:07
>>>>> "cc" == ccc31807 <cartercc(a)gmail.com> writes: cc> We'll get this sorted out on Monday so I'm not worried about cc> it. The point is that the technical person can't work without cc> knowing what the requirements are, and at least in my situation, cc> I am often assigned work with unclear, ambiguous, or absent cc> requirements. Yes, and when a professional software engineer is handed unclear, ambiguous, or absent requirements, it is one of his responsibilities to see that they are clarified, disambiguated, or written at all. That is the point that you do not seem to wish to understand. Charlton -- Charlton Wilbur cwilbur(a)chromatico.net |