IT Automation Requirement Analysis Document Q & A:

Q: What is the link to the RAD template?

A: http://users.cs.fiu.edu/~sadjadi/Teaching/IT%20Automation/Spring%202009/Projects/RAD.doc

Q: Is this a formal document?

A: Yes, it is. So, please avoid using contractions (e.g., it's, don't, aren't, etc) or any colloquial expressions. Do not use different terminology when referring to same idea (e.g., administrators, admins, and technicians). Avoid acronyms as much as possible. If acronyms are needed, clarify what they mean and mention the acronym at its first appearance. As much as possible, avoid using confusing references (e.g., it, its, they, their, theirs). Who and what you are referring to should be clear to the reader when you write they, their, etc. Avoid being too GENERIC in your document. Specify how the functionalities and non-functionalities in your project/system applies SPECIFICIALLY to the targeted organization. Be consistent throughout the entire document. For example, if you refer to a role by a specific term, stick to it and do not use different versions (e.g., Accounting XP Machines, Accounting Machines, XP Machines, etc.).

Q: Are we a 3rd party company being used by our fictitious organization to help them audit in a way and propose a new system using Kaseya or a similar IT automation program?

A: You can assume that you are a Managed Service Provider (MSP, which is the same as a 3^rd party company) providing IT management and automation to another company that is outsourcing its IT management. Alternatively, you can assume that you are the in-house IT department of that company who needs to acquire some IT Automation software to take the IT management of its company to the next level.

Q: Once we developed the RAD, will we also be responsible to perform the detailed design and implementation of RAD ourselves? Should we assume that another group may take over the detailed design and implementation based on our proposed system in the RAD?

A: For this class, the same group that develops the RAD will be responsible to perform the detailed design and implementation of the proposed system. However, your RAD should be a well-written document that any other group with the right knowledge of the field can pick it up and without the need to consulting back with you, they should be able to go one with the design and implementation. In fact, your RAD will be graded based on the completeness and thoroughness of your document.

Q: Should we assume that we will need to train the current employees at this company on how to use Kaseya? We are just wondering what our roles are after proposing this plan whether we will be taking over or just proposing and/or implementing this idea and hopefully having them take it over at some point.

A: The answer really depends on the situation. You can assume that you are part of an MSP company, in which case you will be the one you will continue monitoring and managing the company’s IT services. You can assume that you are part of the in-house IT department, in which case you will continue to provide the service. Or finally, you can assume that you are just providing consultation and initial design and implementation for the company and someone else is going to take over afterwards, in which case you need to plan for the training of the new staff/team.

Q: We've looked into Nagios more and it's more of a monitoring piece of software but no automation type features like patch management. So, I believe we might stick with Kaseya. But in our report we will draw out some pros and cons of the two and compare them.

A: In general, the rationale behind choosing a tool/solution should be strongly supported by your requirement. Keep in mind that in RAD, you are not supposed to make decision about the solution and tools. You are only supposed to elicit and analyze the requirements independent of what solution you may choose during the design phase of your project (the design phase will be after you are done with your RAD). Of course, it is important for you as an IT professional not to suggest something in the RAD that there is no solution available for it. You need to bring the level of expectation by your customer to the level of available solutions out there. Once in the design phase, you are free to choose any solution that you can strongly support the reason for its selection and you do not have to be limited to Kaseya. In fact, even if you choose Kaseya, you still need to have done your homework on studying other solutions, comparing them, and based on strong reasoning selecting Kaseya or any other solutions. Reasoning could be pure technical, economical, availability of software, etc. Note that those project that simply choose Kaseya, but do not provide sufficient technical/etc reasons for their selection/decision in their System Design Document (this is not part of RAD; it is part of SDD that comes next) will be marked off for a couple of points.

Q: How detailed would you like the report to be? For example, part of our proposed system is to cluster mail and database servers together with load balancing so the companies server architecture is better organized, easier to manage and have only those servers be dedicated to those specific services (mail and database) right now we wrote out in the current plan that the company has each server handling all web hosting servers for that server. For example, 1 server has x amount of customers (shared hosting) plus email/ftp/web/database being handled on it for those x amount of customers. We believe that part of the current plan is to move database and email services off of the individual servers and have a dedicated cluster of email and database servers. Now with all of that said do we need to write in our report of what load balancing software or additional software we are using? Or, do we not focus too much on those details? but just explain the overall idea?

A: The more detail the better! Of course, please avoid boring the reader and explaining things that are obvious. The key is that you should provide enough details for someone who was not part of the RAD team to be able to read your document solely and be able to design and implement it.

Q: We learned about n-able as another possible solution to IT automation and management. n-able is better for servers then desktops. It does patch management, remote registry management and so much more. Now if we also include this software as well nagios and compare the 3 and find n-able to be a better fit for the hosting environment could we base the RAD around n-able? Also n-able works with Linux (http://www.n-able.com/software/features/remote-monitoring/devices/). The current system for the RAD we came up with only deals with Windows Hosting. If we were able to do the RAD based on n-able our proposed plan could add Linux machines to the hosting environment to have a hybrid of platforms.

A: Once again, you should not make any decision about the solutions/tools in your RAD document and you need to leave such studies/decisions for the SDD. However, you need to make sure what you propose in RAD is doable with the solutions/tools that you have access to them and you will be able to finish you design and implementation on time for this class. For SDD, the more solutions you study and compare, the better. In fact, you can really impress me with a detailed and fair study and if you take it to the next level of providing taxonomy of solutions for your project, then I will be truly amazed! J In short, you are not limited to Kaseya as a solution and in fact, if you choose Kaseya or any other tool, you need to have a strong rationale and reasoning behind your selection/decision.

Q: Now, the only concern that myself and the rest of the group have is if we are allowed to use n-able, would it be a smart idea since your class focuses more on Kaseya and we have access it to?

A: If you can get legal access to the tools that you want to use for your project, you are more than welcome to do so. I will also try to help to get an academic license for you for the tools that you may choose, but I cannot make any promises ahead of time.

Q: Do you have a sample RAD report that we could look over so we can get a better idea on how detailed you would like it to be? Do we need to come up with a diagram or some sort of visual layout of our current/proposed plan using Visio or something similar? If so, do we need to configure subnets and assign networking to those subnets? I guess the main concern like I mentioned before is how detailed our current/proposed plan should be.

A: Unfortunately, I do not have any sample at this point to share with you. I am hoping to use the best of your RADs for future classes as samples. For the level of details, you need to think of a person who was not part of your RAD process and he/she should be able to easily use your document to design and implement your RAD. I am particularly interested in seeing graphs, table, diagrams, architectural sketches, etc. So, the more visual your document is the better. It would be a plus if you use UML standards for your diagrams, but you do not have to (you will get extra credits if you use UML, but you will not be marked off if you don’t).

Q: Can the RAD be based on the needs of a completely fictitious and imaginary organization?

A: No, the RAD has to be based on the needs of a real organization. You need to make sure that you elicit and analyze the IT management and automation requirements that would be beneficial to a real organization. Of course, you are allowed (and expected) to extend the needs to cover all aspects of IT management and automation that we are interested in this class and similarly you must limit the needs to make sure that the project can be designed and implemented by the end of this semester.

Q: How can we find a real organization to be considered for our project?

A: You can start by looking into the organizations that some of you may be working for them and/or a close relative or friend is working for them. It is very rare that no one in a group of 5 members can have access to someone who works for an organization with IT management and automation needs! If you look hard enough, I am sure that you will be able to find several examples. It is important that you select one, from which you can get sufficient information and help for your project.

Q: Can we look around on the Internet to find some sample RAD for IT Automation?

A: Of course it never hurt to look for answers in the Internet and get some help from search engines such as Google to find some related documents. However, to my knowledge, this is the first time such an IT Automation class is being taught at the university level to senior IT students. Of course, you should be able to find many examples/samples of RAD for variety of Software Engineering projects. However, you need to be careful that the RAD for IT Automation is different from a RAD for Software Engineering. Of course they share similar scope as RAD should stay in the application domain (what your client and end users understand) and should not include solutions such as Kaseya and the like (unless for good reasons your client forces upon you a specific solution).

Q: In Section 3.3 of the RAD document 3.3, we are supposed to discuss the nonfunctional requirements. What are these non-functional requirements and how we can elicit these from our clients?

A: As mentioned in the RAD template, nonfunctional requirements describe user-level requirements that are not directly related to functionality. For example, as functionality of your IT Automation, you may provide Patch Management, which is a functionality of your solution, but the level of reliability and its performance would fall into the non-functionality of the solution. You can provide a solution that is much faster and more reliable, or a solution that takes more time and may not be as reliable. In both cases, the functionality provided is the same, but the quality of delivering it is different. To better understand the different, a Ferrari and a Chevy may both include same functionality (driving you to your job or school), but the quality of drive may be different.

Q: What is the purpose of a RAD document anyway? Why we bother developing a RAD document for IT Automation?

A: A RAD would need to convey the following three points.

· First, RAD needs to clearly explain what the client’s current system is. Some examples of what that means are as follows.

o Does our customer have a backup solution, if so what is it?

o How does the customer currently manage their systems? Whether it be patch management, logging, inventory, monitoring, etc?

o Are they patching systems daily, weekly, monthly? Are they managing the computers manually? How important is data to them? Do they have measures in place for backup / disaster recovery? If so, explain.

o When problems arise, How are they dealt with?

o How important is downtime? Can certain computers afford to be down?

o What are the current roles? Does the web host have class A customers? Is there a high level of security required for certain customers? Maybe the web host has different packages for different customers (basic, professional, enterprise).

· Second, RAD should demonstrate the clients ‘pain’. So from a non tech savvy end users perspective, what are some of their daily frustrations with the current system? What problems if any occur? Examples maybe email problems, Quickbooks problems, programs don’t launch, computers shut down, etc.

· Third, RAD needs to include what the proposed system should be.

o What are the benefits of upgrading our client’s current system model?

o How will it improve their day to day business? We need to show why we chose a specific solution.

o What solution do we recommend to the customer?

Note that RAD must be geared specifically for the needs of your customer. It should not be for any generic company. Therefore, the expected IT Automation must be customized and tailored to the client’s particular problems. It is very important no to include any specific solutions in RAD (e.g., kaseya, AVG, etc). Specific solutions will be documented and discussed in the SDD and DDD. RAD should include an overview of problems and possible solution scenarios. Keep in mind that the solution should exist or should be possible to implement using the current technologies available.

Q: What do you mean by the “scope” of the system?

A: Basically, this gives you a chance to indicate what is included in your system and what is not. For example, installation of the operating system may not be included in your project, but patching the operating system may be included. As another example, getting backup from servers maybe included in your project, but the local drives of the client machines may not be included.

Q: What should be included in the “Definitions, acronyms, and abbreviations” section?

A: Any technical work that may not be understood by the audience of your document (e.g., “patch management” may not be understood by your client) must be clearly defined and explained in this section. Any acronym (e.g., IP, TCP, etc.) and abbreviations (e.g., subnet, etc.) used in your document must be spelled out and defined clearly in this section.

Q: What do you mean by “requirements elicitation the analysis model of the new system”?

A: Requirement elicitation or requirements gathering is the practice of obtaining the requirements of a system from users, customers and any other stakeholders. Requirements elicitation is a non-trivial task as there is always ambiguity and you cannot ever be sure that you have gathered all requirements from the user and customer by just asking them what the system should do. Requirements elicitation includes interviews, questionnaires, user observation, workshops, brain storming, use cases, role playing and prototyping. Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements. [ref: Wikipedia]

Q: Should we base our RAD on the issues/problems/pains of only one company?

A: You should start by gathering real problems/pains from one real company. However, on one hand, you need to make sure that you will expand the issues so that all the IT management/automation aspects that we care about in this class are covered in your project. To satisfy this, you may need to consider the issues that you gather from other relevant companies too. As long as you are not making up the issue out of nowhere and you have a basis for them, you should be fine. Therefore, it is okay if the source of these problems is not just one specific company as you may not be able to find one company that would have all the issues that would cover what we want for this class. On the other hand, you also need to make sure that you will be able to finish addressing all the issues included in your RAD considering your available time during this semester. This means that you may need to cut down on some of the redundant, less interesting, and time consuming issues.

Q: Do we have to have a “go-to-person” who works in that company and plays the role of an expert for us?

A: It would be great if there would be such a person that would be happy to put aside some time to help you out with your project voluntarily. However, if some of your teammates are playing that role for you and/or some of your teammates have access to such experts, but cannot provide the access to this expert for all the teammate, it is still okay. Basically, if there is any ambiguity on a specific issue that cannot be resolved, you need to simply put that issue aside and work on the rest of issues and add another one if necessary.

Q: Should the name of the company (or target organization) be a real name?

A: As long as no one is going to sue you for inappropriate/illegal use of their name, then you should be fine. I really do not care for a real name. What I care is to make sure that you inform the companies/experts of your intension for the project in this class and seek their permission to use the content of your interviews in this class project. You also need to carefully acknowledge the people/companies that helped you with gathering the requirements in an Acknowledgement section at the end of your RAD. You need to add this section to the end of your RAD when appropriate.

Q: In our RAD, we included a few high-level diagrams that we made in Visio? Should we include those in the RAD or wait until the SDD and DDD that follows the RAD?

A: Yes and No!

If the diagrams showing the current state of the system in which you need to show what the problem/pain is, then yes.

If the diagrams are forced to you by your customer/client to consider for the proposed solution, then the answer is again yes.

If the diagrams are what you guys are providing as part of your solution in the proposed system, then you have to wait for SDD and DDD.

Acknowledgements: Some of the questions were contributed by the following individuals: Patty Gibson, Lenny Simon, Yunier Rodriguez, Tito Esteves, Peter Greko, Norman Wright, Lamont Mackey, Jean Kesnel, Luis Crespo, Suylleng Padilla, Seijiro Ikeda, and J.ohann Padron.