[소프트웨어 공학] 요구 공학(Requirement Engineering) - 4-2

소프트웨어 요구사항 명세화(Software Requirement Specification SRS)

: 소프트웨어 요구사항 명세서(SRS)는 소프트웨어의 요구사항을 분석하고 정의하는 단계에서 작성되는 최종 산출물

SRS의 특징에는

 

- Correct 정확한

- Complete 완전한

- Unambiguous 애매하지 않은

- Verifiable 입증할 수 있는

- Consistent 일관성

- Ranked for importance and/or stability 

- Modifiable 수정 가능한

- Traceable 

 

요구사항 명세서에 포함해야 하는 세부 정보 수준은

개발 중인 시스템의 유형과 사용되는 개발 프로세스에 따라 달라집니다

요구사항 명세서는 다음 그림과 같은 기본 양식을 가지고 있다

- 요구 공학은 4가지 수준 높은 활동을 포함한다

• 시스템이 비즈니스에 유용한 지 평가(호환성 연구)
• 요구 사항 검색(추정 및 분석)
• 이러한 요구 사항을 어떤 표준 형태로 변환하는 것(명세화)
•  요구 사항이 고객이 원하는 시스템을 실제로 정의하는지 확인하는 것(검증)

 

요구 도출 및 분석(Requirement Elicitation and Analysis)

요구사항 도출 및 분석은 각 활동에서 다른 활동에 지속적으로 피드백을 제공하는 반복적인 프로세스입니다

 

 소프트웨어 엔지니어는 고객 및 시스템 최종 사용자(end-user)와 함께 다음과 같은 정보를 찾아낸다

• 응용 프로그램 영역
• 시스템이 제공해야 하는 서비스
• 필요한 시스템 성능
• 하드웨어 제약 조건 등

 

요구 도출 및 분석 활동

1. 요구 사항 발견 및 이해(discovery) :

이해 관계자와 상호 작용하여 요구 사항을 발견하는 프로세스

*이해관계자란 프로젝트와 연관이 있는 사람들을 지칭한다. ex) 고객, 프로젝트 팀 멤버, 프로젝트 매니저..

2. 요구 사항 분류 및 구성(classification and organization) :  

이 활동은 비구조적 요구사항 모음을 취하여 관련 요구사항을 그룹화하고 일관성 있는 클러스터(무리)로 구성한다

3. 요구 사항 우선순위 지정 및 협상(prioritization and negotiation) :

여러 이해 관계자가 참여하면 요구사항이 충돌합니다. 이 활동은 요구사항의 우선순위를 정하고 협상을 통해 요구사항 충돌을 찾아 해결하는 것과 관련이 있다

4. 요구 사항 구체화(specification) :

요구 사항이 문서화된다

 

요구사항 도출 기법

1. 인터뷰(Interview)

-  시스템 이해 관계자에 대한 공식 또는 비공식 인터뷰
- 요구사항 엔지니어링 팀은 이해관계자가 현재 사용하고 있는 시스템과 개발될 시스템에 대해 질문합니다.
- 요구사항은 이러한 질문에 대한 답변에서 도출됩니다.
- 인터뷰는 두 가지 유형으로 나눌 수 있습니다.
- 비공개 인터뷰 - 이해관계자가 미리 정의된 일련의 질문에 답변합니다.
- 공개 인터뷰 - 미리 정의된 의제가 없습니다. 요구사항 엔지니어링 팀은 시스템 이해 관계자와 다양한 문제를 조사합니다

 

Interview의 장점

1, 이해 당사자가 하는 일에 대한 전반적인 이해할 수 있다
2. 그들이 새로운 시스템과 어떻게 상호작용할지 알 수 있다

3.  그들이 현재 시스템과 직면하고 있는 어려움을 알 수 있다

 

문제점

1. 도메인 전문 용어는 비전문가가 이해하기 어렵다
2. 전문가는 자신의 지식이 상식이라 간주하여 어떤 도메인 지식을 언급하지 않는 경우도 존재한다

2. 시나리오(scenarios)

특정 작업을 위해 어떻게 시스템을 사용하는지 기술하고
작업 시나리오를 거치면서 무엇을 하는지, 사용하는 정보는 무엇인지, 어떤 시스템을 이용하는지에 대한
설명을 만드는 것

 

• 시나리오 기반 도출에는 이해관계자와 협력하여 시나리오를 식별하고 이러한 시나리오에 포함될 세부 정보를 캡처하는 작업이 포함됩니다.
• 시나리오는 텍스트로 작성되고 다이어그램, 스크린샷 등으로 보완될 수 있다
• 사건 시나리오 또는 사용 사례와 같은 보다 구조화된 접근 방식을 사용할 수 있다

요구 사항 발견(Discovery)

유스 케이스 : 사용자와 다른 시스템 간의 각각의 상호작용을 정의한 것(아래 링크에 자세히 나와있다)https://jelong.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B3%B5%ED%95%99-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EB%AA%A8%EB%8D%B8%EB%A7%81System-modeling-5

[소프트웨어 공학] 시스템 모델링(System modeling) - 5

 Ethnography :

• Ethnography은 운영 프로세스를 이해하고 이러한 프로세스에 대한 지원 요구사항을 도출하는 데 사용할 수 있는 관찰 기법이다.
• 분석가는 참가자가 참여하는 실제 작업을 관찰하기 위해 작업 환경에 몰입한다
• 실제 작업 방식을 반영하는 암묵적인 시스템 요구 사항 발견에 도움이 된다

요구 사항 명세(Requirement Specification)란

사용자 요구사항 및 시스템 요구사항을 요구사항 문서로 작성하는 과정

• 시스템의 외부 행위를 명시한다
• 시스템 건축과 디자인의 세부사항을 포함할 필요 없다
• 자연어로 작성해야 하고, 간단한 표, 양식 그리고 다이어 그램과 함께 작성된다
• 시스템 요구사항은 사용자 요구사항의 확장된 version이다
• 사용자 요구사항은 시스템으로부터 어떻게 제공되어야 하는지 자세하게 기술한다

이상적인 요구사항 명세

• 시스템의 외부 행동과 운영상의 제약조건을 기술해야 한다
• 시스템 설계와 구현에 대한 사항을 다루지 않아야 한다

현실적인 요구사항 명세

요구사항에서 설계정보를 완전히 제외하는 것은 불가능하다

• 초기 아키텍처 설계가 요구사항을 구성하는데 도움이 된다
• 시스템은 설계를 제한하고 새로운 시스템에 요건을 부과하는 기존 시스템과 상호 운용할 수 있다
• 비기능적 요구사항을 만족시키기 위해 특정 아키텍처를 허용해야 하는 경우도 존재한다.

자연어 명세 (Natural Language Specification)

시스템 소프트웨어 요구 사항을 명세하기 위해 가장 보편화된 수단이지만 애매모호한 단점도 존재

 

자연어 명세 지침

1. 표준 형식을 만들어 사용
2. 필수적인 사항과 바람직한 사항을 구분하기 위해 일관성 있는 표현을 사용
3. 중요 부분의 글자를 강조
4. 요구사항의 독자가 기술적이고 소프트웨어 공학 용어를 이해한다고 생각하지 말 것
5. 가능하다면 사용자 요구사항에 대한 이유를 기록하여 변경 시 활용한다.
: 왜 포함됐는가 / 누가 제안했는가 등

 

구조적 명세 (Structured Specifications)
- 구조적 자연어는 요구사항을 자유롭게 작성하지 않고 표준화된 방식으로 작성하는
  시스템 요구사항의 한 방법이다.
- 자연어의 대부분의 장점을 살리면서도 어느 정도의 통일성을 부여할 수 있다.
- 변동성을 줄이고, 요구사항을 더 효과적으로 구성 가능

 

요구사항 검증(Requirement Validation)

요구사항 검증은 소비자가 정말 원하는 것이 무엇인지 정의하고 검토하는 과정

개발 중 또는 시스템 사용 중에 이러한 문제가 발견될 때 요구사항 문서에 오류가 있을 경우 광범위한 재작업 비용이 발생할 수 있기 때문에 중요합니다

 

유효성 검사(validity checks) - 이해관계자가 제안한 기능은 시스템이 수행해야 하는 기능과 일치해야 합니다. 대신 추가 기능이 있거나 다른 기능이 필요하다는 것을 나중에 알게 될 수도 있습니다.

일관성 검사(Consistency checks) - 문서의 요구 사항이 충돌하지 않아야 합니다. 즉, 동일한 시스템 기능에 대한 모순된 제약이나 다른 설명이 있어서는 안 된다

 

완전성 검사(Completeness Checks) - 요건 문서에는 모든 기능과 시스템 사용자가 의도하는 제약조건을 정의하는 요건이 포함되어야 한다

현실주의 점검(Realism Checks) - 기존 기술에 대한 지식을 사용하여 요구 사항이 실제로 구현될 수 있는지 확인해야 합니다

검증 가능성(Verifiability) - 고객과 계약자 간의 분쟁 가능성을 줄이기 위해 시스템 요구 사항은 항상 검증 가능하도록 작성되어야 합니다

 

검증 기법

• 요구사항 검토(Requirement reviews) - 오류 및 불일치를 확인하는 검토자 팀에 의해 요구사항이 체계적으로 분석된다

• 시제품 제작(Prototyping) - 검증에 대한 이 접근 방식에서 최종 사용자 및 고객에게 해당 시스템의 실행 가능한 모델을 시연합니다

• 시험 사례 생성(Test-case generation) - 요구 사항이 시험 가능해야 한다. 요구사항에 대한 시험이 검증 과정의 일부로 고안된 경우, 이는 종종 요구사항 문제를 드러낸다