[소프트웨어공학] 4. Requirements Engineering

🔎Requirements Engineering

 

 Requirements engineering

 

- 고객이 시스템에서 요구하는 서비스와 시스템의 운영&개발에 대한 제약사항을 설정하는 과정

- 시스템의 요구사항은 요구공학 프로세스에서 생성되는 시스템 서비스(요구 서비스) 및 제약사항에 대한 설명

 

💡 요구사항이란?

 - 시스템이 수행해야 하는 작업 (시스템이 무엇을 해야하는가?)

 - 서비스 or 제약사항에 대한 상위 수준 추상 설명부터 세부 기능 사양에 이르기까지 다양함

 

 즉, 요구란 시스템이 무엇을 해야하며, 이 시스템을 크게 설명하는 것부터 구체적으로 설명하는 것을 이름

 

💡 요구사항의 종류

 요구사항은 "누구를 위해 작성되는가"로 구별됨

 - 사용자 요구사항

  * 시스템이 사용자에게 제공할 서비스와 동작상 제약 사항에 대해 자연어, 다이어그램(그림)으로 기록

  * 고객을 위해 작성

  * reader: 고객 관리자, 계약 관리자, 시스템 최종 사용자, 고객 엔지니어, 시스템 아키텍트

 

 - 시스템 요구사항

  * 시스템의 기능, 서비스 및 운영 제약에 대해 보다 상세하게 설명한 구조화된 문서

  * 구현할 사항을 정의하므로 클라이언트와 계약자 간 계약의 일부가 될 수도 있음

  * reader: 소프트웨어 개발자, 시스템 최종 사용자, 고객 엔지니어, 시스템 아키텍트

 

요구사항 예제

 

💡 기능 요구사항 & 비기능 요구사항

 (1) 기능 요구사항

  - 제공 서비스, 입력에 대한 시스템 반응 방식, 동작 방식을 기술

  - 시스템이 해서는 안되는 일 명시 O

 

 (2) 비기능 요구사항

  - 서비스나 기능에 대한 제약사항 (ex. 시간 제약, 개발 프로세스 제약)

  - 개별 기능/서비스보다 전체 시스템에 적용

 

 (3) 도메인 요구사항

  - 운영 영역에서의 시스템 제약사항

 

💡 기능 요구사항

  - 기능 or 서비스 설명

  - 사용자 기능 요구사항 시스템이 수행해야하는 작업에 대한 상위 수준 설명(추상)

  - 시스템 기능 요구사항 서비스를 자세히 설명(구체)

 

 

 💡요구사항 부정확성

  - 요구사항 정확히 명시되지 않으면 문제 발생

  - 모호한 요구사항은 개발자/사용자가 다르게 해석할 수 있음

 

 

 💡 요구사항 완전성과 일관성

  - 원칙적으로 요구사항은 완전하고 일관되어야함

  - 완전성: 사용자가 필요로 하는 모든 서비스와 정보 포함해야함

  - 일관성: 요구사항에 대한 설명에 충돌, 모순이 없어야함

 

  => 하지만, 실제로 완전하고 일관된 요구사항 문서 생성은 불가능

 

 💡 비기능 요구사항

  - 시스템 속성과 제약 조건 정의 (ex. 안전성, 응답 시간, 메모리 공간)

  - 프로세스 요구사항은 프로그래밍 언어, 개발 방법 지정 가능

  - 비기능 요구사항이 기능 요구사항보다 더 중요할 수도. 비기능이 충족되지 않으면 시스템이 쓸모 없어짐

  ex) 구글에서 검색하는데 1시간 걸림

 

  * 비기능 요구사항 종류

★ 아래 표(속성, 척도)들 암기하기

                                                                           <품질 속성>

품질 특성: 기능성, 신뢰성, 효율성, 사용성, 유지보수, 이식성

보안성, 호환성 추가

  * 요구사항 목표

  - 비기능 요구사항은 정확하게 적기 어려울 수 있고 부정확한 요구사항은 검증이 어려울 수 있음

  - 검증 가능한 비기능 요구사항 : 객관적 척도 사용하여 작성 (정확한 목표를 작성)

   

객관적 척도 사용하여 기술한 비기능 요구사항

비기능 요구사항에 사용 가능한 척도

 

💡 도메인 요구사항

  - 시스템 운영 도메인에서 얻는 요구사항

  ex) 열차 제어 시스템은 다양한 기상 조건에서 제동 특성 고려해야함

  - 도메인 요구사항 미충족시, 시스템 작동 안할 수도

  - 도메인 요구사항의 문제

   * 요구사항이 어플리케이션 도메인 언어로 표현 -> 소프트웨어 개발자가 이해 못할 수도 (열차 전문 용어 모를 것)

   * 도메인 전문가는 너무 당연하게 아는 내용이기 때문에, 도메인 요구사항을 친절히 명시적으로 만들 생각을 안함 

 

 

 소프트웨어 요구사항 문서

 

- 요구사항 문서는 시스템 개발자에게 요구되는 사항에 대한 공식 설명

- 사용자 요구사항 정의와 시스템 요구사항 사양 모두 포함

- 설계 문서가 아님. 시스템 수행 방법보다 수행 작업을 작성

 * 원칙적으로, 요구사항은 시스템 수행 작업을 명시하고 설계는 수행 방법을 설명

 * 실제로는 요구사항과 설계는 분리하기 어려움

 

💡 요구사항 문서의 사용자

 - 시스템 고객: 자신들의 요구 만족하는지 확인. 고객은 요구사항 변경 명세

 - 관리자: 요구사항 문서로 입찰 계획하고 개발 프로세스 계획 수립

 - 시스템 엔지니어: 요구사항 문서로 어떤 시스템 개발 해야하는지 이해

 - 시스템 테스트 엔지니어: 요구사항으로 검증 테스트 개발

 - 시스템 유지보수 엔지니어: 요구사항으로 시스템 부분과의 관계 이해

 

 💡요구사항 문서 구조

 

 

 요구사항 명세 작성 방법

 

(1) 자연어 - 번호 매긴 자연어 문장으로 작성. 각 문장은 하나의 요구사항

(2) 구조적 자연어 - 표준 양식이나 템플릿에 따라 자연어로 작성.

(3) 디자인 설명 언어 - 프로그래밍 언어와 유사한 언어 사용. 인터페이스 사양에 유용하지만 거의 사용되지 않음

(4) 그래픽 표현 - 문자 표기법으로 보완된 그래픽 모델은 기능 요구사항 정의. UML 유스케이스, 시퀀스 다이어그램 사용

(5) 수학적 명세 - 이 분명한 명세는 모호함을 줄이지만, 고객들은 정형적 명세를 이해하지 못함

 

=> 앞 번호일수록 사용자가 이해하기 쉬움

 

💡자연어 사용 시 문제점

  - 명확성 부족: 읽기 쉽게 만들면 명확하게 표현하기 어려움

  - 요구사항 혼동: 기능, 비기능 혼동

  - 요구사항 통합: 여러 다른 요구사항이 함께 표현

자연어 예시

 

💡구조적 자연어

  - 기능, 개체에 대한 설명

  - 입력과 입력 출처에 대한 설명

  - 출력과 출력 목적지에 대한 설명

  - 수행 동작에 대해 설명

  - 사전 조건, 사후 조건(필요 경우)

  - 기능 부작용

구조적 자연어 예시

 

 * Tabular specification

  - 자연어 보완시 사용

  - 대체 조치 정의해야할 때 유용

  <위의 동작 부분을 표 형식으로 작성>

 

💡 디자인 설명 언어

프로그래밍 언어와 비슷하게 보임

 

💡 수학적 명세 (ex. Z-schema)

 

 

🔎 Requirements Engineering Process

 

 요구 공학 프로세스

 

- 요구공학 프로세스는 애플리케이션 도메인, 관련 사람, 요구사항 개발 조직에 따라 달라짐

- 하지만 모든 프로세스에 공통 일반 활동이 있음

 타당성 조사 -> 요구사항 도출&분석 -> 요구사항 명세 -> 요구사항 검증

요구공학 프로새스의 공통 활동

 

- 실제로 요구공학은 위의 프로세스가 중첩되는 반복적인 활동

 

💡 요구사항 도출(elicitation)&분석

 - 요구사항 도출 또는 발견이라 함

 - 기술 스태프가 고객과 협력해서 애플리케이션 도메인, 제공 서비스, 운영 제약사항 찾는 것

 - 최종 사용자, 관리자, 유지보수 관련 엔지니어, 도메인 전문가, 노동 조합 등이 포함될 수 있음 (이해관계자=stake holder)

 

 * 요구사항 분석의 문제점

  - 이해관계자들은 자신들이 진정으로 원하는 것이 뭔지 모름

  - 이해관계자는 요구사항을 자신의 용어로 표현

  - 이해관계자끼리 요구사항 상충

  - 조직적 및 정치적 요인이 요구사항에 영향 미칠 수 있음

  - 요구사항은 분석 과정 도중 변경. 새로운 이해관계자 등장하거나 비즈니스 환경이 바뀔 수도

 

 * 요구사항 도출 및 분석 단계

  - 요구사항 발견

  - 요구사항 분류 및 구성

  - 요구사항 우선순위 정하기 및 협상

  - 요구사항 문서화

 

 * 인터뷰 (요구사항 도출 및 분석 위한)

  - 이해관계자와 공식(절차O)/비공식(절차X) 인터뷰는 대부분의 요구공학 프로세스의 일부

  - 인터뷰 유형 => 보통 폐쇄, 개방을 혼합

   + 폐쇄적: 미리 정의된 질문에 답함

   + 개방적: 다양한 이슈를 함께 탐색

  - 효과적인 인터뷰: 열린 마음으로 요구사항에 대한 선입견 피하고 경청. 인터뷰 대상자에게 스프링보드 질문, 요구사항 제안, 프로토타입 시스템 함께 사용하며 토론

 

💡 요구사항 명세

 

 * 시나리오

  - 시스템 사용 방법의 실제 예

  - 시나리오가 포함하는 것: 시작 상황 설명, 정상 흐름 설명, 잘못될 경우 설명, 동시에 진행 가능한 다른 활동 정보, 시나리오 종료 시 시스템 상태 설명 

 

 

 * 유스케이스

   - 상호작용의 행위자 식별, 상호작용 자체를 설명하는 UML 시나리오 기반 기술

  - 가능한 모든 상호작용 설명

  - 자세한 표 설명으로 보완된 고수준 그래픽 모델

  - 시퀀스 다이어그램은 이벤트 처리 순서 보여줌으로써 유스케이스에 세부 사항 추가하는데 도움

 

💡 요구사항 검증

 - 요구사항이 고객이 진정으로 원하는 시스템 정의하고 있는지 점검

 - 요구사항 문제 수정 비용이 설계/코드 오류 수정 비용보다 훨씬 높음

  + 고객 인도 후 요구사항 오류 수정하는 것은 구현 오류 비용의 최대 100배

  => 개발 후반으로 갈수록 에러 발생 시 비용 높아짐

 

 * 요구사항 확인

  - 유효성: 고객 요구를 가장 잘 반영하는 기능 제공하는가?

  - 일관성: 요구사항 충돌 있나?

  - 완전성: 요구하는 모든 기능이 포함됐나?

  - 실현성: 주어진 예산과 기술로 구현 가능한가?

  - 검증가능성: 요구사항 확인 가능한가?

 

 * 요구사항 검증 방법

  - 요구사항 리뷰: 요구사항을 체계적으로 분석

   + 요구사항 정의가 공식화되는 동안 정기적 리뷰 이루어져야함. 

   + 고객과 계약 직원 모두 리뷰에 참여

   + 리뷰는 공식(완성된 문서 포함)/비공식(절차X). 원활한 의사소통으로 초기 단계에 문제 해결 가능

  - 프로토타이핑: 실행 가능 모델로 요구사항 확인

  

💡 요구사항 관리

 - 변화하는 요구사항 관리하는 프로세스

 - 시스템 개발되고 사용되기 시작한 후에 새로운 요구사항 나타남

 - 개별 요구사항 추적하고 종속된 요구사항 간 링크 유지.