[attachment=10859]
1. SYNOPSIS
“This project mainly used to extend the business of the organizations world wide. E-care attempts to integrate all products and services of the organizations and provides the automated help desk to the end users.”
• E-Care is customer care management system. E-Care is called as E-Desk or Help Desk System because it tries to solve all the HD (help desk) problems, which are coming from the users of E-Care.
• E-Care will take care of every request coming from their users and try to solve and produce the solution of the particular request. E-Care will also store the responses for the future use.
• E-Care is about better and more joined up care, advice and assistance to the people through the use of computers and communication technology. With the individual's consent E-Care enables secure information sharing between professionals such as doctors, nurses, social workers and teachers in public and voluntary agencies.
• This project mainly used to extend the business of the organizations worldwide. E-Care attempts to integrate all products and services of the organizations and provides the automated held desk to the end users.
This project mainly used to extend the business of the organizations worldwide. E-care attempts to integrate all products and services of the organizations and provides the automated held desk to the end users.
This project mainly deals with automating the task of the E-Care system that helps many end-users to know the solutions for their request within no time. E-Care can be done annually but there may be problems that have to be faced so, to overcome such problems we need to automate the Help Desk System.
2. ABSTRACT
E-Care is customer care management system. E-Care is called as e-Desk or Help Desk System. It is so called as Help Desk System because it tries to solve all the HD (helpdesk) problems, which are coming from the users of E-Care. E-Care will take care of every request coming from their users and try to solve and produce the solution of the particular request. E-Care also will store the responses for the future use.
E-Care contains six main members who play very important role in this Help Desk System. They include super user, level1 administrator, level2 administrator, level3 administrator, corporate client user and corporate user (or end-user). Super user is the chief head of the organization that assigns first level, second level, and third level administrators. The super user is responsible for all the three level administrators including the corporate clients. The Super user is the sole person who is responsible for creating categories, modules and the support team.
E-Care is very useful for the corporate clients who want their business to extend world wide i.e., by keeping contact and good relation with the corporate users who buy their products. The corporate clients who buy E-Care for their business can know what are the various problems of their product which are coming from their users so that they improve their products to the user needs. Any user who knows a little about of the computer can handle E-Care.
3. REQUIREMENT ANALYSIS
3.1 Sources of Requirements
Good requirements start with good sources. Finding those quality sources is an important task and, fortunately, one that takes few resources. Examples of sources of requirements include:
• Customers
• Users Administrators and maintenance staff
• Partners
• Domain Experts
• Industry Analysts
• Information about competitors
3.2 Requirements Gathering Techniques
After you have identified these sources, there are a number of techniques that may be used to gather requirements. The following will describe the various techniques, followed by a brief discussion of when to use each technique.
To get the requirements down on paper, you can to do one or more of the following:
• Conduct a brainstorming session
• Interview users
• Send questionnaires
• Work in the target environment
• Study analogous systems
• Examine suggestions and problem reports
• Talk to support teams
• Study improvements made by users
• Look at unintended uses
• Conduct workshops
• Demonstrate prototypes to stakeholders
The best idea is to get the requirements down quickly and then to encourage the users to correct and improve them. Put in those corrections, and repeat the cycle. Do it now, keep it small, and correct it at once. Start off with the best structure you can devise, but expect to keep on correcting it throughout the process. Success tips: Do it now, keep it small, and correct it immediately.
Conduct a brainstorming session
Brainstorming is a short group session where everyone is allowed to say whatever they feel is important to the topic of discussion. After that, a facilitator leads the group in organizing and prioritizing the results. The following basic rules for brainstorming ensures better results:
• Start out by clearly stating the objective of the brainstorming session.
• Generate as may ideas as possible.
• Let your imagination soar.
• Do not allow criticism or debate while you are gathering information.
• Once information is gathered, reshape and combine ideas.
Interview users
Face-to-face contact with users through individual interviewing is the primary source of requirements and an important way you gather and validate their requirements. Remember that it is not the only possible technique, and that you can conduct interviews many different ways. Develop a repertoire of styles to fit different situations. Unless you use the system yourself, you will need to make an effort to understand and experience the user's problem to describe it clearly and correctly.
Send Questionnaires
If face-to-face meetings are possible, they are always preferable, because they provide a better means of uncovering the problem behind the problem. Sometimes, through, face-to-face meetings with stakeholders are not feasible (when developing products for the consumer market, for example). In those situations, consider using questionnaires. Send a set of questions, possibly with multiple choice responses, to the relevant stakeholders, and ask them to complete it and return it to you. Success tips: Keep it short and given them a deadline.
This technique has the advantage of providing a lot of information for statistical analysis. However, the questions must be well designed to be clear and to avoid so-called "leading questions", which bias the responses.
Work in the target environment
Experience the work of the users for yourself. Working with users helps you understand problems that have resisted previous solutions. Familiar systems developed in this way inevitably include tools for programmers, such as interactive editors and compilers, as the developers naturally have both the expertise in the subject area, and the desire to solve their own problems. It would be good to see the same dedication devoted to solving problems in other areas too. Where the work cannot easily be experienced in this way, it may still be possible to do a bit more than just sit quietly and observe. Users can give you a commentary on what they are doing, what the problems are, and what they would like to have to make the work easier.
Study analogous systems
The starting point for many projects is often a similar or an existing system. Sometimes, comparable products and systems contain working versions of good ideas for solving user problems. You can save the time lost in reinventing the wheel by looking at systems already on the market, whether they are systems installed at the user's site or products made by rival organizations. Even if they are trying to solve slightly different problems, they often provide valuable clues as to what you need to do.
Listen when a customer asks why a product couldn't do something that the customer wants, and keep a list of these suggestions. Later, use it to start discussions with other users. You should be able to obtain some requirements directly this way. If not, capture and store suggestions for future use.
You can describe to users selected features of other products. Explain that the system is designed for another purpose but contains an interesting feature, and you wonder it or something similar would help them. Sometimes these systems are described in documents, such as a contract from another organization or a report written for management. Often, these documents were never intended as formal requirements, and were written merely to communicate a stream-of-consciousness idea. Define a process of going from disorganized to organized information.
Such a process might involve the following activities:
• Read the document from end to end (several times) to comprehend what the customer wants and what actually has been written.
• Classify all of the types of information in the document. (user, system requirements, design elements, plans, background material, irrelevant detail)
• Mark up the original text to separate out such requirements.
• Find a good structure for each of the different types of information such as: a scenario for the user requirements, functional breakdown for the system requirements, and architecture for the design.
• Organize the information to show gaps and overlaps. Feel free to add missing elements, but confirm these decisions with the users.
• Create traceability links between these information elements to show the designers exactly what the users want.
• Convince the customer to accept the new information as the basis for the contract.
• Examine suggestions and problem reports
Requirements can come from change suggestions and user problems. A direct road to finding requirements is to look at suggestions and problems as first described. Most organizations have a form for reporting system problems or software defects. You can ask to look through the reports (and there will probably be many). Sort them into groups so you can identify the key areas that are troubling users. Ask users some questions about these areas to clarify the users' actual needs.
Talk to support teams
Most large sales organizations have a help desk that keeps a log of problems and fixes, and support engineers who do the fixing. Many organizations have similar facilities to support their own operations. Talking to the help desk staff and the support engineers may give you good leads into the requirements, and save you time. Also talk to the training team and installation teams about what users find to be difficult.
Study improvements made by users
This is an excellent source of requirements. Users of a standard company spreadsheet may have added a few fields, or related different sheets together, or drawn a graph, that exactly meets their individual needs. You need only ask: Why did you add that? Their answers help you get to the heart of the actual requirement. This applies also to hardware and non-computer devices. For example, a lathe operator may have manufactured a special clamp, or an arm that prevents movement of the tool beyond a certain point. Any such modification points to something wrong with the existing product, which makes it a valid requirement for the new version.