HIM 330

HIM 330 The main focus of this research paper is on the development of a practice management system for a clinic treating patients who suffer from cancer. The location of this clinic in rural setting has made most of the patients not to have health insurance coverage and instead to depend on Medicare and Medicaid. The assumption is that the system will cost $150000. Therefore, the paper will give an indication of the way different feasibility studies will be conducted, the identification of strategy for executing requirements elicitation, together with all steps necessary for requirements elicitation, based on the above stated problem, and finally, the paper will give an example of catastrophic software failure resulting from bad feasibility study.
The different aspects of feasibility studies to be looked at include schedule feasibility, economic feasibility, technical feasibility and operational feasibility. Operational feasibility will be conducted by looking at whether the users like the new system, whether the users have to be trained first, whether users will be demanded to have some new ways of operating and whether customers will be comfortable with the new systems. If training will be required, it is important for the company to evaluate its cost, so that it does not become a huge economic burden. If the system will assure patients of security and privacy of their medical records, then it will be feasible. Therefore, each of these has to be evaluated.
As far as the technical feasibility is concerned, the company has to evaluate whether it has enough network, software and hardware resources to establish the system. Apart from having these resources, it also has to see whether it has the necessary technical expertise. The functionality, performance and environmental consequences of the available resources also have to be evaluated. If the company will find it hard to get all these requirements, then it may not be feasible for it to go ahead with the setting up of the system. If the resources will not work well with the existing systems or if they will have environmental effects, then the project may not be feasible. Under economic feasibility, the company will be required to estimate consultation expenses, the cost of facility and the estimated cost of not putting in place the system so as to weigh whether the cost of developing it is higher than that of not developing it. If it can reduce the labor cost, then it is feasible. Last, as far as schedule feasibility, the company has to determine whether there are factors that can delay the development of the system, and also the risks that can arise because of delayed or accelerated schedule. If the risks are within acceptable limits, then the project is feasible (Pressman, 2010).
Rapid Application Development will serve as a strategy for executing requirement elucidation. This is because the Rapid Application Development refers to a development lifecycle made to offer much faster development of the system and higher outcomes than those achieved with conventional lifecycle. Therefore, there will be a number of steps in requirement elucidation. The first step is the definition of a process of requirements development. This can be done by defining steps of validating and gathering requirements. The second step involves coming up with a vision as well as scope document containing the business requirements of the product. The third step involves the identification of the classes of users as well as their characteristics. The fourth step involves the selection of a product champion or leader for each user class. The fifth step involves the establishment of the typical users’ focus groups. The sixth step involves working with user representatives to identify cases related to the use of the system. This is followed by the seventh step involving the identification of the system responses and events. The eighth step involves conducting of facilitated elicitation workshops. The ninth step involves observing users doing their jobs. The tenth step involves the examination of the reports of the current developed systems to get requirement ideas. The eleventh and last step involves reusing requirements across projects (Pressman, 2010).
One of the catastrophic software failures involves the space shuttle challenger. This machine disintegrated 73 seconds after it had taken off. This was on his tenth flight into space. It led to the death of 7 astronauts. The engineers were in a hurry and despite knowing that the rubber sealing, also called O-ring of the propellant rocket was not working well under freezing temperatures, they launched it. Because of the cold temperature, there was a leakage of the heat flow along the rubber sealing (Pressman, 2010).
Reference:
Pressman, R. S. (2010). Software engineering: A practitioners approach. New York: McGraw- Hill Higher Education.