After finishing our lecture on Use Case Diagrams and Class Models, David completed a lecture titled “Finishing Analysis”.
This stage can be broken down into:
Prioritizing System Requirements -> Describe relevant strategic decisions required for implementation -> Determine alternative approaches for development -> Evaluate and Select an approach -> Write up request for proposal and evaluate vendor proposals (should be prior to selecting approach?) ->Present findings to management.
Put simply the final stage of analysis is to (along with management) decide on what Design, Implementation and Support path will best suit the needs of the organization.

Going back to Week 4’s Lecture, Analysis Phase:

* Gather information (review documents, current practices, conduct interviews, prototyping, questionnaires, JAD sessions, Vendor Solutions)
* Define System Requirements
-> * Prioritize Requirements
-> * Prototype (feasibility and discovery)
-> * Generate and evaluate alternatives
-> * Review with management

These 4 final steps really are just drawing a conclusion from the information gathered in the Planning phase and earlier Analysis phase steps.

Pearl of the week: In the final stages of Analysis with presentations to management it is very easy to respond ‘Yes’ to management requests which would result in serious ‘scope creep’. Ensure the solution will solve the key issues with the resources allocated (this is superior to attempting to solve everything with more than the allocated resources).

When determining alternatives, particularly for businesses, a tiered approach is best; Low Automation and cost, Mid Automation and Cost, High automation and cost. In presenting/selecting alternatives the POSTEL analysis method is relevant as a ‘big picture’ view is necessary.

Build or Buy? Buy will become increasingly prevailent

Towards the end of the Analysis Phase, Technological Constraints now become relevant. Particularly the Application Deployment Environment (Hardware and Software requirements). Two examples of this which I see regularly at work are PHP5 (not all web-servers have PHP5 installed and alot of CMS solutions require it, the other big one is ASP.NET (Windows Hosting environment). Considering the development tools is also done at the close of Analysis.

A Request for Proposal [RFP] will become an increasingly important part of a Systems Analyst’s work with rises in customizable Vendor solutions. An RFP should contain the following:

  • Introduction and background
  • Overview of Need
  • Description of Technical requirements
  • Description of Functional requirements
  • Description of General requirements
  • Requested Provider and Project Information
  • Details for Submitting Proposal
  • Evaluation Criteria and Process

It is unlikely that the lowest bid for any significant System Design and Implementation will be the best fit for mission critical solutions. This was demonstrated by the 1992 failure of the London Ambulance System, for more details:

I really feel that 90% of companies would be best suited to outsourcing System Development, if it is not a core competency than find an experienced business who does focus on systems in the relevant industry.

In the tutorial we again worked with Visual Paradigm to build UML models. The process is actually quite enjoyable although I did find that the discussions can get a bit irritating as long debates over irrelevant or unambiguous points chew up alot of time.