Systems Analysis, Requirements and Solution Architecture

Introduction and Context

Information systems succeed when they solve a real organisational problem, fit their operating environment, and can be maintained over time. Technical implementation is therefore only one part of systems development. Before software is designed or purchased, analysts must understand the current situation, identify stakeholder needs, evaluate alternatives, model processes and information, and select an architecture that is feasible, secure and adaptable.

Systems analysis is the disciplined investigation of an organisation, its problems, opportunities, processes, information and constraints. Requirements engineering transforms that investigation into an agreed description of what a solution must do and the qualities it must possess. Solution architecture then provides the high-level structure through which the requirements will be realised. These activities are interdependent: an incomplete requirement can produce an unsuitable architecture, while an inappropriate architecture can make valid requirements expensive or impossible to satisfy.

This chapter considers the systems development life cycle, requirements elicitation and analysis, feasibility, process and data modelling, architectural patterns, prototyping, evaluation, governance and professional practice.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Compare major systems development life-cycle models and select an appropriate approach.
2. Identify stakeholders and elicit, analyse, specify, validate and manage requirements.
3. Conduct technical, economic, operational, legal, schedule and organisational feasibility analysis.
4. Model business processes and data using appropriate notation.
5. Explain common solution architecture patterns and evaluate their trade-offs.
6. Use prototypes and structured evaluation to reduce uncertainty and improve solution quality.
7. Recognise ethical, security, privacy and governance responsibilities in systems analysis.

1. Systems Development as a Socio-Technical Activity

A system comprises people, processes, technology, information and organisational arrangements. A payroll system, for example, is not merely a database and application. It includes payroll officers, employees, approval rules, tax regulations, source data, interfaces with banking services and procedures for correcting errors.

This perspective is socio-technical because system outcomes arise from interactions between technical components and human or organisational factors. A technically efficient system may fail if users do not trust it, if responsibilities are unclear, or if it conflicts with established work practices. Analysis must therefore address both the formal requirements of the organisation and the social context in which the system will operate.

Systems analysis and systems design

Systems analysis focuses primarily on understanding the problem domain and determining what the system must achieve. Systems design focuses on deciding how those needs will be implemented. In practice, the boundary is iterative rather than absolute. Architectural constraints may expose unrealistic requirements, and analysis may change after users see a prototype.

A useful distinction is:

2. Life-Cycle Models

A life-cycle model organises activities used to develop, deploy and maintain an information system. No model is universally best. Selection depends on requirement stability, risk, regulatory obligations, stakeholder availability, technical uncertainty and the cost of change.

Predictive or waterfall development

In a predictive model, major activities are planned sequentially: feasibility and planning, requirements, design, implementation, testing, deployment and maintenance. Reviews or approvals occur between stages. This approach can be appropriate where requirements are stable, interfaces are tightly controlled, evidence must be documented, or contractual and regulatory approval is significant.

Its strengths include clear milestones, predictable governance and extensive documentation. Its weaknesses include delayed user feedback and the risk that assumptions discovered late will be expensive to change. A signed requirements document does not guarantee that requirements are correct.

Iterative and incremental development

Iterative development revisits analysis, design and implementation repeatedly. Incremental development delivers the system in usable portions. For example, a student information system might first deliver enrolment, then fees, then reporting. Each increment can produce feedback and operational value.

These approaches reduce the risk of building the wrong product, but they require disciplined prioritisation, a sustainable architecture and ongoing stakeholder involvement. Iteration is not an excuse for absent documentation or uncontrolled scope.

Agile approaches

Agile development emphasises frequent delivery, customer collaboration, responding to change and working software. Scrum, Kanban and extreme programming are examples of approaches associated with agile practice, although organisations often adapt them. Product backlogs, short planning cycles, reviews and retrospectives provide mechanisms for learning.

Agile is particularly useful when needs are uncertain or changing. However, agile projects still need architecture, security, data governance, release planning and compliance evidence. “Agile” does not mean that analysis is unnecessary; it means that analysis is performed continuously and at an appropriate level of detail.

Spiral and risk-driven development

The spiral model organises development around repeated risk analysis. Each cycle identifies objectives, evaluates alternatives, addresses the highest risks through prototypes or experiments, and plans the next cycle. It is valuable for complex or high-risk systems, but it can be costly and requires strong risk-management expertise.

DevOps and continuous delivery

DevOps integrates development, operations, testing, security and monitoring. Automated build pipelines, infrastructure as code, deployment automation and operational feedback support frequent releases. DevOps extends the life cycle beyond delivery: reliability, observability, incident response and continuous improvement become design concerns.

Selecting a model

Selection should be justified rather than based on fashion. A useful decision considers:

• stability and clarity of requirements;
• consequences of failure;
• technical novelty and integration risk;
• need for early business value;
• stakeholder availability;
• regulatory and audit requirements;
• team capability and supplier arrangements; and
• cost of changing the design after implementation.

A hybrid approach is often realistic: predictive governance and architecture decisions may coexist with iterative development of user-facing features.

3. Stakeholders and Requirements Engineering

A stakeholder is an individual, group or institution that affects, is affected by, or believes it may be affected by the system. Stakeholders can include customers, operational users, managers, administrators, suppliers, regulators, auditors, security personnel and people indirectly affected by automated decisions.

Stakeholder analysis identifies interests, influence, knowledge and possible conflicts. A powerful executive may approve funding but know little about daily work; a front-line employee may understand exceptions that are invisible to management. Both perspectives matter.

Types of requirements

Business requirements state organisational goals, such as reducing claim-processing time or meeting a reporting obligation.

User requirements describe capabilities from a user or role perspective, often in natural language.

Functional requirements specify behaviours or services. For example, “The system shall allow an authorised officer to suspend an account and record a reason.”

Non-functional requirements describe qualities or constraints. Examples include availability, response time, accessibility, maintainability, privacy, auditability and interoperability.

Transition requirements concern migration, training, data conversion and coexistence with a legacy system.

A requirement should be necessary, unambiguous, feasible, testable, traceable and prioritised. “The system shall be user-friendly” is weak because it does not define a measurable quality. “At least 95% of trained users shall complete the standard registration task without assistance in usability testing” is more testable, although the measurement method and context must be specified.

Elicitation techniques

No single technique reveals every requirement.

• Interviews provide depth and allow probing, but may reflect personal bias.
• Workshops create shared understanding and expose conflicts quickly, but require skilled facilitation.
• Observation and contextual inquiry reveal workarounds and tacit knowledge that participants may omit in interviews.
• Document analysis identifies rules, forms, policies, reports and legacy assumptions.
• Surveys efficiently gather broad views, but usually provide less detail.
• Focus groups explore attitudes and language, though dominant participants can distort results.
• Scenarios and use cases describe interactions between actors and the system.
• Prototypes enable users to react to concrete examples.
• Process mining and system logs can reveal actual behaviour where reliable event data exists.

Elicitation should include accessibility considerations. A remote workshop, for instance, may exclude people with limited connectivity or disabilities unless alternatives are provided.

Analysing and prioritising requirements

Analysis resolves ambiguity, identifies dependencies, detects contradictions and separates needs from preferred solutions. Asking “Why is this needed?” can uncover the underlying business outcome and prevent premature commitment to a particular technology.

Prioritisation methods include the MoSCoW scheme: Must have, Should have, Could have and Won’t have for the current release. Priority should also consider risk, value, regulatory necessity, dependency and implementation effort. A requirement marked “must” should have a defensible reason, not merely a senior sponsor’s preference.

A requirements traceability matrix links business objectives to requirements, design elements, tests and acceptance evidence. Traceability supports impact analysis when a requirement changes and helps demonstrate coverage during audits.

Validation

Requirements validation asks whether the documented requirements describe the right system and whether they are expressed well. Reviews should check completeness, consistency, feasibility, verifiability, security, privacy, accessibility and exception handling. Stakeholders should review realistic scenarios, not only isolated statements.

Acceptance criteria define observable conditions for accepting a feature. A useful criterion identifies the context, action and expected result. For example: given a valid customer account, when an authorised officer changes the address, then the system records the old and new values, the officer identity and the timestamp.

4. Feasibility and the Business Case

Feasibility analysis prevents an organisation from committing prematurely to an attractive but impractical solution. It should compare realistic alternatives, including improving the current system or changing the process without new software.

Costs include acquisition, development, integration, migration, training, support, infrastructure, licences and change management. Benefits may be financial, service-related, risk-reducing or strategic. Benefits should not be counted as certain merely because a system is installed.

A simple return-on-investment measure is:

Here, benefits and costs must be measured over the same period and in consistent monetary units. This simple measure ignores the timing of cash flows and is therefore unsuitable as the only investment criterion. Where timing matters, discounted cash-flow analysis may be used. With discount rate r and net cash flow CF_t in period t, net present value is:

The assumptions are that cash flows are estimated for defined periods, r represents the relevant discount rate, and the timing convention is consistent. A positive NPV indicates value under the stated assumptions, not a guarantee of success. Intangible benefits, uncertainty and distributional effects should be reported separately.

Sensitivity analysis tests how a conclusion changes if costs, adoption, benefits or delivery time differ from estimates. Scenario analysis can compare optimistic, expected and adverse conditions. Feasibility reports should make assumptions visible rather than presenting false precision.

5. Process Modelling

Process models represent work, decisions, events, actors and information flows. They provide a common language for discovering inefficiency and defining the scope of a system.

A context diagram shows the system as a single process and identifies external entities and major information flows. A data-flow diagram decomposes a system into processes, data stores, external entities and flows. The model should maintain balancing: flows entering or leaving a decomposed process should correspond to flows at the higher level unless a justified refinement is documented.

Business Process Model and Notation (BPMN) represents events, activities, gateways, sequence flows, message flows and pools or lanes. Pools can represent participants, while lanes can represent roles or departments. BPMN distinguishes sequence flow within a participant from message flow between participants. This distinction avoids implying that an external organisation is directly controlled by the process being modelled.

A process model should show normal and exceptional paths. For example, an order process may include payment rejection, stock shortage, cancellation and duplicate submission. Ignoring exceptions produces an incomplete design and often shifts complexity to manual workarounds.

Process analysis can identify delays, duplication, bottlenecks, unnecessary approvals and control weaknesses. “As-is” models describe current practice; “to-be” models describe a proposed future state. The gap between them informs requirements, migration and change management.

6. Data Modelling and Information Quality

Data modelling identifies entities, attributes, relationships, constraints and ownership. An entity represents a relevant class of object, such as Student, Invoice or Asset. An attribute describes an entity, while a relationship describes an association between entities.

In an entity–relationship model, cardinality expresses how many instances may participate. A student may enrol in many courses, and a course may have many students; this many-to-many relationship normally requires an associative entity such as Enrolment. Primary keys identify records, while foreign keys connect related records and support referential integrity.

Normalisation reduces unnecessary duplication and update anomalies. In simplified terms, first normal form requires atomic values rather than repeating groups; further normal forms separate attributes that depend on something other than the key. Normalisation is not an absolute rule: carefully justified denormalisation may improve read performance, provided consistency and update controls are maintained.

Data quality includes accuracy, completeness, consistency, timeliness, validity, uniqueness and fitness for purpose. A technically correct database can still contain poor data if definitions differ across departments. Data dictionaries, ownership roles, validation rules, retention schedules and lineage documentation support governance.

Privacy-by-design requires analysts to consider purpose limitation, data minimisation, access control, transparency, retention and individual rights from the beginning. Sensitive data should not be collected simply because storage is inexpensive.

7. Solution Architecture

Solution architecture describes the significant structures and relationships of a proposed system. It addresses components, interfaces, data, deployment, security, operational qualities and design constraints. Architecture decisions should be recorded with their rationale, alternatives considered and consequences.

A common layered architecture separates presentation, application or service, domain logic and data access. Layering can improve maintainability and testability by controlling dependencies. However, excessive layers may add complexity and latency. A system should not be called layered merely because its code is stored in folders; dependencies and responsibilities must actually be governed.

A client–server architecture separates requesting clients from services that provide data or processing. Web applications commonly use browsers or mobile clients, application services and databases. Security boundaries, authentication, authorisation, input validation and failure handling must be explicit.

Service-oriented architecture organises capabilities as services with defined contracts. Microservices take this idea further by creating independently deployable services, often aligned with business capabilities and owning their data. Microservices can support independent scaling and team autonomy, but introduce distributed-systems problems: network failure, latency, versioning, observability, data consistency and operational overhead. They are not automatically superior to a modular monolith.

Event-driven architecture uses events to communicate that something has happened, such as PaymentAccepted. Producers and consumers are decoupled in time or location, which can support integration and responsiveness. Designers must address duplicate delivery, ordering, schema evolution, replay, monitoring and the difference between an event and a command.

Cloud architecture can provide elastic infrastructure and managed services, but it does not remove responsibility for identity, configuration, data protection, resilience, cost control or supplier dependency. Architecture decisions should be based on requirements and risk rather than branding.

Figure: A conceptual layered architecture. Real systems may include cross-cutting security, monitoring and governance across all layers.

Cross-cutting concerns include identity and access management, encryption, logging, monitoring, configuration, error handling, backup, recovery and accessibility. Quality attributes should be expressed as scenarios. For example: “When 500 concurrent users submit a search, 95% of responses shall be returned within two seconds under the specified test environment.” The load, percentile, operation and environment must be defined for the statement to be meaningful.

Architecture evaluation compares alternatives against weighted drivers such as security, performance, resilience, maintainability, interoperability, cost and time to market. The best architecture is not the one with the most fashionable components; it is the one that provides an acceptable balance for the context.

8. Prototyping and Solution Evaluation

A prototype is a deliberately incomplete representation used to learn. A throwaway prototype explores an idea and is discarded. An evolutionary prototype is progressively refined into the solution. A proof of concept tests technical feasibility, such as whether a legacy interface can exchange data securely. A clickable interface prototype explores navigation and terminology without implementing real transactions.

Prototypes reduce ambiguity, but they can create false confidence. Users may assume that a visually polished screen is nearly complete, while developers may accidentally treat experimental code as production code. Prototype purpose, fidelity, limitations and disposal or transition plan should be explicit.

Evaluation should combine several forms of evidence:

• requirements-based testing checks specified behaviour;
• usability evaluation examines effectiveness, efficiency and satisfaction;
• security assessment identifies vulnerabilities and misuse cases;
• performance and resilience testing examines behaviour under defined conditions;
• accessibility testing combines automated checks with user evaluation;
• operational readiness assessment examines support, monitoring, backup and recovery;
• pilot or A/B evaluation examines outcomes in a controlled operational context.

Evaluation criteria should be established before results are observed where possible. Measures may include task completion, error rate, processing time, adoption, service availability, data quality and user satisfaction. Qualitative feedback explains why a result occurred; quantitative measures help compare alternatives. Neither should be interpreted without context.

9. Illustrative Case: Community Health Appointment Service

Background. A regional health provider uses telephone booking and several disconnected spreadsheets. Patients experience long waits, staff duplicate records, and managers cannot reliably measure missed appointments. This is an illustrative case, not a report of a real organisation.

Problem. The provider wants online and staff-assisted booking while protecting sensitive health information. Stakeholders include patients, receptionists, clinicians, managers, IT operations, accessibility advisers, privacy officers and external messaging suppliers.

Analysis. Interviews and observation reveal that appointment types have different durations, clinicians have changing availability, and urgent cases must not enter the ordinary queue. Document analysis identifies retention and consent obligations. A process model shows duplicate entry between booking and reminder activities. Requirements are prioritised using risk and value: secure identity verification, appointment availability, cancellation, audit logging and accessibility are release-critical; advanced predictive reminders are deferred.

Approach and solution. An iterative delivery model is selected because user needs and terminology require feedback, while formal security and privacy gates remain predictive. A modular service architecture is chosen rather than microservices because the team is small and transaction boundaries are closely related. The design includes role-based access, encrypted communication, an audit trail, a canonical patient identifier, validation of appointment rules and an integration boundary for messaging. A low-fidelity prototype is tested with patients using assistive technologies before implementation.

Evaluation and outcome. Acceptance tests cover booking, cancellation, conflicting appointments, unauthorised access and message failure. A pilot measures booking completion, call-centre volume, duplicate-record rate and accessibility issues. The service is not declared successful solely because it has been deployed: operational and patient outcomes are reviewed after release. If reminders reduce missed appointments but increase privacy complaints, the design must be reassessed.

Learning points. The case demonstrates that stakeholder diversity improves requirements, process modelling exposes organisational problems, architecture must reflect team capability and risk, and evaluation must include social and operational outcomes as well as technical correctness.

10. Professional, Ethical and Governance Considerations

Analysts exercise influence over what is recorded, automated and made visible. They must represent stakeholder evidence honestly and disclose uncertainty. Requirements should not be manipulated to justify a predetermined product.

Security should be addressed throughout the life cycle. Threat modelling considers assets, actors, trust boundaries, attack paths and controls. Least privilege, secure defaults, strong authentication, secrets management, patching and logging are architectural concerns, not final-stage additions. Personal data requires lawful and transparent handling under applicable privacy and data-protection obligations. Organisations must also consider records management, accessibility law, intellectual property, contractual responsibilities and sector-specific regulation.

Automated or AI-supported decisions require particular care. Training data may reproduce historical bias; explanations may be inadequate; outputs can be confidently wrong; and accountability can become unclear. Analysts should document purpose, data provenance, human oversight, validation, monitoring and appeal mechanisms. Generative AI can assist with drafts, classification or prototype content, but confidential information must not be exposed to unauthorised services, and generated requirements or code require expert verification.

Contemporary practice increasingly treats architecture as a living set of decisions. Infrastructure automation, platform engineering, zero-trust security, API governance, event streaming and responsible AI are useful only when connected to explicit organisational needs. Continuous monitoring can reveal drift in performance, data quality or model behaviour, enabling the life cycle to continue after deployment.

Best-Practice Checklist

1. Define the problem and desired outcomes before selecting technology.
2. Establish scope, assumptions, constraints and decision authority.
3. Involve diverse stakeholders, including users with accessibility needs.
4. Record functional, non-functional, transition and regulatory requirements.
5. Make requirements testable, prioritised and traceable.
6. Model both normal and exceptional processes.
7. Establish data ownership, quality rules, privacy controls and retention.
8. Compare architectural alternatives and document trade-offs.
9. Prototype uncertain or high-risk aspects early.
10. Evaluate usability, security, performance, resilience and operational readiness.
11. Treat deployment as a transition into monitored operation, not the end of analysis.
12. Revisit assumptions when evidence, regulation or organisational conditions change.

Chapter Summary

Systems analysis investigates organisational problems and opportunities before implementation. Requirements engineering identifies stakeholders, elicits and validates needs, and manages change through prioritisation and traceability. Life-cycle models range from predictive approaches to iterative, agile, spiral and DevOps practices; selection should reflect uncertainty, risk, regulation and organisational capability.

Feasibility analysis examines technical, economic, operational, schedule, legal and organisational dimensions. Process models reveal work, decisions and exceptions, while data models define entities, relationships, constraints and quality responsibilities. Solution architecture organises components and addresses quality attributes, security, integration and operational concerns. Layered, client–server, service-oriented, event-driven, cloud and modular architectures each involve trade-offs.

Prototypes support learning but require controlled interpretation. Evaluation must address requirements, usability, security, performance, accessibility and operational readiness. Ethical practice requires privacy, fairness, transparency, accountability and honest communication of uncertainty. Effective systems development is therefore a managed learning process connecting people, processes, information and technology.

Key Terms

Systems analysis: Investigation of a system, its context, problems, opportunities and requirements.

Requirements engineering: The systematic elicitation, analysis, specification, validation and management of requirements.

Stakeholder: A person or organisation that affects, is affected by, or has an interest in a system.

Functional requirement: A required behaviour, service or capability of a system.

Non-functional requirement: A quality attribute, constraint or performance expectation.

Traceability: The ability to link requirements to objectives, design, implementation and tests.

Feasibility analysis: Evaluation of whether a proposed solution is practical and worthwhile.

Life-cycle model: A framework for organising system development and operation activities.

Iterative development: Repeated cycles of analysis, design, implementation and feedback.

Prototype: An incomplete representation created to explore, communicate or test an idea.

Process model: A representation of activities, events, decisions, roles and flows.

BPMN: Business Process Model and Notation for representing business processes.

Entity–relationship model: A representation of data entities, attributes and relationships.

Cardinality: The number of instances that may participate in a relationship.

Architecture pattern: A reusable high-level approach to structuring a solution.

Layered architecture: An architecture that separates responsibilities into controlled layers.

Event-driven architecture: An architecture in which components communicate through events.

Quality attribute: A property such as security, performance, availability or maintainability.

Acceptance criteria: Observable conditions used to determine whether a requirement is satisfied.

Privacy by design: Incorporating privacy protection into system design from the beginning.

Review Questions

Short Answer Questions

1. What is the difference between systems analysis and systems design?
2. State two advantages and two limitations of predictive development.
3. Distinguish a functional requirement from a non-functional requirement.
4. What is the purpose of a requirements traceability matrix?
5. Why should process models include exceptional paths?

Long Answer Questions

1. Compare predictive, iterative, agile and spiral life-cycle models. Recommend a model for a safety-critical system with uncertain user needs and justify your decision.
2. Explain a complete requirements engineering process from stakeholder identification through validation and change management.
3. Discuss the dimensions of feasibility analysis and explain why a positive financial return alone does not establish feasibility.
4. Compare layered, modular monolith, microservices and event-driven architectures, including their principal trade-offs.
5. Explain how privacy, security, accessibility and ethical accountability should influence analysis and architecture.

Analytical / Application Questions

1. A university wants to replace paper-based examination appeals with an online service. Identify the principal stakeholders, propose five functional and five non-functional requirements, and describe two elicitation techniques you would use.
2. A proposed system costs $120,000 and is expected to produce benefits of $180,000 over the evaluation period. Calculate the simple ROI using the formula in this chapter, then identify two important limitations of that result.
3. A small organisation is considering microservices because a supplier describes them as modern and scalable. Analyse whether that is sufficient justification. Recommend an architecture-selection process and identify evidence the organisation should gather before deciding.

Multiple Choice Questions with Answers

Question 1

Which activity primarily determines what a proposed system must achieve?

A. Requirements analysis

B. Physical database tuning

C. Server procurement

D. Release packaging

Correct Answer: A. Requirements analysis

Question 2

Which requirement is most clearly non-functional?

A. The system shall create an invoice

B. The system shall allow a manager to approve leave

C. The system shall return 95% of searches within two seconds under the specified load

D. The system shall send a cancellation message

Correct Answer: C. The system shall return 95% of searches within two seconds under the specified load

Question 3

What is a principal purpose of a prototype?

A. To guarantee production security

B. To reduce uncertainty and obtain feedback

C. To replace all acceptance testing

D. To eliminate the need for requirements

Correct Answer: B. To reduce uncertainty and obtain feedback

Question 4

Which feasibility dimension asks whether users, processes and support arrangements can make a solution work?

A. Technical feasibility

B. Operational feasibility

C. Schedule feasibility

D. Economic feasibility

Correct Answer: B. Operational feasibility

Question 5

In a many-to-many relationship between Student and Course, what is commonly introduced?

A. A gateway

B. A message queue only

C. An associative entity such as Enrolment

D. A presentation layer

Correct Answer: C. An associative entity such as Enrolment

Question 6

What distinguishes message flow from sequence flow in BPMN?

A. Message flow represents communication between participants

B. Message flow is used only for database tables

C. Sequence flow always crosses organisational boundaries

D. Sequence flow cannot represent decisions

Correct Answer: A. Message flow represents communication between participants

Question 7

Which architecture pattern commonly communicates that something has happened?

A. Event-driven architecture

B. Waterfall architecture

C. Entity–relationship architecture

D. Prototype architecture

Correct Answer: A. Event-driven architecture

Question 8

Using ROI = (benefits − costs) ÷ costs × 100%, what is the ROI for benefits of $180,000 and costs of $120,000?

A. 20%

B. 33.3%

C. 50%

D. 66.7%

Correct Answer: C. 50%

Question 9

Which statement about microservices is most accurate?

A. They remove the need for monitoring

B. They are always cheaper than a monolith

C. They can increase independent deployment but add distributed-systems complexity

D. They prevent all data-consistency problems

Correct Answer: C. They can increase independent deployment but add distributed-systems complexity

Question 10

Which practice best reflects privacy by design?

A. Collecting all potentially useful data indefinitely

B. Considering purpose limitation, minimisation and retention during design

C. Adding a privacy notice only after deployment

D. Allowing every employee to access personal data

Correct Answer: B. Considering purpose limitation, minimisation and retention during design