7.소프트웨어 공학 요구사항 (2)

4. 요구사항의 표현

표현과 모델의 이해

표현

• 생각하거나 느낀 것을 표현하는 방법은 다양
• 수학 공식은 글로 표현하면 너무 길고 불분명해지는 내용을 공통으로 이해할 수 있고 오해의 소지가 없는 특정 기호로 표현

모델

• 표현을 위해 사용하는 악보나 수학 공식은 하나의 모델
• 장난감 자동차나 로봇, 생명 과학자들이 사용하는 DNA 분자 모형 등 또한 모델의 종류

모델의 정의와 필요성

모델의 정의와 필요성

• 복잡한 대상의 핵심 특징만 선별해 일정한 관점으로 단순화한 뒤 기호나 그림 등을 사용해 체계적으로 표현한 것
• 모델이 필요한 가장 큰 이유는 실제 모습을 미리 확인하기 위함 (예: 모델하우스)
• 하나의 사물도 여러 모델이 필요 (예: 건물 건설시 여러 관점과 사용 목적에 따라 다수의 도면이 필요)

소프트웨어 개발 모델

• 건축에 여러 도면이 필요하듯이 소프트웨어를 개발할 때도 여러 종류의 모델이 필요
• 객체지향 개발에서는 UML의 다양한 다이어그램을 통해 개발 소프트웨어의 범위나 개략적인 구조와 기능을 이해할 수 있음
• UML의 수많은 다이어그램이 소프트웨어 개발 과정에서 하나의 모델로 사용

소프트웨어 개발 모델 사용의 장점

이해도 향상

• 모델을 사용하려면 실제 개발 범위에 해당하는 복잡한 내용을 단순화해야 하므로 개발 영역을 더 정확히 이해할 수 있음
• 프로그램의 전체 모습을 시각적으로 나타낼 수 있으므로 사용자는 관련 요소들의 상호 관계를 빨리 파악할 수 있음
• 이해 당사자 간의 의사소통 도구로 활용할 수 있음

유지보수 용이

• 추후 요구사항 변경에 따른 유지보수에 활용할 수 있음
• 이 후 유사한 시스템을 개발할 때도 활용해 개발 기간과 비용을 줄여줌

소프트웨어 개발 모델 사용의 단점

과도한 문서 작업으로 일정 지연

• 단계마다 각종 다이어그램을 포함한 문서 작성에 많은 시간을 할애하다 보면 실제 개발 업무가 지연될 수 있음

형식적인 산출물로 전락할 가능성

• 단계마다 수많은 문서가 형식적으로만 만들어져 활용되지 못할 수 있음
• 변경된 내용을 산출물에 즉시 반영하지 않으면 문서 자체가 사장될 가능성이 높음

모델링

모델링의 개요

• 앞서 설명한 모델을 제작하는 과정 또는 작업
• 연필로 종이에 간단한 콘티를 작성하거나 스토리보드같이 자기가 표현하고 싶은 것을 문장으로 서술하는 것도 한 종류
• 각 전문 분야의 모델링은 기호나 다이어그램, 표기법 등을 사용해 차이가 없이 일관성 있는 해석이 가능하도록 표현

자연어를 사용한 표현

• 사용자 요구사항을 자연어로 표현(모델링)하는 것
• 도구나 기술을 따로 익힐 필요가 없 고 사용자와 대화할 때도 이해하기 쉬움
• 표현이 길어질 수 있고 해석이 달라질 수 있으며 표현된 내용을 검증하기가 어려움

형식 언어를 사용한 표현

• 친숙하지는 않지만 문법과 의미가 수학을 기초로 작성되어서 간결하고 정확하게 표현할 수 있음
• 표기법을 별도로 공부해야 하므로 일반 개발자가 사용하기에는 조금 어려운 편
  • 관계형 표기법: 함의 방정식, 순환 관계, 대수 공리, 정규 표현법을 사용
  • 상태 위주 표기법: 의사결정 테이블, 이벤트 테이블 , 전이 테이블, 유한 상태 기계, 페트리 넷을 사용

UML 다이어그램을 사용한 표현

• UML 다이어그램을 사용하면 개발할 소프트웨어를 가시적으로 볼 수 있고, 개발할 소프트 웨어에 대한 문서화도 가능
• 이 문서들은 분석 및 설계 과정에서 유용하며 검증 자료로도 활용

모델링 언어

모델링 언어의 정의

• 모호한 표현의 문제를 해결하기 위해 사용하는 기호, 표기법, 도구
• 악보 기호, 수학 기호 등과 UML 다이어그램, Z 언어와 같은 형식적 표기법 등

소프트웨어 개발에서의 모델링 언어

• 요구사항 정의 및 분석·설계의 결과물을 다양한 다이어그램으로 표현하는 표기법
• 모호한 표현이 없고 일관되어 모델링을 하는 데 매우 유용
• 개발자 간에 원활하게 의사소통할 수 있고 시스템을 주관적으로 해석하는 일도 줄어듬
• 다양한 다이어그램을 사용하므로 시스템을 여러 시각으로 볼 수 있음
• 사용자 요구사항을 검증하는 의사소통 도구로도 사용

개발 방법에 따른 모델링 언어

• 구조적 방법: 자료 흐름도(DFD), 자료 사전(DD), 소단위명세서를 사용해 요구분석 결과를 표현
• 정보공학 방법: E-R 다이어그램(ERD)을 데이터베이스 설계 표현을  사용
• 객체지향 방법: 이 방법은 대부분의 나라에서 공통으로 사용하는 UML 표기법을 사용
  • UML 표기법은 10여 개의 다이어그램으로 구성되어 있으며 특히 요구사항은 유스케이스 다이어그램을 사용해 표현

구조적 방법의 표현 도구: DFD

자료 흐름도

• 자료 흐름도: 들어온 자료를 처리한 후 결과를 내보내는 과정을 나타낸 것

자료 흐름도 작성 단계

[1단계] 처리 표현: DFD를 작성할 때는 먼저 필요한 기능이 무엇인지 찾아내야 함

[2단계] 입력과 출력 자료 표현: 학점계산에 대한 입력 자료와 출력 자료를 찾아 화살표 위에 나타냄

[3단계] 자료 저장소 표현: 처리할 자료가 많아 데이터베이스 테이블로 저장되어 있다면 자료 저장소로 나타냄

[4단계] 자료 출원지와 목적지 표현: 자료의 출원지와 목적지도 DFD에 표현해야 함 자료의 출원지와 목적지는 사각형 박스로 표현 (터미네이터)

구조적 방법의 표현 도구: DFD

자료 사전

• 자료 사전(DD): 자료 흐름도(DFD)에 존재하는 데이터에 대한 자세한 설명을 기록해 놓은 것
• 자료 사전은 몇 가지 기호를 사용해 자료를 정의

자료 사전 작성의 예

• 교과목은 과목번호, 과목명, 이수 구분, 학점(시수), 개설 학년(학기)으로 구성
• 과목번호는 교과목을 구별할 수 있는 유일한 키 값으로 사용
• 학점은 1학점 또는 2학점 또는 3학점 중 하나
• 시수는 1주일에 몇 시간 강의하는지를 나타냄
• 이수 구분은 대학 기초 또는 전공 필수 또는 전공 선택 또는 교직 중 하나
• 개설 학년은 1학년 또는 2학년 또는 3학년 또는 4학년 중 하나
• 개설 학기는 1학기 또는 2학기 또는 계절학기 중 하나

소단위명세서

• 소단위명세서: DFD에서 원으로 표시한 프로세스인 처리는 실제 알고리즘 형태로 작성한 것
• 소단위명세서를 작성하는 도구에는 구조적 언어, 선후 조건문, 의사 결정표 등이 있음

정보공학 방법의 표현 도구: E-R 다이어그램

E-R 다이어그램

객체지향 방법의 표현 도구: 유스케이스 다이어그램

유스케이스 다이어그램 작성하기

[1단계] 후보 유스케이스 도출

[2단계] 후보 유스케이스 검토 / 교수 액터가 사용하는 유스케이스 [2단계] 후보 유스케이스 검토 / 학생 액터가 사용하는 유스케이스 [2단계] 후보 유스케이스 검토 / 조교 액터가 사용하는 유스케이스 [2단계] 후보 유스케이스 검토 / 학사담당직원 액터가 사용하는 유스케이스

[2단계] 후보 유스케이스 검토 / 유스케이스 특성 확인 및 통합

• 실행 후 사용자가 원하는 결과 제공: 결과물을 제공하는 지 다시 검토
• 사용자에 의해 시작: 어떤 사용자가 사용하는지, 어 떤 사용자가 시작하는지를 생각
• 많이 사용하는 기능은 하나의 유스케이스로 도출: ‘등록/수정/조회/삭제’ 기능은 하나의 유스케이스로 만드는 것이 타당

사용하는 기능만 유스케이스로 도출

• 여러 기능을 단순화해 하나의 유스케이스로 만들면 사용자는 그 안에 포함된 기능을 모두 사용해야 함

주 기능은 유스케이스, 보조 기능은 이벤트 흐름

• 가장 핵심이 되는 기능은 유스케이스로 나타내고 나머지는 이벤트 흐름에 나타냄

• 홀로 존재하는 유스케이스는 없음: 홀로 존재하는 유스케이스는 불필요한 것일 가능성이 높으므로 재검토

[3단계] 유스케이스 정렬

유스케이스 명세서 작성하기

• 유스케이스 다이어그램을 작성하면 각각의 유스케이스에 대한 명세서를 작성해야 함
• 유스케이스 명세서는 7개 항목으로 구성되며 각 유스케이스의 자세한 내용을 기술하는 문서

개요

• 유스케이스가 제공하는 기능을 나타내는 것으로, 그 기능을 사용하는 사용자 액터까지 표현해야 함

유스케이스	개요
수강신청	학생은 시스템이 제공하는 개설과목 목록에서 수강할 과목을 선택한다. ‘과목삭제’와 ‘과목추가’ 기능이 포함되어 있다.

• 개요는 유스케이스에 포함된 모든 기능을 액터까지 포함해서 표현해야 함

유스케이스	개요
성적등록	교수는 학생의 성적을 입력한다	X
성적등록	성적을 입력하고 수정한다	X
성적등록	교수는 학생의 성적을 입력하고 수정한다	O

• 유스케이스의 기능은 이벤트 흐름에서 별도로 자세히 표현하기 때문에 개요에서는 간략하게 나타냄

관련 액터

• 유스케이스를 사용하는 액터를 나타냄
• 관련 액터 항목에 나타낸 액터와 유스케이스 다이어그 램에서 연관 관계를 맺고 있는 액터는 일치해야 함

유스케이스	관련 액터
수강신청	학생

우선순위

• 개발할 때의 순서를 나타낸 것
• 기준을 정하고 그에 따른 개발 순서를 정한다면 프로젝트 관리 측면에서 도움이 됨
• 우선순위는 사용자 관점에서 정할 수도 있고, 개발자 관점에서 정할 수도 있음
• 중요도로 정하는 사용자 관점 우선순위: 일정 조절, 자원 배분, 인력 투입 등에서 균형 있게 프로젝트 관리를 할 수 있음
• 개발 난이도로 정하는 개발자 관점 우선순위: 개발 난이도를 기준으로 ‘상’, ‘중’, ‘하’를 결정

선행 조건

• 해당 유스케이스를 수행하기 위해 미리 만족해야 하는 상태나 조건
• 해당 유스케이스를 수행하기 위한 직전의 선행 조건 유스케이스를 기입

유스케이스	선행 조건
수강신청	개설과목등록

후행 조건

• 유스케이스 수행 후 만족해야 하는 상태
• 상태나 수치의 바뀐 모습을 명확하고 구체적으로 작성
• 모호하게 기술하지 않고 객관적으로 판단할 수 있게 작성

유스케이스	후행 조건
수강신청	수강신청을 한 총 학점이 표시되어야 한다

이벤트 흐름

• 유스케이스 기능에 대한 액터와 시스템 간의 대화로 문장이나 순차 다이 그램을 사용해 표현
• 사용자가 이해할 수 있는 쉬운 용어로 명확하게 작성해야 하며 당연히 개발자가 사용하는 기술적 용어는 사용해선 안됨
• 작성된 이벤트 흐름은 개발자들이 설계와 테스트 단계에서도 활용
• 유스케이스의 큰 줄기에 해당하는 정상적인 흐름은 기본 흐름으로, 나머지는 대안 흐름에 표현
• 이벤트 흐름은 순차 다이어그램으로도 표현할 수 있음

기본 흐름

• 가장 일반적이고 정상적인 흐름
• 액터와 시스템의 대화를 정리하다 보면 정상적인 흐름은 한 가지로 작성

대안 흐름

• 기본 흐름을 제외한 나머지 발생 가능한 여러 경우의 액터와 이벤트 간 대화 내용을 정리한 것
• 예외적이거나 특수한 상황이 포함

비기능 요구사항 요구

• 비기능 요구사항: 성능, 신뢰성, 보안성, 가용성 등 여러 요구 품질 요소를 나타냄
• 요구분석명세서의 비기능 요구사항은 유스케이스와 직접 관련이 있는 비기능 요구사항을 기술하는 것

유스케이스	비기능 요구사항
도서 검색	3초 이내에 결과가 나타나야 한다	X
도서 검색	1백만 권까지 3초 이내에 결과가 나타나야 한다	O
수강 신청	전교생이 동시에 접속해도 문제가 없어야 한다	X
수강 신청	수강신청 시 2,000명까지 동시 접속해도 1기가바이트 이상의 속도가 유지되어야 하고, 시스템이 멈추지 않아야 한다	O

• 이벤트 흐름

---

5. 요구사항의 문서화

소프트웨어 요구분석명세서의 정의

• 요구분석 과정의 최종 산출물로 사용자와 개발자를 연결하는 중요한 문서
• 설계와 구현에서 참조할 사항, 전반적으로 알아야 할 사항을 포함하는 문서
• 사용자와 개발자의 계약서

요구분석명세서 작성

• 분석가와 사용자의 배경 지식이 너무 다르기 때문에 분석가가 요구분석명세서를 작성하는 일은 어려움
• 완전한 요구분석명세서를 작성하려면 분석가는 현행 업무 내용을 충분히 파악한 후 사용자와 대화할 수 있도록 준비
• 입출력 화면 등이 어떻게 구성되는지 사용자에게 설명하면서 사용자가 느끼는 문제점과 원하는 요구사항을 파악해야 함
• 분석가가 작성한 요구분석명세서는 사용자에게는 계약서, 개발자에게는 설계 및 구현을 위한 공식 문서로 사용
• 소프트웨어 개발과 관련된 이해 당사자에게는 중요한 기준이 되는 문서

요구분석명세서 작성 시 주의 사항

사용자가 쉽게 읽고 이해할 수 있도록 작성

• 사용자와의 관계에서 요구분석명세서는 계약서와 같은 효력이 있음
• 문제가 발생해 분쟁으로까지 이어질 때는 약관이 매우 중요한 근거 자료로 활용되고 잘잘못에 대한 판단 기준이 됨
• 상품의 약관처럼 작성해서는 안 되고 사용자가 쉽게 읽고 이해할 수 있도록 작성해야 함

개발자가 설계와 코딩에 효과적으로 사용할 수 있도록 작성

• 개발자가 해당 문서를 기반으로 설계하고 코딩하며 검증 기준으로 사용 하는 등 여러 목적으로 활용할 수 있게 제공해야 함

비기능 요구를 명확히 작성

• 요구분석명세서에 서술된 기능과 제약 사항은 사용자와 개발자 모두 충분히 동의해야 함
• 사용자는 적절한 개발비를 제시해야 하고 요구사항도 개발 기간 내에 끝낼 수 있을 정도여야 해야함
• 개발자도 요구사항을 수용하기 위해 드는 비용과 기간, 불가능한 요구 등을 사용자에게 정확히 알려주고 이해시킴
• 제약 사항과 같은 비기능 요구사항은 사용자가 명확히 알 수 있도록 작성

테스트 기준으로 사용할 수 있도록 정량적으로 작성

• 소프트웨어 요구분석명세서는 테스트 기준을 작성하고 테스트 케이스를 만드는 데도 사용
• 원하는 기능 요구사항뿐만 아니라 품질과 제약 사항 등의 비기능 요구사항을 가능한 정량적으로 명확히 작성

품에 대한 우선순위 명시

• 품질 특성이 서로 상충하는 경우에 어떤 특성을 우선순위에 둘 것인지를 명시해야 함
• 상충 관계: 어느 한쪽이 좋으면 다른 한쪽은 손해를 보는 관계(예: 터널공사)
• 요구사항의 품질도 이런 상충 관계가 성립될 수 있음(보안성 <-> 사용자 편의성)

잘 만든 요구분석명세서의 특성

완전성

• ‘완전하다’라는 말은 빠진 부분 없이 모두 있다는 의미
• 요구분석명세서는 기능 요구사항 뿐 아니라 성능, 제약 사항 등의 비기능 요구사항이 빠지지 않고 모두 서술되어야 완전
• 요구사항 정의 및 분석 과정에서 아주 드물게 발생할 수 있는 것까지도 찾아내 반영해야 완전성을 충족하는 요구분석명세서

일관성

• 상반된 요구뿐 아니라 불일치하거나 중복된 요구가 존재하면 일관성이 없는 요구분석명세서
• 예) 아무나 접근할 수 없게 보안을 매우 철저히 해주고 사용자들이 인증 절차를 번거롭지 않고 단순하게 사용할 수 있음

명확성

• 요구분석명세서도 계약서와 같은 역할을 수행하므로 요구사항, 비용, 기간 등에서 문제가 발생하면 근거가 됨
• 요구사항을 잘못 해석해 의도하지 않은 결과를 초래할 수 있으므로 누구나 같은 해석을 하도록 표현을 명확히 해야 함

유스케이스	비기능 요구사항
도서 검색	3초 이내에 결과가 나타나야 한다	X
도서 검색	1백만 권까지 3초 이내에 결과가 나타나야 한다	O
수강 신청	전교생이 동시에 접속해도 문제가 없어야 한다	X
수강 신청	수강신청 시 2,000명까지 동시 접속해도 1기가바이트 이상의 속도가 유지되어야 하고, 시스템이 멈추지 않아야 한다	O

추적 가능성

추적이 가능하도록 요구분석명세서를 작성

변경 용이성

• 한 곳의 변경으로 인해 다른 곳에 미치는 영향이 작은 것
• 요구사항끼리 영향을 덜 미치려면 서로 의존도가 낮고 독립적으로 서술되어야 함

검증 가능성

• 요구분석명세서가 시스템이 요구사항을 만족하는지를 체계적으로 검사할 수 있다면 검증 가능성은 큼
• 요구분석명세서가 모호한 표현이 많이 포함되게 작성되었다면 검증 가능성은 작음
• 예) ‘많은 학생이 동시에 수강신청을 해도 문제가 없어야 한다’ 에서 ‘많은’은 주관적인 표현이므로 객관적인 수치로 변경

비정형 명세 기법

• 사용자 요구를 표현할 때 자연어를 기반으로 서술하거나 작업 흐름도와 같은 다이어그램을 사용해 작성
• 특별한 기술이 필요하지 않아 요구사항을 작성하기 쉬움
• 명세 내용을 이해하기 쉬워 사용자와 분석가의 의사소통이 쉬움

• 분석하는 과정에서 사용자의 적극적인 관심과 참여를 유도할 수 있음

• 자연어로 작성하면 표현이 모호할 수 있고, 해석을 다르게 할 수도 있음’일관성이 떨어질 수 있고 명세가 불충분할 수 있음
• 작성된 내용이 사용자 요구를 충분히 반영해서 표현하고 있는지 완전성을 검증하기가 어려움

정형 명세 기법

• 사용자의 요구를 수학적 원리와 표기법을 이용해 표현하는 것(Z 정형 명세 언어)사용자 요구를 정확하고 간결하게 표현할 수 있음
• 수학에서 사용되는 증명 기술을 이용해 작성된 사용자 요구가 일관성이 있는지, 완전한지 등을 검증할 수 있는 장점이 있음
• 사용자 요구를 정형화된 형태로 작성함으로써 효율적으로 테스트 케이스를 생성할 수 있음
• 이 테스트 케이스는 명세 내용과 구현의 일치 여부를 확인하는 데 사용할 수 있음
• 수학적 원리와 표기법을 사용하려면 분석가가 관련된 수학 지식이 있어야 함
• 수학적 표현으로 작성된 표기법을 충분히 이해할 수 있어야 함
• 이 표기법을 사용해 사용자 요구를 정확히 표현할 수 있어야 함

요구사항 검증

• 여러 방법을 통해 추출하고 정리한 사용자의 요구분석명세서가 정확하고 완전하게 서술되었는지 검토하는 활동
• 사용자 요구사항이 완전하게 서술되었는지 검증
• 요구분석명세서를 작성할 때 문서 표준을 따랐는지 확
• 설계에서 사용하기에 적합한지를 확인