Effectively Translating Requirements

Let's face it the rhetorical questions we've just posed will rarely be questions you can put directly to your client.

Although you may be confronted from time to time with projects for which the client takes full ownership of systems architecture and simply wants you to build the application (in which case, you can skip to the next chapter), far more likely is that you're expected to make the big decisions based on what the client has told you or the answers to questions you've asked him or her.

Far more likely, therefore, is that you're the one who will have to ask the questions. These questions should be designed to fill a veritable stockpile of information, which you can then use to design your environment. But what questions should you ask?

Hosting, Connectivity, Servers, and Network

The first question is "Do you have an Internet service provider?''

Unfortunately, the answer to this question is almost always yes and is also almost always followed by "And we'd like to use it to host this Web site, because Doug there is always so helpful; why, just last week he helped me get this virus off my laptop.....''

If you then ask, "And who might they be?'' and are told, "BudgetISP just $300 a year for unlimited disk space,'' you could be forgiven for having a slight sinking feeling in your stomach.

You know as a PHP professional that getting budget or even expensive third-party ISPs to host PHP applications is a bit like asking your local mechanic to tune up a Formula One race car. On the other hand, being dismissive at this early stage of the project and trying to push the client toward your preferred ISP could well prove counter-productive.

Our preferred approach is a diplomatic one; "OK, I'll call BudgetISP tomorrow and explain our requirements to them.'' When you return to your client a few days later, you can truthfully say, "Well, I spoke to BudgetISP, and I'm afraid they don't think they're going to be able to host our application.'' Your client will inevitably respond, "What do you recommend?'' At this time, you can launch into your spiel about how good Acme Hosting is, and your client will actually listen to you. Works every time.

In terms of asking questions to determine hosting requirements, the only question that needs to be asked is "What kind of traffic are you expecting, and at what times of day?'' The answer to such a question will allow you to determine not only bandwidth requirements but also the approximate number and configuration of servers you're likely to need.

Should your client not be able to easily provide you with an answer, coax it out of him or her. Ask how big the client's customer base is and how often the client will be using the platform. The figure you are trying to arrive at is the approximate number of simultaneous users likely to be in-session at any given time.

It's also worth finding out whether your client knows whether the users are likely to be on broadband or dialup, and in what rough slices; we discuss why a bit later.

Redundancy and Resilience

Rather than ask your client "Do you need redundancy?'' (which often solicits a stony look and a silent room), you should aim to get to the heart of the matter.

"Let's say the worst happened and a server blew up, taking this site down for a few hours. How bad would that be?''

You'd be amazed by the number of clients who say it wouldn't be a big deal. If this is the case, you don't need to worry too much about redundant power supplies, failover database servers, and so forth. However, you may want to then rephrase the question slightly: "What if when we got the site back up again, some of the database were lost?'' You'll find very quickly that the client's attitude changes and that loss of data would be a big deal. Keep this in mind. Redundancy to handle temporary outages is very different from redundancy of data, as the next section explains.


What you should attempt to establish here is this: Who will take ownership of these servers? Not legal ownership, of course. We assume that legal ownership remains with your client unless you're providing the hosting, too.

Instead, think responsibility. Whose responsibility will it be to upgrade the kernel? Reboot the server if it goes down? Resist the temptation to go into sales mode here. Instead of saying "Would you be interested in a support package?'' (which sounds suspiciously like "Can I interest you in an extended warranty?''), ask the question and then let the client decide:

"From time to time the software running on these servers might need an upgrade. Did you have any ideas about who you might like to be responsible for carrying those out?''

From the client's response, you have a place to start for discussing the benefits of taking out a support and maintenance contract with you, without appearing pushy.


The best sales technique you'll ever learn is not to sell; instead, you should delve, dig, probe, find pains, and help your client find them, too. Present obvious solutions to those pains and you'll have a sale.


This will often be a matter close to your client's heart. From friends and colleagues, the client will have heard horror stories of being hacked, and maybe even experienced it themselves. He or she will almost certainly have seen features on CNN.

An unexpected rant can be quite beneficial sometimes. The client may find it therapeutic in some manner or other. Try to solicit one with, "Would I be right in thinking it's important to you that this application and infrastructure is very secure against intruders?''

Listen and sympathize with the answer that follows, and propose a reassuring solution. There is no real question needed here, if we're honest; the answer is always "Yes, of course'' but it's worth asking for the political benefits it can bring. Shows you're on the ball. Clients like that.

Professional PHP5 (Programmer to Programmer Series)
Professional PHP5 (Programmer to Programmer Series)
Year: 2003
Pages: 182

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net