dwwright99 wrote "How does that work for you? Thanks again for raising this. Guy" I am not sure yet. What would be an example of a Requirement you would validate 'behind the scenes'?

David,

So I'm saying that I would validate all requirements behind the scenes but here's the thing. We're business analysts and we're meant to specify requirements without worrying about the solution (that's design).

So in the analysis process I have a requirement to ABC - ask, believe no-one and check. This supports the objective of delivering high quality analysis deliverables as measured by the number of faults in the analysis.

But most of the questions and comments have not been about "do you really need to do ABC" but are about how to do ABC (and avoid being confrontational etc). Well, that's design isn't it and once we agree ABC is a requirement then it can be implemented through any design that delivers the requirement: consensus cuddly discussions, in-your-face challenge and answer - doesn't matter so long as all enagaged are happy to work that way and deliver the objectives.

As for a specific example of a requirement that gets validated this way - how about this one doing it as we're doing right now in this forum in these posts?

Guy

David,

ok - a real example from the project I am currently working on: we have an objective to reduce the average journey time of patients through an Accident  Emergency dept - a user came up with a requirement to have Ambulance crews assign an episode number to a patient in the ambulance. That's what the users told me when I asked them. "A" out of ABC. I checked this out as an idea with senior managers and have started to with Ambulance crews (I "B"elieve no-one so "C"heck with every stakeholder I can find) and I have researched how other A&E depts do this and researched A&E performance reports to try and quantify how much impact this would have (I "C"heck via other sources as well). ABC.

But I am surprised that all the challanges to this ABC (and there are many both here and over at my RGNG post) are all about how to do this (deisgn and implementation) and not whether we (as BAs) should - requirement. Now - about your question about how does the first part of the sentence relate to the second...the next sentence and subsequent ones make the point that the challenges to this ABC are all about design and implementation and not requirement - the questions about design and implementation are irrelevant if the requirement is wrong. So if ABC is wrong why worry about the implementation? But no-one seems to be suggesting that ABC is wrong, just that we should be more cuddley about it (which is fine, interpersonal skills and all) and my post is not intended to discuss how to ABC, just raise the question of whether we should.

There are buckets and buckets of posts/books/presentations/courses on inter-personal skills and everyone has an opinion on them. Great, important stuff, and well covered. Analysis (structured, methodical and analytical in the true sense of the word) does not seem to get as much as air time (look at Agile's focus on the collaborative touchy-feely side of the job).

Mind you - I think that may be because humans just don't like analysing on the whole for reasons I may have mentioned in other posts!

Guy

David,

Good call: the user requirement was a solution in hunt of a requirement. I did not record the requirement as that solution (me? trust someone and take what they say at face value?!?! Are you crazy??!?! )  - rather it became a functional requirement  "the ability to uniquely identify patients to A&E treatment services" and the process model has one  starting event "Ambulance crew assess patient" resulting in the creation of an Episode entity on th data model with the primary key being the business data item Episode No and all because of the signed-off (i.e. comitted to) objective "reduce average journey time of patient through A&E". I researched other A&E depts to assess the requirement feasibility. Were there constraints that would prohibit such a requirement?

Eliciatation techniques used were 1:1 interviews, on-site inspection of current processes (client and other sites), document investigation (of client and other sites), workshop process model development with 2 subject matter experts and some slow, ponderous thinking.

ABC?

Guy