The implementation phase begins with putting the system in the customer's hands and training the end users. Time will be spent with the client to make sure the implementation of the system is successful and operational. At that point the system will be taken from the developers and given to the maintenance crew of the company to handle questions, comments and complaints.
Business Process Automation: This is the process of automating what the business already does without changing the procedure. For instance, if Company XYZ is currently keeping their inventory in Excel and updating it manually, then it can be automated. Company XYZ is paying for a system that will, in turn, eliminate an employee doing data entry.
Business Process Improvement: This is the process of changing a procedure and automating it for Company XYZ. For instance, if they weren't keeping track of new customers, then the development team could implement a CRM system and a procedure of entering the new customers into it with details about the customer. Another procedure that would follow quickly behind the CRM would be a follow-up plan with new customers. Should Company XYZ send them company literature, free samples or create a face-to-face meeting to grow the new customer.
Business Process Re-engineering: This is the process of teaching an old dog new tricks. Imagine a business owned by the same person for 30 years that says no to technology because they're used to a certain procedure. I imagine a lot of paper and pencils instead of keyboards and computers. This is a company that needs to be re-engineered and automated. Instead of writing notes down on paper and putting them in folders the notes can be entered into a database. This way the company can run reports for sales and inventory instead of gathering folders and adding the sales figures with a calculator.
Overview: This use case is created in the early stages when the developers have just begun to understand the client's situation. Usually it's very basic information that would be included in a template version rather than a client specific version.
Detail: This use case specifies the details needed for the use case itself.
Essential: There are no "maybes" with the essential use cases. Only essential information is needed to make the use case function. Extras and upgrades will be considered later.
Real: This use case gets more specific by mentioning procedures and steps for the end user to use as a guide. For instance, a sales person might need to follow up with a new customer after 10 days of placing their first order.
Things "creep" up on developers quickly when designing and developing a new system. They can be a burden on the initial budget and may or may not be necessary for the particular client. If developers plan to do A, B, C and D then the budget is planned accordingly. However, if steps E and F continue to come up after the initial budget it can creep into the profit.
It can be avoided by sticking to the plan. The plan was created with the client and agreed upon by both parties. Any additions that creep into the initial budget can be documented and presented to the client as "extras" in order to be sure the developers are being paid for the additional steps E and F. The client may end up saying no because they don't want to spend more money.
Technical Feasibility: This asks the question, "Can we do it?" Before taking on a project as developers one should make sure they can actually do what they say they can do. Can it actually be designed, developed and installed? Would it be easier to upgrade a current system of the client instead?
Economic Feasibility: This asks the question, "Should we do it?" If it's not feasible to complete the project and make a profit then the developers should not accept the project. Determine all of the costs, the return on investment and the break-even point before starting the project. It's always important to make a profit and, in order to do that the developers need to stick to the plan without wondering off into an area that the client never asked for or paid for.
Organizational Feasibility: This asks the question, "If we build it, will they come?" The system should fit well with the end users. The end users should also be actively involved to help the developers understand what will make the users experience better.
Systems Analysis and Design with UML, 4th Edition by Dennis, Wiley, John & Sons, Incorporated. Retrieved from: