System Investigation
Understand the existing environment, business problem, stakeholders, processes, constraints and opportunities before proposing a solution.
SYSTEMS ANALYSIS & DESIGN
Systems Analysis and Design: From Requirements and Process Analysis to System Architecture.
A comprehensive Systems Analysis and Design resource covering SDLC methodologies, requirements engineering, feasibility analysis, business process modelling, DFDs, ER diagrams, UML, system architecture, prototyping, testing, implementation and maintenance.
SYSTEMS ANALYSIS & DESIGN FUNDAMENTALS
Understanding how information systems are analysed, modelled and designed.
Systems Analysis and Design provides a structured way to understand organisational problems, identify information and process requirements, model system behaviour and design solutions that support users and business objectives.
An information system is more than an application or database. It normally involves people, processes, data, technology, organisational rules and interactions between different components. Systems analysis attempts to understand how these elements work together and where a proposed system could create improvements.
Systems design then takes the findings from analysis and turns them into a structured description of how the proposed solution should operate. This can involve system architecture, database structures, user interfaces, process models, security requirements, integrations and technical components.
This makes Systems Analysis and Design particularly important for information systems, software engineering, business information systems, database applications and enterprise technology projects.
A well-designed analysis process reduces the risk of building a technically functional system that does not actually solve the original business or user problem.
CORE AREAS
Major areas covered by Systems Analysis and Design.
A complete systems analysis and design process connects business investigation, requirements, modelling, architecture and implementation planning.
Requirements Analysis
Identify, analyse, document, prioritise and validate functional and non-functional system requirements.
Feasibility Analysis
Evaluate technical, economic, operational and schedule considerations before significant development begins.
Process Modelling
Model business processes and system behaviour using structured techniques such as DFDs, flowcharts and UML.
Data Modelling
Identify entities, attributes, relationships and data requirements that support the proposed information system.
System Design
Translate requirements into system architecture, components, interfaces, data structures and implementation specifications.
SYSTEMS DEVELOPMENT LIFE CYCLE
SDLC: understanding the systems development life cycle.
The Systems Development Life Cycle provides a structured way to organise activities involved in investigating, specifying, designing, developing, testing, implementing and maintaining information systems.
01
Planning and Investigation
The project begins by understanding the business problem, organisational context, stakeholders, objectives, constraints and initial scope.
02
Requirements Analysis
Analysts identify what users and stakeholders need from the proposed system and document functional and non-functional requirements.
03
Feasibility Study
The proposed solution is evaluated against technical, economic, operational and scheduling considerations.
04
System Design
Requirements are translated into system architecture, processes, data models, interfaces, components and other design specifications.
05
Development and Construction
The designed solution is implemented using appropriate technologies, development practices and project controls.
06
Testing
The system is evaluated to determine whether requirements are satisfied and whether defects, usability problems or integration issues need attention.
07
Implementation
The completed system is introduced into its operational environment, which may involve migration, training, configuration and deployment.
08
Maintenance and Improvement
After deployment, systems may require corrective maintenance, enhancements, security updates, performance improvements and adaptation to changing requirements.
SYSTEMS INVESTIGATION
System investigation: understand the problem before designing the solution.
System investigation is concerned with understanding the current environment and establishing whether a proposed system is worth taking forward.
A common mistake in systems projects is to begin designing screens or databases before understanding the underlying problem. System investigation provides an opportunity to examine how work is currently performed and why change may be required.
An analyst may examine existing processes, information flows, systems, stakeholders, organisational policies, technology limitations and recurring operational problems.
Investigation can also identify the boundaries of the proposed system. Defining what belongs inside the system and what remains outside it is important because unclear scope can create requirements conflicts later in the project.
Typical investigation questions
- What business problem is the organisation experiencing?
- Who are the main stakeholders and users?
- How is the current process performed?
- What information is created, stored or exchanged?
- What limitations exist in the current system?
- What objectives should the proposed system support?
- What constraints could affect the project?
- What should be included within the proposed system scope?
REQUIREMENTS ENGINEERING
Requirements analysis and requirements engineering.
Requirements engineering establishes what a system needs to accomplish and provides a foundation for later design, development and testing.
Requirements elicitation
Requirements elicitation involves gathering information from users, stakeholders, documents, existing systems and other relevant sources. Interviews, workshops, observation, questionnaires and document analysis can all contribute.
Requirements analysis
Collected requirements need to be examined for ambiguity, duplication, conflict, feasibility and completeness. Analysts may need to negotiate priorities when stakeholders have competing needs.
Requirements specification
Important requirements should be documented in a form that stakeholders, analysts, designers, developers and testers can understand and use.
Requirements validation
Validation checks whether documented requirements accurately represent stakeholder needs and whether they are sufficiently clear, consistent, realistic and testable.
Common categories of system requirements
Functional Requirements
Describe what the system should do. Examples include user authentication, searching, reporting, transaction processing, notifications or record management.
Non-Functional Requirements
Describe qualities, constraints or performance expectations such as security, usability, availability, scalability, reliability and response time.
Business Requirements
Describe the broader organisational objectives or outcomes that the proposed system is intended to support.
User Requirements
Describe system needs from the perspective of users and stakeholders, often using accessible language before being translated into more detailed specifications.
REQUIREMENTS GATHERING
Requirements gathering techniques used in systems analysis.
Different techniques reveal different types of information. The choice depends on the users, organisation, system complexity and project context.
Interviews
Interviews allow analysts to explore user responsibilities, pain points, expectations and proposed improvements in detail. Structured, semi-structured and informal approaches can be useful in different circumstances.
Observation
Observing users performing real tasks can reveal practical details that may not be mentioned during interviews. This is particularly useful when analysing complex workflows or repetitive operational processes.
Questionnaires and surveys
Questionnaires can gather information from larger groups of users and can be useful when common requirements or perceptions need to be identified.
Workshops
Requirements workshops bring multiple stakeholders together to discuss processes, priorities, problems and proposed capabilities.
Document analysis
Existing forms, reports, policies, databases, manuals and system documentation can provide useful information about current processes and data requirements.
FEASIBILITY ANALYSIS
Feasibility study in Systems Analysis and Design.
A feasibility study helps determine whether a proposed information system is practical from technical, economic, operational and scheduling perspectives.
A technically attractive system may still be unsuitable if an organisation cannot afford it, lacks the required skills or cannot integrate it into existing operations. Feasibility analysis brings these considerations into the project before major resources are committed.
Technical Feasibility
Can the organisation access the required hardware, software, infrastructure, technical skills and integration capabilities?
Economic Feasibility
Are the expected benefits and organisational outcomes reasonable in relation to development, implementation and ongoing operating costs?
Operational Feasibility
Can the proposed system operate effectively within the organisation and be accepted and used by relevant stakeholders?
Schedule Feasibility
Can the system realistically be analysed, designed, developed and implemented within the required timeframe?
BUSINESS PROCESS ANALYSIS
Business process modelling and workflow analysis.
Understanding how work moves through an organisation is an important part of analysing information systems.
Business process analysis examines activities, decisions, information flows, participants and dependencies within an existing or proposed process.
The purpose is not simply to draw a workflow. Analysts need to understand why each activity exists, where information enters the process, where decisions occur and where delays, duplicate work or control problems may arise.
Process models can then provide a foundation for identifying automation opportunities, defining system requirements and designing improved workflows.
As-is and to-be process models
An as-is model represents the current process. A to-be model represents a proposed future process. Comparing the two can help identify what the proposed information system needs to change or support.
DATA FLOW DIAGRAMS
Data Flow Diagrams: context diagrams, Level 0 and detailed DFDs.
Data Flow Diagrams provide a structured way to represent how information moves through a system.
A Data Flow Diagram focuses on the movement and transformation of information. It commonly represents external entities, processes, data flows and data stores.
A context diagram provides a high-level representation of the system boundary. More detailed DFD levels can then decompose major processes into smaller processes and flows.
Context Diagram
The context diagram presents the system as a single process and shows the main external entities that exchange information with it.
Level 0 DFD
A Level 0 DFD expands the system into its major processes and provides more detail about data flows and data stores.
Lower-level DFDs
Individual processes can be decomposed further when additional detail is required. The objective is to maintain consistency between levels while providing useful detail.
Important modelling principle: a DFD should represent meaningful data movement rather than simply reproduce the visual structure of an application interface.
UML SYSTEMS ANALYSIS
UML diagrams used in Systems Analysis and Design.
Unified Modeling Language provides a common visual language for describing different structural and behavioural aspects of software and information systems.
Context Diagram
A context diagram provides a high-level view of the system and its interactions with external entities. It establishes the system boundary before more detailed process modelling is developed.
Data Flow Diagram
DFDs model how information moves between external entities, processes and data stores. Different levels can progressively represent greater detail.
Entity Relationship Diagram
ER diagrams model data entities and their relationships. They are particularly useful when analysing the information requirements of database-driven systems.
Use Case Diagram
Use case diagrams provide a high-level view of actors and the interactions they have with system functionality.
Class Diagram
Class diagrams describe classes, attributes, operations and relationships and are commonly used when modelling object-oriented systems.
Sequence Diagram
Sequence diagrams represent interactions between actors and system objects over time, helping clarify the order in which messages or operations occur.
Activity Diagram
Activity diagrams represent workflows and activities, making them useful for modelling business processes and system behaviour.
State Diagram
State diagrams describe how an object or system component moves between states in response to events or conditions.
USE CASE ANALYSIS
Use case modelling: understanding users and system functionality.
Use case analysis focuses on interactions between actors and the system and can provide a useful bridge between requirements and system design.
A use case represents a meaningful goal or interaction that an actor has with a system. Actors may represent human users, external systems or other entities that interact with the proposed solution.
Use case analysis can help clarify what the system is expected to provide without immediately prescribing how the functionality must be implemented.
Typical use case components
- Actor or stakeholder
- System boundary
- Use case
- Association between actor and use case
- Relevant relationships between use cases
- Detailed scenarios where required
Detailed use case descriptions can additionally document preconditions, main flows, alternative flows, exceptions and expected outcomes.
DATA MODELLING
Entity Relationship Diagrams and database design.
Data modelling identifies the information a system needs to store and the relationships between different data entities.
An Entity Relationship Diagram, or ERD, can be used during systems analysis to represent entities, attributes and relationships. This provides a conceptual view of the information requirements before detailed database implementation.
For example, a university information system might involve entities such as students, courses, enrolments and assessments. The exact model depends on the requirements of the particular system.
Database design can then progress from conceptual modelling to logical structures and, where appropriate, physical implementation decisions.
Important data-modelling considerations
- Identify meaningful entities.
- Define relevant attributes.
- Determine relationships between entities.
- Identify appropriate keys.
- Consider cardinality and relationship constraints.
- Check for redundancy and inconsistent data structures.
- Maintain consistency with system requirements.
SYSTEM ARCHITECTURE
From system requirements to system architecture and design.
System architecture describes the major components of a proposed solution and how those components interact.
Architecture decisions should be driven by system requirements rather than selected independently of the problem. Security, performance, availability, scalability, integration, data requirements and operational constraints can all influence the architecture.
Depending on the project, architecture discussions may include application components, databases, APIs, client interfaces, authentication services, external systems, networks and cloud infrastructure.
Logical and physical design
Logical design focuses on what the system needs to accomplish and how its components relate conceptually. Physical design moves closer to implementation and can specify technologies, infrastructure, deployment components and technical details.
Keeping these perspectives distinct can make system documentation easier to understand and allows requirements to be considered before implementation technology becomes the dominant focus.
USER INTERFACE & PROTOTYPING
System prototyping and user interface design.
Prototypes can help stakeholders visualise proposed functionality and provide feedback before a complete system is built.
Low-fidelity prototypes
Simple sketches, wireframes or paper prototypes can be used to explore page structure, navigation and workflow without investing heavily in implementation.
High-fidelity prototypes
More detailed interactive prototypes can represent interface behaviour and visual structure more closely and can be useful when stakeholder feedback needs to address specific interactions.
Requirements validation
Showing users an early representation can expose unclear or incomplete requirements before development costs become significant.
Usability considerations
Interface design should consider the needs, capabilities, workflows and expectations of intended users rather than focusing only on visual appearance.
DEVELOPMENT METHODOLOGIES
Waterfall, Agile, prototyping and iterative systems development.
Systems Analysis and Design can be performed using different development methodologies. The appropriate approach depends on project requirements, uncertainty, stakeholders and organisational context.
Waterfall
A sequential development approach in which major stages are generally planned and completed in an ordered progression.
Agile
An iterative approach that emphasises incremental delivery, collaboration, feedback and adaptation as project understanding develops.
Prototyping
An approach that uses early representations of the proposed system to explore requirements, interfaces and user expectations.
Iterative Development
The system evolves through repeated cycles of analysis, design, development, testing and feedback.
Agile and Systems Analysis
Agile environments do not eliminate analysis and design. Instead, analysis and design activities may be performed incrementally as understanding develops and requirements are refined through stakeholder feedback.
Waterfall and Systems Analysis
In a more sequential approach, substantial analysis and requirements documentation may take place before later development stages. This can provide structure when requirements are sufficiently understood and stable.
SYSTEM TESTING
Testing as part of system analysis, design and implementation.
Testing provides evidence about whether the implemented system behaves as expected and satisfies documented requirements.
Testing should not be treated as an activity that begins only after development is finished. Requirements should be sufficiently clear and testable so that the project team can determine whether the final system meets expectations.
Depending on the system, testing may include functional testing, integration testing, usability testing, security testing, performance testing, system testing and user acceptance testing.
Traceability between requirements and testing
Requirements can provide a basis for test cases. If a documented requirement cannot be tested or verified, it may need greater precision. Traceability helps connect requirements, design decisions and test evidence.
IMPLEMENTATION
System implementation, deployment and change management.
A technically complete system still needs to be introduced into its operational environment in a controlled way.
Implementation may involve data migration, infrastructure configuration, software deployment, user training, documentation, integration with existing systems and operational support.
Organisations may also need to consider how the transition from an existing system to a new system will occur. Depending on risk and project requirements, approaches can include direct changeover, phased implementation, pilot deployment or parallel operation.
Change management can be important because users may need to understand new workflows, responsibilities and system capabilities before adoption can be successful.
SYSTEM MAINTENANCE
Maintenance and continuous improvement after deployment.
Information systems continue to evolve after implementation because organisations, technologies, regulations, users and business requirements change.
Corrective maintenance
Addresses defects or errors discovered after deployment.
Adaptive maintenance
Adapts the system to changes in its operating environment, technologies, regulations or organisational context.
Perfective maintenance
Improves functionality, usability, performance or other characteristics in response to evolving needs.
Preventive maintenance
Reduces the likelihood of future problems by improving maintainability, reliability or underlying system components.
SYSTEM DOCUMENTATION
Documentation in Systems Analysis and Design projects.
Clear documentation creates a shared reference for stakeholders, analysts, designers, developers, testers and future maintenance teams.
Documentation requirements vary according to the project and methodology. A small application may need relatively limited documentation, while a complex organisational information system may require extensive technical and business documentation.
Common Systems Analysis and Design documentation
- Problem definition and project scope
- Stakeholder analysis
- Feasibility study
- Requirements specification
- Functional and non-functional requirements
- Business process models
- Data Flow Diagrams
- Entity Relationship Diagrams
- UML diagrams
- System architecture documentation
- Interface specifications
- Database design documentation
- Test plans and test cases
- Implementation and deployment documentation
- User and operational documentation
CASE TOOLS
CASE tools and software used for systems analysis and design.
Computer-Aided Software Engineering tools can support modelling, documentation, requirements management and other activities across the system development process.
CASE tools can help analysts and designers create and maintain models, diagrams and project documentation. Depending on the tool, capabilities may include UML modelling, database modelling, requirements management, process modelling, versioning and documentation generation.
The value of a CASE tool is not simply its ability to produce attractive diagrams. Effective use depends on whether the models accurately represent requirements and remain consistent with the system being analysed.
Diagramming and modelling software can therefore be considered part of the broader Systems Analysis and Design toolkit rather than a replacement for analysis itself.
SYSTEMS ANALYSIS PROJECTS
Common Systems Analysis and Design project areas.
Systems Analysis and Design projects often combine requirements analysis, process modelling, data modelling and system design into one integrated case.
A typical academic or practical systems analysis project may begin with a business scenario such as a retail system, healthcare information system, university management system, hotel reservation system, library system, banking application, inventory system or appointment platform.
The project can then require the analyst to investigate the current situation, identify stakeholders, define system requirements, conduct a feasibility study and produce appropriate process and data models.
Depending on the project requirements, the design phase may include use cases, UML diagrams, DFDs, ER diagrams, database design, system architecture, interface prototypes and test specifications.
A useful project structure
- Define the problem and project scope.
- Identify stakeholders and users.
- Investigate the existing process.
- Gather and analyse requirements.
- Evaluate feasibility.
- Model processes and information flows.
- Develop data and UML models.
- Design the proposed system architecture.
- Develop interface or system prototypes where required.
- Define testing and implementation considerations.
- Document assumptions, limitations and recommendations.
SYSTEMS ANALYSIS & DESIGN ACADEMIC WORK
Approaching Systems Analysis and Design assignments and projects.
Systems Analysis and Design coursework often requires students to combine theoretical understanding with practical modelling and documentation.
Academic assignments in Systems Analysis and Design may ask students to analyse a scenario, identify requirements, create diagrams, compare methodologies, evaluate system alternatives or design a proposed information system.
A useful approach is to begin with the assessment question and scenario before selecting modelling techniques. Not every project requires every UML diagram or every possible framework.
The diagrams and models should support the analysis. For example, a DFD should communicate information flows, an ERD should communicate data relationships and a use case diagram should communicate actors and system functionality.
Consistency is particularly important. Requirements, diagrams, database models, interface designs and testing expectations should describe the same proposed system rather than separate interpretations of it.
QUALITY CHECKLIST
Systems Analysis and Design checklist.
Before finalising a systems analysis or design project, check that the major artefacts remain consistent and traceable.
The problem statement clearly explains the issue being addressed.
The system scope is clearly defined.
Relevant stakeholders and users have been identified.
Functional requirements are clear and testable.
Non-functional requirements are specific enough to evaluate.
Feasibility considerations are supported by reasonable evidence.
Process models represent the intended workflow accurately.
Data models are consistent with system requirements.
UML diagrams use consistent terminology.
Use cases correspond to meaningful system functionality.
The proposed architecture addresses relevant requirements.
Interface designs are consistent with user requirements.
Testing considerations can be traced back to requirements.
Implementation assumptions and constraints are documented.
Recommendations are supported by the analysis.
RELATED TECHNOLOGY TOPICS
Systems Analysis and Design connects with several areas of computing.
The systems analysis process often overlaps with databases, programming, software engineering, networking, cybersecurity and information systems.
SYSTEMS ANALYSIS & DESIGN FAQ
Frequently asked questions.
Common questions about Systems Analysis and Design, SDLC, requirements, modelling, UML, DFDs and system design.
What is Systems Analysis and Design?
Systems Analysis and Design is the structured process of understanding an existing or proposed information system, identifying requirements, analysing business and user needs, designing a solution and planning its implementation and maintenance.
What are the main phases of Systems Analysis and Design?
The exact phases depend on the methodology, but common activities include system investigation, requirements analysis, feasibility analysis, system design, implementation, testing, deployment and maintenance.
What is the difference between systems analysis and systems design?
Systems analysis focuses primarily on understanding the problem, business processes, users, requirements and constraints. Systems design uses those findings to determine how the proposed system, data, interfaces, components and technical architecture should work.
What is requirements engineering?
Requirements engineering is the systematic process of discovering, analysing, documenting, validating and managing requirements for a system.
What is a Data Flow Diagram?
A Data Flow Diagram, or DFD, represents how data moves through a system. It commonly shows external entities, processes, data flows and data stores at different levels of detail.
What are UML diagrams used for in Systems Analysis and Design?
UML diagrams provide standardised ways to model different aspects of a system. Common diagrams include use case, class, sequence, activity and state diagrams.
What is a feasibility study in systems analysis?
A feasibility study evaluates whether a proposed system is practical and worthwhile from perspectives such as technical capability, economic cost, operational suitability and implementation schedule.
What is the difference between Agile and Waterfall?
Waterfall generally follows a more sequential development structure, while Agile uses iterative development and encourages repeated feedback and adaptation. The appropriate approach depends on the project context and requirements.
Why are prototypes used in system design?
Prototypes provide an early representation of a proposed system or interface. They can help stakeholders visualise requirements, identify usability issues and provide feedback before full implementation.
What documentation is produced during Systems Analysis and Design?
Documentation varies by project and methodology but may include requirements specifications, feasibility reports, process models, DFDs, UML diagrams, data models, interface designs, architecture documentation, test plans and implementation documentation.
PROJECTASSIGNMENTS
A practical Systems Analysis and Design knowledge hub.
Use this resource to understand the concepts, models, methodologies and documentation techniques commonly encountered in Systems Analysis and Design projects.
Systems Analysis and Design works best when each activity contributes to the same overall understanding of the system. Requirements should inform models, models should support design, design should address requirements and testing should provide evidence that the implemented system satisfies those requirements.
Whether the project involves a small information system, a database-driven application or a larger organisational platform, the underlying principle remains the same: understand the problem carefully before deciding how the technology should work.
Let's make your work clearer
Bring us the difficult part.
Tell us what you're researching, building, or trying to understand. We'll help you find the clearest ethical next move.