Systems Analysis and Software Development

Introduction

Information systems rarely fail because programmers cannot write code. They fail more often because the organization has misunderstood the problem, stakeholders have conflicting expectations, technical constraints were ignored, or changes were managed poorly. Systems analysis and software development provide disciplined ways to understand organizational needs, define requirements, design solutions, construct software, and sustain it after deployment.

Systems analysis examines a business problem or opportunity and determines how information, people, processes, and technologies should work together. Software development is the organized creation, testing, deployment, and maintenance of software that supports those needs. Although analysis and development are often described as separate activities, they are closely connected. An analyst translates business concerns into system requirements, while developers transform validated requirements into an operational product.

This chapter considers the full development lifecycle. It compares predictive, iterative, Agile, and DevOps approaches; explains requirements engineering and process modelling; examines feasibility, design, testing, deployment, documentation, maintenance, and change management; and discusses professional, ethical, security, and governance responsibilities.

Learning Objectives

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

1. Identify stakeholders and distinguish business, functional, non-functional, and transition requirements.
2. Analyse processes and model systems using appropriate techniques.
3. Evaluate predictive, iterative, Agile, and DevOps lifecycles.
4. Conduct technical, economic, operational, legal, and schedule feasibility analysis.
5. Explain the relationship among architecture, interface, data, security, and software design.
6. Develop a coherent approach to testing, deployment, documentation, maintenance, and change control.
7. Analyse ethical, accessibility, privacy, security, and governance implications.
8. Apply systems-analysis concepts to a realistic organizational case.

1. Systems Thinking and the Role of the Analyst

A system is a set of interacting components that transforms inputs into outputs within an environment. An information system normally includes people, procedures, data, hardware, software, communications, and controls. A software application is therefore only one part of a larger sociotechnical system.

Systems thinking emphasizes relationships rather than isolated features. For example, an online student-registration system is affected by academic rules, identity management, payment services, timetable data, staff procedures, and privacy obligations. Improving one component may create problems elsewhere. A faster registration interface is not beneficial if it permits invalid enrolments or overloads a downstream database.

The systems analyst performs several related roles:

• Investigator: discovers how work is currently performed and why problems occur.
• Facilitator: helps stakeholders reach a shared understanding.
• Modeller: represents processes, data, actors, and system boundaries.
• Translator: converts business language into precise requirements.
• Evaluator: compares solution options and identifies risks.
• Change agent: supports organizational adoption and continuous improvement.

A good analyst does not simply record what users first request. The analyst investigates the underlying objective. “Add another report” may reflect a deeper problem involving unreliable data, unclear performance measures, or inefficient decision-making.

2. Stakeholders and Requirements Engineering

2.1 Stakeholder identification

A stakeholder is a person, group, or organization that affects, is affected by, or has an interest in the system. Stakeholders may include customers, operational employees, managers, system owners, suppliers, regulators, auditors, security personnel, support teams, and members of the public.

Stakeholder analysis should identify:

• interests and desired outcomes;
• authority and decision-making power;
• knowledge of current processes;
• likely benefits and losses;
• accessibility and inclusion needs;
• conflicts with other stakeholder groups; and
• communication and participation requirements.

A power–interest matrix is a useful practical tool. High-power, high-interest stakeholders require close management; high-power, low-interest stakeholders should be kept satisfied; low-power, high-interest stakeholders should be kept informed; and low-power, low-interest stakeholders should be monitored. The matrix is not a substitute for judgement: marginalized users may have low formal power but high ethical importance.

2.2 Types of requirements

A business requirement states an organizational goal, such as reducing average loan-processing time. A user requirement expresses what a user needs to accomplish. A functional requirement specifies a capability or behaviour, such as “The system shall allow an authenticated applicant to upload a PDF document.” A non-functional requirement specifies a quality or constraint, such as performance, security, reliability, accessibility, or legal compliance.

Other useful categories include:

• Data requirements: entities, attributes, quality, retention, ownership, and permitted use.
• Interface requirements: interactions with users, devices, or external systems.
• Transition requirements: data migration, training, conversion, and temporary parallel operation.
• Constraint requirements: mandated technologies, standards, budgets, policies, or regulations.
• Acceptance criteria: observable conditions that determine whether a requirement is satisfied.

A requirement should be clear, necessary, feasible, testable, traceable, and prioritized. Ambiguous terms such as “fast,” “user-friendly,” or “secure” should be converted into measurable or testable statements. For example, “The search results shall be displayed within two seconds for 95% of requests under a load of 500 concurrent users” is more useful than “The search shall be fast.” The quantitative target must be agreed with stakeholders and supported by an appropriate test environment.

2.3 Elicitation techniques

No single technique reveals every requirement. Common approaches include:

• Interviews: provide depth and allow follow-up questions, but may reflect personal bias.
• Observation: reveals actual workarounds and informal practices that interviews may miss.
• Workshops: create shared understanding and resolve conflicts quickly.
• Questionnaires: reach many people efficiently but provide less contextual depth.
• Document analysis: identifies policies, forms, reports, contracts, and legacy rules.
• Prototyping: helps stakeholders react to a tangible representation.
• Contextual inquiry: studies users in their real work environment.
• Mining operational data: identifies volumes, exceptions, delays, and error patterns.

Elicitation should include normal cases, exceptions, misuse, accessibility needs, and future changes. Analysts should distinguish stated requirements from inferred assumptions and record unresolved issues explicitly.

2.4 Managing requirements

Requirements management continues throughout the lifecycle. A requirements baseline is an approved version against which changes are evaluated. A traceability matrix links business objectives to requirements, design elements, tests, and delivered features. Traceability supports impact analysis, auditability, and coverage assessment.

A requirement repository commonly records an identifier, statement, rationale, source, priority, status, dependencies, acceptance criteria, owner, and revision history. Requirements can be prioritized using techniques such as MoSCoW: Must have, Should have, Could have, and Won’t have in the current release. Priorities must be negotiated rather than assumed to be permanent.

3. Process and System Modelling

Models simplify reality so that people can reason about a system. A model is useful when it is accurate enough for its purpose, understandable to its audience, and maintained as the system changes.

3.1 Process modelling

A process model describes activities, sequence, decisions, participants, inputs, outputs, and controls. Business Process Model and Notation (BPMN) uses events, activities, gateways, pools, and message flows. A simple process may be represented as:

Receive application → Validate information → Assess eligibility → Approve or reject → Notify applicant.

The analyst should identify the process owner, trigger, inputs, outputs, business rules, exceptions, handoffs, delays, and performance measures. “As-is” models describe current practice; “to-be” models describe the desired future state. Comparing them reveals the gap that the project must address.

A process should not be automated merely because it exists. Analysis may show that an unnecessary approval step should be removed, a policy clarified, or data captured once and reused. Automation can reproduce inefficient or discriminatory practices at greater speed.

3.2 Data and object modelling

An entity–relationship model represents important data entities, their attributes, and relationships. For example, a Student may enrol in many Courses, while each Course may have many Students. This is a many-to-many relationship, often resolved in a relational design by an associative entity such as Enrolment.

Object-oriented models represent classes, attributes, operations, and relationships. A class diagram can show inheritance, association, aggregation, and multiplicity. Data and object models should reflect business meaning, not merely database implementation details.

3.3 Use cases and context diagrams

A use case describes a goal achieved by an actor through interaction with a system. A use-case specification normally includes the trigger, preconditions, main success scenario, alternative flows, exceptions, postconditions, and special requirements. “Submit assignment” is a goal; “click button” is usually a step within a use case rather than a complete business goal.

A context diagram establishes the system boundary and external entities. It prevents analysts from confusing responsibilities of the proposed system with those of surrounding organizations or services. Data-flow diagrams may then show processes, data stores, external entities, and flows. Models should be validated with stakeholders; an attractive diagram can still encode a false understanding.

4. Software Development Lifecycles

A lifecycle is a structure for organizing development work. No lifecycle eliminates uncertainty; each distributes learning, control, feedback, and risk differently.

4.1 Predictive development

In a predictive approach, scope, schedule, cost, and design are planned early, with formal stage approvals. The approach is appropriate when requirements are stable, interfaces are tightly controlled, safety or contractual documentation is essential, and change is costly or highly regulated. The traditional “waterfall” interpretation should not be confused with the broader predictive approach: real projects may include controlled feedback between stages.

Predictive development can create a false sense of certainty. If stakeholders cannot understand requirements until they see a working system, early approval may be unreliable. Prototypes, reviews, and risk analysis are therefore valuable even in plan-driven projects.

4.2 Iterative and incremental development

Iterative development revisits analysis, design, and implementation to improve the solution. Incremental development delivers usable portions over time. They can be combined: each increment adds capability, and each iteration learns from feedback.

These approaches reduce the risk of building a complete but unsuitable system. They require architectural coherence, integration planning, regression testing, and explicit decisions about what remains unfinished.

4.3 Agile development

Agile approaches emphasize working software, customer collaboration, responding to change, and close communication. Scrum, Kanban, and Extreme Programming are examples of Agile methods, although Agile is not a single prescriptive process.

A Scrum team commonly works with a product backlog, product goal, sprint, increment, review, and retrospective. The product owner prioritizes value; developers create the increment; and the Scrum Master supports effective practice. These titles do not remove the need for analysis, documentation, architecture, testing, or governance.

Agile practices include user stories, acceptance criteria, continuous integration, refactoring, test automation, pair programming, and backlog refinement. A user story often follows the form: “As a [user], I want [capability], so that [value].” A story is not a complete requirement specification; complex stories need supporting rules, models, prototypes, and tests.

4.4 DevOps

DevOps extends collaboration beyond development to operations, security, quality assurance, and business teams. Its practices may include version control, automated builds, continuous integration, automated testing, infrastructure as code, deployment automation, observability, feature flags, and rapid rollback.

Continuous delivery means that software is maintained in a releasable state; continuous deployment additionally automates release to production when specified controls pass. DevOps does not mean releasing without approval. It means making delivery repeatable, observable, and appropriately controlled.

5. Feasibility and Project Evaluation

Before committing significant resources, organizations evaluate whether a proposed system is desirable and achievable. A feasibility study normally considers:

• Technical feasibility: technologies, skills, integration, performance, security, and maintainability.
• Economic feasibility: costs, benefits, savings, revenue, and opportunity cost.
• Operational feasibility: fit with processes, culture, staffing, support, and user adoption.
• Schedule feasibility: whether a credible solution can be delivered by the required date.
• Legal and regulatory feasibility: privacy, intellectual property, accessibility, sector rules, and contractual obligations.
• Organizational feasibility: strategic alignment, sponsorship, governance, and capacity for change.

Economic analysis should distinguish one-time capital costs from recurring operating costs. A simple net benefit estimate is:

When benefits and costs occur at different times, discounted cash flow may be more appropriate:

Here, B_t is the benefit in period t, C_t is the cost in period t, r is the discount rate per period, and n is the number of periods. The formula assumes cash flows can be estimated and that a suitable discount rate is available. It does not capture every social, ethical, strategic, or risk-related value.

For example, suppose a project costs $100,000 immediately and produces net benefits of $60,000 in year 1 and $60,000 in year 2. At a 10% annual discount rate:

NPV = −100,000 + 60,000÷1.10 + 60,000÷(1.10)²

The result is approximately $4,132, so the discounted financial case is positive, subject to the reliability of the assumptions. Sensitivity analysis should test what happens if benefits are lower, costs are higher, or delivery is delayed.

6. System and Software Design

Design converts approved requirements into a blueprint for construction and operation. Important design viewpoints include:

• Architecture: major components, responsibilities, interfaces, deployment locations, and communication.
• Data: structures, ownership, integrity, retention, backup, and migration.
• Application logic: rules, services, workflows, and error handling.
• User experience: interaction, accessibility, information architecture, and feedback.
• Security: identity, authorization, encryption, secure defaults, logging, and threat mitigation.
• Operations: monitoring, capacity, resilience, recovery, and support.

Good design seeks high cohesion within components and low coupling between them. It applies separation of concerns so that changes in one responsibility do not unnecessarily affect others. Design decisions should be recorded with their rationale, alternatives considered, assumptions, and consequences.

Security and privacy must be designed in, not added at the end. Threat modelling asks what must be protected, from whom, by what attack paths, and with what controls. Privacy analysis considers data minimization, purpose limitation, transparency, consent or lawful basis where applicable, retention, access rights, and possible harm. Sensitive data should not be collected merely because storage is inexpensive.

Accessibility requires more than visual design. Keyboard operation, readable contrast, captions, screen-reader compatibility, clear error messages, and alternatives to complex interactions should be considered. Inclusive design improves usability for many users, not only those with legally recognized disabilities.

7. Construction, Testing, and Quality Assurance

Construction includes coding, configuration, database creation, integration, and automated build activities. Professional practice uses version control, peer review, coding standards, dependency management, secure development practices, and reproducible builds.

Testing provides evidence about quality; it cannot prove that software has no defects. Major levels include:

1. Unit testing: examines a small component in isolation.
2. Integration testing: examines interactions among components or services.
3. System testing: evaluates the complete system against specified requirements.
4. Acceptance testing: determines whether business and user needs are met.
5. Regression testing: checks that changes have not damaged existing behaviour.
6. Performance testing: examines response time, throughput, scalability, and resource use.
7. Security testing: examines vulnerabilities, access control, misuse, and resilience.
8. Usability and accessibility testing: evaluates effectiveness, efficiency, satisfaction, and inclusive access.

Verification asks, “Are we building the product correctly?” Validation asks, “Are we building the right product?” Both are necessary. Test cases should have preconditions, inputs, steps, expected results, actual results, and status. Requirements traceability helps identify untested or over-tested areas.

Testing should begin early. Requirements and designs can be reviewed before code exists, and automated tests can be written alongside implementation. Defects should be prioritized according to impact, likelihood, exploitability, and business urgency rather than merely the number of defects.

8. Deployment, Documentation, and Maintenance

Deployment moves a system into an operational environment. Activities may include environment preparation, configuration, data migration, user training, communication, backup verification, access provisioning, monitoring, and support readiness.

Common deployment strategies include:

• Big bang: all users move at once; simple but high risk.
• Phased: capabilities or groups migrate in stages.
• Pilot: a limited group uses the system before wider release.
• Parallel: old and new systems operate together temporarily; safer but costly.
• Blue–green: two production environments support controlled switching and rollback.
• Canary: a small proportion of users receive the release before expansion.

A rollback plan must specify conditions, authority, data handling, communication, and technical steps. Deployment success is not simply installation; it includes stable operation and achievement of intended outcomes.

Documentation may include requirements specifications, process models, architecture decisions, API documentation, database definitions, test evidence, operational runbooks, user guides, training materials, support procedures, and records of known limitations. Documentation should be maintained as a product asset, not treated as a ceremonial deliverable.

Maintenance begins after release and commonly includes:

• Corrective maintenance: fixing defects.
• Adaptive maintenance: responding to environmental or platform changes.
• Perfective maintenance: improving performance, usability, or capability.
• Preventive maintenance: reducing future failure or technical debt.

Technical debt is the future cost created by expedient or poorly designed decisions. It is not automatically bad; deliberate short-term compromise can be rational if recorded, funded, and repaid. Unmanaged debt increases fragility and slows change.

9. Change Management and Governance

Change is inevitable because markets, laws, technologies, risks, and organizational priorities change. A controlled change process records the request, reason, urgency, affected requirements, cost, schedule, risks, dependencies, testing needs, and approval decision.

A change control board may evaluate significant changes in predictive projects. Agile teams manage change through backlog prioritization, product goals, iteration boundaries, and release decisions. Both approaches require impact analysis and stakeholder accountability. Agile does not mean that every request is accepted immediately.

Organizational change management addresses adoption. It includes communication, sponsorship, training, role redesign, support, feedback, and reinforcement. Resistance may indicate poor communication, legitimate loss of autonomy, inadequate design, workload concerns, or previous failed projects. Treating resistance as merely an attitude problem is analytically weak and ethically risky.

Governance defines decision rights, standards, controls, escalation paths, architecture oversight, risk ownership, and evidence requirements. Useful measures include defect trends, deployment frequency, lead time for changes, change failure rate, recovery time, user satisfaction, adoption, process-cycle time, and benefits realization. Metrics should guide learning rather than encourage harmful gaming.

10. Contemporary Issues: Cloud, AI, and Responsible Development

Cloud services can reduce infrastructure lead time and provide elasticity, but they introduce dependency, data-residency, cost-management, identity, availability, and exit-planning concerns. A feasibility analysis should consider the entire service lifecycle, including portability and supplier concentration.

Artificial intelligence can support requirements classification, code assistance, test generation, anomaly detection, documentation, and support. However, AI-generated outputs may contain defects, insecure code, fabricated explanations, copyright concerns, or biased decisions. Human review, approved tools, data governance, confidentiality controls, provenance, testing, and accountability remain necessary. An organization should never treat AI output as automatically correct or as a substitute for stakeholder consultation.

Responsible development considers fairness, transparency, privacy, safety, accessibility, sustainability, and accountability. Automated decisions affecting employment, education, credit, health, or public services require especially careful impact assessment, human oversight, appeal mechanisms, and regulatory review.

11. Illustrative Case: University Advising Platform

Background

A university uses email, spreadsheets, and a legacy portal to manage academic advising. Students often receive inconsistent advice, advisers cannot see current progress, and administrators cannot reliably identify students at risk of delayed graduation.

Problem

The university proposes a central advising platform. Initial requests focus on dashboards and appointment booking, but analysis identifies deeper issues: course rules are inconsistent across faculties, student data is duplicated, and students with disabilities experience barriers in the existing portal.

Analysis

The analyst maps the current process from student request to adviser follow-up. Stakeholders include students, advisers, faculty administrators, registry staff, disability support staff, information security personnel, and senior management. Workshops reveal conflicting priorities: advisers want flexibility, registry staff require rule consistency, and students want understandable explanations rather than administrative codes.

Requirements are prioritized as follows:

• The system must display an authenticated student’s current programme requirements.
• Advisers must record recommendations with an audit history.
• Students must request appointments using accessible interaction methods.
• The system should identify possible progression risks using transparent rules.
• The system must integrate with the student-record and timetable systems.

The project is technically feasible because standard interfaces exist, but data quality and rule harmonization create significant risk. A pilot is economically and operationally preferable to immediate university-wide deployment.

Approach and solution

An incremental Agile approach is selected, with formal privacy, security, and architecture gates. The first increment provides authenticated access, programme information, and appointment requests. A later increment adds adviser notes and reporting. Risk scoring is initially rule-based and explainable rather than based on an opaque predictive model.

The design applies role-based access control, data minimization, audit logging, encryption, accessibility testing, and explicit retention rules. Test scenarios include a student changing programme, a student using assistive technology, an adviser lacking permission to view sensitive information, and an integration service becoming unavailable.

A pilot is conducted in two faculties. Training, drop-in support, feedback channels, and a rollback plan are established. The old and new processes operate in parallel for a limited period while records are reconciled.

Outcome

The pilot reduces duplicated data entry and improves visibility of outstanding requirements. It also reveals that some programme rules were contradictory. Rather than hiding the problem in software, the university creates a governance group to standardize academic rules. The project therefore improves both technology and institutional process.

Learning points

1. Stakeholder requests may conceal process and policy problems.
2. Data quality and governance are often more difficult than interface development.
3. Incremental delivery reduces exposure while producing early learning.
4. Accessibility, privacy, and explainability must be design requirements.
5. Successful deployment includes training, support, adoption, and process ownership.

Challenges and Limitations

Systems analysis is constrained by incomplete information, political interests, changing environments, legacy dependencies, limited budgets, and uncertain benefits. Models can oversimplify reality, interviews can reflect power imbalances, and metrics can encourage local optimization. Agile methods can become superficial ceremonies if teams lack technical capability or stakeholder access. Predictive methods can become paperwork exercises if plans are not updated when evidence changes.

Analysts should state assumptions, expose uncertainty, validate models, use multiple evidence sources, and revisit decisions. No lifecycle or modelling notation guarantees success. Professional judgement, communication, ethical awareness, and continuous learning remain central.

Best-Practice Checklist

• Define the business problem before selecting technology.
• Identify affected and marginalized stakeholders, not only senior sponsors.
• Separate goals, requirements, assumptions, constraints, and solutions.
• Model current and future processes, including exceptions.
• Make requirements testable and maintain traceability.
• Select a lifecycle according to uncertainty, risk, regulation, and feedback needs.
• Assess technical, economic, operational, schedule, legal, and organizational feasibility.
• Design security, privacy, accessibility, resilience, and support from the beginning.
• Test behaviour, quality attributes, integrations, misuse, and recovery.
• Use controlled deployment with monitoring and rollback capability.
• Maintain documentation and manage technical debt deliberately.
• Evaluate outcomes and benefits after implementation.
• Govern AI and automated decisions through human accountability and evidence.

Chapter Summary

Systems analysis and software development connect organizational objectives with operational technology. Effective work begins with stakeholder identification, careful elicitation, testable requirements, and models of processes, data, actors, and system boundaries. Predictive lifecycles provide structure and control where scope is stable, while iterative, incremental, Agile, and DevOps approaches provide faster feedback and adaptability when uncertainty is high. Each approach requires discipline.

Feasibility analysis examines whether a proposed solution is technically, economically, operationally, legally, organizationally, and schedulably realistic. Design must address architecture, data, interfaces, user experience, security, privacy, accessibility, and operations. Construction is supported by version control, review, automation, and secure engineering. Testing provides evidence through unit, integration, system, acceptance, regression, performance, security, usability, and accessibility activities.

Deployment is a socio-technical transition requiring migration, training, monitoring, support, and rollback planning. Documentation, maintenance, technical-debt management, change control, governance, and benefits evaluation sustain value after release. Contemporary systems work must also address cloud dependency, AI reliability, fairness, privacy, explainability, and accountability. The central professional lesson is that successful software is not merely functional code; it is a governed, usable, secure, maintainable, and valuable system embedded in human work.

Key Terms

Acceptance criteria: Conditions used to determine whether a requirement or feature is complete.

Agile: A family of adaptive development approaches emphasizing collaboration, feedback, and response to change.

Business requirement: An organizational objective or outcome that a system should support.

Change control: A structured process for evaluating, approving, implementing, and recording changes.

Context diagram: A model showing a system boundary and its interactions with external entities.

DevOps: Practices and culture integrating development, operations, quality, security, and automated delivery.

Feasibility study: An evaluation of whether a proposed solution is achievable and worthwhile.

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

Incremental development: Delivery of a system in usable functional portions.

Maintenance: Post-release work that corrects, adapts, improves, or prevents software problems.

Non-functional requirement: A quality, constraint, or characteristic such as performance, security, or accessibility.

Predictive lifecycle: A plan-driven lifecycle in which scope and activities are largely defined in advance.

Requirements traceability: The linking of requirements to their sources, designs, tests, and delivered components.

Stakeholder: A person, group, or organization that affects or is affected by a system.

System testing: Testing of the complete integrated system against specified requirements.

Technical debt: Future cost or risk created by expedient or deficient technical decisions.

Transition requirement: A requirement concerning migration, training, conversion, or implementation of a new system.

Use case: A description of a goal achieved by an actor through interaction with a system.

Verification: Evaluation of whether a product has been built according to specification.

Validation: Evaluation of whether the product solves the intended problem and meets stakeholder needs.

Review Questions

Short Answer Questions

1. What is the difference between a functional and a non-functional requirement?
2. Why should analysts model both “as-is” and “to-be” processes?
3. Identify two strengths and two limitations of a predictive lifecycle.
4. What is the purpose of requirements traceability?
5. Distinguish verification from validation.

Long Answer Questions

1. Explain how stakeholder analysis and requirements elicitation contribute to successful systems development. Include at least four elicitation techniques.
2. Compare predictive, iterative, Agile, and DevOps lifecycles, and recommend circumstances in which each may be appropriate.
3. Discuss the major dimensions of feasibility analysis and explain why financial feasibility alone is insufficient.
4. Explain how security, privacy, and accessibility should influence system design and testing.
5. Describe a complete deployment and maintenance strategy for a critical organizational information system.

Analytical / Application Questions

1. A hospital wants to replace a scheduling system, but clinical rules are changing and several departments disagree about priorities. Analyse the situation and recommend a lifecycle, stakeholder approach, and risk controls.
2. A proposed project costs $150,000 immediately and is expected to produce net benefits of $80,000 in each of the next two years. Using a 10% annual discount rate, calculate the approximate NPV and explain at least three non-financial assumptions that should be examined.
3. An organization plans to use an AI model to identify employees at risk of leaving. Analyse the requirements, privacy, fairness, explainability, testing, governance, and change-management issues that should be addressed before deployment.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a non-functional requirement?

A. The system shall allow a customer to place an order.

B. The system shall calculate sales tax.

C. The system shall display search results within two seconds for an agreed workload.

D. The system shall create an invoice after payment.

Correct Answer: C. The system shall display search results within two seconds for an agreed workload.

Question 2

What is the primary purpose of a context diagram?

A. To specify program variables

B. To show the system boundary and external interactions

C. To calculate project profitability

D. To document test execution results

Correct Answer: B. To show the system boundary and external interactions

Question 3

Which lifecycle is generally most suitable when requirements are highly uncertain and frequent stakeholder feedback is valuable?

A. Adaptive Agile or iterative development

B. Unmodified big-bang deployment

C. A lifecycle with no testing

D. A fixed plan that prohibits change

Correct Answer: A. Adaptive Agile or iterative development

Question 4

Which activity is most closely associated with DevOps?

A. Separating development and operations completely

B. Avoiding automated testing

C. Automating builds, testing, deployment, and operational feedback

D. Defining all requirements once and never revisiting them

Correct Answer: C. Automating builds, testing, deployment, and operational feedback

Question 5

Which feasibility dimension examines whether users, processes, culture, and support arrangements can accommodate a proposed system?

A. Technical feasibility

B. Operational feasibility

C. Schedule feasibility

D. Cryptographic feasibility

Correct Answer: B. Operational feasibility

Question 6

What is the main purpose of acceptance testing?

A. To determine whether stakeholder and business needs have been met

B. To test only individual functions in isolation

C. To replace requirements elicitation

D. To measure programmer productivity

Correct Answer: A. To determine whether stakeholder and business needs have been met

Question 7

A system costs $100,000 now and produces $60,000 at the end of each of the next two years. At a 10% annual discount rate, which is the closest NPV?

A. −$20,000

B. $4,132

C. $60,000

D. $120,000

Correct Answer: B. $4,132

Question 8

Which deployment strategy introduces a system to a limited group before wider release?

A. Pilot deployment

B. Big-bang deployment

C. Uncontrolled deployment

D. Permanent parallel deployment

Correct Answer: A. Pilot deployment

Question 9

Which type of maintenance adapts software to a changed operating environment or platform?

A. Corrective maintenance

B. Adaptive maintenance

C. Perfective maintenance

D. Destructive maintenance

Correct Answer: B. Adaptive maintenance

Question 10

Why should AI-generated code or analysis be subject to human review?

A. AI output is guaranteed to be correct but review is traditional

B. AI output may contain defects, insecure logic, bias, or unsupported claims

C. Human review prevents all future changes

D. AI systems cannot produce any useful output

Correct Answer: B. AI output may contain defects, insecure logic, bias, or unsupported claims