On Thu, 05 Feb 2004 19:10:25 -0800, Kevin Counts wrote:
[snippage]
You are right on with what the project manager indicated this morning,
none. Understand I am asking for a questions which may evolve into
multiple levels/layers so an easy to answer question like that may contain
sub-questions (these are what I am really looking for) which get to the
"meat" of the requirements.
If you're familiar with the Software Development Life Cycle (SDLC), then
you're interested in the Functional Requirements Modelling/System
Requirements Modelling parts of the process. In reality, SDLC and systems
design are normally disjointed from each other (at least at the $VB_TELCO
I work for), but I'll share some of what I have found as effective
requirements questions. I'm giving you what I recall from the top of my
head (having been remote from the requirements gathering biz for a while
now) in the form of top-level questions that can stimulate some of the
discussion around the requirements.
Keep in mind that all of this cannot be considered
without factoring in the software that will run on top of the systems you
build. You can have the greatest HA set up in the world, but if the cost
can't use it, it's wasted dollars and worse, false security for your
customers.
1) Availability requirements:
The more 9's you want, the steeper the curve on cost. Do you require:
a) Automated failover of transactions in flight?
b) Automated failover of systems that allow a user to retry a transaction?
c) Redundancy of hardware components to minimize downtime and speed
recovery?
2) Recovery requirements:
The quicker you want to recover data, the steeper the curve on cost. Do
you require:
a) Geographically dispersed failover sites that mirror data?
b) Locally mirrored data on dedicated recovery equipment?
c) Mirrored data on disk backed up to tape?
3) Database requirements:
The more detail you can provide here, the better the resultant design will
be.
1) How big is the database projected to be once fully in production?
2) How much growth is expected?
3) How quickly does the database need to be backed up?
4) What is the predominant activity on the database (Read/Writes,
OLTP/Data Warehouse?)
5) What vendor is supplying the database?
6) What method will the DBA be expecting to use to back the database up?
7) How will the database be archived/purged, and what are the retention
requirements for data managed in that way?
8) What are the retention requirements for backups of the database?
9) Are there any legal requirements around the data in the database
(HIPPA, encryption, access requirements)
4) Transaction requirements
1) What types of transactions are flowing through the system (Access Data,
Update data, Business Logic, Accounts Receivable, Data Warehouse,
Reporting)
2) What volume of each of these transaction types can be expected at a
peak? At an average?
3) What are the expected performance levels of these transactions?
4) Can the application code track how long each component takes to
execute?
5) How many users can be expected to be accessing each front end/back end
system at a peak? At an average?
5) System requirements
1) Is there a vendor providing the application infrastructure for this
project?
2) Do they have specific hardware/OS/software requirements?
3) Do they have sizing information relating to transaction volumes being
executed on their systems from other customers?
4) Do they have a roadmap on OS and 3rd party software currency to allow
us as a company to remain current with the latest patches/OS upgrades?
5) Is there specialized hardware required for this project? (ie handhelds
etc)
6) Is there application code to be loaded on end-user desktops?
7) Is there application network utilization data available from the vendor
or from internal benchmarking?
You get the idea. The list goes on and on and ON! :-)
A good way to start working through the other questions
you have that you'll want to ask is imagine the system is in production
and work your way back from there, especially if you start during a
production outage situation. The challenge is discerning the information
you need to bring to the table distinct from what the customer brings to
the table. Oh, and be prepared to give the cost of doing a mix of the
availability/recovery/transaction "options" you by default end up
presenting to them through the questioning.
Exactly what business impact will you have from data loss? Can you
quantify it in lost dollars and/or lost hours? How bad is losing 5 minutes
of data compared to a week? If less, can losing 5 minutes of data be as
bad as a week if its the wrong 5 minutes? ;-)
This is called a "Business Impact Assessment", which falls under the realm
of the Business Continuity/Disaster Recovery area of practice.
Oh - BTW - AFAIK we have no formal SLAs in place on any past, present, or
future system.
Get some. Quick. Or else you'll have nothing to even remotely shoot for as
you progress through production!
Regards,
Chris
--
Chris "Saundo" Saunderson ***@earthlink.net
Unix/CCNA/CCDA Guy Powered by Linux and the Orb.