 |
Gather requirements first; design second
From WebSiteGravy.com - http://www.WebSiteGravy.com
Picture this: it is Monday morning. You, the web developer, wake up and prepare for a first meeting with a new client. You dress yourself up and grab a bite to eat before hopping in your car in-route to your client's office. Amazingly, you make 90% of the stop lights and arrive 10 minutes early, so you review your pre-built question list you hastily put together the night before. What's the first question on your list? Is it something like "What do you want your web site to look like?" If it is, then yank that sucker out from its current position and slap it further down on your list; ideally, that question shouldn't come up during your first meeting at all. Why, you ask? Since this is your first meeting, your goal in life is to get into the mind of your client. Why does he want a web site? What is the site suppose to do? Is this an information-centric web site or a corporate web presence? And so, your first question should read something like this: "What do you want your web site to do?" Many times the client will respond vaguely, like "We're looking to put our company on the web." Okay, good, now we know that this web site will probably be used for publicity or marketing. Further questions need to be asked, though. Is this an e-commerce enabled venture? How many products do you offer? (Or perhaps more directly, "How many products do you plan to display online?") From these initial questions, you should have a good idea of what the goals of the web site are. If you believe that you have a good idea what the goals are, re-state them to the client for confirmation. "So, the goal of your web site is to directly sell your products to the customer." If the client nods, then give yourself a pat on the back. Otherwise, now is the time to clarify the goals of your client's web site. Often times the goal of the web site will include the satisfying of another company goal. If this is the case, understand what the other company goal is. Once clear goals are established, now is the time to gather a set of requirements to satisfy those goals. This collection of requirements is known as the requirements specification, and it need not be complex. You can think of this document as a detailed list of what the web site needs to do, and how users of the web site do it. For example, does the client want rotating ad banners? Should the web site randomly select a product from a database for display on the main page? What about company colors or logos? Will this web site be updateable by the company, or will you, the web developer, perform the updates? Approximately how many pages will the site consist of? Constructing a complete Requirements Specification As alluded to before, this document should not be complex, but needs to be precise and complete enough for you, the client and any applicable party to easily understand it. Let's take a look at the items that make a requirements specification complete. Technology: A discussion of technology within a RS includes both hardware and software, like web servers and browsers and PC and Macs. If specific technological requirements exist, it is always helpful to reveal them as early as possible. Error handling: This is an important but frequently overlooked part of an RS. Error handling stretches wide and far, ranging from hardware failure to web site error messages. Find out if backups are to be made and, if so, how often. Schedule priorities: If the client is under a deadline and entire functionality cannot be completed within that deadline, then a schedule of priorities needs to be laid out. Specify which requirements are to be implemented first and which are less important and can be added later on. Performance: This should be fairly self-explanatory. Performance includes the programming languages to be used and which databases hold web site information. It should indicate any browser or connection requirements and if speed is of particular importance. Functional requirements: Certainly the largest part of any RS, this section details what the web site does including, but certainly not limited to, login procedures, database connections, banner rotations and any administration tools. Future additions: This section may not be needed in some projects. In short, it discusses features that may be added in the future, such as automation utilities or color changes. Although many web developers prefer to jump right into the development of the site, a properly constructed requirements specification ultimately helps the process 10-fold. Less client interaction is needed and both parties know the site's goals, its capabilities and the approximate completion date. Further, especially when working with established businesses, an RS makes you look professional and experienced. Those with knowledge of the software development process can easily relate the requirements specification to the Analysis phase, the first phase of the project. The question of "How do you want the site to look?" falls clearly in the 2nd phase, or the Design phase. Following these phases and using the 1st meeting to establish nothing but the goals and requirements of the site work to ensure repeatable success on your web projects. Author: Steve Date written: November, 2003 Words: 893
Article viewed 830 time(s). Read more: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | |
