12/10/15
It is a Cross Life Cycle Activity (CLCA) that may be performed at any stage ◦ In fact, some part of it (e.g. risk analysis and management) should be continuous Some methodology “flavours” devote one phase specifically to feasibility ◦ After analysis before design begins ◦ Called “system proposal” step
Schedule feasibility is a measure of how reasonable the project timetable is Technical feasibility is a measure of the practicality of a specific technical solution and the availability of technical resources and expertise Operational and technical feasibility criteria measure the worthiness of a problem or solution ◦ Operational feasibility is people-oriented ◦ Technical feasibility is computer-oriented
Is the problem worth solving, or will the solution to the problem work? PIECES framework ◦ Performance ◦ Information ◦ Economy ◦ Control ◦ Efficiency ◦ Services How do the end- users and managers feel about the problem (solution)? ◦ must evaluate whether the system will work, not just can work ◦ resistance to change
Examined after analysis and design phases Is the proposed technology of solution practical? ◦ mature and proven technology ◦ IS architecture Do we currently possess the necessary technology? ◦ can our printer handle new report formats? Do we have the necessary technical expertise?
Are the project deadlines reasonable? It is preferable to deliver a properly functioning information system late than to deliver an error-prone, useless information system on time Schedule Feasibility
Difficult to estimate until user requirements and technical solutions have been identified Cost-benefit analysis How much will a system cost? ◦ development and operational costs ◦ lifetime benefits must recover both the development and operational costs ◦ fixed and variable operating costs
What benefits will the system provide? tangible benefits are those that can be easily quantified ◦ fewer processing errors, increased throughput, decreased response time, elimination of job steps, reduced expenses, increased sales, better credit, reduced credit losses intangible benefits are those benefits believed to be difficult or impossible to quantify ◦ improved customer goodwill, improved employee morale, better service to community, better decision- making
Is the proposed system cost effective? ◦ Payback analysis, Return on Investment, Net Present Value ◦ must take into account the Time Value of Money ◦ A Framework that incorporates factors such as technology, people, data, processes should be used
Feasibility CriteriaWt.Candidate 1Candidate 2Candidate 3 Operational Feasibility An assessment of how well the solution meets the identified system requirements to solve the problems and take advantage of the opportunities envisioned for the system. 15% Score: Score: Score: Cultural/Political Feasibility An assessment of how well the solution will be accepted in a given organizational climate. 15% Score: Score: Score: Technical Feasibility An assessment of the practicality of the solution and the availability of technical resources and expertise to implement and maintain it. 20% Score: Score: Score: Economic Feasibility An assessment of the cost- effectiveness of a project or solution. Cost to develop: Payback period (discounted): Net present value: Detailed calculations: 30% Score: Score: Score: Schedule Feasibility An assessment of how long the solution will take to design and implement. 10% Score: Score: Score: Legal Feasibility An assessment of how well the solution can be implemented within existing legal and contractual obligations. 10% Score: Score: Score: Ranking:100%
When 38 IT professionals in the UK were asked about which project stages caused failure, respondents mentioned “ requirements definition ” more than any other phase.
A requirement is a statement about an intended product that specifies what it should do or how it should perform. Goal: To make as specific, unambigous, and clear as possible.
Consistent not conflicting or ambiguous Complete all possible system inputs and responses Feasible can be met with available resources & constraints Required truly needed and fulfill purpose Accurate stated correctly Traceable directly map to system functions Verifiable can be demonstrated during testing Pa ge 13
Cost Delay Dissatisfaction leading to mis-use or dis-use High maintenance / enhancement costs Unreliability / down-time Reputation of IT suffers Pa ge 14
Identify and contextualize the problem (the task) Lower level models need requirements analysis Pa ge 15
Discovering and Collecting Requirements ◦ requirements discovery, requirements gathering Fact-finding Analysing requirements ◦ Criteria defining requirements Documenting requirements ◦ Requirements specification Pa ge 16
Organizing different techniques into a meaningful process aimed at fulfilling the goals of fact finding Using a set of fact finding techniques efficiently ◦ Determine key points using techniques that offer the most information with the least effort/expense ◦ Follow up with less expensive techniques to collect mass data ◦ Target fine details ◦ Use other people’s time wisely and considerable – / I – 3 / Pa ge 17
Learn all you can from existing documents, forms, reports, and files If appropriate, observe the system in action Given all the facts collected to date, design and distribute a questionnaire to clear up things you don’t fully understand Conduct your interviews (or group work sessions) Follow up – / I – 3 / Pa ge 18
Focus on identifying the stakeholders Involve all the stakeholder groups Need more than on person from stakeholder group(s) Use a combination of data gathering techniques For example: use observation to understand the context, interviews to target specific user groups, questionnaires to reach a wider population, and focus groups to build a consensus view
Sampling of existing documentation forms and files Site visits Observation of work environment Research of similar systems Surveys of users and management (questionnaires) Interviews of users and management 2013 – 2014 / I – 3 / Page 20