technical support
Case Study 2
1. Who are stakeholders should Users be included in defining the system requirements? Why or why not? Should users interact with founders other than technical
support? Why or why not?
o Founder Members (people who take the decision)
o Volunteers (users who will maintain the website, none technical users)
o Users of the website (Practitioner members and non-members)
o Technical Staff
o Web hosting provider
In defining the system requirements we should include the users so they can appreciate the system.it will take more efforts from the staff but in the end the users
will be satisfied.
Users should interact with founders. This can be beneficial for founders to understand the users better to a void any mistakes in making diction
2. If you were the lead analyst for, how would you determine the requirements? Be specific in your answer. List several questions you need answered.
The leader will put the requirement by getting the experience from interviewing users who have tried similar websites and know if they were satisfied or not with
explaining why. The feed back from the users will determine the requirements for mindfulness. Example how the question will be asked
● How do you use mindfulness today?
● How do you prefer to share our article with others?
● Do you often search for services similar to the one we provide?
● What attracts you the most in this website?
● Were you satisfied with the provided features?
3. What are the primary functional requirements for the system as described so far in the case?
● Provide privet contacts to services providers
● The capability to have multimedia options.
● Improve the interactive abilities to make it easier to use
● Provide technical support for users through FAQs and remote support
● Allowing users to create their own account profile and be a part of TIM.
● Organizing the provided services based on the type of membership each costumer has.
4. Are the parameters for alerting end users and tech support personnel the same? Can they vary by users? What are the implications for the system’s functional
requirements?
The website will be equipped with an alert system which, will keep users updated in terms of maintenance and operation events. The website will offer the users a
notification alert based on the contact information of their choice. Users will be able to choose the level of necessity, which users will be in the position to
choose. This system will be offer even for the international contact. The system will offer multiple notifications such as, account information including the password
and expiration date and the credit card operation. The least level of alerting will not be mandatory in users account.
5. Briefly describe some possible nonfunctional requirements for technical support?
Usability – however is hard to imply but it’s very important to make it easy for users to use. The media materials will be the hardest part in the usability process.
The design must meet the criteria half way.
Reliability- the website have to be reliable in all times and the best way to do it is hosting the website in a trusted web provider but the only down side is
dependent. The cost of development, labor and support will be reduced. The content that users will add to the website have to be monitored by mindfulness members and
make sure they fit with the website desirer.
Performance- the only effect on the performance will be from the user side on anther world their devises Internet connection will be the only thing effecting the
performance because the website will be hosted by trusted host organization
Security –all the files and content that going to be upload to the website will be scanned and reviewed to stop any a wonted an authorized activity. All the users
credit information will be stored data base and encrypted while it is transmitting by doing so we can make sure the website is secure
case study 3
1. Identify all actors that will use TechSupport ?
Technical Staff
Users of the website Non-Members
Volunteers
2. Using the actors that you identified in question 1, develop a list of use cases based on the user goal technique. Draw a use diagram for these use cases
Technical Staff
● Place support ticket
● View support FAQ
● Create content
● Edit content
● Delete content
Users of the website
● View support FAQ
● Create content
● Edit content
● Delete content
Volunteers
● Place support ticket
● View support FAQ
● Create content
● Edit content
3. Using the event decomposition technique for each event your identified in the description, name the event, state the type of event, and name the resulting use
case. Draw a use case diagram for these use cases.
Event Type Use Case
Technical Staff views posting External Record data
Technical Staff creates posting External Record data
Technical Staff uploads attachment External Record data
Technical Staff submits support ticket External Request Assistance
Technical Staff Reviews FAQs External View data
Volunteer receives support ticket External View data
Support Ticket Dashboard Reporting Temporal View trend data
Case study 4
1. Modify the diagram (Figure 4-25) to incorporate the changes under consideration. You may need to use association classes and generalization/specialization
(inheritance).
Case study 5
1. Which use cases include which other use cases? Modify the diagram to incorporate included relationships.
2. Consider the use cases that actors share but have a different vision of the former. Why do the actors have different versions? Would the diagram be correct if
each actor had his or her own version of the use case? Why or why not?
Since the actress is the same we don’t need to make deferent for the use cases because it’s processing steps. Also, the activities are the same
3. Develop a System Sequence Diagram (SDD). Assume that the system will automatically display the most recent results in a time interval to Users of the website
for Support Tickets. Assume further that the Users of the website can ask the system to view the results during a specified time period and that the levels can be
displayed in a tabular form or graph.
Case study 6
1. What regulations apply to Tech?
The system should protect the users personal data. This information will be saved in the system and the users can use it later fore example the user can use his
information in finance
2. How the system can ensure data security between transmission of data?
We could use HTTPS and TLS to secure the personal the data. Will be securing connect by that we will be able to secure any personal information. We are focusing on
protecting all of the data.
3. Consider the data storage issues related to a patient’s mobile device and the possibility of It being lost or stolen.
Https will be used to protect data on website browsers and password encryptions will be used for privacy purposes. To enhance the protection of personal data by the
passwords, special characters and length requirements will be adhered to hence avoiding security issues like cryptanalytic attacks. In case authentication is required
to access any data, a timeout feature will be applied in the event of the mobile device being stolen hence limiting access to a private window.
4. Consider the issues related to accessing the system from multiple systems and on and off premise.
HTML 5 will be enabled on the system’s full web to ensure that any private data is protected against similar security challenges regardless the device used. Support
issues will be limited in this system alongside security constraints introduced by mobility. When any private encrypted data is accessed from any location, it will be
protected especially when it comes to private account data.
5. What security issue relate to wired and wireless transmission of private data? Does this change with a hosted provider?
HTTPS will be the main security maintainers to ensure privacy in data transmission and all data transmissions through the system will be treated equally. However, the
main issue will be presented by our need to meet the demands of the hosted provider in the system. In depth analysis and assessments will be conducted to ensure that
the authenticated users enjoy the highest level of security in our system. The financial status of the site will however be the determinant of the security regulations
set such as the need for PCI compliance when dealing with credit card information.
Case study 7
A screenshots for browser to show how the ticketing submission will look.
A screenshot to show how it organizes the ticketing
A screenshot for a table to show the rate of the ticketing by each month.
Case study 10
1- Develop a deployment diagram
Develop one Design Class Diagram
Case study 11
1. Develop a first -cut sequence diagram for Use case Chat Box
2. Develop a multilayer sequence diagram that includes domain class and data access classes.
Case study 12
Part1
A:
Name Domain
users providers providerId, firstName, lastName, emailAddress ,PhoneNumber
chatBox chatId, Date
eticketng ticketId, category, detail, status, providerId, date
remoteAccessing remoteAccessId, date
replyTicket replyId, ticketId, usersId, remoteAccessId,chatId, date
B: DIGRAM
PSRT2:
1- The users will be registered at the technical Support Page for securing the data. Registered user can submit E-ticket, chat Window, and Remote Access
2- The database should be secured so we can secure the user data. Always the data should be backed up so it will be hard to lose anything.
3- We will be sending notification to the users as soon as they submit the ticket. By that the users will now if ticket is submitted or not. Also, to know if any
one is breatching the website.
Case study 13
1. What integration and system tests are required and when should they be incorporated into the iteration schedule
• Integration Testing –The system is subjected to be developed in a shorter time since it’s made of predeveloped codes, which can be more useful in examining.
• However, this process will take a large amount of time to insure that the system works properly in terms and all sharing operations work, as it should.
• Problems will be reported by users, which will require users to write a problem report. These reports will be the main source in drive examining in the process
of integration. The tech job on the Mindfulness is going to need to be integrated through different strategies to oversimplify its goal. However, a lot of teamwork and
effort among different categories to make it as successful as it should be. This way if assistance is needed when a Tech is needed or a ticketing problem occurs which
will be accessible through the website help tools.Each repetition is going to be examine actively to maintain a correct data and make sure the dataflow is normal which
will ensure the end user is going to be helped which whoever is assign to help in this situation.
•
• Stress and Performance Testing – This step will be shortened since we are going to be using a cloud provider as our stand.
• The cloud system provides an ability to check and run though the system without problems. Problems that might affect users globally will appear in the
integration process, which focus in our codes. All global issue will have to be fixed before reaching the ticketing process. The other issue that we should be aware of
is the number of tickets issued. Tickets are tied by the organizers and volunteers numbers who are going to mange the event. This process is testable during the
production stage.
Iteration Subsystem No of Use Cases Time Activities
*1 Help Desk Ticketing 1 3 weeks Begin Integration Testes
*2 Help Desk Ticketing 1 2 weeks Unit and Integration Testes
*3 Help Desk Ticketing 1 2 weeks Unit and Integration Testes
*4 Help Desk Ticketing 1 2 weeks Integration Testes
*5 Remote Access Tool 1 2 weeks Integration Testes
*6 Remote Access Tool 1 1 weeks Integration Testes
*7 Chat Window Tool 1 2 weeks Integration Testes
*8 Chat Window Tool 1 1 weeks Integration Testes
*9 Reporting Dashboard 2 2 weeks Integration Testes
*10 Integration System Test 4 weeks
*11 Acceptance Testing 10 weeks
2. What are the documentation and user training requirements for the system, and when should they be incorporated into the iteration?
Documentation is the most essential step, which will help to monitor and maintain a useful data and a reliable system. Getting users used to the system must be as easy
as possible since the whole process of creating this system is to make users more satisfied. However, the process of submitting a request should have some steps, which
end users will do.
End User Documentation – To help users end users and guide them to the right help option, FAQs option will be installed in the top right side of the screen then
provide a stimulation as a reminder option. For example, when entering a text the system will provide suggestions based on the area the user is typing in. If the user
is typing in the place of emails system will provide suggestions such as tech support and so on.
Volunteer Documentation – Our development will be working mainly on volunteer documentation and the main system documentation in the process of developing. The system
will need a volunteer who are going to operate it and help users. These volunteers will have to be trained on the equipment and tools in the system. They also must
have an equipped documentation system to make their job possible. The system will help volunteers know how to deal with problems and sorts them by specialties. The
number of volunteers isn’t going to be the same and they might change due to the opening and downsizing of the system operators. Therefore, The documentation system
must be easy to master to suit high rate of change in volunteers
System Documentation – It is one of biggest and most important sections where a lot of repetition takes place. It is also a very appropriate stage to look for mistakes
and fix them as part of the preparation stage to build the system and also as part of the integration process. The most reliable way to solve the problems and have
knowledge about it is to use the available resources from different providers when we need it. This process will require a very wide range of searching process which
goes through each part of the system to find problems and fix them and neglect the avoided effects of other systems that runs in the website.
3. Assume that after deployment and a three-month testing and evaluation period, updates to the first Android-based systems (client and server) will be
implemented and another client-side version will be implemented for the iPhone. Develop an iteration plan for implementing and deploying the second version of the
system.
The use of open source will make our second project remarkable to our approach where the Ticket subsystem will be used as our code and proper handling will be
required. As a result of this, a predictive approach will be applied because it is the most logical way of using the designed system. In addition to that, the open
source vendors strongly support the latest Android or iPhone Browser to log tickets using the Chat and Remote Control support instruments. It does not make sense for
an Android to be supported for Chat and not be supported for Remote Control in the current technological state. Because of the inability of our system to control the
code, a logical dependence from the Bottom Up will be enabled. This will also be done partly because we cannot control the resources to help keep the current releases
as well as updates up to multiple form operating systems and functions. For the open source subsystems to be updated, the manner in which the publishers have updated
their packaged will need to be determined. This is because some of the publishers prefer to put up the support for both releases into a similar update while others opt
to doing them one at a time. Our choice of the predictive approach is a good approach for us to scout out how to incorporate our support and make important decisions
that will determine which should be supported now and which can afford to wait.
Case study 14
Subsystem Use Case Primary Device Platform
Ticketing Support
Going to Technical Support Browser Desktop Browser
Ticketing Submit Desktop Browser
Receive Ticket Desktop Browser
Chat Box
Chatting with representative Desktop Browser
Review ticketing Desktop Browser
Review Chatting Desktop Browser
Remote Access
Start a session Desktop Browser
Close a session Desktop Browser
Group 1
Liter Use Cases Device
A Going to Technical Support Page Desktop
B Ticketing submit Desktop
C Receive Ticketing Desktop
D Review chatting Desktop
E Review Ticket Desktop
Group 2
Liter Use Cases Device
A Chatting with representative Desktop
B Session for Remote access bigin Desktop
C Session for remote Access ending Desktop
D
Chap02 Case
Volunteers can be identified by functions.
Categorize stakeholders to include more. Such as b-client.
Focus on Tech! Not general issues of main site.
Categorize functions under subsystems. No need for alert, as alert is not essential as medical devices. Good non-functional requirements analysis.
Chap03 Case
volunteers — again work more details with this actor
Need to differentiate mindfulness tech staff, business customer’s tech staff
Need to differentiate tech staff have different titles and priviledges.
Focus on the main subsystems of your subsidiary.
Also, what “content” is referred to here? What content is for tech support, rather than “content” for practice?
why attachment is specifically standing out? should it just be part of tech content?
Chap04 Case
User need to be in Italic. Also if you have userID as key, and then that key should also work as technicalStaffID or UsersWebsiteID, as volunteerID is a property all
three concrete classes should share.
Any user can have SupportTicket? Or only paid member or tech staff? How to represent that? Post is non-essential.
Try to expand the domain class diagram to include all essential classes your group needs, such as Ticket, Chat, etc.
where is multiplicity?
Chap05 Case
Good start.
Cluster web users into those who can and can’t issue tickets. Also think who can and can’t chat and whether or not allowing a ticket generated through chat, or a
ticket has to be filling in a web form.
Also need to think of individual customer, vs. business customer — do they have different use cases in terms of differnt tech support received.
For tech support, you may differentiate between tech support staff, vs. manager.
Again it is a good start for use cases and activity diagrams.
use :System
Chap07 Case
are these your own design or the screenshots for existing ticketing systems? you need to design your own tech support theme (color, structure, etc.) and show how
possibly integrate with the open source ticketing, chatting, etc. you can use existing components, but you need to integrate them.
Chap10 Case
The 2nd diagram is better than the first one. Let’s talk in class after lecturing. You need to first clarify the sequence between ticketing and chat.
Chap11 Case
need the sequence diagram to be more tech-savvy as UML depicts., etc., invovling classes like controller class, DA, etc.
physician? Domain layer classes are not just “nouns”.
DA classes?
Chap12 Case
Please proper labeling for database table. Not name and Domain.
Focus on one main subsystem and to make database clear. Mimic an opensource ticketing system for ticketing.
ok. good logic with domain class diagram. But here you need to make design class disgram.
Please make a full design class diagram with visibility, methods, etc.
Chap13 Case
Reasonable considerations. Would it be possible to simplify the table by consolidating? The first one needs integration testing?
Excellent to consider documentaiton from different stakeholder’s perspective.Rather than counting solely on volunteers for tech support, there is a need for a small
(at lease one person) tech support staff that is not volunteer. There is no need for documentation for volunteer, a volunteer just takes a role as tech support
(temporarily). so the documentation is for tech support staff or manager, etc. at diferent levels of support.
Because of no source code, then isn’t better to be top-down so that the bottom supporting modules can be replaced if one open source module doesn’t work well
Chap14 Case
what open source and rich media and web 2.0 modules you may need?
canIT support to support via smartphone?
use case should be verb + noun.
Please think my systematically for the entire process — e.g., follow the lifecycle of a ticket.
