Introduction
•
S/W 요구사항 KA(Knowledge Area)는 S/W 요구사항의 추출, 분석, 명세, 명세로 이루어져. 이들 활동이 적절히 이루어지지 않으면 SWE(Software Engineering) 프로젝트가 심각하게 취약해짐은 S/W 산업계에 잘 알려진 사실임.
•
S/W 요구사항은 S/W 제품에 대한 요구와 제한사항을 표현하여 실세계 문제의 해결책에 대한 일부를 담당.
•
'요구 공학'이란 용어는 많이 사용되지만, 일관성을 위해 여기서는 사용되지 않음. 전체에 걸쳐 '공학(engineering)'이란 용어는 'S/W 공학'을 제외하고는 사용되지 않을 것임
•
KA 분할(KA breakdown)는 IEEE12207에서 언급한 요구사항 활동 섹션과 호환됨.
•
문제는 제시된 분할(breakdown)이 폭포수적(waterfall-like) 프로세스를 연상시킨다는 건데, 이를 방지하기 위해 '요구사항 공정' 장은 요구사항 공정에 대한 고수준 조감(overview)을 제시.
•
또 다른 분류 방법으로 제품 기반 구조(시스템 요구사항, S/W 요구사항, 프로토타입, Use Case 등)에 기반하는 방법이 있음. 하지만 프로세스 기반 분할은 요구사항 공정이 복잡하고 강하게 엮인 활동(순차적, 동시적 모두)인 사실을 강조하는 데 유효.
•
S/W 요구사항 KA는 S/W 설계, 시험, 유지보수, 구성관리, SWE 관리, SWE 공정, 품질 KA에 연계됨.
Breakdown of topics
1. S/W 요구사항 기본(Software Requirements Fundamentals)
1.1 S/W 요구사항의 정의(Definition of a Software Requirement)
•
A property which must be exhibited by software developed or adapted to solve a particular problem
•
특정 문제를 해결하기 위해, S/W 개발 또는 적용을 통해 외부로 드러나야 하는 속성
•
요구사항은 주어진 자원 내에서 반드시 검증 가능하여야(verifiable)
1.2. 제품 및 공정 요구사항(Product & Process Requirements)
•
Product Requirement : 개발될 S/W 자체에 관계
•
Process Requirement : S/W 개발의 제한사항(constraint)에 관계(ex. 당 S/W는 Ada로 개발되어야)
1.3. 기능 및 비기능 요구사항(Functional & Non-functional Requirements)
•
Functional Requirements : S/W가 수행할 기능을 기술
•
Non-functional Requirements : 해당 솔루션을 제한(constrain)하기 위해 행동(act)하는 것. 제한(constraint) 또는 품질(quality) 요구사항으로 불리기도
1.4. 창발적 속성(Emergent Properties)
•
단일 컴포넌트로는 드러나지 않고 해당 S/W의 여러 컴포넌트간 상호작용을 통해 나타나는 속성 및 요구사항. 본 속성은 본질적으로 시스템 아키텍처에 의존함.
1.5. 정량적 요구사항(Quantifiable Requirements)*
•
S/W 요구사항은 최대한 명확하게 표현하여 모호함을 최대한 배제하여야.
1.6. 시스템 및 S/W 요구사항
•
시스템 : 정의된 목적을 달성하기 위한 요소간 조합(combination)의 상호작용. 요소에는 H/W, S/W, firmware, 사람, 정보, 기술, facilities, 서비스 및 타 지원 요소가 포함됨(INCOSE00 : International Council on Systems Engineering)
•
시스템 요구사항 : 시스템을 전체로 바라본 요구사항. 때때로 사용자 요구사항이 되기도.
2. 요구사항 공정(Requirements Process)
2.1. 공정 모형(Process Models)
•
SDLC의 개별적 초기(discrete front-end) 활동이라기보다는 프로젝트 초기에 시작되어 생명주기 전체에 걸쳐 정제되는(refined; 반복?) 활동
•
S/W 요구사항을 형상 항목으로 식별하고, SDLC 상의 타 산출물과 동일한 형상관리 활동(practice)를 통해 관리하는 활동
•
조직과 프로젝트 배경구조(context)에 적용되어야(needs to be adapted)
2.2. 공정 활동자(Process Actors)
•
수행 주체 : 사용자, 시장 분석가, Regulator, S/W 기술자 등의 다양한 이해당사자가 결부됨. 따라서 trade-off 가 필수. 이해 당사자를 식별하고, 이들의 이해를 분석하고 이들의 요구를 추출해야 함.
2.3. 공정 지원 및 관리(Process Support and Management)
•
요구사항 프로세스에서 요구되고 소비되는 프로젝트 관리 자원. 이는 SWE 관리 지식 영역(KA)의 초기 및 범위 정의를 다루는 첫 부 영역(sub-area)를 위한 배경을 수립함. 주요 목적은 2.1.에서 식별한 프로세스 활동 및 비용, 인력, 훈련, 도구 간의 연계(link) 수립에 있음
2.4. 프로세스 품질 및 향상(Improvement)
•
요구사항 프로세스가 수행하는 주요 역할을 비용과 S/W 제품의 시간선(timeliness), 그리고 S/W에 대한 customer의 만족으로서 나타냄. S/W 품질 KA와 SWE 프로세스 KA와 깊은 연계.
•
주요 토픽으로,
◦
프로세스 향상 표준 및 모델을 통한 요구사항 프로세스
◦
요구사항 프로세스 측정 및 벤치마크
◦
향상 계획 및 구현
3. 요구사항 추출(Requirements Elicitation)
3.1. 요구사항 소스(Requirements Sources)
•
S/W에 영향을 주는 모든 잠재적 Source의 식별이 중요. 따라서 다양한 Source의 인지 및 이들을 관리할 Framework이 필요. 주요 핵심으로서, 다음과 같은 것이 있음.
•
목표(Goal), 도메인 지식(Domain Knowledge), 이해당사자(Stakeholder), 운영 환경(The operational environment), 조직 환경(Organizational environment)
3.2. 추출 기술(Elicitation Techniques)
•
인터뷰, 시나리오(use case는 가장 흔한 유형임. Topic 4.2 개념 모델링과 연계), 프로토타입(topic 6.2. 프로토타이핑과 연계), 촉진 미팅(facilitated meetings; 혼자보다는 다수가 요구사항으로의 직관력을 높힘. 요구사항간의 충돌 조정 기능도. 브레인스토밍), 관찰(비즈니스가 이루어지는 조직 환경으로 뛰어들어 느끼기)
4. 요구사항 분석(Requirements Analysis)
•
요구사항 간 충돌의 식별 및 해결 / S/W의 범위 및 S/W가 환경과 어떻게 상호작용하는지 / S/W 요구사항을 유도하기 위해 시스템 요구사항에 공들이기(elaborate)
•
SADT와 같은 개념적 모델링으로 압축되어, 여기에는 요구사항 trade-off를 위한 분류, 협상 등이 포함
4.1. 요구사항 분류(Requirements Classification)
•
다양한 차원으로 분류될 수 있어.
◦
기능/비기능 요구사항
◦
소스에 의해서 : 고수준 요구사항, 창발적 속성, 이해당사자 또는 타 자원
◦
제품/프로세스 요구사항
◦
요구사항 우선순위, 범위, 변화 여부 : 휘발성(volatility)/안정성(stability)
◦
조직의 일반 프랙티스 및 application 자체
•
요구사항 분류와 요구사항 속성간에는 강한 오버랩이 존재
4.2. 개념 모델링(Conceptual Modeling) - IEEE 1320.1 for functional modeling, IEEE 1320.2 for information modeling
•
실세계 문제에 대한 모델 개발은 요구사항 분석의 핵심. 해결책의 제시보다는 문제의 이해에 중점을 둠. 따라서 이는 실세계의 관계 및 의존성을 반영한 문제 영역의 Entity에 대한 모델을 포함.
•
다양한 모델이 있는데, 이들은 데이터와 제어 흐름, 상태 모델, 이벤트 추적, 사용자 상호작용, 객체 모델, 데이터 모델 등이 있음. 선택 기준은 아래와 같음
◦
문제의 특성, 기술자의 기술수준, 프로세스 요구사항, 해당 모델을 지원하는 기법, 지원 도구의 수준
•
거의 모든 경우에서 개념 모델링은 외부 환경과의 상호작용을 기술하는 S/W 컨텍스트 구축을 시작함.
•
모델링은 주로 널리 퍼진 표기법(notation; UML 등)으로 이루어짐.
•
이산 수학에 기반한 정형 모델링은 논리적 추론을 가능케 하며 이는 특화된 영역에서 사용됨. 주로 고객 또는 표준, 타 모델링 기법에 비해 이점이 있을 때 사용
4.3. 아키텍처 설계(Architectural Design) 및 요구사항 할당(Requirements Allocation) - IEEE 1471-2000, Recommended Practice for Architectural Description of Software Intensive Systems
•
시스템 또는 S/W 설계 프로세스와 중첩되어, S/W 설계 KA의 S/W 구조와 아키텍처 부영역과 밀접히 연계됨.
•
요구사항 분석 프로세스는 요구사항 충족을 구체적으로 담당하는 컴포넌트의 식별을 요구하며 이는 아키텍처 설계의 일부. 컴포넌트 식별이 바로 요구사항 할당임.
•
할당은 요구사항의 세부 분석을 수행. 여러 요구사항이 컴포넌트에 할당되면, 컴포넌트간 상호작용에 의해 타 요구사항이 어떻게 충족되는지를 파악 가능.
•
아키텍처 설계는 개념 모델링과 비슷하기는 하나 실세계 영역의 엔티티와 S/W 컴포넌트 간 mapping은 명확하지 않음. 따라서 명확히 분리되는 영역임. - 허나 사용되는 표기법은 거의 공통적임.
4.4. 요구사항 협상(Requirements Negotiation)
•
다른 말로는 충돌 해결(conflict resolution)임. 이해당사자간 또는 자원과 요구사항 간 조정을 요구하므로, 대부분의 경우에서 사안에 대해 S/W 기술자 단독적 결정은 현명치 못한 처사. 이해 당사자가 함께 모여 trade-off를 이루도록 해야.
•
본 과정은 요구사항 분석의 결과에 따라 발생하나 확인 단계에서도 나타남.
5. 요구사항 명세(Requirements Specification)
•
'명세'란 제품의 설계 목표에 수치적 값 또는 제한의 할당을 의미하는데, 전형적으로 물리적 시스템은 그러한 값이 상대적으로 적은 반면, S/W는 요구사항이 매우 많기에 초점은 대량의 요구사항 간 상호작용의 복잡도 관리에 대해 수치적 양화(量化; quantification)에 있음.
•
따라서 SWE에서의 요구사항 명세란 시스템적으로 검토, 평가 및 승인이 가능한 문서적 산출물(production) 또는 이에 상응한 전자적 산출물을 뜻함. 특히 복잡한 시스템에서는 3가지의 문서, 즉 시스템 정의, 시스템 요구사항, S/W 요구사항이 수반됨.
5.1. 시스템 정의 문서(System Definition Document) - IEEE 1362, Concept of Operations Document
•
사용자 요구사항 문서(the user requirements document) 또는 운용 개념(concept of operations)으로 알려지기도.
•
도메인 관점에서 고수준 요구사항을 정의함. 사용자/고객이 독자층에 포함되기에 도메인 언어로 기술되어야.
•
내용 : 시스템의 전체 목표에 대한 배경 정보, 시스템 요구사항, 대상 환경, 제한 조건, 가정, 비기능 요구사항. 시스템 컨텍스트를 표현하기 위한 개념 모델과 사용자 시나리오, 주요 도메인 엔티티, 데이터, 정보, workflow를 포함하기도.
5.2. 시스템 요구사항 명세(System Requirements Specification) - IEEE1233-98
•
시스템 요구사항에서 S/W 요구사항이 도출된 후, S/W 컴포넌트의 요구사항이 지정됨.
5.3. S/W 요구사항 명세(S/W Requirements Specification) - IEEE 1465(ISO/IEC 12119와 유사), IEEE 830 for the production and content of the SRS
•
S/W가 할 일에 대한 고객과 계약자(CONTRACTOR) 또는 공급자간 합의의 기반이 됨. S/W 요구사항 정의 문서와 통합되기도.
•
S/W 설계 전에 엄격한 요구사항 평가(assessment)를 수행함으로 재설계의 위험을 제거.
•
제품 가격, 위험, 일정 산정을 위한 현실적 기반을 제공
•
조직은 자체적인 V&V 계획을 위해 사용할 수도
•
시스템 인수 및 S/W 향상(enhancement)를 위한 기반
•
S/W 요구사항은 종종 자연어로 기술되나, SRS에서는 정형 또는 준 정형 기술로 보강되기도. 표기법의 선정은 최대한 정확하고 자세하게 기술할 수 있으면 됨.
•
SRS의 품질과 타 프로젝트 변수(예산, 인수, 성능, 일정 등)와 연계하기 위한 다양한 품질 지표(quality indicator)가 있으며, 이들 지표에는 크기, 가독성, 명세, 깊이, 문서 구조 등이 포함됨.
6. 요구사항 확인(Requirements Validation)
•
요구사항 문서는 V&V 대상으로 S/W 기술자의 요구사항 이해 여부를 확인(validate)하고 기업 표준 준수, 이해 가능성, 일관성, 완전성을 검증(verify)함. 정형 표기는 일관성과 완전성을 증명하는데 이점을 가짐. 고객과 개발 측 대표를 포함한 이해당사자가 검토.
•
요구사항 프로세스에서 명시적인 일정을 가져, 자원이 투입되기 전에 문제를 걸러내는 데 목적이 있음.
6.1. 요구사항 검토(Requirements Reviews) - IEEE 1028
•
확인(validation)의 가장 보편적 의미는 인스펙션 또는 검토임. 검토자는 그룹을 이루어 오류, 가정(assumption)에서의 문제, 명확성, 표준 준수 여부 등을 확인.
6.2. 프로토타이핑(Prototyping)
•
S/W 기술자의 요구사항 해석 여부 확인 및 새 요구사항 추출을 위한 대표적 수단.
•
요구사항 확인 외의 다양한 용도로 사용 가능하며, S/W 기술자의 가정을 해석하고 feedback을 받기에 좋음. 하지만 치장된 표현물 및 품질 문제로 인해 주요 기반 기능에 대한 초점을 흐리게 하는 단점을 내포.
6.3. 모델 확인(Model Validation)
•
분석 프로세스 중 개발된 모델 역시 확인 대상. 정형 명세 표기의 경우, 명세 속성을 증명하는 정형 추론을 사용 가능함.
6.4. 승인 시험(Acceptance Test)
•
요구사항 문서의 핵심 속성은 최종 제품이 요구사항 문서를 만족하는지 여부를 확인 가능토록 하는데 있음. 본 확인이 불가능하면 요구사항 문서는 단지 'wish'에 불과함. 따라서 각 요구사항을 어떻게 검증(verify)할지를 계획하는 절차, 즉 인수 테스트 케이스 설계는 매우 중요.
•
비기능 요구사항에 대한 인수 테스트 식별 및 설계는 어렵기에, 먼저 정량적으로 표현함으로 분석이 시작되어야.
7. 실제적 고려사항(Practical Considerations)
•
요구사항 프로세스는 SDLC 전체에 걸치며, 변화 관리 및 요구사항의 유지보수, 즉 현 S/W의 상태를 mirroring하는 것은 SWE 프로세스 성공의 핵심임
•
많은 조직이 요구사항 문서화를 불필요하게 생각하나 이들 조직이 커갈 수록, 그리고 그들의 고객이 많아질 수록, 제품이 진화할 수록, 제품의 변경에 따른 영향을 평가하기 위해 이를 중요시 하게 됨.
7.1. 요구사항 프로세스의 반복적 속성(Iterative Nature of Requirements Process)
•
대규모 프로젝트에서 완벽하게 이해되고 명세화된 요구사항이란 미신에 가까움. 요구사항 프로세스 각각은 설계 및 획득 결정(procurement decision)이 충분히 가능할 때까지 반복적으로 이루어짐.
•
대부분의 경우에서 요구사항에 대한 이해는 설계와 개발이 진행되면서 이루어짐. 따라서 요구사항의 개정이 생명주기 중에 일어남. 요구사항이 변화함은 요구 공학의 이해에 대한 가장 핵심적인 사항임. 이는 분석 과정에서의 오류에서도 기인하지만 주로 '환경'의 변화로 인해 발생. 변화는 관리되어야 하며 이는 검토와 승인 과정을 통해 수행되어야. 이를 위해 요구사항의 추적, 영향 분석, S/W 구성 관리가 요구됨.
•
따라서 요구사항 프로세스는 S/W 개발의 초기(front-end) 작업이 아니라 전체 생명 주기로 퍼짐.
7.2. 변화 관리(Change Management)
•
변화 관리는 요구사항 관리의 핵심. S/W 구성 관리 KA와 밀접히 엮임
7.3. 요구사항 속성(Requirements Attributes)
•
요구사항은 요구되는 사항에 대한 명세 뿐 아니라 요구사항의 관리 및 해석을 돕기 위한 부가 정보로 구성됨. 무엇보다도 중요한 요구사항 속성을 요구사항을 명확하게 식별하는 것.
7.4. 요구사항 추적(Requirements Tracing)
•
추적의 핵심은 요구사항의 영향 예측 및 요구사항의 근원 파악임. 추적은 요구사항의 변화에 대한 영향 분석을 위한 기반이 됨.
•
또한 요구사항 추적을 통해 해당 요구사항에 대한 설계 엔티티까지 다가갈 수 있어야.
•
요구사항 추적 결과는 요구사항의 복잡한 DAG(directed acyclic graph)를 형성함
7.5. 요구사항 측정(Measuring Requirements) - IEEE 14143.1 the concept of FSM
•
계량화는 요구사항의 변화의 정도, 개발 및 유지보수 작업의 비용 등을 평가하는데 유용.
•
FSM(Function Size Measurement)은 기능 요구사항의 크기를 평가하는 기술.