How to Solve a System of Inequalities: Graph, Test, and Verify Every Region

To solve a system of inequalities, graph each inequality's boundary line on the same coordinate plane, then shade the side that makes that inequality true; the solution is every point inside the overlap of all shaded regions. Shade below a line for y < (boundary) and above it for y > (boundary). After graphing, verify by testing one point from the overlap and one from outside it. The rest of this guide explains why that overlap method works, where it breaks, and how to check your answer reliably.

The Mechanism: Why the Overlap Is the Solution

A single two-variable inequality describes a half-plane, a flat region of the coordinate plane bounded by one line. The boundary line itself comes from the related equation: y = mx + b replaces y < mx + b. That line divides the plane into exactly two halves—one where the inequality statement is true and one where it is false.

The shading rule exists because the boundary line has slope and intercept that fix the tilt, while the inequality symbol picks the side. For y < mx + b, every point with a smaller y-coordinate than the line sits below it. For y > mx + b, every point with a larger y-coordinate sits above it. Vertical lines work the same way horizontally: x < 3 shades left, x > 3 shades right.

A system is an intersection problem. Each inequality acts as a filter, and a point must pass every filter at once. If inequality one permits the lower half-plane and inequality two permits the upper half-plane, only the points in both halves survive. That shared territory is the feasible region.

The boundary type matters for inclusion. A strict inequality (< or >) excludes its boundary line, so you draw it dashed. A non-strict inequality (≤ or ≥) includes the line, so you draw it solid. Mixing the two in one system is common and legitimate; the region then has some solid edges and some dashed ones.

Plain-language version: each inequality narrows the plane to half, and stacking the inequalities narrows it further until little or nothing remains.

Quantifying the Feasible Region

The feasible region has measurable properties, and computing them is often the real assignment. Its corners, called vertices, sit where two boundary lines cross. Take the system y ≥ x + 1 and y ≤ −x + 5. Setting x + 1 = −x + 5 gives x = 2, so the lines meet at (2, 3), and the usable band between them runs upward from that crossing.

Three inequalities typically produce a triangular region with three vertices. Four or more can produce quadrilaterals or unbounded wedges. In linear programming, a classic application, the optimum of an objective function such as P = 3x + 2y always occurs at a vertex—never strictly inside a bounded polygon. That theorem is why corner-testing matters more than eyeballing the middle of the region.

Unbounded regions need special handling because no finite area exists. A system like x ≥ 0, y ≥ 0, x + y ≥ 4 opens toward infinity, so the objective may grow without limit. Checking any single point can never prove a maximum there; you must confirm whether the direction of improvement extends forever.

At the school level, systems commonly involve 2 to 4 inequalities and 2 variables, and answer sets are the union of shaded overlap regions. When a problem says "graph the solution set," graders look for three things: correct boundary slopes and intercepts, correctly dashed or solid lines, and plausibly shaded overlap.

Edge Cases That Break the Pattern

Several situations defeat the simple shade-and-look approach. Treat wildcard cases with care rather than optimism.

Parallel boundaries with no overlap: y > x + 4 and y < x + 1 share no points, because no number exceeds x + 4 while staying below x + 1. The solution set is empty. Identical boundary lines: y ≥ 2x + 1 and y ≤ 2x + 1 intersect in exactly one line, not a region, so the solution is the line itself. Disjoint slivers: two adequate-looking half-planes can miss each other entirely if their slopes are close and their intercepts are far apart. Dividing by a negative: solving −2x > 6 flips the symbol to x < −3. Forgetting the flip is the most common algebra error in the whole topic. Unbounded overlap: when the shaded intersection runs off the graph, the solution is not "wrong"—it just extends beyond the visible window. Boundary-inclusion disputes: open circles versus closed circles on number lines and dashed versus solid lines on graphs must match the strictness of each symbol.

One counterintuitive detail: an overlap can be nonempty yet contain no lattice points. A thin wedge like 0 < y − (x − 1.4) < 0.1 holds infinitely many real-number solutions but zero integer pairs. If a word problem demands whole-number answers, verify integral feasibility explicitly rather than assuming the region provides it.

Misconceptions Worth Correcting

The most persistent myth is that shading one region "solves" a system. It does not; the shaded overlap does. Students who shade each inequality's true side correctly still fail when they shade the false side or skip the intersection step entirely.

Another misconception treats the boundary line as always included. The symbol alone decides inclusion, not the graphing tool or the textbook's default. A dashed line at the edge of a feasible region means nearby points qualify while the line itself does not—a distinction that changes answers in scheduling and budget problems.

A third error substitutes substituting the origin for testing every time. Origin testing is only valid when the origin is not on the boundary; if it lies on the line, the test is inconclusive and you need another point.

Students also conflate the system's solution with the solution to each inequality. Inequality one's solution is its whole half-plane; the system's solution is the shared slice. Finally, some assume that more inequalities always shrink the region. Not so: adding a constraint whose half-plane contains the existing overlap changes nothing, a redundancy that examiners do plant.

Practical Steps and Verification Thresholds

A reliable workflow, in order:

Convert each inequality to slope-intercept or vertical form and note the symbol. Record the slope and intercept, and flag any symbol that must flip during isolation. Graph all boundary lines first, dashed for strict and solid for non-strict. Check at least two points per line by substitution before shading. Pick a test point per inequality, one that is not on the line. Substitute, and shade the side containing a true result. Mark the overlap with a distinct pattern or color. If no overlap appears after 3 inequalities, suspect a mistake before declaring an empty solution. Compute vertices by solving each pair of boundary equations that actually enclose the region. For linear programming, evaluate the objective at every vertex; a bounded problem has its optimum among them. Run a final check: one point from inside the overlap must satisfy all inequalities at once; one point from outside must fail at least one. This two-point confirm catches shading errors almost every time.

For word problems, define x and y before writing anything, then write every constraint as an inequality including non-negativity: x ≥ 0 and y ≥ 0. States like "at most" map to ≤, "at least" to ≥, and "more than" to >. Reconcile the result against the question asked—an unbounded region may make a maximum impossible, and an empty region means the constraints contradict each other.

For integer-answer problems, list candidate lattice points inside the overlap and test each. Keep the list short by scanning the region's interior grid by grid, then verify each candidate against all constraints.

Timeline: What the Process Looks Like Step by Step

Limitations: Where the Method Stops

Graphing by hand scales poorly. Beyond two variables, the feasible region becomes a three-dimensional solid or a higher-dimensional polytope, and you must solve with linear algebra or software instead of pencils. Even in two dimensions, hand-drawn lines introduce slope error; conclusions about narrow slivers or near-parallel boundaries should be confirmed algebraically.

Graphical solutions also depend on the viewing window. A region that looks empty may exist outside your axes, and one that looks finite may continue past the page edge. Always state whether the solution set is empty, a single point, a bounded polygon, or an unbounded region—glancing at a graph does not establish this.

When problems fall outside pure mathematics—budget planning, resource allocation, safety limits—the correct constraint interpretation depends on local rules you cannot derive from algebra. Consult a qualified professional in those settings rather than relying on a generalized model. This article is general educational information, not financial, legal, or medical advice, and it promises no particular outcome from any optimization model; for decisions with real consequences, work with a qualified local professional.