Web Sites. The Web development methods - Essay Example

Introduction As Taylor writes, "Over the years, web sites have become quite a phenomenal and developers are developing web sites using an ad hoc approach, which is causing problems. Developing efficient web sites requires meeting user needs by producing high quality web sites. One way of solving the problems developers are having is by developing a web development process for developers to use." (Taylor, n.d.) The web development methods include a process that describes the steps to follow during development of web sites. The web site development process is driven by use cases that are created based on user requirements, that's why it's so important to build up comprehensive user requirements. As Tran writes, "Requirements and specifications are very important components in the development of any embedded system. Requirements analysis is the first step in the system design process, where a user's requirements should be clarified and documented to generate the corresponding specifications." (Tran, 1999) According to Kaner et al. cited in Sisson (2002), "A requirement is an objective that must be met. Planners cast most requirements in functional terms, leaving design and implementation details to the developers. They may specify price, performance, and reliability objectives in fine detail, along with some aspects of the user interface. Sometimes, they describe their objectives more precisely than realistically." Website projects are usually done on tight schedules, with limited resources, and without a well-defined approach for achieving usability. For many developers it's easy to dismiss usability methods as an unnecessary overhead cost. But usability methods can be integrated efficiently and effectively into each stage of the website design process. Employing this process, and by using forms, checklists, and other tools to improve communication and workflow, website projects can be managed successfully achieving a highly-usable product. (Gergle, Brinck, Wood 1999) One very useful technique for implementing usable website requirements described by Rhodes (2006) is Pareto Principle. He writes, "Usability provides another benefit to product teams. It is very likely that you have one or more people on the team who live and die by the Pareto Principle. Everything is defined in terms of the 80/20 rule, where the majority of issues seem to stem from a small fraction of items. Similarly, most of the value seems to come from just a few features or functions." Various literature (Bolchini and Randazzo 2005; Tran, 1999; Cockburn, 2000; Courage, Baxter, 2004; Lauesen, 2002) mention 3 phases of user requirements life-cycle in web site development: Requirements Identification, Requirements Analysis and Requirements Definition/Specification. Requirements Identification Requirements Identification is the requirements engineering task during which raw new potential requirements are identified. The typical responsibilities of Requirements Identification are to: Identify the desires, potential needs, and expectations of the application's stakeholders. Transform these desires, potential needs and expectations into potential new raw (unanalyzed) requirements. (Cockburn, 2000; Lauesen, 2002) Requirements identification typically involves the requirements team performing the following steps: Identify possible sources of requirements, such as stakeholders, experts, reusable requirements and requirements specifications, documentation, etc. Interview customer representatives, user representatives, domain experts, marketing personnel, and user support agents. Observe representative users at work. Informally identify and capture the resulting potential requirements. (Cockburn, 2000; Lauesen, 2002) Requirements identification for website development can typically be performed using the following techniques: Website Studies. Reverse engineer requirements from legacy websites, competing websites, similar websites, and website databases. Textual analysis of websites (e.g., noun/verb for object/operation, shall/must/will for requirements). Incremental Development. Incrementally develop the lists of potential stakeholders, other sources of requirements, and requirements. Iteration. Iterate the lists of potential stakeholders, other sources of requirements, and requirements. Brainstorming. Brainstorm informal lists of potential stakeholders, other sources of requirements, and requirements. Questionnaires. Have the stakeholders and subject-matter experts fill out questionnaires regarding the requirements. Observation. Observe the users while they are using the current or related website. Prototyping. Prototype the human interface of the website and derive requirements from the prototypes (Cockburn, 2000; Lauesen, 2002) Requirements identification should be performed iteratively, incrementally, and in parallel with other tasks (e.g., requirements management, the development of a human interface prototype). The requirements team must understand the user's work in order to properly elicit requirements from them and understand the requirements that they elicit because the website or component to be specified exists in order to help the users perform their work or else perform the work for the users. Requirements Analysis Current requirements analysis methodologies for web applications fail to capture important elements of the requirements picture. On the one hand, there is the need for modelling the assumptions of a stakeholder which dictate his vision on the design. From properly eliciting stakeholder visions, important goals and requirements for the design may arise. On the other hand, the emotional, psychological, social or individual elements which can trigger a person to use an interactive application should be understood. User motivations - properly combined with stakeholder visions - are keys to derive a sound set of user requirements. (Bolchini, Randazzo 2005). Requirements Analysis is phase of website development when the development team analyzes the requirements and specifications document for completeness and feasibility. The purpose of the analysis is to determine the scope of the effort. To help identify what is required for the project, it is necessary to answer to the following questions: What are the software tools necessary What developer skills are required for the project (Taylor, n.d.) During the Requirements Analysis the requirements team study, refine, and understand the raw and reusable requirements, categorize, organize, and determine relationships between the raw and reusable requirements. Also at this phase the team builds related models and diagrams and informally determines the quality of the analyzed requirements, models and diagrams. Requirements analysis of the website can typically be performed using the following techniques: Categorization. Use a classification scheme to categorize and thereby organize and analyze the requirements. Cost Benefit Analysis. Produce a cost/benefit analysis for requirements that may be cost-prohibitive to implement. (Cockburn, 2000; Lauesen, 2002) Requirements may be informal, semiformal, or formal. Requirements analysis is when formal requirements models (if any) would be produced. Requirements Definition/Specification During the Requirements Definition/Specification a functional design document should be generated. This document consists of the information, figures and charts so that, when combined with the specification, someone new to the project can understand what the project does and how it does it. The project specification must be in writing; a verbal agreement is not acceptable. That way, when the customer changes their mind, you can renegotiate the work. Requirements definition is the process by which the needs of the customer are translated into a clear, detailed specification of what the web site must do and achieve. The output from this phase is the specification document. The specification defines what the project does, not how the project does it. Requirements Specification is the requirements engineering task during which the analyzed requirements for a website are published in requirements specifications (and related requirements documents). "A specification document describes how something is supposed to be done. The specifications may describe the steps of any functional interaction, and the order in which they should be followed by the user. A requirements document, on the other hand, would state that the software must handle error states reasonably and effectively, and provide explicit feedback to the users. The specifications show how to meet this requirement." (Sisson, 2002) The requirements specification task can typically be performed using the following techniques: Content and Format Standards Documentation Templates Inspection Checklists Standard documents, or documents in electronic formats such as XML, HTML, or MS Word or other (Cockburn, 2000; Lauesen, 2002) Each individual requirement should be mandatory, correct, cohesive, consistent with other requirements and higher-level goals, unambiguous and not redundant with other requirements. Requirements can be specified as traditional paper documents or electronically. Requirements can be specified in the form of traditional paper formats (e.g., MS Word or Adobe Acrobat PDF documents), spreadsheets (e.g., MS Excel), database reports, or output screens from a requirements management tool. All types of requirements should be addressed. Too often, all of the requirements engineering training and effort go into the functional requirements, leaving the other requirements underanalyzed and underspecified Appendix A Reliable, useful, and valid websites: Rhodes, J. (2006). 'How Product Teams Benefit from Usability.' (online). Available http://www.apogeehk.com/articles/How_Product_Teams_Benefit_from_Usability.html (23 May 2006). I think the website is usable because Rhodes clearly states importance of usability in website development. Taylor, C. (n.d.). 'Applying Software Engineering Principles to a Web Site Development Process.' DePaul University, School of Computer Science and Information Systems, Chicago, IL (online). Available http://facweb.cs.depaul.edu/ctiphd/ctirs99/online/taylor.html (23 May 2006) I think the website is reliable, useful, and valid because DePaul University is known for various publications on website development. Tran, E. (1999). Requirements & Specifications. Carnegie Mellon University, 18-849b Dependable Embedded Systems. (online). Available http://www.ece.cmu.edu/koopman/des_s99/requirements_specs/ (23 May 2006) I think the website is reliable, useful, and valid because Carnegie Mellon University is known as one of the leading institutions. Sisson, D. (2002). Requirements and Specifications. (online). Available http://www.philosophe.com/design/requirements.html (23 May 2006) I think the website is usable because Sisson cite known experts in requirements development, analysis and documentation. References Bolchini, D., Randazzo, G. (2005). 'Capturing visions and goals to inform communication design'. ACM Special Interest Group for Design of Communications, pp.131-137, NY: ACM Press Cockburn, A. (2000). Writing Effective Use Cases. M: Addison-Wesley Professional Courage, C., Baxter, K. (2004). Understanding Your Users: A Practical Guide to User Requirements Methods, Tools, and Techniques. L: Morgan Kaufmann Gergle, D., Brinck, T., Wood, S. (1999). 'Practical usability methods in website design.' Conference on Human Factors in Computing Systems, pp.120-121. NY: ACM Press Lauesen, S. (2002). Software Requirements: Styles and Techniques. M: Addison-Wesley Professional Rhodes, J. (2006). 'How Product Teams Benefit from Usability.' (online). Available http://www.apogeehk.com/articles/How_Product_Teams_Benefit_from_Usability.html (23 May 2006) Taylor, C. (n.d.). 'Applying Software Engineering Principles to a Web Site Development Process.' DePaul University, School of Computer Science and Information Systems, Chicago, IL (online). Available http://facweb.cs.depaul.edu/ctiphd/ctirs99/online/taylor.html (23 May 2006) Tran, E. (1999). Requirements & Specifications. Carnegie Mellon University, 18-849b Dependable Embedded Systems. (online). Available http://www.ece.cmu.edu/koopman/des_s99/requirements_specs/ (23 May 2006) Sisson, D. (2002). Requirements and Specifications. (online). Available http://www.philosophe.com/design/requirements.html (23 May 2006) Wood, L. E. (1997). User Interface Design: Bridging the Gap from User Requirements to Design. NY: CRC Read More