소프트웨어 요구사항에 대해 알아보자. 말 그대로 소프트웨어 개발하는데 필요한 요구사항들이다.
S/W가 어떠한 기능을 제공해주길 바라는지, 어떤 제한사항이 있는지 등을 설정하는 것이다.
요구 사항에 대한 프로세스를 요구 공학 프로세스 라고 한다.
먼저 요구사항에 대해 알아야겠다.
요구사항(Requirements)는 시스템의 기능 또는 제약 조건에 대한 고수준의 추상적인 문장 에서부터 상세한 수학적인 기능 명세서까지 포함시킨다.
요구사항은 두가지 용도로 사용된다.
- 계약을 위한 시도 : 과제를 제안하는 용도이다. 공모전을 예로 들 수 있겠다. RFP라는 게 있는데 (과제도출->공모->선정) 과정을 말하는 것이다.
- 계약서 자체 : 계약서 자체에 정의된 요구사항이다. 굉장히 상세해야 하겠지?
요구 사항에도 여러가지 종류가 있다. 사용자 요구사항, 시스템 요구사항, 소프트웨어 명세서 등이 있다.
- 사용자 요구사항은 요구사항 정의와 같다. 간략하다. 주로 자연언어+다이어그램 등 고객을 타겟으로 쉽게 작성된다.
- 시스템 요구사항은 요구사항 명세서와 같다. 상세하다. 고객과 계약자간에 계약을 위해 작성된다.
- 소프트웨어 명세서는 좀더 상세하다. 설계, 구현에 기초로 사용되는 상세한 기술서이다. 개발자를 위해 작성된다.
정의와 명세화 차이는 저번에도 말했는데, 상세함 정도의 차이이다.
요구공학의 요구사항 분류
기능 관점의 분류 : 기능적, 비기능적, 도메인 요구사항
대상 관점의 분류 : 사용자, 시스템 요구사항
먼저 기능 관점의 분류 3가지를 알아보고
추가로 대상 관점의 2가지를 알아보겠다.
1. 기능적 요구사항
기능적 사용자 요구사항은 시스템이 무엇을 수행할 것인가에 대한 고수준의 문장이다.
반대로 기능적 시스템 요구사항은 시스템 서비스가 상세히 기술되어있는 문장이다.
이 요구사항을 정의할 때 주의해야될 점이 있는데, 모호한 표현을 사용하지 않는 것이다.
사용자와 개발자가 서로 다른 해석을 할 가능성이 높기 때문이다.
예를들어,
"시스템은 사용자가 문서 저장소에 있는 문서들을 읽을 수 있도록 적당한 뷰어를 제공할 것이다."
라는 문장이 요구사항에 포함되어 있는데, 적당한 뷰어라는 표현이 문제가 될 수 있다.
사용자 의도는 각각의 문서 종류에 대한 특정 목적의 뷰어였다면, 개발자가 해석한 것은 그냥 문서의 내용을 보여주는 텍스트 뷰어의 제공일 수 있다는 것이다.
본질적으로 요구사항은 완전성과 일관성을 추구해야 한다.
완전성(Completeness)는 필요한 모든 기능들이 빠짐없이 설명되어 있는 것.
일관성(Consistency)는 시스템 기능들에 대한 설명에서 충돌이나 모순이 없어야 하는 것이다.
실제로 두 가지가 모두 만족되는 요구사항 문서를 만드는 건 불가능하지만, 지키려고 해야 한다.
2. 비기능적 요구사항
비기능적 요구사항은 쉽게 말해 "제한사항"을 정의하는 것이다.
기능적 요구사항을 수행할 때 문제점이 되는 제한사항들이 비기능적 요구사항이라 할 수 있다.
예를 들어, 개발 시에 정해준 특정한 툴을 사용하도록 하는 것, 특정 언어로 개발하라고 하는 것 등이 될 수 있따.
이 비기능적 요구사항이 기능적 요구사항보다 훨씬 더 중요할 수가 있다. 이걸 만족못하면 그 시스템은 無쓸모하므로.
중요하다고 한 만큼 분류도 굉장히 여러갈레로 나온다.
크게 프로덕트 요구사항, 조직의 요구사항, 외부 요구사항으로 나뉜다.
- 프로덕트 요구사항 :인도되는 제품의 실행 속도, 신뢰도 등과 같은 특정한 방식으로 동작해야 한다는 것을 명시하는 요구사항. (e.g. 4.C.8 APSE와 사용자 사이에 표준 Ada 문자 집합으로 표현되는 모든 필요한 통신이 가능해야 한다.)
- 조직의 요구사항 : 사용되는 프로세스 표준, 구현 요구사항 등과 같은 조직의 정책과 절차의 영향에 따른 요구사항.
(e.g. 9.3.2 시스템 개발 프로세스와 인도물 문서는 XYZCo-SPSTAN-95에 정의된 프로세스와 인도물에 적합해야 한다.)
- 외부 요구사항 : 상호운영성(interoperability ), 법률적 요구사항 등과 같이 시스템과 개발 프로세스 외부에 있는 요인들에 의해 발생하는 요구사항.
(e.g. 7.6.5 시스템은 어떤 사용자도 개인 정보가 시스템에서 유지되는 가를 검사할 수 있는 기능을 제공해야 한다. )
비기능적 요구사항을 정확하게 언급하는 일은 어렵고, 부정확한 요구사항을 검증하는 것은 더더욱 어렵다. 기술적인 내용이 아니라서 약간 모호하다.
그래서 목표(goal)를 설정하는 것과 검증이 가능한 비기능적 요구사항을 정의하는 것으로 그것들을 어느정도 해소할 수 있다. 특히나 goal은 시스템 사용자의 의도를 전달해주는 것이므로 개발자에게 큰 도움이 된다.
예를 들어보자면
시스템 목표(goal) 예시: 시스템은 경험이 있는 제어자가 쉽게 사용할 수 있어야 하며, 사용자 오류가 최소화되도록 구성되어야 한다.
검증이 가능한 비기능적 요구사항 예시: 경험이 많은 관리자는 총 2시간의 교육후에 시스템을 사용할 수 있어야 한다. 이 교육 후에는, 경험이 많은 사용자가 저지르는 에러의 평균 회수는 하루에 2개를 초과해서는 안된다.
그리고 요구사항 간에 모순이 발생하는 경우가 있다. 다음과 같은 상황을 보자.
이런 상황일 때 어떻게 해야 할까?? 요구사항들에 대한 우선순위를 정해야 한다. 무게를 최소화하는 것이 우선인가, 전력 소모를 최소화하는 것이 우선인가를 선택해야만 한다.
3. 도메인 요구사항
해당 분야(SW의 분류)에 대한 요구사항이다. 대충 영역? 범위 이런 뜻으로 해석하면 될 것 같다.
도메인 요구사항이란 응용 시스템의 도메인(범위)로 부터 유도되며, 그 도메인을 반영하는 시스템의
특성과 기능을 설명하는 요구사항이라고 말할 수 있다.
아 뭔가 말이 좀 어려운데.. 쉽게 말해서 그냥 그 S/W의 해당 분야에 대한 내용이다.
만약 개발하려는게 음악 재생 프로그램이라면, 음악 재생 프로그램으로써 갖추어야 할 요구사항들이 나와있는 것이다.
여기에는 기능적 요구사항이 들어갈 수도 있고, 기존 요구사항에 대한 제한사항(비기능적 요구사항)일 수도 있다.
그리고 특정한 컴퓨터 작업을 정의할 수도 있다. 도메인 요구사항을 만족하지 않으면 그 시스템은 사용할 가치가 없는 것이 되버린다.
이 도메인 요구사항을 정의하는 데도 문제점이 있다.
- 이해도(Understandability)
도메인 요구사항은 응용 시스템의 도메인에 대한 언어로 표현이 된다.
이것이 시스템 개발자들에게 어려운 요구사항일 수 있다.
예를 들어, 건설분야에서 사용될 S/W 개발을 의뢰했는데, 고객은 건설 분야 종사자이므로 자기들이 쓰는 전문용어가
도메인 요구사항에 포함될 것이다. 그럼 개발자는 무슨말인지 모르니 문제가 생김
- 묵시성(Implicitness)
해당 도메인 전문가들은 이 분야에 대해 매우 잘 알고 있기 때문에, 지네들이 도메인 요구사항에 정확하고 명백하게
기재할 필요성을 느끼지 못한다. 개발자는 그 분야에 정통한 사람이 아니므로 이렇게 SKIP하고 넘어가는 부분에 대해
알리가 만무하다.
4. 사용자 요구사항
기능적 비기능적 도메인 요구사항 3가지가 요구사항의 기능적인 분류 였다면, 이제 사용자, 시스템 요구사항은 요구사항 문서의 대상에 초점을 맞춘 분류이다.
먼저 사용자 요구사항부터 알아보자. 앞에서 배운 기능적, 비기능적인 요구사항들을 아무 지식없는 시스템 사용자를 위하여 알기 쉽게 풀어 적는 요구사항을 말한다.
사용자 요구사항 = 요구사항 정의
와 같은 말이다. 이렇게 쉽게 풀어 쓸라면 자연 언어, 표, 다이어 그램등을 이용해야 한다.
사용자 요구사항을 작성할 때 고려해야 될 부분이 몇가지 있다.
자연 언어의 사용에 문제점이 많다.
일단 명확성이 부족하다. 문서를 읽기 쉽게 만들면서 정확도도 잃지 않도록 하는 것은 힘들다.
그리고 기능적, 비기능적 요구사항이 섞여서 요구사항에 혼란을 줄 수 있다. 또한 여러가지 요구사항이 짬뽕이 되어 요구사항 혼합이 되면 정말 노답이다.
예제를 보면서 알아보자.
위 요구사항은 요구사항이 혼합된 예이다.
형상 제어의 개념을 설명하던지, 상세 내용을 기술하던지.. 짬뽕되어 있다.
이 것은 초기화 정보가 부족한 예이다. on 상태일 때 내용이 정의 되어있지 않다.
그리고 3종류의 다른 요구사항이 섞여있다.
그리드의 필요성 (개념적인 기능적 요구사항)
그리드의 단위 (비기능적 요구사항)
그리드 switching ( 비기능적 UI 요구사항)
이렇게 사용자 요구사항을 작성할 때는 문제점이 많다. 해결법은 없을까? 한번 알아보자.
1. 표준 양식을 개발하고 그 양식을 모든 요구 사항에 적용시킨다.
2. 일관된 방식의 언어 표현을 사용한다.
- 의무적인 요구사항: 해야한다.
- 희망 요구사항 : 하는 것이 좋다.
3. 주요 부분을 표시하기 위해 Bold나 underline을 사용한다.
4. 너무 많은 컴퓨터 용어의 사용을 피한다.
5. 시스템 요구사항
시스템 요구사항 = 요구사항 명세화
와 같은 말이다. 사용자 요구사항에 비해서 좀더 상세화된 명세서이다. 시스템 설계의 기초서, 계약서의 일부분 등으로 사용될 수 있다.
시스템 요구사항과 설계는 뗄래야 뗄 수 없느 관계에 있는데, 요구사항은 무엇(what)을 하는 지에 초점을 맞추는 것이고, 설계는 어떻게(how)에 초점을 맞추는 것이다. 실제로는 두가지가 잘 분리 되지 않는다.
사용자 요구사항은 자연 언어로 했는데, 명세화할 때 문제점이 있다.
- 모호성(Ambiguity) : 작성자와 독자가 동일하게 해석해야 하는데, 그렇지가 못하다.
- Over-flexibility : 과도하게 유연하다. 같은 것이 여러개의 다른 방식으로 언급될 수 있다.
- 모듈화의 부족(Lack of moularisation) : 자연언어가 명세화단계에서 구조화하기에는 부적절하다.
그럼 어떻게 하면 명세화를 유연하게 할 수 있을까. 표를 봅시다.
구조화된 언어, PDL, 그림, 수학적인 명세화 등등 표를 보면 여러개가 나와있다.
구조화된 언어 사용부터 보자면, 일단 제한된 자연언어보다 좀더 일관성(uniformity)있는 명세서를 작성할 수 있다.
먼저 구조화된 언어 사용 방법의 일종인 Form-based specification 을 알아보자.
Form-based specification 은 이런 식으로 구조화 시켜서 명세화 하는 것이다. 예를 하나 들어 보겠다.
다음은 PDL(Program Design Language) 기반 요구사항 정의에 대해 알아보자.
이건 쉽게 말해 의사코드? 같은 것이다.
반복문 속의 반복문 (Nested loops & condition) 을 써야할 때나, HW/SW 인터페이스들이 명세화 되야할 때
이럴 때 사용한다. 하지만 영역의 개념을 충분히 표현하기 힘들 수 있고, 명세서가 아니라 설계물 처럼 될 수도 있다.
위 PDL이 방금 언급한 설계물처럼 보이는 것이다. 이게 무슨 의사코든가 그냥 소스 코드지 ㅡㅡ;
PDL은 위에서 말했듯이, 시스템의 기능을 이해하기 쉽도록 표현하기에는 힘들 수 있다.
그리고 프로그래밍 언어를 아는 사람만이 이해할 수 있고, 설계 명세서처럼 받아들여 질 수 있다.
자 그럼 표기법은 이정도가 있고( 더 있긴한데 뒤에서 다시 언급함)
인터페이스 명세화에 대해 알아보자.
대부분의 시스템들이 다른 시스템과 같이 함께 돌아가므로 인터페이스에 대한 내용도 명세화가 되어야한다.
총 3가지 인터페이스가 명세화 되어야 한다.
1. Procedural interface (e.g. 함수 이름, 인자, 리턴 등)
2. Data Structure that are exchanged
3. Data representations (e.g. 바이트 오더링)
끝으로..
요구사항 문서에 대해 알아보자 시스템 개발자에게 무엇이 필요한지를 알려주는 공식적인 문서를 말한다.
요구사항에 대한 정의, 사양을 모두 포함해야 한다.
설계 문서가 아니다.
요구사항 문서 = [사용자 요구사항(기능,비기능,도메인)] + [시스템 요구사항(기능,비기능,도메인)]
이라고 보면 된다. 이 요구사항 문서는 굉장히 여러 사람이 본다.
사용자, 관리자, 개발자, 테스터, 유지보수하는 기술자 등등 다 이거보고 작업함.
요구사항 문서에는 여러가지 내용이 필수적으로 들어가야 한다.
1. 시스템의 외부행위
2. 구현에 대한 제한 조건
3. 변경하기 쉬워야 한다.
4. 유지 보수를 위한 참조도구로서의 활용
5. 시스템 라이프 사이클에 관한 예측 기록
6. 예기치 않은 변화에 대한 반응
등등 여러가지 들어가야 한다.
요구사항 문서 양식 표준에 대한 예를 보자.
시스템 요구사항을 찾아내고 분석하고 확인하기 위한 요구공학 프로세스에 대해 알아보자.
1. 가능성 분석 (Feasibility study)
가능성 분석 (Feasibility study) 이란 제안된 시스템이 수행할 만한 가치가 있는 것인지, 수행이 가능한지 판단하는 과정이다. 정보 수집, 평가, 보고서 작성 등을 수행한다.
* 시스템이 조직의 목적에 기여할 수 있는가?
* 현재 기술과 가능한 예산 범위 내에서 개발 가능한가? (= 남는 장사냐)
* 다른 시스템과 통합될 수 있는가?
등을 알아보는 것이다.
가능성 분석을 할 때 조직의 구성원들에게 아래 질문들을 한다.
• 시스템이 개발되지 않으면 어떻게 되는가?
• 현재의 프로세스의 문제점들은 무엇인가?
• 제안된 시스템은 어떻게 도움을 줄 수 있는가?
• 통합에 관계된 문제점들은 무엇이 있을 수 있는가?
• 새로운 기술 또는 기법들이 필요한가?
• 제안된 시스템은 어떤 기능들을 지원하는가?
2. 요구사항 유도, 분석 - 분석 프로세스
가능성 분석이 끝났다면, 요구사항 유도와 분석의 단계를 거친다. 요구사항 유도 혹은 발견이라고 일컫는다.
시스템이 제공해야할 서비스(기능적), 시스템 작동에 대한 제한사항(비기능적) 등을 찾아내는 작업이다.
요구사항 유도에서는 사용자, 관리자, 유지보수 관계자, 도메인 전문가, 마케팅 관계자 등이 관련되는데,
이 사람들을 통틀어 Stakeholders(이해당사자) 라고 부른다.
즉, 이 프로젝트가 망하면 피해를 보는, 잘되면 득보는 사람들
이 요구사항 유도, 분석 과정에서 문제점 즉, 왜 유도를 해야하는지에 대해 알아보자.
1. Stakeholders들은 그들이 정말로 무엇을 원하는지를 모름
2. Stakeholders들은 요구사항을 자신들의 용어로 표현
3. 서로 다른 stakeholders 들이 요구사항에 의견 차이가 있을 수 있음.
4. 조직의 또는 정책적 요인들이 요구사항에 영향을 미칠 수 있음
5. 요구사항이 분석 과정 동안 변함. 새로운 요구사항을 가진 새 stakeholders가 나타날 수 있음
자 그럼 요구사항 유도,분석에도 일정한 정형화된 프로세스가 있다. 이름 하야 요구사항 분석 프로세스이다.
도메인 이해 → 요구사항 수집 → 요구사항 분류 → 요구사항 충돌 해결 → 요구사항 우선순위화 → 요구사항 검사
과정을 거쳐서 요구사항을 분석한다.
분석 과정을 거치며 여러가지 시스템 모델(system model)이 생성될 수 있는데,
시스템 모델들은 요구사항 분할(partitioning), 분할된 개체의 일반성을 인식(abstraction), 여러가지 관점 인식(projection) 등의 3가지 구조적 작업을 포함한다. 이것들은 나중에 자세히 다룰 예정이다.
3. 요구사항 유도, 분석 - 관점 중심의 유도
이제 실질적으로 어떤식으로 유도, 분석하는지 알아보자. 먼저 관점 중심의 유도이다.
stakeholder(이해당사자)들은 각자 자기가 보는 관점이 다다르다. 하나의 정확한 방법이 없으므로 여러 관점에서 봐야한다.
각각의 스테이크홀더들을 기준으로 보통 관점을 잡는다.
현금 자동 지급기 시스템에 대한 여러 분류의 스테이크홀더들을 예로 한번 보자.
관점은 여러가지로 나눌수 있다. 이렇게 여러 관점으로 나누면 요구사항 충돌을 찾는데 도움이 된다.
a. Data sources or sinks (생산, 소비 중심 관점)
• 자료의 생산과 소비에 중점을 둠.
b. Representation frameworks (관점의 시스템 모델화)
• 관점을 시스템 모델의 특별한 유형으로 생각.
다른 engineer 들이 하나의 시스템에 대해 분석하여 다른 모델(예를 들면, ER, STD, ...)을 개발함.
(이렇게 하면 한 모델에서 빼먹은 부분을 찾을 수 있다.)
c. Receivers of services (외부의 관점)
• 시스템의 외부에 있는 관점, 시스템의 최대 수혜자인 사용자들의 입장에서 보는 관점.
• 요구사항 유도 작업을 구조화할 수 있다.
• 비기능적 요구사항들을 구조화하는데 사용 가능함.
• 관점이 올바른지 검사하는 것이 상대적으로 쉽다.
• interactive system에 적합
관점에 대한 구조를 한가지 예를 들어보자면 아래와 같다.
4. 요구사항 유도, 분석 - 방법 중심 분석, System context
이 방법은 시스템을 이해하기 위해 사용되는 방법에 의존하는 것이다.
* 프로세스 모델
* 시스템 모델링 표기법 (DFD, ERD, OSD, Use Case Diagram, ...)
* 시스템 모델에 적용되는 규칙
* 설계 지침
* Report 양식(templates)
등에 의존해서 분석작업을 하는 것이다. 예를 들어보면,
위는 템플릿(templates) 을 틀로 분석한 것이다.
다음 알아볼 내용은 System context(시스템 범위) 라는 개념이다.
무엇이 구현되어야 하는지에 대하여 결정할 때 시스템 경계를 확실히 설정하는 것이다.
환경 내에 있는 다른 시스템에 대한 기술도 포함시킨다.
이렇게 경계를 나누어 분석하는 것이다.
5. 요구사항 유도, 분석 - 시나리오
시나리오(Scenarios)는 시스템이 실제로 사용되는 방식에 대한 설명이다.
이건 시스템 요구사항 유도, 분석에 굉장히 많은 도움이 된다.
추상적인 내용들 보다 좀더 쉽게 접근이 가능하기 때문이다.
시나리오는 개략적인 요구사항 설명에 상세한 내용을 추가할 때 유용하다.
시나리오에는 다음과 같은 사항들을 기술한다.
a. 시나리오 시작 시의 시스템 상태
b. 시나리오에 있는 이벤트들의 정상적인 흐름.
c. 잘못된 경우와 이에 대한 대처 방법
d. 다른 병행적인 활동들
e. 시나리오 종료 시의 시스템 상태
이 시나리오 기반의 기법들 중 UML에서 사용하는 Use-case 라는 것이 있다.
시스템에 관련된 외부 행위자(Actor)를 표시하고, actor와 시스템의 상호작용을 표시하는 것이다.
Actor와 use case 즉, 시스템과의 상호작용을 이런식으로 졸라맨과 타원으로 표시한다.
도서관 시스템에 대한 use-case를 예를 들어서 보자
정말 간단하다. 이렇게만 표현하면 뭔가 부족해 보인다. 아닌가?
그래서 Sequence Diagram(순차 다이어그램) 이라는 개념을 추가시켜서 주로 표현한다.
순차 다이어그램은 시스템에서의 이벤트 처리 순서를 보여주는 것이다.
actor나 객체를 상위에 두고 아래는 시간의 흐름에 따라 표기하는 것이다.
Use-case 는 보통 이렇게 순차 다이어그램과 같이 쓰인다.
6. 요구사항 확인
이제 요구사항 유도, 분석 과정이 끝났다. 이제 요구사항이 정말 고객이 원하는 시스템을 정의했는지 확인하는 작업이 필요하다.
그 작업을 요구사항 확인이라고 한다. 요구사항 에러에 따른 비용은 매우 크므로 이 과정은 굉장히 중요하다.
(보통 고객에게 인도 후에 요구사항 에러를 고치는 비용은 구현 시의 에러를 고치는 비용의 100배라고 한다.)
그래, 그럼 요구사항을 확인하기 위해 검사하는 과정이 필요하다. 아래에 검사 시에 체크하는 항목들을 보자.
a. 정확성(Validity) : 시스템이 고객의 요구사항을 가장 잘 지원하는 기능을 제공하는가 ?
b. 일관성(Consistency) : 요구사항들간에 불일치는 없는가?
c. 완전성(Completeness) : 고객이 필요로 하는 모든 기능이 포함되었는가 ?
d. 현실성(Realism) : 요구사항이 주어진 가용한 예산과 기술로서 구현될 수 있는가 ?
e. 검증성(Verifiability) : 요구사항이 검사될 수 있는가?
위 5가지 방법들을 초점으로 요구사항 검사를 수행한다. 그리고 요구사항을 확인하는 기법들도 몇가지 있다.
- 요구사항 검토회의
요구사항이 완전히 확정될 때까지 계속해서 회의가 진행되어야 한다. 고객과 계약자 모두가 참여해야 함.
검토 회의로 서로간에 좋은 커뮤니케이션이 초기 단계에서 문제를 해결할 수 있다.
이 요구 사항 검토회의 시에 체크해야 될 항목들을 함보자.
검증도(Verifiability): 요구사항이 현실적으로 시험가능한가 ?
이해도(Comprehensibility): 요구사항이 적절히 이해되는가 ?
추적도(Traceability): 요구사항의 기원이 명백히 언급되었는가 ?
순응도(Adaptability): 요구사항이 다른 요구사항에 커다란 영향 없이 변경될 수 있는가 ?
위 사항들을 꼼꼼하게 체크하여 요구사항 검토회의를 진행해야 한다.
- 프로토타이핑(Prototyping)
요구사항을 검사하기 위해서 실행이 가능한 모델을 만들어 사용하는 기법이다.
- 테스트-케이스 생성
요구사항 검사하는 과정 중 "검증성(Verifiability)"을 확인하기 위한 방법이다.
시험 가능한지를 검사하기 위해 테스트 케이스를 개발한다.
input 으로 Test-data를 집어 넣고 Test-case가 Output으로 나오는 지 확인하는 것이다.
이게 문제점이 있다면, 결과가 맞는지 틀린지 모를 수가 있다.
- 자동화된 일관성 분석
구조화된 요구사항 설명에 대한 "일관성(Consistency)"을 검사하는 것이다.
위와 같은 구조로 진행된다.
7. 요구사항 관리
이것은 요구 공학 프로세스 과정과 시스템 개발과정 전체에 아울러 요구 사항을 관리하는 일이다.
일단 요구 사항이라는 것 자체가 반드시 불완전하며 일관성이 없고 계속해서 진화하고 변경된다.
개발 하는 과정 동안 여러 관점의 변화에 따라 요구사항의 우선순위가 변하고, 요구사항이 충돌하기 마련이다.
또한 요구사항은 계속해서 변화하면서 그 과정에 진화를 한다.
이런 요구사항은 크게 지속적 요구사항과 휘발성 요구사항으로 나눌 수 있다.
- 지속적 요구사항 : 고객 조직의 핵심적 활동에서 나오는 안정적인 요구사항
e.g. 병원에는 항상 의사, 간호사 등이 있다. (도메인 모델로부터 유도될 수 있음.)
- 휘발성 요구사항 : 개발하는 동안 또는 시스템을 사용하는 동안 변경되는 요구사항
e.g. 병원에서 건강관리 정책으로 부터 유도된 요구사항.
또한 어떻게 발생하느냐에 따라 또 요구사항의 종류를 나눌 수 있다.
변하는 요구사항 : 시스템의 환경에 따라 변하는 요구사항.
생겨나는 요구사항 : 시스템을 개발하는 동안 이해를 통해 생겨나는 요구사항.
결과적인 요구사항 : 컴퓨터 시스템의 도입에 따른 결과로 발생하는 요구사항.
호환성에 대한 요구사항 : 다른 시스템 또는 조직의 프로세스에 종속적인 요구사항.
그럼 이렇게 자꾸 생기고 바뀌는 요구사항들을 관리하는 계획에 대해 알아보자.
a. 요구사항 인식.
요구 사항을 어떻게 식별할 것인가에 대한 계획
b. 변경 관리 프로세스
요구 사항이 변경 되었을 때 어떻게 할 것인가에 대한 프로세스이다.
제안된 모든 변경 사항을 요구사항에 적용 시켜야만 한다.
먼저 문제 분석, 요구사항의 문제점을 토의하고 변경을 제안한다.
다음 변경 분석 및 비용추정, 변경에 따른 다른 요구사항에 미치는 영향을 측정한다.
마지막으로 변경 실현, 요구사항 문서와 변경의 영향을 받는 다른 문서들을 수정한다.
c. 추적성 정책 (Traceability)
요구사항, 요구사항의 근원 그리고 시스템 설계 사이의 관계에 관심을 두는 정책이다.
* 요구사항 추적성 : 종속적인 요구사항 사이의 관계
* 근원 추적성 : 요구사항으로부터 요구사항을 제안한 이해당사자(stakeholder)로의 링크
* 설계 추적성 : 요구사항에서 설계로의 링크
d. CASE 도구 지원
요구사항 변경 관리를 위해 가용한 도구들에 대한 계획
* 요구사항 저장소 : 요구사항을 안전하게 관리되는 데이터 저장소에 보관
* 변경 관리 : 각 단계들 사이의 정보 흐름을 부분적으로 자동화
* 추적성 관리 : 요구사항 사이의 링크들을 자동적으로 검색
'IT 그리고 정보보안 > Knowledge base' 카테고리의 다른 글
| 소프트웨어 공학 - 시스템 모델링 (0) | 2021.04.11 |
|---|---|
| UPS(Uninterruptible Power Supply)와 전원 차단 (0) | 2021.04.11 |
| COCOMO (Constructive Cost Model) (0) | 2021.04.10 |
| 소프트웨어 공학 - Software Process (0) | 2021.04.10 |
| 소프트웨어 공학 개요 (0) | 2021.04.10 |