|
Home > Archive > Unix administration > February 2004 > Questions to elicit systems requirements
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Questions to elicit systems requirements
|
|
| Kevin Counts 2004-02-04, 4:34 pm |
| Trying to develop a rough template to draw
from when interviewing stakeholders to elicit
system requirements (e.g. a project to
setup the os, hardware, and install the
application software binary).
Any suggestions for questions?
Here are some high-level ones, I think I need more system specific
stuff.
Q: Why is the project needed?
Q: What are the expected benefits from the new system?
Q: If we do not work on this project, what are the consequences?
Who does this most affect? Can we specifically say who?
Q: What is an acceptable amount of application data loss?
Q: What is an acceptable amount of downtime for the application service?
Q: Are there any windows of downtime that are better than others?
Q: What are critical times to ensure uptime?
Q: What systems will this system communicate with?
Q: (If this is replacing a system)
Why is the old system going away?
How long do you plan to run in parallel?
Q: What are the risks of not meeting the product delivery date?
Q: .................. Thanks for any input!
Kevin
| |
| Dave Hinz 2004-02-05, 12:37 am |
| On 4 Feb 2004 21:41:44 -0800, Kevin Counts <kcounts@helios.acomp.usf.edu> wrote:quote:
>
> Any suggestions for questions?
> Here are some high-level ones, I think I need more system specific
> stuff.
>
> Q: Why is the project needed?
> Q: What are the expected benefits from the new system?
> Q: If we do not work on this project, what are the consequences?
> Who does this most affect? Can we specifically say who?
Are you building a system, or asking them to justify the business
case for it? This seems odd.
quote:
> Q: What is an acceptable amount of application data loss?
> Q: What is an acceptable amount of downtime for the application service?
Easy answers, "none and never". Instead, ask what Service Level Agreement
applies (you should have these already).
quote:
> Q: Are there any windows of downtime that are better than others?
> Q: What are critical times to ensure uptime?
That's better.
quote:
> Q: What systems will this system communicate with?
> Q: (If this is replacing a system)
> Why is the old system going away?
Old systems _never_ go away.quote:
> How long do you plan to run in parallel?
quote:
> Q: What are the risks of not meeting the product delivery date?
Maybe if we knew the context of your arrangement that would help.
What's the situation you're in? To me, some of this seems awkward
and/or obviously not needed to ask?
Dave Hinz
| |
| Kevin Counts 2004-02-05, 1:35 pm |
| Dave Hinz <davehinz@spamcop.net> wrote in message news:<bvtgk7$10g7lk$1@ID-134476.news.uni-berlin.de>...
> On 4 Feb 2004 21:41:44 -0800, Kevin Counts <kcounts@helios.acomp.usf.edu> wrote:
>
> Are you building a system, or asking them to justify the business
> case for it? This seems odd.
>
>
> Easy answers, "none and never". Instead, ask what Service Level Agreement
> applies (you should have these already).
>
Dave -
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.
This morning when the project director answered the question as
you correctly predicted, it jostled my noggin to come up
w/ some follow-ups:
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 where I am hoping to get some general system administration
domain question ideas from a diverse group such as yourself and others.
>
> That's better.
>
> Old systems _never_ go away.
>
>
> Maybe if we knew the context of your arrangement that would help.
> What's the situation you're in? To me, some of this seems awkward
> and/or obviously not needed to ask?
>
> Dave Hinz
This is taking place at a Hospital/Med Research Center. The project
is for us sysadmins to develop and implement a system infrastructure
for an HL7 EDI application server that routes the EDI data between
different clinical systems.
Oh - BTW - AFAIK we have no formal SLAs in place on any past, present,
or future system.
This is apparently a work in progress by our new director.
Thanks for your input. I appreciate additional comments!
Kevin
| |
| Dave Hinz 2004-02-05, 3:34 pm |
| On 5 Feb 2004 19:10:25 -0800, Kevin Counts <kcounts@helios.acomp.usf.edu> wrote:
>
> 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.
Right, scoping the project.
> This morning when the project director answered the question as
> you correctly predicted, it jostled my noggin to come up
> w/ some follow-ups:
>
> Exactly what business impact will you have from data loss?
Um, we lose customers and have to polish up our resume?
> 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? ;-)
That is very true; some 5 minutes are worth alot more than
others. Perhaps you could leverage this into a "clustering
your application servers would add $N to the cost, but would
reduce the likelihood of downtime from (X) to (X/whatever).
Is the benefit worth the expense to mitigate the risk?
> This is where I am hoping to get some general system administration
> domain question ideas from a diverse group such as yourself and others.
Your original question sounded like homework, sorry to say, so it
might be that some others are hanging back. Context helps.
>
> This is taking place at a Hospital/Med Research Center. The project
> is for us sysadmins to develop and implement a system infrastructure
> for an HL7 EDI application server that routes the EDI data between
> different clinical systems.
HIPAA certainly complicates a number of things, doesn't it. I'm also
an EMT, so you can probably imagine the interesting effects that has
in that field. Obviously some basic things like using encryption to
move your data around are imperitive; do they go so far as to dictate
encryption schemes and protocols used, or how does that work?
> Oh - BTW - AFAIK we have no formal SLAs in place on any past, present,
> or future system.
If you google for "sample SLA" (include the quotes) you'll see some
templates. There may be things in there that you haven't thought of,
or topics to make sure you cover with your requirements gathering.
Helps you figure out what they need, and helps _them_ figure out what
they need.
Good luck,
Dave Hinz
| |
| Chris 'Saundo' Saunderson 2004-02-07, 1:34 am |
| 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 saundo@earthlink.net
Unix/CCNA/CCDA Guy Powered by Linux and the Orb.
|
|
|
|
|