Requirements and constraints

A design is only as good as its requirements. If they are vague, the team will argue about what "done" means. If they are wrong, the team will deliver the wrong thing efficiently. If they are missing, the gap shows up at the worst possible time: at inspection, at handover, or in the first winter. Studies of failed projects in many industries keep finding the same root cause near the top of the list: poorly defined or changing requirements.

This chapter turns the agreed problem statement from Lesson 1 into requirements a team can design against and test. You will learn the kinds of requirement, how to write them so they cannot be misread, how codes and standards act as constraints, how to identify and manage stakeholders, how to prioritize when requirements conflict, and how to plan the verification that proves each one was met. We continue with the community center entrance.

From needs to specifications

Requirements live in a hierarchy, from what people want to numbers an engineer can check.

• A need is a statement in the user's language: "I want to get into the building on my own."
• A requirement says what the design must do or be, in a way that can be verified: "The entrance shall allow a person using a manual wheelchair to enter without assistance."
• A specification gives the measurable value: "The running slope of any walking surface on the accessible route shall not exceed 1:20, except at ramps, which shall not exceed 1:12."

One need usually produces several requirements, and each requirement may produce several specifications. Keeping the links between them (traceability, covered below) lets you answer the question every reviewer eventually asks: why is this number here?

Kinds of requirement

Sorting requirements by type helps you notice what is missing.

• Functional requirements say what the design must do: carry people from the sidewalk to the door; open the door automatically.
• Performance requirements say how well: complete an entry in under 30 seconds; operate down to −35 °C.
• Interface requirements say how the design connects to other things: match the existing door threshold; tie into the storm sewer.
• Non-functional ("quality") requirements cover properties such as reliability, maintainability, appearance and service life: a 30-year design life; no part heavier than two people can lift during repairs.
• Constraints limit the solution space rather than describing what the design does: budget, schedule, site boundaries, codes and standards, heritage rules, material availability.

The difference between a requirement and a constraint is not always sharp, and it does not need to be. What matters is that every one is written down and agreed.

Writing requirements that cannot be misread

The test of a requirement is simple: could two competent people, reading it independently, disagree about whether a finished design meets it? If so, rewrite it. Good requirements share a few characteristics, summarized in guidance such as INCOSE's Guide to Writing Requirements:

• Necessary: it traces to a real need; remove it and something important would be lost.
• Unambiguous: one interpretation only. Words like adequate, user-friendly, robust, sufficient, approximately, as appropriate and minimize are warning signs.
• Singular: one requirement per statement, so each can be verified and tracked separately. "And" is often a sign that two requirements are hiding in one sentence.
• Verifiable: there is a way to show it has been met, by inspection, analysis, demonstration or test.
• Feasible: it can be achieved within the constraints.
• Solution-neutral, where possible: it says what is needed, not how. "Shall provide a level change of 24 in" leaves room for a ramp, a lift or regrading; "shall have a concrete ramp" does not.

By convention, "shall" marks a mandatory requirement, "should" a desirable goal, and "may" an option. Use them consistently; never use "will" or "must" interchangeably with "shall" in the same document.

Codes and standards as constraints

Much of what an engineer must achieve is fixed by codes and standards, which record society's minimum expectations and the lessons of past failures.

In the United States, most building codes start from the model codes published by the International Code Council (ICC), such as the International Building Code (IBC), on a three-year cycle. The model codes take effect only when a state or local government adopts them, usually with amendments, and some jurisdictions adopt older editions. Local building departments enforce the adopted code through permits and inspections. Accessibility is also a civil-rights requirement: the Americans with Disabilities Act (ADA) applies to state and local government facilities and to places of public accommodation, and the 2010 ADA Standards for Accessible Design set its technical rules. A community center must meet both the adopted building code and the ADA.

Standards, written by bodies such as ASTM International, NFPA, UL and the ICC, many of them accredited by ANSI, set out detailed requirements for products, methods and design. A standard is voluntary on its own, but becomes legally binding when a code or regulation references it. ICC A117.1, Accessible and Usable Buildings and Facilities, referenced by the IBC, and the 2010 ADA Standards are the main accessibility documents for our project.

The figures used in this lesson come from the 2010 ADA Standards (sections 403 to 405). The IBC and ICC A117.1 contain very similar rules, but always design to the code and standard editions in force where you are building, and meet whichever is stricter.

• A walking surface steeper than 1:20 is a ramp. Ramps shall not be steeper than 1:12, and cross slopes shall not exceed 1:48.
• The rise of any single ramp run shall not exceed 30 in; landings at least 60 in long are required at the top and bottom of each run and where the ramp changes direction.
• Clear width between handrails at least 36 in.
• Ramp runs with a rise greater than 6 in need handrails on both sides, with the top of the gripping surface 34 to 38 in above the ramp surface.

Codes are minimums, not targets. A 1:12 slope is legal, but many wheelchair users find it hard to climb unaided, and accessibility advocates often recommend gentler slopes where space allows. Meeting code is necessary; it is not always sufficient to meet the need.

Stakeholders

A stakeholder is anyone who affects, or is affected by, the project. Missing one is a common way for a well-engineered project to fail: the design is excellent, but the heritage committee was never consulted and the permit is refused.

For the entrance, the list includes: the board (client and funder); members who use mobility aids; older members; parents with strollers; staff who clear snow; the custodian; the city's building department; the heritage advisory committee (the façade is listed); neighbors during construction; the contractor; and the insurer.

A power-interest grid helps decide how to engage each group. Stakeholders with high power and high interest are managed closely (involve them in decisions); high power and low interest are kept satisfied; low power and high interest are kept informed; and the rest are monitored.

Be careful with the grid's labels. The people who will actually use the entrance have little formal power over the project, but their needs are the reason it exists. Good practice is to involve users directly, through interviews, site visits and testing, not just keep them informed. Accessibility work uses the principle "nothing about us without us" for exactly this reason.

Conflicts, trade-offs and priorities

Requirements often conflict. The heritage committee wants the historic stone steps preserved and visible. The users want the main entrance to be the accessible entrance. The budget does not stretch to everything. Making these conflicts explicit, early, is far better than discovering them during construction.

One common prioritization scheme is MoSCoW: must have, should have, could have, won't have (this time). Every "must" is non-negotiable, which is why the list of musts should be short. Code requirements are always musts.

Contingency is not padding. At the concept stage, cost estimates are typically uncertain by tens of percent, and the contingency is the honest expression of that uncertainty. As the design firms up, the contingency can shrink.

Derived requirements

Some requirements are not stated by anyone; they follow from decisions already made. The five whys in Lesson 1 found that roof water was icing the old steps. Adding a canopy over the door creates a new roof area whose water must go somewhere other than the walkway.

Verification and validation

Every requirement needs a planned way to prove it has been met. Systems engineering uses four verification methods:

• Inspection: look at or measure the finished product. Is the clear width at least 36 in?
• Analysis: show by calculation or simulation. Will the canopy carry the design snow load?
• Demonstration: operate it and observe, without detailed measurement. Does the automatic door open when the button is pressed?
• Test: operate it under controlled conditions and measure. Does the slip-resistance test meet the required value?

Verification asks "Did we build it right?", meaning does the design meet the written requirements. Validation asks "Did we build the right thing?", meaning does it meet the users' actual need. A ramp can pass every inspection and still fail validation if, say, it ends at a door too heavy for a wheelchair user to open. That is why validation involves real users, like the chalk-line walkthrough in Lesson 1.

The traceability matrix

A requirements traceability matrix ties it all together in one table: each row is a requirement, with its source (need, code clause or stakeholder), its verification method, the design document that addresses it, and its status. Reviewers, inspectors and the eventual owner all use it.

Managing change

Requirements change: the client learns more, a code is updated, a stakeholder appears late. Change is normal; uncontrolled change is not. Each proposed change should be recorded, its impact on cost, schedule and other requirements assessed, and a decision made by the right person before the design is altered. Projects without this discipline suffer "scope creep", a slow accumulation of small additions that together break the budget and schedule.