요구 사항을 문서로 정리하기

생각 열기 — 사흘 뒤에 남는 것

1차시 회의에서 모둠이 이렇게 정했다.

“점수를 넣으면 평균이랑 최고점이 나오게 하자. 이상한 값은 걸러 내고.”

사흘 뒤 각자 만들어 온 것을 보니 이렇게 달랐다.

• A는 평균을 정수로 반올림했고, B는 소수점 둘째 자리까지 냈다.
• A는 이상한 값을 만나면 프로그램을 멈췄고, B는 0으로 바꿔 계산에 넣었다.
• A는 점수를 다섯 개만 받게 만들었고, B는 개수 제한을 두지 않았다.

왜 문서로 남기는가

요구 사항 명세서(requirements specification) — 프로그램이 해야 할 일과 지켜야 할 조건을 확인할 수 있게 적어 놓은 문서를 쓰는 까닭은 검사받기 위해서가 아니다. 세 가지 실제 쓸모가 있다.

1. 같은 것을 만들게 한다. 여럿이 나눠 만들 때 서로 다른 것을 만드는 일을 막는다.
2. 설계의 출발점이 된다. 3차시에서 구조를 나눌 때 이 문서의 기능 목록을 그대로 쪼갠다.
3. 테스트의 기준이 된다. 7·8차시에서 “제대로 만들었는가”를 판정하려면 미리 정한 기준이 있어야 한다. 이 문서가 그 기준이다.

기능 요구와 비기능 요구

요구 사항은 두 갈래로 나눠 적는다.

기능 요구와 비기능 요구

갈래	무엇을 적는가	예	빠뜨리면
기능 요구	프로그램이 무엇을 하는가	점수 목록을 받아 평균을 계산해 보여 준다	만들다가 바로 티가 난다
비기능 요구	프로그램이 어떤 조건을 지키는가	설치 없이 전산실 브라우저에서 실행된다 / 300개 자료를 3초 안에 처리한다	다 만든 뒤에 드러나 되돌리기 어렵다

비기능 요구가 위험한 이유는 만드는 동안 아무 문제도 일으키지 않기 때문이다. 1단원 5차시 활동의 도서 대출 프로그램이 그랬다. 5권으로 시험할 때는 잘 됐지만 8,400권을 넣자 40초가 걸렸다. “몇 권까지 몇 초 안에”가 적혀 있지 않았던 것이다.

확인할 수 있게 적는다

명세서에 적힌 문장은 나중에 참인지 거짓인지 판정할 수 있어야 한다. 판정할 수 없는 문장은 요구 사항이 아니다.

판정할 수 없는 문장을 판정할 수 있게 고치기

이렇게 적으면 안 된다	왜 안 되는가	이렇게 고친다
평균을 보여 준다	몇 자리까지? 반올림인가 버림인가?	평균을 소수점 첫째 자리까지 반올림해 보여 준다
이상한 값은 걸러 낸다	무엇이 이상한 값인가? 걸러 낸 뒤 어떻게 알리는가?	0 미만 또는 100 초과인 값은 계산에서 빼고, 제외한 개수를 함께 보여 준다
많은 점수를 넣을 수 있다	몇 개까지인가?	한 번에 최대 300개까지 받는다
빠르게 처리된다	얼마나?	300개 자료를 3초 안에 처리한다
사용하기 편하다	무엇이 편한 것인가?	점수를 모두 입력한 뒤 단추 한 번으로 결과가 나온다
오류가 나지 않는다	증명할 수 없다	점수 자리에 글자를 넣어도 프로그램이 멈추지 않고 몇 번째 값이 잘못됐는지 알린다

우선순위를 매긴다

1차시에서 기능을 세 갈래(반드시 / 있으면 좋음 / 하지 않음)로 나눴다. 명세서에도 그 순위를 함께 적는다. 시간이 모자랄 때 무엇을 버릴지 미리 정해 두는 것이 우선순위의 목적이다.

요구 사항 명세서 — 예시 프로젝트

1차시에서 기획한 반 성적 정리 프로그램의 명세서다. 이 문서가 3차시 설계의 입력이 되고, 7·8차시 테스트의 기준이 된다.

1. 개요

항목	내용
프로그램 이름	반 성적 정리
사용자	수행평가 점수를 정리하는 담임 교사
해결할 문제	점수를 손으로 더하다 실수가 나고, 잘못 입력된 점수를 눈으로 찾아야 한다
만들지 않는 것	학생 이름 관리, 성적표 출력, 여러 반 동시 처리

2. 기능 요구

번호	요구 사항	우선순위
F1	정수 점수를 여러 개 입력받는다. 한 번에 최대 300개까지 받는다	반드시
F2	0 미만 또는 100 초과인 값은 계산에서 제외하고, 제외한 개수를 함께 보여 준다	반드시
F3	계산에 쓴 인원수, 평균, 최고점, 최저점을 보여 준다. 평균은 소수점 첫째 자리까지 반올림한다	반드시
F4	쓸 수 있는 점수가 하나도 없으면 “쓸 수 있는 점수가 없다”고 알리고 끝낸다	반드시
F5	90 이상 A, 80 이상 B, 70 이상 C, 그 미만 D로 등급을 세어 보여 준다	있으면 좋음
F6	결과를 파일로 저장한다	있으면 좋음

3. 비기능 요구

번호	요구 사항
N1	전산실 컴퓨터에서 새 프로그램 설치 없이 실행된다
N2	300개 자료를 3초 안에 처리한다
N3	실제 학생 이름·학번을 저장하거나 입력받지 않는다
N4	점수 자리에 글자가 들어와도 프로그램이 멈추지 않고 몇 번째 값이 잘못됐는지 알린다

4. 확인 방법

각 요구가 지켜졌는지 어떻게 판정할지 미리 적어 둔다. 이 칸이 7차시 테스트 사례의 뼈대가 된다.

번호	넣을 값	기대하는 결과
F2	88, 92, 75, 100, 64, −5, 120	제외 2건으로 표시된다
F3	위와 같음	인원 5명, 평균 83.8, 최고 100, 최저 64
F3	0, 100	평균 50.0 (경계값이 계산에 들어간다)
F4	−1, 200	“쓸 수 있는 점수가 없다”
N4	88, 칠십오, 92	두 번째 값이 잘못됐다고 알리고 계속 진행한다

디지털 도구로 공유한다

명세서를 한 사람의 컴퓨터에만 두면 1단원 9차시에서 다룬 문제가 그대로 생긴다 — 최신본을 모르고, 고친 이유를 모르고, 되돌릴 수 없다.

• 함께 편집되는 문서 도구에 둔다. 누가 언제 무엇을 고쳤는지 기록이 남는 것을 고른다.
• 한 곳만 정본으로 둔다. 내려받아 고친 사본이 돌아다니면 다시 최신본을 모르게 된다.
• 고칠 때 이유를 남긴다. “F3 평균 자릿수 소수 첫째로 확정 — 교사 요청”처럼 적는다.
• 공유 범위를 확인한다. 링크를 아는 사람 모두가 볼 수 있게 열어 두면, 나중에 개인정보가 섞였을 때 되돌릴 수 없다.

활동

프로젝트

요구 사항 명세서 작성과 모둠 간 상호 검토

약 45분

1차시에서 정한 주제로 명세서를 쓴다. 코드는 아직 쓰지 않는다.

1단계 — 명세서를 쓴다 (20분)

위 예시와 같은 네 부분을 채운다.

1. 개요 — 프로그램 이름, 사용자, 해결할 문제, 만들지 않는 것
2. 기능 요구 — 번호를 붙여 적고 우선순위를 매긴다. “반드시”는 최대 4개까지만 허용한다
3. 비기능 요구 — 최소 3개. 환경·성능·개인정보를 반드시 하나씩 포함한다
4. 확인 방법 — 기능 요구마다 넣을 값과 기대 결과를 적는다. 기대 결과는 손으로 계산해 확인한다

2단계 — 상호 검토 (15분)

옆 모둠과 명세서를 바꾼다. 읽는 사람은 만든 사람에게 묻지 않고 표에 표시한다.

검토 항목	몇 번 요구에서 걸렸는가
두 가지로 읽힐 수 있는 문장이 있는가
참·거짓을 판정할 수 없는 문장이 있는가
숫자가 빠진 곳이 있는가 (몇 개, 몇 초, 몇 자리)
확인 방법의 기대 결과가 비어 있거나 계산되지 않은 곳
“반드시”가 4개를 넘는가

3단계 — 고친다 (10분)

검토받은 것을 반영해 고친다. 고칠 때마다 무엇을 왜 고쳤는지 문서 아래에 한 줄로 남긴다.

이 명세서는 다음 차시부터 계속 쓴다. 3차시에서는 기능 목록을 함수로 쪼개고, 7차시에서는 4번 표를 테스트 사례로 옮긴다. 여기서 대충 적으면 뒤가 전부 흔들린다.

개념 확인 문제

보기를 누르면 바로 채점된다. 틀려도 해설을 읽으면 된다.

요구 사항을 문서로 남기는 이유로 알맞지 않은 것은?프그03-01

1. 1여럿이 나눠 만들 때 서로 다른 것을 만드는 일을 막는다
2. 2설계 단계에서 기능을 쪼갤 근거가 된다
3. 3테스트에서 무엇을 확인할지 정하는 기준이 된다
4. 4문서를 쓰면 프로그램이 자동으로 만들어진다

다음 중 비기능 요구에 해당하는 것은?프그03-01

1. 1점수 목록을 받아 평균을 계산해 보여 준다
2. 2최고점과 최저점을 함께 보여 준다
3. 3전산실 컴퓨터에서 설치 없이 실행된다
4. 4쓸 수 있는 점수가 없으면 그 사실을 알린다

'이상한 값은 걸러 낸다'를 확인할 수 있는 요구 사항으로 가장 잘 고친 것은?프그03-01

1. 1이상한 값을 잘 걸러 낸다
2. 20 미만 또는 100 초과인 값은 계산에서 빼고, 제외한 개수를 함께 보여 준다
3. 3오류가 나지 않도록 처리한다
4. 4값을 안전하게 검사한다

모둠에서 기능 우선순위를 매길 때 전부 '반드시'가 되었다. 순위를 가르는 판단 기준으로 알맞은 것은?프그03-01

1. 1만들기 쉬운 순서로 정한다
2. 2코드가 짧은 순서로 정한다
3. 3이 기능이 없어도 사용자가 이 프로그램을 쓸 이유가 있는지 묻는다
4. 4모둠원이 좋아하는 순서로 정한다

명세서의 '확인 방법' 표에 적는 기대 결과는 어떻게 정해야 하는가?프그03-01

1. 1프로그램을 실행해서 나온 값을 그대로 적는다
2. 2손으로 계산해 확인한 값을 미리 적는다
3. 3비워 두었다가 나중에 채운다
4. 4대략적인 범위만 적는다

명세서를 디지털 협업 도구에 둘 때 지킬 일로 알맞지 않은 것은?프그03-01

1. 1누가 언제 무엇을 고쳤는지 기록이 남는 도구를 고른다
2. 2한 곳만 정본으로 두고 사본을 돌리지 않는다
3. 3고칠 때 무엇을 왜 고쳤는지 남긴다
4. 4누구나 볼 수 있도록 링크를 넓게 공개해 둔다

더 알아보기

심화사용자 이야기로 적는 방법

요구 사항을 표 대신 한 문장 형식으로 적는 방법도 널리 쓰인다. “〈사용자〉로서 〈무엇〉을 하고 싶다. 왜냐하면 〈이유〉이기 때문이다.” 예를 들면 “담임 교사로서 잘못 입력된 점수를 자동으로 걸러 내고 싶다. 손으로 찾다가 놓치기 때문이다.” 이렇게 적으면 이유가 함께 남는다는 장점이 있다. 나중에 그 기능을 고칠지 뺄지 판단할 때, 무엇을 하려던 것인지 알 수 있다. 표 형식과 섞어 써도 된다.

실무요구 사항은 반드시 바뀐다

아무리 잘 적어도 만드는 도중에 요구 사항은 바뀐다. 쓰는 사람이 중간 결과를 보고 나서야 자기가 원하던 것을 알아차리는 일이 흔하기 때문이다. 그래서 바뀌는 것을 막으려 하지 않고, 바뀐 것을 기록하는 쪽으로 관리한다. 명세서에 “고침 이력” 칸을 두고 언제 무엇을 왜 바꿨는지 남기면, 나중에 “이건 원래 이랬는데 왜 바뀌었지”를 되짚을 수 있다. 1단원 4차시에서 다룬 반복 방식이 이런 상황을 전제로 한 것이다.

심화모호한 말 목록을 만들어 두면 편하다

명세서를 검토할 때 찾아볼 말을 미리 정해 두면 빠르다. 적당히 · 알맞게 · 충분히 · 빠르게 · 많이 · 쉽게 · 편하게 · 안전하게 · 필요하면 · 등등 · 기타. 이런 말이 보이면 그 문장은 아직 요구 사항이 아니다. 문서를 다 쓴 뒤 이 말들을 찾아 하나씩 숫자나 규칙으로 바꾸는 것만으로도 명세서의 질이 크게 올라간다. 1단원 6차시에서 알고리즘의 명확성을 다룰 때 나온 말들과 같은 목록이다.