From 3f7a140d88289482b9c55cecb48732e828c388eb Mon Sep 17 00:00:00 2001 From: Michael K Date: Tue, 10 Oct 2023 09:16:58 -0400 Subject: [PATCH] remove 'a' --- chapters/specifications.bd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/specifications.bd b/chapters/specifications.bd index 3a705fa..498911e 100644 --- a/chapters/specifications.bd +++ b/chapters/specifications.bd @@ -4,7 +4,7 @@ As you've probably noticed by now, this type of process doesn't really scale, ev The techniques we've discussed so far for avoiding this boil down to _specifying_ what code should do, so everyone can write code according to a plan. We've talked about [requirements specifications|requirements], which are declarations of what software must do from a users' perspective. We've also talked about [architectural specifications|architecture], which are high-level declarations of how code will be organized, encapsulated, and coordinated. At the lowest level are *functional specifications*, which are declarations about the _properties of input and output of functions in a program_. -In their simplest form, a functional specification can be a just some natural language that says what an individual function is supposed to do: +In their simplest form, a functional specification can be just some natural language that says what an individual function is supposed to do: `javascript // Return the smaller of the two numbers,