software requirements again, take 483
in [Perl]
|
From: ccc31807 on 6 Apr 2010 16:53 On Apr 4, 5:07 pm, Charlton Wilbur <cwil...(a)chromatico.net> wrote: > 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. It's not that I don't wish to understand the point. In some cases, the end user doesn't know the requirements until he has a handle on the data. An end user that doesn't understand the problem can't specify clear and precise requirements. In order to follow your advice to clarify, disambiguate, or reduce to writing the requirements, it's sometimes necessary to write code that does something. We don't always have the luxury of having a complete and precise specification before writing the first line of code. This is one of the challenges that the spiral development cycle was designed for. CC.
From: Charlton Wilbur on 6 Apr 2010 17:03 >>>>> "R" == Ruud <rvtol+usenet(a)xs4all.nl> writes: R> Do they really still exist, these environments where they write R> up specifications and sign them off and such? What a waste! R> Go and work in a communicative environment, where the "business" R> and the "developers" continuously share and improve the business R> knowledge, and help each other to get results, with noticeable R> improvements every day. ....and what you're doing is just writing the specifications iteratively and interactively. If you don't know what your goals are, you have no idea if you're making any progress towards them. Charlton -- Charlton Wilbur cwilbur(a)chromatico.net
From: ccc31807 on 7 Apr 2010 07:57 On Apr 6, 5:03 pm, Charlton Wilbur <cwil...(a)chromatico.net> wrote: > ...and what you're doing is just writing the specifications iteratively > and interactively. What's wrong with that? Seems to be that the basis of 'requirements engineering' is that requirements are developed in an empirical, deductive manner, rather than a top down all-or-nothing manner. > If you don't know what your goals are, you have no > idea if you're making any progress towards them. This is a truism, and like all other truisms has limited application. The 'goal' might be to grow the business, but the devil is in the details. I did a project recently analyzing call center data, developing scripts showing when, where, and why the users called. Some areas had a lot more calls than others, and I recall a heated discussion as to whether it was because these units were doing a better job than the others, or a worse job than the others. The 'goal' was to service the users. Does a high call volume mean that you are doing a better job? or a worse job? Do you want to increase the help calls, which might indicate that people were using the product? Or do you want to decrease the help calls, which might indicate that people were actually using the product rather than having problems with it? CC.
From: Charlton Wilbur on 7 Apr 2010 08:33 >>>>> "cc" == ccc31807 <cartercc(a)gmail.com> writes: >> If you don't know what your goals are, you have no idea if you're >> making any progress towards them. cc> This is a truism, and like all other truisms has limited cc> application. The 'goal' might be to grow the business, but the cc> devil is in the details. "Make the business grow" is a strategic goal. Someone who knows the business needs to derive some tactical goals from that -- things that, if the workers should accomplish them, should result in the business growing. But "make the business grow" is a completely useless goal to give to a programmer. More to the point, you cannot invalidate the usefulness of goals in software development by pointing out the difficulty of working towards a vague strategic goal. Yes, that's a goal. No, it's not a useful goal for a programmer to work towards without an intermediate goal. Time and time again you're given a vague specification or no specification at all, you dive in headfirst, it turns out to be not what the person actually wanted, you take all the blame, and then you vent here. You are contributing to and enhancing the problem that you're complaining about, and you're too stubborn or stupid to see it. You are building the hell you're in, and when other people point out that you are doing so, you come up with a paragraph of quasi-management speak to justify why you should keep on building your own hell. If you want help, you've come to the right place. If you want to vent about how miserable your life is and how nobody understands you, livejournal is that way. Charlton -- Charlton Wilbur cwilbur(a)chromatico.net
From: ccc31807 on 7 Apr 2010 09:08
On Apr 7, 8:33 am, Charlton Wilbur <cwil...(a)chromatico.net> wrote: > If you want help, you've come to the right place. If you want to vent > about how miserable your life is and how nobody understands you, > livejournal is that way. I think you might have misinterpreted the thrust of the conversation. My intention was to provoke a discussion about the process of developing applications, which in mu case means little scripts that import data and export information. I don't want or need 'help' in dealing with my personal employment situation. I don't want or need to 'vent' in the sense garnering sympathy. I certainly don't want to give the impression that my life is miserable, because it's not. These kinds of discussions have value (IMO) because they allow us to share experiences and ideas, which help in the day to day practice of our profession. My clients aren't stupid, ignorant fools who exist merely to make my life hell, but smart, knowledgeable professionals who want to grow the enterprise. It's my job to help them by giving them the information they need. The fact that they might lack the skills to do this, and the vocabulary to talk about the process, just makes the job more challenging, and my own role more important. CC. > > Charlton > > -- > Charlton Wilbur > cwil...(a)chromatico.net |