|
When we meet the customer, what do we ask them to
find out the specifications of the application we are suppose to
build?
Issues to Consider:
-
What is the application supposed
to do?
-
Probably is very vague.
-
Could be contradictory.
-
What does it mean to say "It has to get such and such a job done" or "Make it
better"?
-
What are they doing
now?
-
What is wrong or deficient with the current
system?
-
What do they want in the
future?
-
Is there a migration
path?
-
What input data is available and in what form is it?
-
What outputs are required?
-
What controls are required?
- Which features are the most important?
- Conversely, what features are the least important?
- Which features are needed first?
- Not necessarily the most important feature.
- Can we construct a timeline for feature inclusion?
- What are the simplest forms (note
plural) of the application with which the customer can deal?
- Can an evolution of the application be charted out?
- Work process flow
-
How do they go about doing that task at the
moment?
-
What data and in what order does that data
appear in the process?
-
Does the customer want to keep that
process?
-
An application that is unusable is
useless.
- What plans for extension are
envisioned?
- Is customer willing to pay for some amount of up-front cost for
that extensibility?
- Is customer willing to pay for a back-end cost for
rearchitecting for extensibility?
- XP issues:
- What user stories can be created?
- What acceptence tests can be created?
- How and when can the customer be contacted by the programmer?
- How and when can the programmer be contacted by the
customer?
|