요구사항 명세
— 사용자 요구사항 및 시스템 요구사항을 문서로 작성하는 과정
이상적인 요구사항 작성
- 조건
- 대상 : 사용자 요구사항과 시스템 요구사항 모두
- 특징 : 명확하고, 모호하지 않으며, 이해하기 쉽고, 완전하고, 일관성 있어야 함
- 실제로 달성 어려움 ← 충돌이나 불일치 자주 발생 ← 이해당사자들 간의 다른 해석
사용자 요구사항 작성
- 단순한 표, 양식, 직관적 다이어그램을 가지고 자연어로 작성
- 기술적 지식이 없는 시스템 사용자가 이해할 수 있도록 기능적/비기능적 요구사항을 포함
- 시스템의 외부 동작에 대해서만 명세
- 시스템 아키텍처나 설계에 대한 상세한 내용 X
시스템 요구사항 작성
- 사용자 요구사항에 상세한 내용 추가
- 시스템의 외부 동작과 운영상의 제약에 대해서만 기술
- 시스템의 설계와 구현에 대해서는 다뤄선 안됨
- 하지만 복잡한 소프트웨어 시스템에서는 설계 정보를 모두 제외할 수 없음
- 시스템의 설계와 구현에 대해서는 다뤄선 안됨
복잡한 시스템에서 설계 정보를 제외할 수 없는 이유
- 요구사항 명세서의 구조를 잡는데 도움을 주기 위해 시스템의 초기 아키텍처를 설계해야 하는 경우
- 예 ) 시스템을 구성하는 다양한 서브 시스템에 따라 시스템 요구사항을 구성
- 예 ) 시스템을 구성하는 다양한 서브 시스템에 따라 시스템 요구사항을 구성
- 기존 시스템과 상호작용하는 시스템을 구현하는 경우
- 대부분의 경우, 시스템은 설계를 제한하고 신규 시스템에 요구사항을 부여하는 기존 시스템과 상호작용
- 대부분의 경우, 시스템은 설계를 제한하고 신규 시스템에 요구사항을 부여하는 기존 시스템과 상호작용
- 비기능적 요구사항을 만족시키기 위해 특정 아키텍처를 사용해야만 하는 경우
- 시스템이 안전함을 인증해야 하는 경우, 이미 인증을 받았던 아키텍처 설계를 사용해야 한다고 할 수 있음
- 예) N 버전 프로그래밍
시스템 요구사항을 작성하기 위한 표기법
자연어 문장- 요구사항을 작성할 때 번호를 붙인 자연어 문장으로 작성
- 각 문장은 하나의 요구사항
구조적 자연어- 표준 양식이나 템플릿에 따라 자연어로 요구사항 작성
- 각 필드는 요구사항의 한 양상에 대한 정보 제공
그래픽 표현- 문자 표기법으로 보충한 그래픽 모델로 시스템의 기능적 요구사항 정의
- UML 유스케이스와 시퀀스 다이어그램을 흔히 사용
수학적 명세- 유한-상태 머신이나 집합 같은 수학적 개념에 기반
- 분명한 명세로 요구사항 문서의 모호성을 줄여줄 수 있지만 고객들의 대부분은 정형적 명세 이해 X
→ 고객은 그 내용을 시스템 계약으로 채택하는데 주저함
자연어 명세
- 1950년대부터 사용
- 장점 : 표현력 풍부, 직관적이고 보편적임
- 단점 : 애매하고 모호하며, 읽는 사람의 배경에 따라 다르게 해석될 여지가 있음
- 시스템과 소프트웨어 요구사항 명세에 가장 많이 사용되는 수단
- 단점으로 인해 다양한 대안 제안되었으나, 어떠한 제안도 널리 채택 도지 못함
- 단점으로 인해 다양한 대안 제안되었으나, 어떠한 제안도 널리 채택 도지 못함
- 요구사항 예시
- 매 10분마다 시스템은 혈당량을 측정하고 필요한 경우 인슐린을 전달해야 한다.
- 시스템은 테스트할 조건에 대해 매분마다 정기적인 자가진단을 실시해야 하며 이와 관련된 동작을..
자연어 명세의 기본적인 가이드라인
- 표준 형식을 만들어 적용할 것
- 모든 요구사항 정의가 그 형식을 따르도록 할 것
→ 표준화를 통해 누락을 줄이고 요구사항을 쉽게 확인 가능 - 자연어로 1~2 문장 정도로 작성
- 모든 요구사항 정의가 그 형식을 따르도록 할 것
- 언어를 일관성 있게 사용할 것
- 필수적인 사항과 바람직한 사항을 구분하기 위해 필요
필수적인 요구사항: 대부분 “shall”을 사용해서 작성바람직한 요구사항: 요구사항 “should”를 사용해서 작성
- 필수적인 사항과 바람직한 사항을 구분하기 위해 필요
- 텍스트 강조를 사용할 것
- 요구사항의 중요 부분을 강조(굵게, 이탤릭, 색 등)
- 요구사항의 중요 부분을 강조(굵게, 이탤릭, 색 등)
- 요구사항을 읽는 사람이 기술적, 소프트웨어 공학적 언어를 이해할 것이라고 생각 X
- 전문용어, 약어, 두음문자 사용 X
- 아키텍처와 모듈 같은 언어는 오해하기 쉬움
- 가능하면 각각의 사용자 요구사항에 대한 근거를 남길 것
- 요구사항을 왜 포함시켰는지, 누가 요사항을 제안하였는지 등을 알 수 있음
- 요구사항이 바뀌는 경우에 유용
구조적 명세
- 표준화된 방식을 따라 작성하는 시스템 요구사항 작성의 한 방법
- 자연어의 장점(표현력이 뛰어나며 이해하기 쉬움) + 어느 정도의 통일성 부여
- 자연어의 장점(표현력이 뛰어나며 이해하기 쉬움) + 어느 정도의 통일성 부여
- 자연어 명세의 문제점을 일부 제거 가능
- 명세 과정에서의 변동성을 줄이고 요구사항을 더 효과적으로 구성
- 명세 과정에서의 변동성을 줄이고 요구사항을 더 효과적으로 구성
- 복잡한 계산을 명세해야 하는 경우에는 여전히 어려움
- 이를 다루기 위해 표 또는 시스템의 그래픽 모델 등을 이용
- 시스템 상태의 변화나 사용자-시스템 간의 상호작용, 동작 순서 등을 알 수 있음
- 각 경우에 대해 수행해야 하는 동작을 설명하는 표를 이용하면 편함
- 템플릿 사용하여 시스템 요구사항을 명세
- 프로그래밍 언어 구조 이용하여 명세 가능
- 명암이나 폰트를 이용해서 강조 가능
- 요구사항에 대한 하나 이상의 템플릿을 정의하고 구조화된 양식으로 나타내야 함
- 시스템이 다루게 되는 객체들, 수행 기능들, 처리 이벤트들을 중심으로 명세를 구조화
- 시스템이 다루게 되는 객체들, 수행 기능들, 처리 이벤트들을 중심으로 명세를 구조화
- 예시
기능적 요구사항에서 포함해야 하는 정보
- 명세를 하는 기능이나 개체에 대한 설명
- 입력과 입력의 출처에 대한 설명
- 출력과 출력의 목적지에 대한 설명
- 계산에 필요한 정보나 시스템에서 필요한 다른 개체들에 대한 정보
- 수행해야 하는 동작에 대한 설명
- 기능적 방법을 사용하는 경우 → 사전조건 및 사후조건
- 동작으로 인한 부작용에 대한 설명
소프트웨어 요구사항 문서
- 개발자가 구현해야 하는 것에 대한 공식적인 내용
- 시스템에 대한 사용자 요구사항 + 시스템 요구사항에 대한 상세명세
- 두 요구사항이 하나로 통합되어 있는 경우도 있음
- 사용자 요구사항이 시스템 요구사항의 서론으로 들어가 있는 경우도 있음
- 요구사항 문서가 반드시 필요한 경우
- 시스템 개발을 외주로 맡길 경우
- 여러 팀이 시스템의 서로 다른 부분들을 개발할 경우
- 요구사항의 상세한 분석이 필수적일 경우
- 요구사항 문서가 필요 없는 경우
- 예) 소프트웨어 제품이나 비즈니스 시스템 개발과 같은 환경
애자일 기법에서의 요구사항 문서
- 공식적인 문서 사용 X
- 요구사항이 너무 빨리 바뀌기 때문 → 문서를 작성하는 노력이 낭비라고 생각
- 요구사항이 너무 빨리 바뀌기 때문 → 문서를 작성하는 노력이 낭비라고 생각
- 사용자 요구사항을 점진적으로 수집해서 카드에 작성 혹은 짧은 사용자 스토리로 칠판 기록 방식
- 이후, 사용자가 다음 시스템 증가분 구현에 필요한 스토리들의 우선순위를 정함
- 이후, 사용자가 다음 시스템 증가분 구현에 필요한 스토리들의 우선순위를 정함
- 요구사항이 불안정한 비즈니스 시스템은 적당한 접근법
- 비즈니스와 시스템에 대한 확실성 요구사항을 정의하는 보완문서는 짧게 작성
→ 전체 시스템에 적용해야 하는 요구사항을 잊기 쉽기 때문
- 비즈니스와 시스템에 대한 확실성 요구사항을 정의하는 보완문서는 짧게 작성
요구사항 문서의 사용자
- 다양한 부류의 사용자들이 요구사항 문서를 다룸
고객- 요구사항을 설명해야 함
- 요구사항을 설명해야 함
개발자와 테스터- 정확하고 상세한 수준으로 요구사항을 정의해야 함
- 향후 시스템 진화에 대한 정보도 포함해야 함
시스템 설계자 및 유지보수 엔지니어- 예상되는 변경에 대한 정보를 제공해야 함
- 제한적인 설계 결정을 피할 수 있음
- 신규 요구사항에 따라 시스템 변경 작업에 도움
요구사항 문서의 상세 수준
- 개발 시스템의 종류와 개발 프로세스에 따라 달라짐
- 중대한 시스템의 경우
- 상세한 요구사항 필요 → 안정성과 보안에 대한 분석 필요
- 상세한 요구사항 필요 → 안정성과 보안에 대한 분석 필요
- 시스템 개발을 여러 회사에서 나누어서 하는 경우
- 시스템 명세는 상세하고 정확해야 함
- 시스템 명세는 상세하고 정확해야 함
- 내부에서 반복적 프로세스를 사용하는 경우
- 요구사항 문서가 덜 상세해도 무관
← 시스템 개발 도중 내용 추가해서 모호성 해결 가능
- 요구사항 문서가 덜 상세해도 무관
요구사항 문서의 구조
서문- 새로운 버전 생성에 대한 근거와 각 버전에서 이루어진 변경에 대한 요약을 포함
- 예상하는 문서의 독자층을 정의하고 버전 내역 서술
도입- 시스템에 대한 필요성 설명, 시스템 기능 설명, 다른 시스템과의 상호작용 설명
- 시스템이 비즈니스 또는 조직의 전략적 목표와 부합하는지를 서술
용어 사전- 문서에서 사용하는 기술적 용어를 정의
- 문서에서 사용하는 기술적 용어를 정의
사용자 요구사항 정의- 사용자에게 제공할 서비스를 기술
- 비기능적 시스템 요구사항, 준수해야 하는 제품 및 프로세스 표준 기입
- 고객이 이해 가능한 자연어, 다이어그램이나 다른 표기법 사용 가능
시스템 아키텍처- 시스템 모듈 사이에 분포하는 예상 시스템 아키텍처에 대한 고수준의 개요를 보여준다
- 재사용할 아키텍처 컴포넌트는 강조한다.
시스템 요구사항 명세- 기능적/비기능적 요구사항을 상세하게 기술, 필요할 경우 비기능적 요구사항에 내용 추가
- 다른 시스템에 대한 인터페이스를 정의
시스템 모델- 시스템 컴포넌트 사이의 관계를 보여주는 그래픽 시스템 모델을 포함한다.
- 예 ) 객체모델, 데이터 흐름 모델, 시맨틱 데이터 모델
시스템 진화- 시스템이 기반하고 있는 여러 기저 환경들로 인해 예상되는 변경사항들을 기술한다.
- 여러 가지 환경 = 기본적인 가정, 하드웨어 개선, 사용자 요구 변화 등
- 시스템에서 향후 발생할 수 있는 변경을 제약하는 설계를 하지 않도록 도움
부록- 개발하는 애플리케이션과 관련한 상세하고 구체적인 정보 제공
- 예) 하드웨어와 데이터베이스 설명
- 하드웨어 요구사항 : 시스템에 대한 최소 최적 환경설정
- 데이터베이스 요구사항 : 데이터의 논리적 구조와 데이터 사이의 관계
색인- 문서에 다양한 색인들을 포함
- 알파벳 순서 색인, 다이어그램 인덱스, 기능 인덱스 등
요구사항 문서에 들어가는 정보
- 개발 소프트웨어 종류와 접근법에 따라 달라짐
- 복잡한 공학적 시스템의 경우
- 여러 회사들이 개발하는 하드웨어와 소프트웨어 포함
- 위의 요구사항 구조 같은 구조를 가지며, 길고 상세하게 작성
- 내용에 대해 이해하기 쉬운 표와 문서 인덱스를 포함하는 것이 핵심
- 내용에 대해 이해하기 쉬운 표와 문서 인덱스를 포함하는 것이 핵심
- 내부적 소프트웨어 제품에 대한 요구사항 문서
- 상세 내용 많이 생략
- 사용자 요구사항과 고수준의 비기능적 시스템 요구사항에 초점
- 시스템 설계자와 프로그래머는 스스로 판단하여 시스템에 대한 포괄적 사용자 요구사항을 충족시킬지 결정