My friends and colleagues often ask me how I am able to produce so much in so little time.  Although I am flattered by such compliments, it's really not much of a secret which I attribute to the following areas (in no particular order):...

Author: Tim Bryce

Have you noticed the examples of requirements elicitation on my blog? In one case, I had a bit of a contest, using a game to elicit information. You can see this technique by looking in the category Online Game on the blog. Then I had a survey to elicit information. You can see that survey by looking in the category Survey on the blog. Today I am going to use the information from the survey to show you another technique you might use when developing requirements. That technique is writing Personas (or Personae for you Latin fans).

You write a Persona when you want to understand your customers better. This Persona is a story you will tell about a typical (but not real) customer. The Persona is a composite story about your typical customers, made very lifelike.

THE ANALYST (aka, Systems Analyst, Systems Engineer, Systems Architect, Business Analyst) - requires specifications about the end-User's information requirements in order to design a system solution.  This is normally based on a definition of the user's business actions and/or decisions to be supported.  Following the system design, the Analyst produces the specifications required by the Programmer and DBA to fulfill their part of the puzzle.  From this perspective, the Analyst is the translator between the end-User and the Programmers and DBAs.

Each party has his own unique perspective of the puzzle and, as such, requires different "specifications."  To compound the problem though, the role of the Analyst sharply diminished over the years, leaving it to the Programmers to try and determine what the end-User needs, a skill they are typically not trained or suited for.