1. University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 1 what is systems analysis? preparation of the system’s requirements/definition, with focus on: what, why, who, when, where, and for whom functional requirements what does the new/revised system do? what activities are supported by the system? what information is maintained? what interfaces are supported? non-functional requirements what are the global constraints on the system? (resources, security, reliability…) what are the operational constraints on the system? (hardware, personnel…) what are the life cycle constraints on the system's development? (schedule, methodologies, tools…)

2. University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 2 and when you complete the analysis? you have: statement of problem to be solved i.e. a complete set of requirements communication between analysts and users/clients support for system evolution input to design system feasibility statement in the form of: text, diagrams, charts…

3. University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 3 knowledge area breakdown engineering process: process models, process actors, process support and management, process quality and improvement elicitation: requirements sources, elicitation techniques analysis: requirements classification, conceptual modeling, architectural design and requirements allocation, requirements negotiation specification: requirements definition document, software requirements specification, document structure and standards, document quality validation: conduct of requirements reviews, prototyping, model validation, acceptance tests management: change management, requirements attributes, requirements tracing

4. University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 4 process models:how you conduct the project, configuration management, marketing and feasibility studies process actors:stakeholders, their goals and constraints process support and management: cost, resources, schedule, training, tools process quality and improvement: software quality attributes and measurements improvement planning and implementation improvement standards and models requirements engineering process

5. University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 5 users: management and workers who will use the system customers/clients: those who pay for the system market analysts: for systems for sale regulators: government, professional organizations system developers: development and maintenance requirements engineering stakeholders (the sources of the requirements)

6. University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 6 sources of requirements current system system objectives, critical success factors the “competition” domain knowledge stakeholders operational environment organizational environment requirements elicitation elicitation techniques interviews scenarios prototypes facilitation meetings observation

7. University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 7 conceptual modeling data and control flows state models event traces object models etc. architectural design and requirements allocation requirements negotiation (conflict resolution)

8. University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 8 validation conduct of requirements reviews by stakeholders prototyping, esp. for any dynamic system behaviour model validation, checking for completeness, accuracy… acceptance test planning management change management: handling proposed changes requirements attributes: source, rationale, change history… requirements tracing: impact analysis when requirement change requirements definition document (aka concept of operations) includes software requirements specification, completed with formal document structure and standards, to ensure document quality specification requirements

9. University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 9 how is design different from analysis? analysis identifies what the system must do design states how the system will be constructed without actually building it design is done in two stages: logical design (technology independent) physical design (technology dependent)