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.
Author: Geri Schneider Winters
Defining specifications for the design and development of systems and software is a lot like this classic Gershwin song and what I personally regard as the biggest cause of confusion in the Information Technology field for as long as I can remember, which is over 30 years in the industry. Some people say specifications should be based on the inherent properties of information, others believe it is based on a screen/report or file layout, yet others adamantly believe it should be based on process and data specifications. Interestingly, all are absolutely correct. The difference lies in the perspective of the person and the work to be performed. For example, how we define specifications for the design of an automobile is certainly different than how we specify a skyscraper. The same is true in the I.T. field where we have different things to be produced by different people.
brought to you by enabling practitioners & organizations to achieve their goals using: