System Development

Chapter learning objectives

1. Translate an organizational need into scoped, prioritized, and verifiable requirements.
2. Connect architecture and usability choices to actual user tasks and exceptions.
3. Compare life-cycle, iterative, agile, and low-code/no-code approaches.
4. Distinguish verification, validation, acceptance, conversion, and ongoing maintenance.

Goals for this part

• Explain Needs and Problems.
• Explain Stakeholders and Scope.
• Explain Requirements Quality and Change.

Needs and Problems

A need describes a desired outcome or a gap in the current work. A requirement states a capability or condition a proposed solution must satisfy. Requirements analysis investigates those needs and translates them into a form that stakeholders can examine and test.

Needs and Problems

“Build a mobile app” is a proposed solution. “Applicants need to know whether their submission is complete before the review deadline” identifies an outcome that several solutions might support. Clarifying the need preserves the ability to compare a process change, a configuration change, a purchased service, or new development.

Needs and Problems

Analysis uses records, interviews, observation, and examples of normal and exceptional work. A manager's description may omit informal steps employees use to keep the service running. The agency should therefore examine actual applications and handoffs rather than documenting only the official procedure. Understanding the current problem makes the later design choice more defensible.

Needs and Problems

Systems development is the organized creation or change of an information system and its associated work. It is a form of organizational change because records, responsibilities, routines, and decisions may all be affected. The terms system analysis and system design are also used for the analysis and design activities discussed here.

Needs and Problems

The vocabulary should help explain the work rather than imply that those activities are cleanly separated in every project.

Stakeholders and Scope

Stakeholders are people or groups who affect or are affected by the solution. They can include users, customers, process owners, support teams, partners, and people represented in the records. A stakeholder need can be important even when the person has no purchasing authority.

Stakeholders and Scope

Scope defines what the proposed change includes and excludes. It should identify process boundaries, affected users, information, interfaces, and outcomes. A boundary helps manage delivery while also making dependencies on excluded work visible.

Stakeholders and Scope: comparison

Stakeholders and Scope

Different concerns can conflict. Adding every requested feature does not resolve those conflicts. The agency needs a way to prioritize and record decisions, including why some work is deferred.

Requirements Quality and Change

A useful requirement is clear enough to interpret, relevant to the need, feasible within constraints, and verifiable. Functional requirements describe what the solution does. Nonfunctional requirements describe qualities or constraints such as performance, usability, availability, and access protection. Both affect whether the service is suitable.

Requirements Quality and Change

“Make the system fast” leaves timing and workload unspecified. A more testable requirement identifies the task, conditions, and response expected. The exact target should come from the service need and evidence, not from an arbitrary number chosen for the specification.

Requirements Quality and Change

Traceability connects a requirement with its source, design decision, and verification. When the agency changes an eligibility rule, those links help identify the screens, records, guidance, and tests affected. Change is not automatically a failure of planning. The management task is to understand its consequences, authorize it appropriately, and keep the related work consistent.

Goals for this part

• Explain Analysis and Architecture.
• Explain Usability and Solution Design.
• Explain Development Approaches.

Analysis and Architecture

Systems analysis examines the problem and information requirements. Systems design specifies an arrangement intended to meet those requirements. Architecture describes important components, relationships, and design choices that shape how the system operates and evolves. The boundaries overlap in practice, especially when learning about a feasible design changes the understanding of the need.

Analysis and Architecture

The agency might separate the applicant interface, submission service, case records, and notifications. Each component needs a responsibility, and their connections need meaningful events and error handling. A diagram of boxes becomes useful when it explains those relationships rather than merely listing technologies.

Analysis and Architecture

For example, submission should create a traceable case and a usable acknowledgment. If notification fails, the agency needs to know whether the case exists and how the applicant can verify it. Defining that behavior is a design decision tied to the service requirement. Choosing a fashionable component name does not settle it.

Usability and Solution Design

Usability concerns whether intended users can complete tasks effectively, efficiently, and with an appropriate experience in the relevant context. Accessibility addresses barriers affecting people with disabilities. Both need evaluation with realistic tasks and users rather than relying only on the design team's familiarity.

Usability and Solution Design

A prototype makes part of the proposed solution available for examination before full implementation. It can test language, navigation, and information needs. A convincing prototype does not necessarily have the reliability, access controls, or operating support needed for production use.

Usability and Solution Design: comparison

Usability and Solution Design

The table translates a general design preference into observable work. W3C's WCAG guidance provides a basis for accessibility checks; observation and feedback are still needed to understand the service experience.

Development Approaches

A life-cycle approach organizes development activities such as analysis, design, implementation, testing, deployment, and maintenance. A plan-driven approach emphasizes defining and coordinating work in advance. Iterative development revisits and improves the solution through repeated cycles. Agile approaches emphasize useful increments, collaboration, and adaptation; they do not imply the absence of planning, documentation, or responsibility.

Development Approaches

A purchased package or low-code/no-code environment can reduce some implementation work while introducing constraints in process fit, integration, permissions, and provider dependence. Users can create a working interface without resolving those wider design concerns.

Development Approaches

DevOps connects development and operations through collaboration and practices supporting dependable changes and feedback. For the agency, the appropriate approach depends on uncertainty, consequences, available skills, and integration needs. A small prototype can clarify language while formal verification remains necessary for a consequential submission process.

Development Approaches

The organization should combine practices for a reason rather than adopting a label as the solution.

Development Approaches

The systems development life cycle is another name for the organizing view of development activities. Agile development applies iterative, collaborative approaches to learning and delivering useful changes. Low-code development uses environments that reduce the amount of hand-written code; no-code development emphasizes configuration or visual construction by users.

Development Approaches

These approaches can reduce some implementation effort while leaving requirements, integration, access, testing, and maintenance responsibilities in place.

Goals for this part

• Explain Validation and Defects.
• Explain Conversion and User Acceptance.
• Explain Production and Maintenance.

Validation and Defects

Verification examines whether a solution meets specified requirements. Validation examines whether it is suitable for the intended use. The distinction is useful even though organizations use the terms in different ways. A system can implement the specification correctly while the specification fails to address the actual service problem.

Validation and Defects

A defect is a shortcoming relative to a requirement or intended behavior. Tests should connect inputs and conditions to expected results. Unit tests examine individual components; integration tests examine connections; system tests examine the combined behavior. Different tests provide different evidence and do not replace one another.

Validation and Defects

For the agency, a realistic test follows submission through case creation, acknowledgment, reviewer access, and exception handling. A duplicate submission should have an explicit expected outcome. Tests should also include access, recovery, and important failure conditions.

Validation and Defects

NIST's Secure Software Development Framework treats secure development as work integrated into the development process rather than a check performed only at the end.

Conversion and User Acceptance

User acceptance testing allows authorized business participants to examine whether the solution supports agreed work and acceptance criteria. It needs realistic tasks and records, including important exceptions. A signature after a brief presentation is weak evidence that users can operate the process.

Conversion and User Acceptance

Conversion moves work from the old arrangement to the new one. A direct cutover changes at a defined point; a phased approach changes selected functions or locations over time; parallel operation runs arrangements together temporarily. Each has costs, risks, and reconciliation needs.

Conversion and User Acceptance: comparison

Conversion and User Acceptance

Migration testing should compare meaningful record counts, relationships, and samples of actual use. Matching a total alone can miss wrongly linked or misinterpreted records.

Production and Maintenance

Production is the operating environment used for real work. Maintenance includes correcting defects, adapting to changes, and improving the service over its life. The service needs ownership, support arrangements, monitoring, controlled changes, and a way to learn from incidents.

Production and Maintenance

A release should identify what changed, how it was checked, who can authorize it, and how the organization will respond if the change fails. A rollback plan can be useful, but returning software to an earlier version may not reverse records already changed. Recovery therefore needs to consider information and work, not only application files.

Production and Maintenance

The agency should review whether the new service reduces incomplete applications and makes status understandable. A technically successful launch with continuing applicant confusion needs further work. Feedback from production can reveal new requirements or invalidate earlier assumptions. Testing is part of that continuing learning cycle rather than a declaration that the system will never have a problem.

Reading and assignments

• Chapter reading
• Curated references
• Preview, Case Study, and Homework