* 요구사항 명세서 작성시 중요한 것
ⓐ Natural language specification
- 자연언어의 문장과 모호함을 줄이기 위한 그림(다이어그램), 표(테이블)로 이뤄져있다.
- standard format을 만들어서 요구사항을 쓰는 형식이다.
- 어체는 ~해야한다. ~해야만 한다. ~할 수 있다. 등의 어체로 실현가능성을 나눠서 작성하는 것이 일반적이다.
- 글을 읽었을때 컴퓨터공학과 사람이 작성한 것이라는 생각이 안들 도록 해야한다.
- 왜 이 소프트웨어가 필요한지 포함 시켜야 한다.
- 자연언어의 문제점
> 명확성이 떨어지며, 애매하고 불확실하다. 또한 여러가지 개념이 뭉쳐져서 나타난다.
ⓑ Structured specification
- 어느 정도 형식을 갖추어서 기술을 한다.
> 표 또는 잘 짜여진 형식에 의거하여 기술
- embedded control 기반의 시스템에는 사용하기 좋다. 반면에 business system 제안서엔 적용하기 힘들다.
※ 즉, 경우에 따라 structured가 필요할 수 도 있고 없을 수도 있다.
ⓑ-1. Form-based specifications(요소)
- 기능, Input(오는 곳도 포함), output(가는 곳도 포함), 기타정보, 조치해야하는 사항, pre and post condition,
이로 인해 발생할 수 있는 부작용 등을 기술해야 하며, 각각의 form에는 id가 붙여진다.
ⓑ-2. Tabular specification
- Form으로 해도 길어서 오해가 생길 요지가 있을 때 이를 간략하게 표시해준다.
- 상황에 따란 대안들을 기술할 때 유용하다.
> Form안에 tabular가 들어가는 형식이다.
* 요구사항 작성 과정
- 요구사항 추출, 발견
- 요구사항 분석
- 요구사항 검토
- 요구사항 관리
- 요구사항 관리(변경사항 제어)
ⓐ 요구사항 추출, 발견
- 요구사항을 발견하는 단계.
- stakeholders를 통해서 결과를 얻는다.
※ stakeholder : 개발 system(개발부터 사용까지)에 관련된 사람들의 집합
: 기술 스텝, 사용자, 메니저, 공학자, domain 전문가, 협회 사람들이 참가한다.
>> 협회 사람들 : 그 system에서 사용되는 data format을 주관
- stakeholders의 문제점
> 자신이 실제로 원하는 것이 무엇인지를 모른다.
> 그들만의 언어로 요구사항을 이야기한다.
> 서로 충돌을 하거나 문제가 발생 할 수 있다.
- 이러한 문제점을 해결하기 위해서 다음과 같은 과정을 반복적으로 실시한다.
1) 요구사항 발견
> stakeholder의 상호교환
2) 요구사항 분류 및 정리
> 관련된 요구사항들을 group으로 조직화 시킨다.(비슷한 요구사항을 묶는다.)
3) 요구사항 우선순위 부여 및 타협
> 요구사항의 우선순위를 부여한다.
> 요구사항들간의 충돌을 타협한다.
4) 요구사항 명세
- stakeholder로 부터 정보를 뽑아내는 방법은 다음과 같은 방법이 존재한다.
1) interview
> formal or informal interview가 존재한다.
> closed interviews는 이미 제공된 문제들의 목록에 기반을 둔다(설문지 형식)
> open interviews는 편하게 대화하는 방식이다.
> 실제로 closed와 open이 혼재된 형태로 발생한다.
> interview를 통해서 전체윤곽을 얻는데는 유용하지만, 도메인(시스템에 필요한 전문지식)적인 요구사항을
얻기는 힘들다.
2) Scenarios
> 현실세계의 예제를 살펴본다.
ⓐ Starting situation : 시작조건, 전제 저건
ⓑ normal flow of event : 정상적인(보편적인) 것에 대한 작성
ⓒ what can go wrong : 잘 못된 일에 대한 작성
ⓓ 시나리오 동작시 동시에 일어나는 일
ⓔ 종료상태(Finish situation)
> 위의 5가지 내용이 포함되어 있으며 form을 만들어서 작성하면 편하다.
> Scenario의 모음은 하나의 System으로 만들어진다.
3) Usecase(사용사례)
> UML의 시나리오를 기반 기술
> "Actor(stakeholder)"와 "사용사례"로 이뤄져 있으며 사용자가 어떤 요구사항이 필요한지를 기술
> usecase의 집합은 하나의 System을 이룬다.
> Usecase diagram으로 표현되며, 추가적으로 Sequence diagram을 사용해 표현해준다.
(Sequence diagram > class간의 연결관계를 자세하게 알려줌)
> 하나의 usecase는 여러명의 actor와 연결될 수 있다.
ⓑ Requirements Validation
- 수집한 요구사항을 검증
- 사용자가 원하는 것인가?(모호함이 있으면 안된다.), 일관성이 있는가?(요구사항이 출돌하는가?)
완전한가?(모든 요구사항을 밝혔는가?), 현실적으로 실현가능하고 검증이 가능한가?
등에 대한 판단을 실시
- 요구사항 검증 방법
1) 요구사항 reviews : 관련된 사람들이 모여서 이야기를 한다.
(stakeholder가 모여서 formal, informal하게 진행을 한다.)
2) prototyping 기법을 사용한다.
3) Test case를 만들어본다.(Test case를 만들 수 없다 = 애매모호하다)
(Test case 생성 = 요구사항이 완벽하다)
ⓒ Review checks
- 관련된 사람들이 formal or informal하게 진행한다.
- 검증이 가능한가? 요구사항 끼리 추적이 가능한가?(적용이 용의한가?)를 판단한다.
※ 적용의 용의성 : 요구사항의 변화가 다른 요구사항에 끼치는 것을 손쉽게 수정가능한 것
> 요구사항끼리의 추적사항을 정리해놓는 Table이 존재한다. "Trace-ability Matrix"
ⓓ Requirements management
- 어떤과정을 통해서 요구사항을 관리(변화 수용)할 것인지를 기술
- 요구 사항이 변하는 경우
> 비지니스의 기술 변화
> 사람의 변화
> ...
- Management planning : 다음의 4가지를 정하면 된다.
1) 요구사항 마다 식별 번호를 어떻게 줄 것인가?
2) 변화에 대해서 어떤 과정을 거칠 것인가?
3) 추적을 어떻게 용의하게 할 것인가?
4) 어떤 Tool을 사용할 것인가
- 요구사항 수용 분석 : 요구사항 수용은 다음과 같은 과정을 따른다.
1) 문제 분석, 변화 기술 조사
2) 변화에 대한 분석 및 가격 산출, 결정
3) 2)에서 나온 결과를 반영하여 구현
- 각 단계에 대해 어떻게 요구사항을 관리 할 것인지, 인원, 일정을 배정해 줘야 한다.