what is 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. 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. 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. requirements engineering process 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

5. requirements engineering stakeholders (the sources of the requirements) 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

6. sources of requirements requirements elicitation stakeholders the “competition” system objectives, critical success factors current system domain knowledge organizational environment operational environment interviews scenarios prototypes facilitation meetings observation elicitation techniques

7. conceptual modeling data and control flows state models event traces object models etc. architectural design and requirements allocation requirements negotiation (conflict resolution)

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

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)