[OT] Business Requirements Analysis... Sort Of

So... yesterday I get an e-mail of a forward to a response to a forward of
a reply to a forward of an FYI to a forward of... etc, going back about
two months... with the question of 'Can you do something about this?'

My response is 'I'm not sure what is wanted.  If someone can tell me,
clearly and unambiguously:

1) Selection criteria - out of (n) employees we need to look at the ones
which have (condition or (combination of conditions))

2) Output requirements - for the employees whose data satisfy 1) above we
need to see (fields)

3) Date span - we need this information for (start period - end period)

... then I should be able to tell you if this is something I can put
together quickly or if it will take a while longer.'

The response was surprisingly to-the-point, given the organisation...
along the lines of 'For all the employees of the Midwestern Division
who qualify for Unsupported Dementia Leave that left the organisation and
received Miscellaneous Graft and Corruption payouts from October 2006 to
the present we want to see name, separation date, amounts paid out and
(some other stuff)'.

And so... I've sent off my response.  What follows are some almost
verbatim quotes:

(note - this is a shop that runs on files, not on a database)

1) Employees of the Midwestern Division - what value(s) in which field(s)
in what file(s) indicate an employee of the Midwestern Division?

2) Employes of the Midwestern Division who qualify for Unsupported
Dementia Leave - given 1) above, what value(s) in which field(s) etc.?

3) Employes of the Midwestern Division who qualify for Unsupported
Dementia Leave that left the organisation - given 1) and 2) above, what
value(s) in which field(s) etc... you might begin to sense a pattern here.

... and the final sentences were:

If all the data you request can be found in a single file (e.g., the
Paymaster) then this will be a moderately cumbersome task.

If multiple files need to be matched and merged for only single pay
periods this will be a cumbersome and time-consuming task.

If multiple files need to be matched and merged for multiple pay periods
then this will be a cumbersome, time-consuming and unwieldy task.

... and the response will not be, I believe... a pleasant thing to see.

DD

<docdwarf@panix.com> wrote in message news:frr1an$ok8$1@reader2.panix.com...
>
> So... yesterday I get an e-mail of a forward to a response to a forward of
> a reply to a forward of an FYI to a forward of... etc, going back about
> two months... with the question of 'Can you do something about this?'
>
> My response is 'I'm not sure what is wanted.  If someone can tell me,
> clearly and unambiguously:
>
> 1) Selection criteria - out of (n) employees we need to look at the ones
> which have (condition or (combination of conditions))
>
> 2) Output requirements - for the employees whose data satisfy 1) above we
> need to see (fields)
>
> 3) Date span - we need this information for (start period - end period)
>
> ... then I should be able to tell you if this is something I can put
> together quickly or if it will take a while longer.'
>
> The response was surprisingly to-the-point, given the organisation...
> along the lines of 'For all the employees of the Midwestern Division
> who qualify for Unsupported Dementia Leave that left the organisation and
> received Miscellaneous Graft and Corruption payouts from October 2006 to
> the present we want to see name, separation date, amounts paid out and
> (some other stuff)'.
>
> And so... I've sent off my response.  What follows are some almost
> verbatim quotes:
>
> (note - this is a shop that runs on files, not on a database)
>
> 1) Employees of the Midwestern Division - what value(s) in which field(s)
> in what file(s) indicate an employee of the Midwestern Division?
>
> 2) Employes of the Midwestern Division who qualify for Unsupported
> Dementia Leave - given 1) above, what value(s) in which field(s) etc.?
>
> 3) Employes of the Midwestern Division who qualify for Unsupported
> Dementia Leave that left the organisation - given 1) and 2) above, what
> value(s) in which field(s) etc... you might begin to sense a pattern here.
>
> ... and the final sentences were:
>
> If all the data you request can be found in a single file (e.g., the
> Paymaster) then this will be a moderately cumbersome task.
>
> If multiple files need to be matched and merged for only single pay
> periods this will be a cumbersome and time-consuming task.
>
> If multiple files need to be matched and merged for multiple pay periods
> then this will be a cumbersome, time-consuming and unwieldy task.
>
> ... and the response will not be, I believe... a pleasant thing to see.
>

LOL!

I guess you have to give them credit for an interesting turn of phrase...
:-)

I'd translate this as:

"You're not expecting us to actually KNOW or UNDERSTAND what's in our data
are you?  Do you have any idea how tiresome it is for us to have to respond
to requests like this? Good grief!... someone may actually have to find out
where data is stored and put together an Easytrieve or something... We don't
come here to work, you know, and being asked to do something that might
actually result in work is simply unreasonable. We don't know which fields
are the ones you need, we don't know where they are stored, and if it turns
out to be across several files there might actually be a few hours work
involved for somebody...even if it's all on ONE file there is still work
involved. You don't REALLY want to do this, do you?"

Must be fun to work in such an organization.

Pete.
--
"I used to write COBOL...now I can do anything."

> DD
>

On Wed, 19 Mar 2008 12:35:35 +0000 (UTC), docdwarf@panix.com () wrote:

>
>So... yesterday I get an e-mail of a forward to a response to a forward of
>a reply to a forward of an FYI to a forward of... etc, going back about
>two months... with the question of 'Can you do something about this?'
>
>My response is 'I'm not sure what is wanted.  If someone can tell me,
>clearly and unambiguously:
>
>1) Selection criteria - out of (n) employees we need to look at the ones
>which have (condition or (combination of conditions))
>
>2) Output requirements - for the employees whose data satisfy 1) above we
>need to see (fields)
>
>3) Date span - we need this information for (start period - end period)
>
>... then I should be able to tell you if this is something I can put
>together quickly or if it will take a while longer.'
>
>The response was surprisingly to-the-point, given the organisation...
>along the lines of 'For all the employees of the Midwestern Division
>who qualify for Unsupported Dementia Leave that left the organisation and
>received Miscellaneous Graft and Corruption payouts from October 2006 to
>the present we want to see name, separation date, amounts paid out and
>(some other stuff)'.
>
>And so... I've sent off my response.  What follows are some almost
>verbatim quotes:
>
>(note - this is a shop that runs on files, not on a database)
>
>1) Employees of the Midwestern Division - what value(s) in which field(s)
>in what file(s) indicate an employee of the Midwestern Division?
>
>2) Employes of the Midwestern Division who qualify for Unsupported
>Dementia Leave - given 1) above, what value(s) in which field(s) etc.?
>
>3) Employes of the Midwestern Division who qualify for Unsupported
>Dementia Leave that left the organisation - given 1) and 2) above, what
>value(s) in which field(s) etc... you might begin to sense a pattern here.
>
>... and the final sentences were:
>
>If all the data you request can be found in a single file (e.g., the
>Paymaster) then this will be a moderately cumbersome task.
>
>If multiple files need to be matched and merged for only single pay
>periods this will be a cumbersome and time-consuming task.
>
>If multiple files need to be matched and merged for multiple pay periods
>then this will be a cumbersome, time-consuming and unwieldy task.
>
>... and the response will not be, I believe... a pleasant thing to see.

select name, separation_date, dirty_money
from employees emp,
(select employee, sum(amount_paid) as dirty_money
from payroll_detail pd
where debit_account = '6969'
and payment_date between to_date(20051001) and sysdate
group by employee
having dirty_money > 0) crook
where crook.employee = emp.employee
and emp.separation_date is not null
and emp.division in
(select division from divisions where division_name like  'Midwest%')
and emp.start_date >
(select min(start_date) from employees where name like '%Dwarf%')

-- Query preparation time: 5 minutes

In article <64dd2dF2att2eU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
>
><docdwarf@panix.com> wrote in message news:frr1an$ok8$1@reader2.panix.com...[/color
]

[snip]
 
>
>LOL!
>
>I guess you have to give them credit for an interesting turn of phrase...
>:-)
>
>I'd translate this as:
>
>"You're not expecting us to actually KNOW or UNDERSTAND what's in our data
>are you?

Mr Dashwood, quite the opposite... I'm using 'our' and 'we' to include the
user, not exclude.  We're all in this together, remember?

>Good grief!... someone may actually have to find out
>where data is stored and put together an Easytrieve or something...

Actually, Mr Dashwood, it is worse than that.  In one file there can be a
field called CODE-A which contains the same data which are in another file
named CODE-B... almost.  The first file uses a structure like:

01  INDICATOR-CODE.
05  CODE-A PIC X(5)
05  SUBSECTION-CODE PIC X(5).

... while the second file contains

01  INDICATOR-CODE.
05  SUPERSECTION-CODE PIC X(5).
05  CODE-B PIC X(5).

... and this, of course, is not documented because it had to be done Just
That Once... and when a user asks for CODE-A broken out by SUPERSECTION an
unwary programmer can spend days working out slicing, dicing, mixing and
matching until A Greybeard says 'Oh... in those two files CODE-A and
CODE-B are always the same, you need only to work with the second file'.

'Finding out where the data are stored' can equate to 'having seven-to-ten
years' worth of experience on that given subsystem'... a bit long to wait
to satisfy a user request, even by Glass House High Priest standards.

>We don't
>come here to work, you know, and being asked to do something that might
>actually result in work is simply unreasonable.

I cannot speak for a 'we'... but yes, I come there to do *my* job and, as
mentioned in another posting, walk the fine line between Getting The Job
Done and Not Doing Someone Else's Job.

>We don't know which fields
>are the ones you need, we don't know where they are stored, and if it turns
>out to be across several files there might actually be a few hours work
>involved for somebody...even if it's all on ONE file there is still work
>involved.

Mr Dashwood, there's the rub... it could not be in 'one file', since data
are stored in separate files for each pay-period... and HMIGRATEd off-line
after a few ws... oh, and the naming conventions aren't constant across
pay periods, either; some pay periods can contain two files (the A1 and
the B1) or just one file (the A1).  Finding out what files there are,
HRECALLing them, setting up JCL during the HRECALL to deal with a
forty-or-so dataset concatenation... never mind coding the actual program
or SORT to deal with it... gets a bit... cumbersome, as noted above.

>You don't REALLY want to do this, do you?"

No, Mr Dashwood.  Presenting the plain and unvarnished facts of the case,
that it might, possibly, be more than a simple pass through a dataset and
format and done... that it might involve a bit more work and analysis than
a mere 'lemme see'... is not, in my book, discouragement; it is making the
user a partner in the task.

>
>Must be fun to work in such an organization.

As with any place else... sometimes I find that it is, sometimes I find
that it isn't.  It is called 'work', not 'play'... although when it
happens that I have fun others say my work is better.  Strange how that
works, eh?

DD

In article <s6f3u3dlalc0i5g0jq4gtilg43kke5nm0o@4ax.com>,
Robert  <no@e.mail> wrote:
>On Wed, 19 Mar 2008 12:35:35 +0000 (UTC), docdwarf@panix.com () wrote:

[snip]
 

[snip]

>select name, separation_date, dirty_money
>  from employees emp,
>          (select employee, sum(amount_paid) as dirty_money
>              from payroll_detail pd
>              where debit_account = '6969'
>                  and payment_date between to_date(20051001) and sysdate
>             group by employee
>             having dirty_money > 0) crook
> where crook.employee = emp.employee
>    and emp.separation_date is not null
>    and emp.division in
>          (select division from divisions where division_name like  'Midwes
t%')
>   and emp.start_date >
>          (select min(start_date) from employees where name like '%Dwarf%')
>
>-- Query preparation time: 5 minutes

Amount of time spent carefully reading what preceded query preparation
time: not enough to catch a clear and unambiguous note.

DD

"Robert" <no@e.mail> wrote in message
 news:s6f3u3dlalc0i5g0jq4gtilg43kke5nm0o@
4ax.com...
> On Wed, 19 Mar 2008 12:35:35 +0000 (UTC), docdwarf@panix.com () wrote:
> 
>
> select name, separation_date, dirty_money
>  from employees emp,
>          (select employee, sum(amount_paid) as dirty_money
>              from payroll_detail pd
>              where debit_account = '6969'
>                  and payment_date between to_date(20051001) and sysdate
>             group by employee
>             having dirty_money > 0) crook
> where crook.employee = emp.employee
>    and emp.separation_date is not null
>    and emp.division in
>          (select division from divisions where division_name like
> 'Midwest%')
>   and emp.start_date >
>          (select min(start_date) from employees where name like '%Dwarf%')
>
> -- Query preparation time: 5 minutes

<Applause> Nice solution, Robert. Now spend another five minutes reading the
statement of the problem, which explains why the above is useless... :-)

Pete.
--
"I used to write COBOL...now I can do anything."

On Thu, 20 Mar 2008 01:01:37 +0000 (UTC), docdwarf@panix.com () wrote:

>In article <s6f3u3dlalc0i5g0jq4gtilg43kke5nm0o@4ax.com>,
>Robert  <no@e.mail> wrote: 
>
>[snip]
> 
>
>[snip]
> 
>
>Amount of time spent carefully reading what preceded query preparation
>time: not enough to catch a clear and unambiguous note.

All ya gotta do is write a schema defining the flat files and define it as a
n ODBC data
source. If there are multiple files, concatenate them with copy command, in 
JCL, or write
a view containing a UNION.

In article <qtt3u35t5f16ej8v6loh3pfnf3v5d3f392@4ax.com>,
Robert  <no@e.mail> wrote:
>On Thu, 20 Mar 2008 01:01:37 +0000 (UTC), docdwarf@panix.com () wrote:
> 
>'Midwest%') 
>
>All ya gotta do is write a schema defining the flat files and define it
>as an ODBC data
>source. If there are multiple files, concatenate them with copy command,
>in JCL, or write
>a view containing a UNION.

That's just the kind of response I'd expect from a Manager, Mr Wagner...
are you considering a career-change?

(actually... I found out Just The Other Day that they *do* have a 'Reports
Group' just for situations like this and the Reports Group does...
something-or-other with an Oracle loading of the files I interrogate with
COBOL and DFSort.

My tech lead said that the users have expressed a preference for putting
these requests into my hands... because I seem to Get More Done.  Go
figure, eh?)

DD

In article <64dsgbF2asnp6U1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
>
>"Robert" <no@e.mail> wrote in message
> news:s6f3u3dlalc0i5g0jq4gtilg43kke5nm0o@
4ax.com... 

[snip]
 

[snip]
 
>
><Applause> Nice solution, Robert. Now spend another five minutes reading th
e
>statement of the problem, which explains why the above is useless... :-)

It has already been said, elsewhere, something about how those with only a
hammer see all problems as nails... I recall something like this happening
a few years back, where I posted a problem and received a response of 'All
ya gotta do is issue an SQL query like...', hence my attempt to avoid such
this time by the parenthetic note above.

Shows how well *that* worked, yep.

DD

On Thu, 20 Mar 2008 09:17:47 +0000 (UTC), docdwarf@panix.com () wrote:

>In article <qtt3u35t5f16ej8v6loh3pfnf3v5d3f392@4ax.com>,
>Robert  <no@e.mail> wrote: 
>
>That's just the kind of response I'd expect from a Manager, Mr Wagner...
>are you considering a career-change?

My parents were married.

>(actually... I found out Just The Other Day that they *do* have a 'Reports
>Group' just for situations like this and the Reports Group does...
>something-or-other with an Oracle loading of the files I interrogate with
>COBOL and DFSort.
>
>My tech lead said that the users have expressed a preference for putting
>these requests into my hands... because I seem to Get More Done.  Go
>figure, eh?)

Users SHOULD ask for a general purpose query screen that THEY can run withou
t running the
bureaucratic gauntlet every time. If I were working there, I'd sell them the
 idea, then
write it for them.

I did that in the Good Old Days. My query program turned into DYL240, which 
became DYL280,
now called Quick Job.