Concepts of web projects

Published:

Web Projects And Elicitation Barriers

The first part of the chapter contains the concepts of web projects and differentiation from conventional software system in development context. The importance of implication of engineering concepts into web development will be presented under web engineering heading.

3.1 Web Projects

Web systems are globally available systems with thousands of distributed users. Each group of users has its usage roles. There are several key points of web projects that differentiate development from traditional projects. More distinct factors of large web system are rapid growth in their requirements and heavy contents management. Web systems need to be developed in such ways that support scalability and maintainability issues because such features cannot be handled later. A web system needs to meet the need of many types of stakeholders, diverse range of system's users (persons who maintain the system, the organization that need the system and also those who fund the system development). This makes the design and development of the system further complex and difficult (L.S. Al-Salem et al, 2007).

3.1.1 Difference between Web Systems and Conventional Systems

Lady using a tablet
Lady using a tablet

Professional

Essay Writers

Lady Using Tablet

Get your grade
or your money back

using our Essay Writing Service!

Essay Writing Service

The development of web based systems is different from traditional software systems in several areas. These areas affect the entire web development and maintenance processes. They also encompass the people involved in development, the intrinsic characteristics of web systems, and the users for which they are built (M. Emilia et al, 2002).

The development of conventional systems remains dominated largely by IT specialists where a good knowledge of programming, database design, and project management is necessary. In contrast, web development covers a much wider variety of developers, such as web coders, graphics designers, technical writers, database designers, and IT professionals. More characteristics are of web systems are given in later part of this chapter. Web systems use communications technologies and have multi-platform accessibility as they are available globally. Furthermore, they are non-sequential by nature, using hyperlinks to interlink web pages and other documents. Therefore, navigation and pluralistic design become important aspects to take into account. The multitude of technologies available for developing web systems means that developers can build a full spectrum of applications, from a static simple web application using HTML (Hyper Text Markup Language) to a fully fledged distributed ecommerce system (M.J. Taylor, 2002). Conventional applications can be developed using several programming languages running on a specific platform e.g. Components/Commercial Off The Shelf (COTS). The communication technologies can also be used in traditional systems to connect and use different database systems. However the speed of implementing new technology is faster for web development relative to conventional systems. Web systems encompass a wide range of users; they may be unknown or known ahead of time (e.g. systems serve within the boundaries of local area network). However, it is more often the case that large web systems are developed for an unknown group of users (Y. Deshpande et al, 2001) In contrast, conventional software applications are generally developed for a known user group (e.g. specific department or organization) making the explicit identification of target users an easier task.

3.1.2 Characteristics of Large Web Projects.

In literature study some authors (O. De Trayer, 2001, Y. Deshpande, 2001) stated the characteristics of large web systems with development point of view.

  • Large projects are obviously complex so they need multi-disciplinary development team; they require diverse skills in different areas.
  • The requirements of the web projects are diverse and volatile: Requirement analysts do not need to explore only functional and non-functional requirements; they also have concern with structuring, navigations, contents and access issues.
  • These systems must have the capability to handle the vast number of diverse users with diverse in geography, age, culture, norms and values.
  • Large number of stakeholders with different background and experience.
  • Contents management is the basic aspect of web projects. These systems have heavy contents that can be in the form of images, texts, audio/video etc depending on the nature of the system.
  • Integration with backend databases and third party application is another critical aspect of web systems. Most of them are integrated with backend systems such as heterogeneous databases (S. Hansen, 2002). They are built using number of diverse components from disparate sources including custom built special purpose applications, COTS and third party products (Kappel et al, 2004)
  • Multi-tier design architecture with HTML, database server and application server is used in large web projects.
  • Most web systems are facing the outside world have no room for error (M. Lang, 2001).
  • The consequence of errors and downtimes in web systems that interface with customers or supplier are major issues and simply cannot be tolerated.

3.1.3 Essentials for successful web project development.

Lady using a tablet
Lady using a tablet

Comprehensive

Writing Services

Lady Using Tablet

Plagiarism-free
Always on Time

Marked to Standard

Order Now

There are some essential steps mentioned by some authors (A. Ginige, 2002, L.S. Al-Salem et al, 2007) in literature. Fiqure3.1 illustrates the essentials of a successful project development.

  • Understandability is an essential step in project development. The clear understandability of functions and operational environment of the system including the business objectives and needs.
  • Clear identification of the stakeholders.
  • Identification and specification of all possible technical, non-technical, users and system requirements.
  • Build appropriate architecture (multitier) for the web based system that meets above mentioned requirements.
  • All non-technical issues e.g. business promises, organizational policies, human resource development , legal , cultures and social issues must be addressed satisfactorily
  • Identification of sub components of the system for implementation designed architecture.
  • Manage the evolution and maintenance issues of the system.

There are several stakeholders involved in completion of above mention steps. These could be requirement analyst, architecture designer, database designers etc.

3.2 Web Engineering

"The use of scientific, engineering, and management principles and systematic approaches with the aim of successfully developing, deploying and maintaining high quality Web-based systems and applications" (S. Murugesan et al, 2001).

This is a similar definition to that used to describe software engineering; however, both disciplines differ in many ways as described earlier. Mostly Industries (travel, hospitality, shopping, manufacturing, banking and education etc.) utilized web-based systems to improve operation and increase their productivity (A. Ginige, 2002). Furthermore, the web allows for the development of corporate intranet (Local area network or Metropolitan area network) web systems, for use within the boundaries of their organizations. Distinct coverage of web applications in communication and commerce fields makes it important leading branch of the software industry (J. Offutt, 2002). To deal the development of web system has been in general ad hoc, resulting in poor quality applications, which create difficulties in maintenance (S. Murugesan et al, 2002). The main reasons for such problems are unsuitable design and development processes, and poor project management practices (A. Ginige, 2002). A survey on web-based projects (C. Consortium, 2000) revealed a number of problems with outsourced large web projects (A. Ginige, 2002).

  • 84% projects did not meet business needs.
  • 53% projects did not provide the required functionality.
  • 79% projects presented schedule delays.
  • 63% projects exceeded their budget.

As the reliance of the global businesses on larger and complex web systems increases. There is a great need of methodologies/standards for best practice guidelines to develop these systems to make on time delivery, within budget, high quality level and maintainable (S.C. Lee et al, 2004, F. Ricca et al, 2001). To develop such applications web development teams need to use sound methodologies, systematic techniques, quality assurance, rigorous, disciplined and repeatable processes, better tools, and baselines. Web engineering aims to meet such needs (A. Ginige, 2002).

3.3 Elicitation Barriers

In most cases stakeholders cannot explain what they really want? E.g. the stakeholder feels a problem but cannot express and sometime user does not feel anything but requirement analyst can see several problems. There is also a trend of exaggeration of today's issue and underestimate crucial problem, even if stakeholder sees the problem but cannot express it as a requirement. Another barrier to requirement elicitation is that, sometimes stakeholders have the problem of explaining what task they perform and why they need to perform such task. Some users specify a solution instead of a demand, e.g. a manger might state that "we should have a computer based decision support system" (S. Lauesen, 2002). It takes the almost a long time to figure out that the real problem is not to discuss and to decide, but to implement what has been decided. The decision support system would not help with that.

The users may find it difficult to think about new work procedure of imagine the consequences of doing a familiar task in a proposed new way. For example, in a multi-national organization, it took a long time to realize that the ever growing problem of the getting through to peoples on the phone could partly be solved with instant messaging/discussion board/forum in a web system. Later, the commencement of these features in web system change the work pattern in an emerging way (S. Lauesen, 2002). In large projects there are several stakeholders attached to the same project and may be distributed at different locations. Often different stakeholders have confliction in their views. In a large ecommerce system the marketing personnel promise optimistic delivery times to ensure they get the order, while the production staffs hate this because of continues work load on them. A production feasible system may irritate the marketing personnel. So, these conflicts must be resolved for successful project development.

Lady using a tablet
Lady using a tablet

This Essay is

a Student's Work

Lady Using Tablet

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Examples of our work

Sometime user refuse proposal due to general resistance to change. The problem behind this barrier may only the difficulty of imaging new work structure. When a requirement analyst work with stakeholders involved in exploring requirements, she/he faces too many requirements come up altogether. Some of them are vital, others are fancy ideas. It can be difficult to have all stakeholders agree on what is essential and what is luxury (S. Lauesen, 2002). Maturation problem also arise in elicitation process, when stakeholders have a meeting with requirement analysts at first time, they might not have the distinct view of system. After some time when they work through with experts and see the new ways. Demands changes over time to time with maturation of stakeholders ideas. External factors may also affect the change the demands. When one benchmark has over new demand arises. So, accomplished tasks can also come up with new demands. System solution providers (system builders) like the maturation idea and new demands trend, because it creates new business opportunities for them.

Further classification of the problems of requirements elicitation in large web projects is categorized into three areas, listed below.

3.3.1 Scope Barriers

Scope problems related to boundaries of target system. The boundaries of the system may be ill defined. By ignoring the contextual issues (of organization) can lead to requirements unfinished, unverifiable, unnecessary and unstable. Collected information may address too narrow or too broad scope of the system. There are also problems of understandability of the organization and environmental factors. The scope barriers arise from abstraction level requirements gathering and requirement sources.

  • Abstraction level Problems
  • The abstraction level of requirement gathering involves the problem analysis and the system specification. Problem analysis is to perceive the problem domain by understanding the situation of concern and setting system boundaries (D.E. Avison, G. Fitzgerald, 1995). Lack of generic knowledge of problem analysis makes harder further proceedings. These problems could be in vision of the project, scope area, and constraints. Problems can also arise at defining the project specifications, lack of specific knowledge of the project may lead to failure. The specific knowledge refers to system features like functional, non-functional and business requirements.

  • Problems of Requirement Sources

Stakeholders are the main sources of the requirements. Due to the diverse social positions in the organizations, it is difficult to explore all needed knowledge from stakeholders.

  • Domain Knowledge
  • Stakeholder
  • Operational environment
  • Organizational structure

3.3.2 Communication Barriers

The information that has been gathered from the communication between the user and the analyst represents the base of information systems design. It becomes the key factor in determining success or failure of a project. The communication barriers are the problems of understandability between/among stakeholders in requirement gathering. Mostly errors in the systems were due to poor communication between user and analyst, and these errors require more resources (time and money) to correct them. The understandability problems during elicitation process of large web projects can lead to requirements ambiguous, inconsistent, unstable and unusable. Valusek and Fryback classify the commutation barriers into three categories (J. L. Valusek, D. G. Fryback, 1987) "within", "between" and "among". Some authors (Z. Zhang, 2006, Valenti, 1998) stated these barriers as individual culture limitations, organizational cultures limitations and national culture limitations respectively.

  • Within
  • The "within" barriers are also known as individual culture limitations. It refers to cognitive shortcoming of human as information receiver, information processor and problem solvers. "Within" problems refer to the ability of comprehension, the capacity of human memory and recalling facts, the information processing activities and the decision making processes. (Z. Zhang, 2006). So these are the cognitive and behavioral limitations within the individuals.

  • Between
  • The "between" barriers are also known as organizational culture limitations. Organizational culture covers different aspects of the organizational operations. For examples management style, organization chain structure, nature of work place, norms and values, terminologies used within the organization. These areas have their own work plans and working methods. So, confliction may arise because requirement analyst may not familiar with hierarchy of the organization and their operations. Psychological limitations also lies in the between barriers because they related to organizational behavior.

  • Among

The "among" barriers are also known as national culture limitations. These problems arise when different users describe their needs that are inconsistent or that conflict either in contents or priority and they require a referee for resolution. In large complex project, peoples involve from different culture backgrounds and have diversity in language, norms and values, attitudes and believes and priorities. Sometime the cooperation of these users in requirement elicitation may become hindrance. When several users provide the same information needs in different and inconsistent ways, then requirement conflict arises. It is challenge for development organization to resolve such conflicts.

3.3.3 Volatility Barriers

Volatility barriers are also known as requirements maturation problems. Requirements are not completely known at the start of the project development and they cannot be specified completely upfront in one huge document. Changing nature of the requirements over time is another barrier to elicitation process of large project development. During the system development the users need may change because of requirement maturity. In start of the project discussion, the users were uncertain about the project vision as already discussed in section 3.5. By the passage of time users' requirements evolve and they get familiar with system goals and operation, then their requirements change. If such amendments are not treated, the original requirements set will become incomplete, inconsistent with present situation, and potentially unusable because they detain information has become outdated.

Summary

Elicitation Planning And Methods

"Good morning, Maria. I'm Phil, the requirements analyst for the new employee information system we're going to build for you. Thanks for agreeing to be the product champion for this project. Your input will really help us a lot. So, can you tell me what you want?" "Hmmm, what do I want," mused Maria. "I hardly know where to start. It should be a lot faster than the old system. And you know how the old system crashes if some employee has a really long name and we have to call the help desk and ask them to enter the name? The new system should take long names without crashing. Also, a new law says we can't use Social Security numbers for employee IDs anymore, so we'll have to change all the employee IDs when the new system goes in. The new IDs are going to be six-digit numbers. Oh, yes, it'd be great if I could get a report of how many hours of training each employee has had so far this year. And I also need to be able to change someone's name even if their marital status hasn't changed." Phil dutifully wrote down everything Maria said, but his head was starting to spin. He wasn't sure what to do with all these bits of information, and he had no idea what to tell the developers. "Well," he thought, "if that's what Maria says she wants, I guess we'd better do it."(K.E. Wiegers, 2003)

4.1 Ground Step for Elicitation

Elicitation process starts from eliciting overall goal of the system, then information about the working environment and current problems. A detail description of issues that system shall deal with and possible solution for the system and transformation of the issues into the proper requirements. The process cannot be done in a semantic way because current working situation may cause the goals to change. Finding the possible solution and vision of new work procedures may also affect on the system goals.

Overall requirement engineering process has been already discussed in chapter 2, deeper operation of this process given in figure 4.1(G. Kotonya et al, 1998). After the feasibility study (discussed earlier) the requirements are gathered in elicitation process from the knowledge sources (stakeholders /view points) by using different elicitation methods (elaborated in rest part of this chapter). When requirement gathering process over, next step is to analyze the gathered requirements (different stakeholders are involved in this phase). Then remaining steps requirements specification and verification are performed. But these phases of requirement development process are not discussed in this thesis. We have only considered the elicitation process (marked in figure 4.1) and related activities (G. Kotonya et al, 1998).

4.2 Choosing method

There are many elicitation methods exist stated in literature, but application of all these methods simultaneously is a hard pill, due to time and cost constraints it is not possible to try all available methods for one system. Choose the ones that produce better result for the specific system. For example if two methods give similar results for same system, then less expensive (refers to that method complete in short time with minimum resources) method will be adopted. For full requirement coverage, both methods can be used because if first method skips something, the other will recover it. This strategy is feasible for large projects but in small projects due to cost constraints it may not possible.

Several but few methods can be used parallel for efficiency, working with several elicitation methods simultaneously beneficial in time context. There is another reason for working several methods simultaneously; it does not matter to wait the results of first method before starting the other one. Mostly requirement analysts spend much time discussing whether use several methods or not. (S. Lauesen, 2002). It could be possible to try several methods in small scale. Some techniques can be tried in few hours, so, it is better to try several methods instead of discussing whether use several or not. Although we could not get full requirements in few hours but the workout of these few hours may give a distinct indication whether the concerning method covers something useful or not. If we are not sure brainstorming or storycards is a feasible method, find few users and try it. This strategy is only feasible in large projects, where time and cost could be spent for quality work.

4.3 Elicitation process guideline

It is impossible to capture requirements form root, the requirements are the end step of the elicitation process. Many intermediate work products required for requirement elicitation process accomplishment. Start with planning of the project's requirements elicitation activities, because a simple course of action can increase the chance of success and sets realistic expectations for the shareholders (K.E. Wiegers, 2003). Some requirement elicitation planning guide given in literature (S. Lauesen, 2002) is listed below.

4.3.1 Present Work

A detail description of present work in specific domain helps to reach at root cause of why a system is being replaced? It also explores the promises that the users expect from follow-on system. As with any improvement activity, dissatisfaction with the present situation gives tremendous feed for the new and improved future state.

4.3.2 Present Problem.

A detail list of the current problems in the particular domain. It raises challenge to requirement analysts to build requirement plan for future system for solution of problem. This list should include all minor problems which present domain has now. Understand the users' present business processes and to see how the new system could improve their performance. Ask about possible changes in the user tasks that the users might face and ways that other users might work with the system. Think about the user's job, or do the job under users' direction. (A. Hickey et al, 2003)

4.3.3 Goals and critical issues

A list of goals and critical issues or initial requirements for future system. When present problems have been identified, then goals and critical issues of the system must be defined. Such as analyzing market data, exploring use cases, or developing a detailed set of system constraints (functional requirements).

4.3.4 Large scale structure

Ideas for large scale structure of the future system for evolution and maintenance.

4.3.5 Realistic possibilities

Think and discuss possible realistic solutions for the system, description of some combination of surveys, workshops, customer visits, individual interviews and other methods. Possibly use different approaches for different stakeholders

4.3.6 Consequences and risks.

All consequences and risks related to the system must be discussed. Identify factors that could resist your ability to accomplish the elicitation process as proposed, estimate the severity of each risk and decide how can diminish or control it.

4.3.7 Commitment from stakeholders.

All Stakeholders should be committed with system development team.

4.3.8 Conflict resolution among stakeholders

All conflicting ideas must be resolved before system development. All stakeholders in a project have same degree of importance. Requirement analyst cannot refuse ideas of stakeholders without any justification. So, conflict resolution must be a win, win solution.

4.3.9 Final requirements

A list of use cases, a detailed SRS (software requirements specification), an analysis of results (results of used methods for elicitation process), or performance and quality attributes specification.

4.3.10 Priorities of requirements

Identified requirements must be prioritized to decide the severity level. If the requirements are prioritized, then high priority needs can be addressed first, and the subsequent requirements changes defined and reexamined, before the low priority need are implemented.

4.3.11 Complete and necessary requirements.

Requirement validation, either they are properly identified or not. Address the completeness, validation of the requirements that are stated in project goals agreement.

4.3.12 Interaction diagrams, class model.

After requirement identification and validation, next phase to draw these requirements into such a fashion that they could give some physical behavior. Requirement sketching could be possible with the help of UML (Unified Modeling Language) diagrams. Each UML diagram is designed to let developers and customers view a system from a different perspective and in varying degrees of abstraction. (Atlas, 2009)

Interaction diagrams are used for modeling the behavior of different objects in a use case. They demonstrate how the objects collaborate for the behavior. It does not give an in-depth representation of the behavior. For full coverage of specific objects astate diagram can be used. To see a particular behavior over many use cases or threads use anactivity diagrams. The class model shows static class objects in a system and the relationships between them. Two particularly important relationships are generalization and aggregation (Atlas, 2009). Although implementing the UML on requirement is not a part of elicitation process

4.4 Users' involvement

Some requirement analysts suggest that involvement of users in a project is a key of success in project development. But users' involvement is no guarantee of success, as we have seen several failed projects (S. Lauesen, 2002). The users can play different roles in project development if they get involve in project development. The users' involvement can be in the following areas.

  • Members of design team or workshops where the user interface is designed.
  • Knowledge sources how tasks and business procedures are currently curried out.
  • Brainstorm participants who produce ideas and identity problem.
  • Test users who exercise the system at acceptance time to check that everything works.
  • Reviewers who assess the user interface.
  • Test users in usability tests, where they try to carry out tasks with the new user interface.
  • Members of the steering committee for the project.

4.5 Requirements elicitation methods

Requirement elicitation is the most critical step in a requirement development process. The success or failure of any large project depends on the quality of the requirements and the involvement of stakeholder in defining the requirements. This quality is greatly achieved by the selection of appropriate methods out of available methods for requirement gathering process. As the stakeholder involved in requirement elicitation process belongs from different background with different organizational and individual goals and have distinct way to store, recognize and express their knowledge about the problem domain, a single method is unlikely to deal with all types of stakeholders in large project (Z. Zhang, 2006).

The combination of methods has been selected based on project characteristics because sometime one method that address a particular problem is used together with other methods that deal with such issues that the former methods do not address (D. Mishra, 2008). Furthermore, the development of Web system is different than the construction of traditional software for many reasons, like it involves more heterogeneous stakeholder and have additional requirement of navigational and multimedia aspects. So to acquire high quality information for Web application from diversity of people, the analyst must have the overall knowledge about the different requirement gathering methods.

Several methods are available to support different requirement issues and each has an advantage over other in term of simplicity, complexity and maturity (LiJiang et al, 2007). So the selection of suitable methods for the purpose of requirement elicitation in large web project is a challenging issue for the analyst. These methods have been divided into four basic categories as shown in figure 4.2 according to the means of communication: Conversational, Observational, Analytical and Synthetic (Z. Zhang, 2006).

4.5.1. Conversational Methods

The conversational methods provide the verbal communication between one or more peoples and help to effectively communicate with other. They are also called verbal methods and verbally express demands are called non-tacit demands. These methods provide the natural way to express the need and ideas and elicit the product requirements. Conversation is the best way to form the social interaction and peoples feel happy to discuss their feeling through it. Methods like interviews, questionnaire, focus group and brainstorming fall in the conversation categories (Z. Zhang, 2006). These methods are discussed in detail below.

  • Interviews
  • Interview is the traditional and the most common technique for requirement elicitation which based on the conversation between two or more peoples (J. C. S. Do Prude Liete et al, 1996). In it, the analyst asked question to different stakeholders, to obtain the detail information about the present work, problems and the objectives they have to fulfill in a large web project. It is useful to solve the misunderstanding about a particular domain. Only the experienced interview that used structure process is helpful in collecting the information from different stakeholders. There are two basic types of interviews (F. Paetsch et al, 2003).

    Closed Interviews: In these types of interviews the analyst has a per-defined set of question and tries to get the answer for stakeholders.

    Open Interviews: In this type of interviews the analyst does not have pre-defined set of question and they discuss in an open ended way.

    Generally the best way to conduct interview is to use both techniques. The analyst should start the interviews with some predefined question and during this process a lot of considerable things may arise which may lead to open discussion. Interviews are used to discover the facts and opinions from many potential users which help the analyst to get the rich collection of information.

    As it is the most simple and the best way to understand the problem in the existing system but on the other hand it is not as such helpful to decide the boundaries of any proposed system and organization procedures. To make the interview more effective the analyst must have to consider the following things.

    Chose the right stakeholder: The selection of stakeholder is an important and critical factor in any interviewing process for large web project. Because these projects have large number of stakeholder and the selection of those who have detail knowledge about the domain is very important factor.

    Prepare yourself: Always prepare yourself by writing a list of question to ask and also have sufficient knowledge about the domain because the business problem you trying to understand are from large domain.

    Prepare good question: Through a list of good question that cover the whole domain the analyst can be able to gather the required information from the interviewee.

    Be patience during interview: Analyst should be open minded and show patient when listening the stakeholder views.

  • Questionnaires

Questionnaire is another important method that analyst used for the purpose of information gathering from the stakeholder in large web project. It is a multistage process that begins with definition of the aspects to be examined and end with interpretation of the result. It has some advantage over other methods as it is inexpensive way to gather data from a large number of stakeholders and also the extracted result is easy to analyze. The result gathered from questionnaire techniques depends upon the quality of question design and the honesty of the respondent (C. F. Manskil et al, 2008).

As in this method the analyst has limited control over the environment so the validity of result highly depends upon the honesty of respondent. Well designed and effective questionnaires influence the people to answer honestly and make possible to decide the actual user requirement, objectives and the constraints. To achieve the best response rate, question should flow from least sensitive to more sensitive and from more general to more specific. This method has an advantage over the interview in term of time because in large web project, interviewing is a time consuming process as it involve large no of stakeholder. This method can be used under following conditions (F. Gump, 2009).

  1. When meeting is not possible with selected stakeholder and users.
  2. When wider base for soliciting requirement is required.
  3. When you want that intended person to be prepared to discuss the certain aspects in the problem domain.
  • Focus group
  • Focus group is a form of qualitative research and powerful mean to evaluate the group of people need and feelings. It consists of a group of people whose goal is to come up with a problem in a current work procedure, identify their need and the ideal way of doing things. This method is effective because it involve people in data analysis as well as help to get the rich data in participant own words. It helps the analyst to observe some group dynamic and organizational issues through user spontaneous reactions and ideas. Several group of stakeholder involve in focus group with in-depth knowledge of domain. Moderator play important role with a preplanned script of specific issues and set of goals for the type of information to be gathered.

    It is somehow helpful for web project development by involving the advertising and marketing people in understanding how your site is used by your target audience and how site conversions can be improved but it is very poor to rely only on them as your only method in a web design project (J. Nielsenl, 2009). Moderator should be careful in selecting the participant of focus group because in website development the number and type of participant depends on target audience and goals.

  • Brainstorming

Brainstorming is another requirement elicitation method used by analyst to generate large numbers of ideas for the solution of problem. It is a best way to generate new ideas and possible solution. It is very similar to focus group and conducted as a conference with six to ten members. Members are from different background and have in dept knowledge of their domain. It is conducted by facilitator who defines the problem area for which idea will be generated prior to the meeting. Each member has equal opportunities to explain their ideas. At the end of session, the best idea is selected by members voting as a solution to the issues discussed in the meeting. Brainstorming is not useful for such project where there is a small group of stakeholders with disparate needs (D. Nielsen, 2009).

4.5.2. Observational Methods

Observational methods are helpful in understanding the application domain by observing human activities. Sometime the stakeholders feel difficulties in explaining such requirement that are even apparent to them because generally people do not thinks about such routine and working environment about which they are very familiar. Such requirement are called tacit requirement. Tacit requirement are difficult to collect through verbal communication and observing how people carry out their routine task are helpful in collecting such requirement.

It is very helpful to get the initial understanding about a particular domain through observational methods especially when the development team is lacking in such domains. Observational methods are inefficient when the project have very tight schedule at requirement stages. Method like ethnographic study falls in the conversation categories (Z. Zhang, 2006).

  • Ethnography
  • Ethnography is the common technique used to capture the tacit requirement. It is helpful in understanding about how customers use their system in real world situation. Deep understanding of work is developed by spending some time along with stakeholder by observing what they do without directing the outcomes. An analyst can get a detailed information about the work in stakeholder own language and terminology. Ethnography is useful in large and complex web project because both the analyst and stakeholder work together throughout the whole process which can help the analyst to develop the in-depth understanding about project routine and can enhanced the understanding of complex problem that the stakeholders faced during their daily routine work as well as can very clearly understand how the information flow in an organization. In ethnography the data is collected through different source such as passive observation, participant observation.

    Traditionally the ethnography was developed to understand the human culture but the technology researchers have decided to use it to understand how professionals act, think and feel during their daily work (T. Hartmann et al, 2008). For example (Anschuetz and Rosenbaum, 2003) used the ethnography approach for the purpose of designing the Ford Vehicles Website.

    Ethnography is a lengthy process so it is not suitable in a situation when requirement elicitation team have very short time.

  • Protocol analysis

Protocol analysis is a form of requirement elicitation techniques in which the analyst analyzes the stakeholders when they are engaged in some type of tasks. The stakeholder speaks aloud during performing some tasks and the analyst records stakeholder activities in the form of radio, audio or written notes. The analyst uses these recording to extract the meaningful structure and rule in order to find the user requirement for the designing of any web application (N. Nurmuliani et al, 2004). Before the protocol analysis session is started the analyst should have enough knowledge about the domain in order to better understand the stakeholder's task otherwise the analyst may completely fail to record the complex part of stakeholder's behaviors. Furthermore, if the stakeholder is not inhabit of talking aloud then analyst should arrange one or two short training in which a simple task is used as an example.

It is important for the analyst to know when to use the protocol analysis as a requirement elicitation method because different methods elicit certain kind of information differently and Protocol analysis is useful to determine what people says is what they do. In large web project where there are large number of stakeholder, it is not possible for the analyst to run protocol analysis session and observe different stakeholder for problem solving as it take relatively long time and only few problem can be addressed. Furthermore, it deliver unstructured transcript which are hard to analyze and also the scope of knowledge produced is very limited (N. Nurmuliani et al, 2004).

4.5.3. Analytical methods

In observational and conversational method requirements are extracted from stakeholder behavior and their verbalized thoughts but in analytical methods required it is gathered by exploring the existing documentation or knowledge. By using this method the analyst capture information about application domain, the work flow and the product feature with the help of studying organizational charts, survey reports and documentation of existing projects. Methods like requirement reuse, laddering and card sorting are used for analytical purpose (Z. Zhang, 2006).

  • Requirement Reuse
  • Requirement reusing is a common method in the field of requirement engineering for requirement elicitation and a key to improve the software development productivity and quality. Even in industries half of the requirements are acquired from existing projects. By using the requirement of a system similar in functionalities will bring the economic saving and this is more useful in case of large web project where development costs are very high and even a small amount of reuse bring large financial saving.

    For large web project requirement reuse is one of the most potential and major fueling factor for software productivity because building software out of available requirement not only reduce development time but also enable companies to save on the production cost. According to (C. Montabert, 2006) the reusability reduces the development cost from 10% to 35%. This requirement elicitation technique is useful when the development team have very tight schedule and low budget.

  • Laddering

Laddering method is a form of structured interview that is widely used in the field of knowledge elicitation activities to elicit stakeholder's goals, aims and values (G. Rugg et al, 2002). Analyst used laddering methods to creates, reviews and modifies the hierarchical content of expert's knowledge in the form of tree diagram. It was first introduced by the clinical psychologists in 1960 to understand the people's core values and beliefs (M. Hawley, 2009). Its success in the fields of psychology allows other researcher in the industries to adapt it in their fields. Specifically software developers have adapted the laddering techniques for gather the complex user requirement such as tacit requirement.

By using one-on-one interviewing techniques the analyst tries to use the limited set of standard question to elicit stakeholder requirement and their answer based around a limited set of probes. Laddering methods model the elicited knowledge in the form of tree by using a small set of probes that reflect the tree structure (G. Rugg et al, 2002). Laddering has several advantages over other requirement elicitation techniques such as observation, interview, protocol and ethnographic (C.H. Chen et al, 2002).

  • It covers the broad domain for requirement elicitation.
  • Less time consuming in term of preparation and elicitation sessions.
  • Require less expert guidance during requirement elicitation.
  • Provides standardized format which is suitable for computerized automation.

As the laddering method is used to elicit hierarchically organized complex knowledge but is also important to note that not all type of requirement is extracted in this way so it is necessary for the analyst to ensure that particular domain is appropriate for laddering (G. Rugg et al, 2002).

  • Card sorting

This requirement elicitation method is one of the most effective ways for capturing information and eliciting the domain expert's idea about the requirement structure. It is widely used in the fields of Knowledge Engineering, Software Engineering and Web Site Design. In this method stakeholder sort the set of card into a group where each card is printed with the description of domain entities. During sorting process stakeholders have to explain the criteria for sorting as well as the name assigned to groups (N. Nurmuliani et al, 2004).

An e-mail and the world wide web has a phenomenal growth but still the user face problem finding the useful information they needs like understanding Web Site Content, identifying relevant source etc. The problem is that stakeholders has different mental model of content as compared to analyst because they do not thinks in the same way as the analyst. So to design the web site that support user more effectively, the analyst should requires to understanding the indented stakeholder requirement more comprehensively. To do so, card sorting is the best available methods which allow the analyst to gather the requirement closer to how the intended user think about the domain and organize information about domain (D. E. Zimmerman et al, 2002).

Card sorting have several advantage over other elicitation methods as it help the stakeholder to recall the domain concepts and distinguish between high level and low level problems. Furthermore, the result generated from card sorting can be used as an input for other techniques and further analysis. Card sorting method is helpful for web development because it provides a methodology to enhance the overall structure and the potential information for web sites. More helpful for understanding the intended stakeholder and require low cost and less time (A. R. Barrett et al, 1995, D. E. Zimmerman et al, 2002).

4.5.4. Synthetic methods

Sometime in complex project a single requirement elicitation method is not useful in gathering the detailed requirement. To overcome such problem analyst tries to use different method even within one requirement elicitation sessions. For example it is good for analyst to start with interviews before he/she start with ethnography study. Instead of combining the different methods of observation, conversation and analytical, analyst can use the synthetic methods. Synthetic methods are formed by combining all these methods into single methods. So the analyst and stakeholder communicate and coordinate in different way to reach common understanding. JAD, contextual inquiry and prototyping are the examples of synthetic methods (Z. Zhang, 2006).

  • Joint Application Design

JAD is a modern requirement elicitation that consists of workshop and group session in which the stakeholders and analysts meet to discuss the desired product feature. Its goal is to involve the entire stakeholder in the requirement gathering process through structured and focus meeting (J. Wood et al, 1995). It was developed by IBM and has been applied successfully on hundred of projects for the purpose of identifying system requirements, package requirements and modification requirement for existing systems. Basically the JAD method is used for software design but as the design effort based on the set of requirement that are well understood by both the analyst and stakeholder so the JAD process is divided into two major steps, JAD/plan and JAD design where the first step is used for requirement elicitation and the later address the software design.

The success of JAD depends on the leader of JAD session and the involvement of stakeholder (I. L. Yihwa, 1993). As the JAD is a useful method for requirement elicitation but it is also important to note that not all projects are good candidate of JAD. An appropriate project should have at least some of the following characteristics (D. Rottmann, 2009):

  • Involves large numbers of stakeholder whose responsibilities cross traditional department or divisions boundaries.
  • First time project for organization and considered critical to the future of the organization.
  • Involves willing users.

The JAD process consists of three main phases: customization, session and wrap-up (S. Sridhar et al, 1994). In customization the analyst prepare the task for sessions such as organizing the team, preparing the material and tailoring the process for the particular system to be built. In session phase the analyst arrange one or more structured meeting with stakeholders. At the start of JAD session the requirement engineer provides the general overview of a system and the discussion continuous with the stakeholders until the final requirement is gathered. This type of discussion is very productive because it resolves any difficulties between two parties while developing new system for a company. In wrap up phase those entire requirements gathered in session phase are converted into requirement specification documents (J. Wood et al, 1995).

  • Contextual Inquiry
  • This method allows the analyst to gain the true understanding of their needs and collect the detailed information by observing and interacting with people in their work context. In contextual inquiry an analyst studies a few selected individual in depth for the purpose of complete understanding of work practice across all customers. (H. Beyer et al, 1998) defines four basic principle of contextual inquiry in their study- context, partnership, interpretation and focus- which help the analyst in interacting with stakeholders and highlight most important aspects of this interaction. An analyst uses contextual inquiry to get the deep understanding of how and why something is done or something is not done. There are various ways to conduct the contextual inquiry- work-based interview, post observation inquiry, artifact walkthrough- depending on the type of project and the information you needs (M. E. Raven et al, 1996).

    Traditionally analyst use focus group, questionnaires or interview to obtain knowledge about the customer and their requirement but such methods provides only the useful demographic and opinion data but they rarely provides such data that is at the sufficient level of details (D. Wixon et al, 1994). Several researchers have used this method to gather data for large web project. For example (A. Rosenthall, 2007) uses the contextual inquiry method to gather customer requirement for redesigning CivicInfo BC Website.

  • Prototyping

Prototyping is another important requirement elicitation method used by analysts in the early stage of implementation of the project. It helps stakeholders to develop a concrete sense about the application which has not yet been implemented. By visualizing the application to be build, stakeholder can identify the true requirement and work flow of actual system. It is useful when the analyst require the early feedback from stakeholders. Analyst use the prototype in a situation when the stakeholder is unable to express their requirement or if the product is new and the stakeholder have no experience with the product. Prototyping has several advantages over other method such as it reduce both cost and time because the error is detected in the early stage and provides high level of user satisfaction. But on the other hand it several disadvantages such as it is expensive than other method and it may not developed quickly because of system complexity and technical limitation (J. Fu et al, 2008).

4.6 Summary

REFERENCES:

  1. Zhang, Z., "Effective Requirements Development - A Comparison of Requirements Elicitation Techniques", INSPIRE 2006, Tampere, Finland, 2006.
  2. Mishra, D., Mishra, A., Yazici, A., "Successful requirement elicitation by combining requirement engineering techniques," in Proceedings of Applications of the First International Conference on Digital Information and Web Technologies, Ostrava, Czech Republic,2008, p. 258-263.
  3. L.Jiang, A. Eberlein, B.H.Far, M. Mousavi, "A methodology for the selection of Requirements Engineering techniques", Software and Systems Modeling, 2007.
  4. J. Cesar Shampoos Do Prude Liete, A. Paula Piano Gilvaz, "Requirements Elicitation Driven by Interviews: The Use of Viewpoints", IEEE publications, 1996, p. 85.
  5. F. Paetsch, A. Eberlein, F. Maurer, "Requirements Engineering and Agile Software Development", Proceedings of the 12th IEEE International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, Linz, Austria, June 2003, pp.307-313.
  6. C. F. Manskil, F. Molinari, "Skip Sequencing: A Decision Problem In questionnaire Design", North-western University and Cornell University, 2008, vol 2, page 264-285.
  7. F. Gump, "Requirement Elicitation Techniques", http://www.docstoc.com/docs/17037477/Requirements-Elicitation-TechniquesDocument-ID-SWENG-DI, last checked, 2009-11-11.
  8. J. Nielsen, "The Use and Misuse of Focus Groups", http://www.useit.com/papers/focusgroups.html, last checked, 2009-11-12.
  9. D. Nielsen, "Requirements Gathering - Choosing the Right Tools", http://ezinearticles.com/?Requirements-Gathering---Choosing-the-Right-Tools&id=2439512, lasted checked, 2009-11-12.
  10. T. Hartmann, M. Fischer, J. Haymaker, "Implementing information systems with project teams using ethnographic-action research." Advanced Engineering Informatics, 2008.
  11. L. Anschuetz, S. Rosenbaum,"Ethnographic Interviews Guide Design of Ford Vehicles Website", In Proceedings of CHI'03 Conference on Human factors in computing systems, 2003, pp. 652 - 653.
  12. C. Montabert, "Supporting requirements reuse in a user-centric design framework through task modeling and critical parameters", M.S. Thesis, Virginia Polytechnic Institute and State University, 2006.
  13. G. Rugg, M. Eva, A. Mahmood, N. Rehman, S. Andrews, S. Davies," Eliciting information about organizational culture via laddering", Journal of Information System, 2002, pp 215-230.
  14. C.H. Chen, L.P. Khoo, W. Yan, "A strategy for acquiring customer requirement patterns using laddering technique and ART2 neural network", Advanced Engineering Informatics, July 2002, Vol. 16, pp. 229-240.
  15. M. Hawley," Laddering: A Research Interview Technique for Uncovering Core Values", http://www.uxmatters.com/mt/archives/2009/07/laddering-a-research-interview-technique-for-uncovering-core-values.php, last checked, 2009-11-15.
  16. N. Nurmuliani, D. Zowghi, S. P. Williams, "Using Card Sorting Technique to Classify Requirements Change", Proceedings of 12th IEEE International Conference on Requirements Engineering, September 2004, p.240-248.
  17. A. R. Barrett, J. S. Edwards, "Knowledge Elicitation and Knowledge Representation in a Large Domain with Multiple Experts", , 1995, vol. 8, p. 169-176.
  18. D. E. Zimmerman, C. Akerelrea, "A Group Card Sorting Methodology for Developing Informational Web Sites", in the Proceedings of International Professional Communication Conference, 2002
  19. S. Sridhar, G. Zelesnik, G. Ford, "Requirement elicitation using Joint application Design", Carnegie Mellon University, 1994.
  20. J. Wood, D. Silver,"Joint Application Development", 2nd ed., New York: Wiley, 1995.
  21. I. L. Yihwa, "Integrating Group Support System, Joint Application Development, and Computer-Aided Software Engineering for Requirements Specification", IEEE, 1993, vol 3, p. 4-12.
  22. D. Rottmann, "Joint Application Development", http://www.umsl.edu/~sauterv/analysis/488_f01_papers/rottman.htm, last checked, 2009-11-19.
  23. H. Beyer, K. Holtzblatt,"Contextual Design: Defining Consumer-Centered Systems", Morgan Kaufmann, San Francisco, 1998.
  24. M.E. Raven, A. Flanders, "Using contextual inquiry to learn about your audiences", The Journal of Computer Documentation, 1996, p. 1-13.
  25. D. Wixon, M. E. Raven, "Contextual inquiry: grounding your design in user's work", Conference companion on Human factors in computing systems, April 24-28, 1994, Boston, Massachusetts, United States, p.409-410.
  26. A. Rosenthall, "Redesign solution for civicinfo.bc web site", Proceedings of the 25th annual ACM international conference on Design of communication, El Paso, Texas, USA. October 22-24, 2007
  27. J. Fu, F. B. Bastani, I. L. Yen,"Model-Driven Prototyping Based Requirements Elicitation", Monterey Workshop 2007, p. 43-61.
  28. S. Lauesen, Software Requirements: Styles and Techniques, Addison-Wesley, 2002, p.330-363
  29. K.E. Wiegers, Software requirements, Microsoft Press, Redmond WA, 2003, p.112-130
  30. A. Hickey, A. Davis, Elicitation technique selection: how do experts do it? , IEEE Computer Society Press, 2003, p. 169-178.
  31. Atlas K, http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/diagrams.htm last checked 2009-11-10
  32. O. De Trayer, Web Design Information Modelling in the New Millennium: Audience-driven, IDEA Group Publishing, 2001
  33. Y. Deshpande, S. Hansen , Web engineering: creating a discipline among disciplines,IEEE Multimedia8, 2001, p. 82-87
  34. G. Kappel, E. Michlmayr, B. Pröll, S. Reich, W. Retschitzegger, Web engineering - old wine in new bottles?,The International Conference on Web Engineering (ICWE2004), Munich, Germany,LNCS, vol. 3140, 2004
  35. M. Lang, Issues and challenges in the development of hypermedia information systems. In: Proceedings of 11th Annual Business Information Technology Conference , 2001
  36. L.S. Al-Salem, A.A. Samaha, Eliciting Web application Requirements-an industrial case study, The Journal of Systems and Software 80, 2007, p. 294-313
  37. A. Ginige, Web Engineering: Managing the Complexity of Web Systems Development, 14th International Conference on Software Engineering and Knowledge Engineering - SEKE 02, 2002.
  38. S. Murugesan, Y. Deshpande, Web Engineering, Managing Diversity and Complexity of Web Application Development, Heidelberg, 2001
  39. J. Offutt, Quality attributes of Web software applications, IEEE Software, 2002, p. 25-32
  40. S. Murugesan, Y. Deshpande, Meeting the challenges of web application development; The web engineering approach, Proceedings of the 24th International Conference on Software Engineering, May 2002, p. 687-688
  41. S.C. Lee, A.I. Shirani, A component based methodology for Web application development. Journal of Systems and Software, 2004, p.177-187
  42. F. Ricca, P. Tonella, Analysis and testing of Web applications, Proceedings of the 23rd International Conference on Software Engineering, 2001, p. 25-34
  43. M.J. Taylor, J. McWilliam , H. Forsyth, S. Wade, Methodologies and website development: a survey of practice. Information and Software Technology, 2002, p.381-391
  44. M. Emilia, S. M. Nile, "Web Engineering", published by Birkhäuser, 2006, p. 20-52
  45. D.E. Avison, G. Fitzgerald, Information Systems Development: Methodologies, Techniques and Tools, McGraw-Hill Book Company, 1995.
  46. J. L. Valusek, D. G. Fryback, Information Requirements Determination:Ostacles Within, Among and Between Participants, in Information Analysis, R. Galliers ed., Addison Wesley, Reading, MA, 1987, p. 139-151