What are the basic questions to ask a person who wants his Medium sized website done?

Question

I wanted to know the basic question that a person needs to ask if someone wants his web app done?? It can be UI,platform,crux of the applications and many other things...Please

Answer 1

Some of these are similar to Mr. Brendel, but hopefully I added value. In no particular order:

• Why are you building this application? (Describe what the "happy endpoint" for this web application looks like.)
• Are we carving new processes/modules/functions, or simply automating existing processes/modules/functions? (The latter is easier than the former.)
• What are the processes/modules/functions in scope for this application? Who defines them?
• What is the overall business model of the client? Where are the touchpoints between the application and that model? How much is being affected?
• What value is being delivered? How will it be measured? (Closely related to the first question...)
• Who's going to use the web application? (The web app needs to be designed with the end-users in mind.)
• Who are the "stakeholders"? (IOW, who's going to benefit or lose directly from the project? Of course, it won't, but what if the dealine must slip? Who's the person(s) that this will reflect on?)
• What's your budget, if any?
• What's the dealine/go-live drop-dead date, if any?
• Do you have any rules/process for interacting with external/internal developers? (Ex: reporting needs, coding standards, etc...)
• Is it technically integrated with anything else or stand-alone?
• Is it visually integrated with anything else or stand-alone? What characteristics/attributes/attitude should the site convey to users?
• Is it replacing anything? If so, what and why?
• What "server stack" will it be deployed on? What technologies must be used, if any?
• What are the "hard metrics" that must met, if any? (Ex: Must be able to field 1000 requests/min.)
• What are the project's security needs?
• Who will test/validate the prototype? What are their needs/expectations for performing testing/validation?
• Who will maintain the web application? What are their needs/expectations for performing maintenance?
• Who will maintain any static content? What are their needs/expectations for performing maintenance?
• Who will train users? What are their needs/expectations for performing training?

Now, be careful. First, interview stakeholders both individually and in groups. Interview multiple times, if possible, because your first interview will possibly precipitate ideas that you'd pick up in a second interview.

It's best not to mash all of this in one interview with all stakeholders and end-users in the room at once. Divide it into two parts, at least: the "current and future business" part, and the "exact solution" part? Don't mix conversations about the business-side of the problem with the other conversation you should have on pet features, functionality, content, search engine optimization, etc. The latter will tend to obscure the former, but the former is where a good developer can really catalyze a business.

Hope this helps. Requirements gathering is pretty much an art, not a science...