Chapter 11 - System analysis methods

Data – origin, uses, volumes and characteristics Procedures – what is done, how errors and exceptions are handled Future – developments plans and expected growth rates Problems – with any existing system

Processing – algorithms and modular structure for the solution, specifying modules with clear documentation Data structures – how data will be held and accessed e.g. in a queue or database Input/output - content, format, method used, etc. User interface – dialogues, menus, etc. Security – how to keep data secure

• Black box testing (functional testing) - create test data by looking at specification that covers all inputs, outputs and functions • White box testing (structural testing) - creates test data by looking at structure that covers each possible path at least once • Alpha testing – reveals errors and omissions in the specification (user may discover the system doesn’t have the required functionality) • Beta testing – distribute software to potential users so that they can report any problems

Errors are traced and corrected Then installed onto user’s system More weaknesses and omissions will surface

Critical examination of system 3-6 months after installation Gives time for user and staff to get used to new system Any new shortcomings will become apparent Evaluated on basis of effectiveness, usability and maintainability

Each step completed one at a time from beginning to end with specific outputs that lead into next step Hard to return to previous stage (need to work down each stage again) User involved at the start (analysis stage), then has little input until evaluation

Same structured steps but done in iterative stages Requirements are defined at the start and developers work towards an initial prototype Each successive spiral produces a more refined prototype

Stages of software development not completed in a linear sequence Feedback obtained from user throughout the process Iterative process – changes made are incremental as next part of the system is built

Intended to improve software quality and responsiveness to changing customer requirements Type of agile software where frequent releases are made in short development cycles Intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted

Intended to complete major projects quickly without cancellations or restarting Focus groups gather requirements, prototyping refines product, user feedbacks often Producing within strict time limits, reusing any software components used elsewhere