The analysis section should provide the reader with a detailed understanding of your project environment equal to your own. The design section should provide the information needed for someone other than yourself to build the solution to the problem.
Analysis of the situation and problem you choose should be as extensive and rigorous as possible. You will probably be doing this for the first time but you will only get one chance to collect the information you need so you must prepare carefully and proceed with care. You must use the formal techniques in your documentation and you will probably need to spend some time turning observations, interviews and thoughts into more structured analysis and diagrams.
You must identify the prospective user (e.g. the receptionist and manager at the taxi company) and ascertain the user's needs. You should design a solution for the problem and justify it, considering any alternatives that you have considered and rejected.
You must specify and document the data flow and the processing requirements for the system, using the appropriate techniques. You must identify needs for the development and maintenance of the system you will develop. You must establish the data requirements and produce a full conceptual data model from these. Produce a preliminary data dictionary and document any specific mathematical algorithms such as calculations. Use other techniques as appropriate, including E-R models.
Specific techniques of analysis include observations, interviews, document searches, meetings and questionnaires. These all take time to prepare and must be done to a high standard: don't rely on informal 'chats' or guesswork. You need to start early and give yourself plenty of time to reflect and produce good quality material. In advance of an interview you need to prepare questions on topics such as: objectives, input, process, output, data, exceptions, errors, security, constraints and solutions. Record the interview as notes or on tape and write them up carefully - this is a part fundamental of your project as it will define your user's requirements.
Document your findings and re-write them in systems terminology: inputs, processes, outputs, problems, requirements, limitations. Seek out input documents, record processes and obtain copies of outputs. Data models are essential for the structure they impose, the questions they raise and for the improved understanding they produce. Models ensure that the problem is broken down into smaller, more manageable chunks or sub-problems and that attention is focused on one aspect of a problem at a time.
Do not underestimate the requirements of this stage, read the specification carefully, fulfill the criteria and get the project off to a solid start. Be sure to do enough research, this will be the basis of the project and you will only get one chance. Use all the methods you can, do not rely on interview and/or questionnaire alone.
Expected contents for this section of the report are:
The systems development lifecycle: this is described in e.g. the 'waterfall' model and the 'spiral' model. A solution is more than just software, it includes hardware as well.
Prototyping: if you have time you may produce a prototype before you complete your main system. This might be a cut-down version of the main product e.g. with a simpler interface or just an interface with incomplete processing.
A project will typically have inputs, processes and outputs - it won't be much use without these!
There must be a clear statement of the problem.
The analyst (you in this case) must not let the user determine the solution.
High level - general, qualitative
Low level - more specific, quantitative
Objectives should be SMART:
You will evaluate the success of your project against these objectives.
Specific objectives may be grouped into input, processing and output objectives; and data requirements such as the data stored about entities such as people; and performance objectives such as time constraints for processing.
Objectives should be agreed with the end user. There is a mark available for maintaining contact with the user during the project's development. Use email to ask questions and provide evidence. Send your user a copy of your objectives and get them to agree to them.
THis shows inputs and outputs (sources and destinations) to and from the system with no details of processing. A data dictionary may be used to provide error messages.
Level 1: adds data flows and stores to the context diagram but not in great detail.
Level 2: provides a detailed breakdown of data flows, stores and messages for the system; but it is not expected at this level.
If your project is based on a database with a number of tables then you may want to provide a data model showing the relationships between entities. Entities should be identified in a formal way, as shown in the text book (B&L p 240).
Many problems lend themselves to an object-oriented approach. You should adopt this style if possible as it will generate more marks.
Identify problem and user
Write an account of the problem and the user as you understand it at the start
Arrange and conduct an interview with the user (or users if more than one)
Arrange and carry out other investigation e.g. document inspection, questionnaire, background theory, observation
Collect and comment critically on any input and output forms associated with the current system
Identify & describe any algorithms associated with the current system
Identify the objectives of the project
Identify, describe and analyse any problems that the user has with the current system
Identify and write about the user's needs: exactly what they require, based on what they currently do and what they would like to do
Identify and write about any constraints on your proposal e.g. time, cost, software, hardware
Identify the sources of the data and their destinations - use a context diagram and a level 1 data flow diagram
Identify the volume of data being processed
Identify the items of data in the system (analysis data dictionary)
Produce E-R and/or object analysis if appropriate
Identify any limitations to your work: areas that will not be included