2.1System Development Technology

From a user thinking "I want a system like this" to actually receiving a working system, several steps happen in order. Understanding the flow of these steps and what gets checked at each one is the starting point for system development technology.

2.1.1The development flow and requirements

• Requirements definition is the first step, where you clarify what the user wants to achieve. The requirements fixed here become the basis for all later design and implementation.
• Design turns the requirements into a concrete, buildable shape (screens, data, processing structure). Implementation is where the program is actually written, based on the design.
• Testing verifies that what was built behaves as required. Acceptance is where the customer (the user side) actually checks the delivered system and gives final approval that it meets the requirements.
• Functional requirements describe what the system specifically does (e.g. users can log in, orders can be placed). Non-functional requirements cover quality aspects other than function, such as performance, reliability, and security (e.g. response within 3 seconds, 99.9% uptime).

2.1.2Test stages and techniques

• Unit test tests a single program part (module) on its own. Integration test checks whether multiple modules work correctly together once combined.
• System test verifies the entire system end-to-end against the requirements (including performance and security). Operational test is a final check, close to the real operating environment, that users can actually work with the system.
• White-box testing is a technique where test cases are built by looking at the program's internal structure (the flow of processing). Black-box testing builds test cases by looking only at the correspondence between input and output, without regard to internal structure.
• Module decomposition is the design idea of splitting a program into manageable parts (modules). Review is the activity of checking a deliverable (a design document, program, etc.) by human eyes to catch mistakes early. Because the cost of fixing a mistake grows the later it is found, catching it early is emphasized.

Consider building a small in-house expense-reimbursement system. First, in requirements definition, you organize functional requirements such as "an applicant can enter an expense and a manager can approve it," and non-functional requirements such as "respond within 3 seconds even with 100 concurrent users." In the following design step, you break this down into screens, database, and processing units, applying module decomposition to create manageable parts. After implementation writes the program for each module, you first check that each module alone works correctly via unit test, then check that the "expense entry module" and the "approval module" cooperate correctly via integration test. Next comes system test, checking the whole system end-to-end including performance and security, and finally an operational test where the actual user department tries it under near-real conditions, after which the customer performs final acceptance. When building test cases, aiming to cover every branch inside the approval logic's internal processing is white-box testing; focusing only on "enter this amount, expect this result" without regard to internals is black-box testing. Inserting a review at each milestone prevents costly rework, such as discovering a requirements mistake only after implementation is done.

2.1.3Section summary

• The flow is requirements definition -> design -> implementation -> test -> acceptance. Distinguish functional requirements (what it does) from non-functional requirements (quality such as performance)
• Testing widens in scope through unit -> integration -> system -> operational. White-box = internal structure, black-box = input/output
• Module decomposition breaks the program into manageable parts. Review catches mistakes early to keep fixing costs low