요구사항 도출과 문서화
Requirements elicitation
요구사항 도출
기술적인 지원, 고객과 협력하여 도메인, 시스템이 제공해야 할 서비스, 제약에 대해 알아내는 과정이다.
요구사항 도출 단계:
1.요구사항 발견
당사자와 상호작용을 해서 요구사항을 발견해야한다
domain requirement 도 이 단계에서 확보해놔야 한다(학교인지 병원인지 등)
기존의 시스템에 대한 정보를 수집하고 사용자 요구사항을 추출하는 단계
Interviewing
요구사항 도출에서 가장 많이 사용하는 방법(인터뷰)
closed interviews
물어볼 말들을 미리 정리해놓고 하는 인터뷰
open interviews
물어볼 말 없이 자유롭게 이야기 하는 인터뷰
실무에서는 이 close 와 open 인터뷰를 혼합해서 사용한다.
계속적으로 사용자와 개발자가 서로 제안을 하며 진행하는것이 조금 더 효과적으로 인터뷰 하는 방법이다.
도메인 요구사항 이해를 하기에 있어서 개발자가 그것을 이해하는데 한계가 있을 수 있다.
예를들어 전문적인 조직에서 전문적인 목적으로 개발을 하는경우 개발자는 그것을 모를 수 있다.
2.요구사항 문서화
User requirement
기술적 배경이 없는 사람들이 이해할 수 있게 작성해야한다.
System requirement
더 디테일 한 요구사항이고 더 많은 기술정보를 포함해야한다.
이 모든것은 소프트웨어 계약을 할 때의 일부가 될 수 있다.
4가지가 될 수 있다.
2-1. natural language:보편적이기는 하지만 체계가 안 잡힐 수 있다
자연어 문장으로 구성이 되어 있는 요구사항. 표현이 직관적이고 보편적이기 때문에 , 사용자와 개발자 모두 이해할 수 있다는 장점이 있다.
* standard format을 사용하여 정의를 하는것이 권장된다
* 요구사항은 일관적으로 작성이 되어야 한다
예를 들어 shall 은 꼭 있어야 한다 should 는 이것이 있으면 만족도가 높아질거다 등,,,,
*컴퓨터 전문용어는 지양하도록 해야 한다.
하지만 아무리 이런식의 포멧을 지킨다고 해도 아래의 요구사항에 비하면 정확도가 떨어질 수 있다.
여러 요구사항이 함께 표현되어 복잡할 수도 있고 몇가지의 기능들이 섞어질수도 있다.
2-2. structured natural language:따라서 특정한 양식이 있게 된다 표준 양식이나 탬플릿에 따라서 작성하는 일이 많다
표준화된 양식을 가지고 각각 작성하는 방식.
임베디드 시스템에서는 적합하지만, 다른 시스템에서는 엄격해 보일 수 있다.
*function 을 정의
*input 입력에 대한 정의, 설명
*output 출력에 대한 정의, 설명
* 계산이 있으면 계산에 대한 설명
* action 취해야 하는 action 에 대한 설명
* pre condition 사전상태
*post-condition 사후상태
* side effects 부작용이 있으면 어떻게 되는지
2-3:Graphical notations: 우리가 썼던 uml 도 이것의 한 종류이다 그림으로 표현해주는것이다.
Use cases 같은 경우는 uml 에 포함되어있는 시나리오 같은 것
사용자들간에 상호작용을 식별하고 상호작용 자체도 설명이 가능하다. 즉 가능한 모든 상호작용을 표현할 수 있어, 표 형식보다 highlevel이다.
sequence diagram 을 그려서 좀 더 다양하게 제공을 해줄 수 있다.
2-4: mathematical: 수학적인 공식으로 표현할때 쓰는것 예를들어 혈당량을 측정하거나 등. 정량적인 명세가 중요시될떄 쓴다 의료분야에서 많이 쓰는것 같다.
