From 12fad6df1a72f6050705c904b85bbeb3cd893d0c Mon Sep 17 00:00:00 2001 From: Mark Goadrich Date: Fri, 20 May 2022 10:57:46 -0500 Subject: [PATCH] Attempting to fix links to other chapters --- chapters/specifications.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/specifications.md b/chapters/specifications.md index db71c14..3a705fa 100644 --- a/chapters/specifications.md +++ b/chapters/specifications.md @@ -2,7 +2,7 @@ When you make something with code, you're probably used to figuring out a design As you've probably noticed by now, this type of process doesn't really scale, even when you're working with just a few other people. That argument you added? You just broke a bunch of functions one of your teammates was planning and when she commits her code, now she gets merge conflicts, which cost her an hour to fix because she has to catch up to whatever design change you made. This lack of planning quickly turns into an uncoordinated mess of individual decision making. Suddenly you're spending all of your time cleaning up coordination messes instead of writing code. -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.html": "requirements specifications, which are declarations of what software must do from a users' perspective. We've also talked about architecture.html": "architectural specifications, 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_. +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: