2. S/W 요구사항

약어 정리

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)

2. 요구사항 공정(Requirements Process)

3. 요구사항 추출(Requirements Elicitation)

3.1.

3.2.

S/W에 영향을 주는 모든 잠재적 Source의 식별이 중요. 따라서 다양한 Source의 인지 및 이들을 관리할 Framework이 필요. 주요 핵심으로서, 다음과 같은 것이 있음.
목표(Goal), 도메인 지식(Domain Knowledge), 이해당사자(Stakeholder), 운영 환경(The operational environment), 조직 환경(Organizational environment)
1. 추출 기술(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를 위한 분류, 협상 등이 포함

5. 요구사항 명세(Requirements Specification)

'명세'란 제품의 설계 목표에 수치적 값 또는 제한의 할당을 의미하는데, 전형적으로 물리적 시스템은 그러한 값이 상대적으로 적은 반면, S/W는 요구사항이 매우 많기에 초점은 대량의 요구사항 간 상호작용의 복잡도 관리에 대해 수치적 양화(量化; quantification)에 있음.
따라서 SWE에서의 요구사항 명세란 시스템적으로 검토, 평가 및 승인이 가능한 문서적 산출물(production) 또는 이에 상응한 전자적 산출물을 뜻함. 특히 복잡한 시스템에서는 3가지의 문서, 즉 시스템 정의, 시스템 요구사항, S/W 요구사항이 수반됨.

5.1.

5.2.

5.3.

1. 시스템 정의 문서(System Definition Document) - IEEE 1362, Concept of Operations Document

사용자 요구사항 문서(the user requirements document) 또는 운용 개념(concept of operations)으로 알려지기도.
도메인 관점에서 고수준 요구사항을 정의함. 사용자/고객이 독자층에 포함되기에 도메인 언어로 기술되어야.
내용 : 시스템의 전체 목표에 대한 배경 정보, 시스템 요구사항, 대상 환경, 제한 조건, 가정, 비기능 요구사항. 시스템 컨텍스트를 표현하기 위한 개념 모델과 사용자 시나리오, 주요 도메인 엔티티, 데이터, 정보, workflow를 포함하기도.
1. 시스템 요구사항 명세(System Requirements Specification) - IEEE1233-98
시스템 요구사항에서 S/W 요구사항이 도출된 후, S/W 컴포넌트의 요구사항이 지정됨.

1. 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)함. 정형 표기는 일관성과 완전성을 증명하는데 이점을 가짐. 고객과 개발 측 대표를 포함한 이해당사자가 검토.
요구사항 프로세스에서 명시적인 일정을 가져, 자원이 투입되기 전에 문제를 걸러내는 데 목적이 있음.

7. 실제적 고려사항(Practical Considerations)

요구사항 프로세스는 SDLC 전체에 걸치며, 변화 관리 및 요구사항의 유지보수, 즉 현 S/W의 상태를 mirroring하는 것은 SWE 프로세스 성공의 핵심임.
많은 조직이 요구사항 문서화를 불필요하게 생각하나 이들 조직이 커갈 수록, 그리고 그들의 고객이 많아질 수록, 제품이 진화할 수록, 제품의 변경에 따른 영향을 평가하기 위해 이를 중요시 하게 됨.

Page updated

Google Sites

Report abuse