요구사항과 요구공학
- 요구사항
- 한 시스템이 제공해야 하는 서비스들과 그 서비들의 동작에 관한 제약을 기술한 것
- 특정 목적을 제공하는 시스템에 대한 고객의 요구 반영
- 요구사항이라는 용어를 일관성 있게 사용하진 않음
사용자 요구사항: 단순 시스템이 제공해야 하는 서비스에 대한 추상적 서술 및 시스템 제약사항시스템 요구사항: 시스템 기능에 대한 상세하고 정형화된 정의- 요구사항 용어 정의 차이가 발생하는 이유
- 한 회사가 소프트웨어 개발 프로젝트에 대한 계약을 허용하려고 한다.
- 계약을 위해선 요구사항을 작성해야만 비용을 협상하고, 설루션을 제공해 줄 수 있다.
그렇기 때문에 회사 측에서는 요구사항을 작성해야만 한다. - 그런데 회사 측에서는 아직 사전 정의된(구체적인) 요구들이 없기 때문에
회사에서는 매우 추상적인 방식으로 요구사항을 계약자에게 제시해야 한다.
→ 사용자 요구사항 - 계약이 이루어지면, 계약자는 고객에 대한 시스템 정의를 더 상세히 작성해서
고객이 해당 소프트웨어가 어떤 식으로 동작할지를 이해하고 검증할 수 있게 된다.
→ 시스템 요구사항
- 요구공학
- 서비스와 제약사항을 찾고, 분석하고, 문서화하며 점검하는 프로세스
사용자 및 시스템 요구사항
- 사용자 요구사항
- 시스템이 사용자에게 제공해야 할 서비스와 동작하면서 준수해야 할 제약사항 등에 대해 기록
- 시스템 기능에 관한 개괄적인 내용부터 시스템 기능에 대한 상세한 설명에 이르기까지 다양함.
- 시스템 요구사항
- 소프트웨어 시스템의 기능, 서비스와 동작 중 제약사항에 대한 보다 상세한 설명
- 무엇을 구현해야 할지에 대해 정확하게 정의해야 함
- 구매자와 개발자 사이의 계약의 일부로 활용
- 다양한 유형의 독자들이 서로 다른 방식으로 요구사항을 읽을 수 있음
→ 상세 수준을 여러 단계로 나누어서 요구사항을 작성할 필요가 있음
이해 당사자
- 어떻게든 시스템의 영향을 받는 사람
→ 시스템에 어느 정도 관심을 가지고 있으면 누구라도 해당 - 예) MentCare 시스템 이해당사자
- 시스템에 정보가 기록되어 있는 환자, 가족, 친인척들
- 환자 진단 및 진료하는 의사들
- 일부 치료 담당하는 간호사들
- 환자 예약 관리하는 의료 접수 담당자들
- 시스템 설치 유지보수 책임 IT직원
- 환자 관리에 있어 시스템의 최신 윤리 규정 준수를 보장하기 위한 의료 윤리 담당자
타당성 조사 (Feasibility studies)
- 요구공학 프로세스 초기에 이루어져야 하는 짧은 기간의 집중적 조사
- 이 질문들에 대해서 하나라도 ‘아니요’라면 해당 프로젝트를 진행 X
- 시스템이 조직의 전체적 목적에 기여하는가?
- 시스템이 현재의 기술을 이용해서 주어진 일정과 예산으로 구현이 가능한가?
- 시스템을 사용하는 다른 시스템과 통합 가능한가?
요구공학을 다루는 이유
- 대부분의 대규모 시스템에서는 요구공학 단계를 가지는 것이 일반적
- 애자일 프로세스에서의 요구사항보다 “전통적” 관점을 다룸
- 애자일 프로세스에서의 요구사항보다 “전통적” 관점을 다룸
- 요구공학의 결과물 - 요구사항 문서
- 시스템 개발 계약이 포함되기도 함
- 시스템 개발 계약이 포함되기도 함
- 시스템 개발과 동시에 애자일 기법을 사용하는 경우도 있음
← 상세한 내용을 추가하고 시스템 요구사항을 개선하기 위한 목적
기능적 / 비기능적 요구사항
- 기능적 요구사항
- 시스템이 제공해야 하는 서비스와 특정 입력에 대해 시스템이 반응하는 방식
, 그리고 특정 상황에 시스템이 동작해야 하는 방식을 기술한 것 - 어떤 경우는 해서는 안될 것들을 명시적으로 기술하기도 함
- 시스템이 제공해야 하는 서비스와 특정 입력에 대해 시스템이 반응하는 방식
- 비기능적 요구사항
- 시스템이 제공하는 서비스나 기능에 대한 제약사항
(시간적 제약, 개발 프로세스에 대한 제약, 표준 제약) - 전체 시스템에 적용되는 경우가 많음
- 시스템이 제공하는 서비스나 기능에 대한 제약사항
- 실제로는 이러한 단순한 정의만으로 유형의 차이를 나누기 어려움
- 요구사항은 독립적이지 않으며,
하나의 요구사항은 다른 요구사항을 만들거나 강제할 수도 있음
- 요구사항은 독립적이지 않으며,
기능적 요구사항
- 시스템이 무엇을 해야 하는지 설명
- 다음의 영향을 받음
- 개발하는 소프트웨어의 유형
- 예상되는 소프트웨어 사용자
- 개발조직이 요구사항을 작성할 때 일반적으로 쓰는 접근법
- 사용자와 관리자가 이해할 수 있도록 자연어로 작성
- 기능적 시스템 요구사항
- 시스템 개발자를 위해 사용자 요구사항을 확장해서 작성한 것
- 시스템 기능, 입/출력과 예외 상황 명시
- 다양한 범위 포함
- 일반적인 요구사항 : 시스템이 무엇을 해야 하는지
- 구체적인 요구사항 : 동작하는 로컬 방식이나 조직의 기존 시스템을 반영
- 예시(Mencare)
- 사용자는 모든 클리닉에 대한 예약 리스트를 검색할 수 있어야 한다.
- 시스템은 당일 예약에 맞추어 참여할 것으로 예상하는 환자의 리스트를 보여줄 수 있어야 한다.
- → 기능적 요구 사항은 다른 정도의 상세 수준으로 작성될 수 있음
각 요구사항의 특징
- 기능적 요구사항
- 앞과 동일
- 앞과 동일
- 정보 요구사항
- 사람들의 각각의 작업을 하는데 필요한 정보에 대한 초점
- 필요한 정보를 명세하고 어떻게 정보가 전달도고 구성되어야 하는지를 기술
- 도메인 요구사항
- 시스템의 응용 도메인에서 얻게 되는 요구사항
- 새로운 요구사항 그 자체일 수도 있고, 기존 요구사항에 대한 제약조건 또는 특정 계산을 하는 방식일 수도
- 소프트웨어 엔지니어가 시스템이 동작하는 도메인의 특성을 이해하기 어려움
요구사항 명세는 정확해야 함
- 요구사항 명세에서의 부정확성
- 고객과 개발자 사이의 분쟁 야기
- 소프트웨어 개발자 - 모호한 요구사항을 구현하기 쉬운 방향으로 해석
- 소프트웨어 개발자 - 모호한 요구사항을 구현하기 쉬운 방향으로 해석
- 시스템 인도 시기를 늦추고 비용 증가
- 고객과 개발자 사이의 분쟁 야기
- 시스템에 대한 기능적 요구사항 명세는 완전하고 일관적이어야 함
완전성: 사용자가 필요로 하는 모든 서비스와 정보가 정의되어야 함일관성: 모순되는 요구사항이 없어야 함
요구사항 일관성과 완전성 달성의 어려움
- 매우 작은 소프트웨어 시스템에 대해서만 가능
- 어려운 이유
- 큰 규모의 복잡한 시스템의 명세를 작성할 때는 실수하거나 빠뜨리기 쉬움
- 서로 다른 배경과 기대를 가진 많은 이해당사자들이 관여
→ 일관적이지 않은 요구를 가지는 경향 높음
- 비일관적인 요구사항
- 처음 명세 때는 잘 드러나지 않음
- 깊은 분석 혹은 시스템 개발 단계 가서야 발견
비기능적 요구사항
- 시스템이 사용자에게 제공하는 특정 서비스와 직접적으로 관련되지 않은 요구사항
- 전체 시스템에 대해 명세하거나 제약사항 설정
- 창발적 시스템 속성과 관련되는 경우가 많음
- 신뢰성, 응답 시간과 메모리 사용량 등
- 신뢰성, 응답 시간과 메모리 사용량 등
- 시스템 구현에 대한 제약을 정의하기도 함
- I/O 장비의 성능이나 다른 시스템과의 인터페이스에서 사용하는 데이터 표현 등
- I/O 장비의 성능이나 다른 시스템과의 인터페이스에서 사용하는 데이터 표현 등
- 기능적 요구사항에 비해 더 논란이 되는 경우가 많음
- 비기능적 요구사항을 만족시키지 못하면 전체 시스템이 무용지물이 될 수 이음
- 기능적 요구사항을 만족 못하면 사용자가 다른 방식으로 해결 가능
- 기능적 요구사항을 만족 못하면 사용자가 다른 방식으로 해결 가능
- 비기능적 요구사항을 만족시키지 못하면 전체 시스템이 무용지물이 될 수 이음
- 비기능적 요구사항을 구현하는 시스템 컴포넌트를 찾는 것은 기능적 요구사항보다 어려움
- 시스템 전체 아키텍처에 영향을 줄 수 있기 때문
- 예) 임베디드 시스템에서 성능을 보장하기 위해 통신을 최소화하도록 구현
- 예) 임베디드 시스템에서 성능을 보장하기 위해 통신을 최소화하도록 구현
- 구현하기 위해 필요한 여러 기능적 요구사항이 필요할 수도 있음
- 예) 시스템 정보에 대한 접근 제한
- 예) 시스템 정보에 대한 접근 제한
- 시스템 전체 아키텍처에 영향을 줄 수 있기 때문
- 외부 요인 때문에 발생하는 사용자 요구에 의해 작성
- 예산 제약, 조직적 정책, 다른 소프트웨어나 하드웨어 시스템과의 상호 운영성에 대한 요구 등
- 예산 제약, 조직적 정책, 다른 소프트웨어나 하드웨어 시스템과의 상호 운영성에 대한 요구 등
비기능적 요구사항의 종류
제품 요구사항: 소프트웨어의 런타임 동작에 대한 명세나 제약을 작성한 것- 얼마나 빨리 실행되어야 하는지, 얼마나 많은 메모리를 필요로 하는지, 허용 가능한 고장률, 보안 항목 등
- 얼마나 빨리 실행되어야 하는지, 얼마나 많은 메모리를 필요로 하는지, 허용 가능한 고장률, 보안 항목 등
조직 요구사항: 고객과 개발자 조직의 정책이나 절차로부터 얻은 넓은 범위의 시스템 요구사항- 시스템 운영방안, 프로그래밍 언어 명세, 개발 환경, 프로세스 표준, 시스템의 운영 환경 등
- 시스템 운영방안, 프로그래밍 언어 명세, 개발 환경, 프로세스 표준, 시스템의 운영 환경 등
외부 요구사항: 시스템과 개발을 위한 프로세스의 외부 요소로부터 얻는 모든 요구사항- 규제 담당자가 사용 허가를 위해 시스템이 갖추어야 할 항목, 법 준수 요구사항, 대중 수용 요구사항 등
비기능적 요구사항 예시
- 시스템 설계자가 고려해야 하는 제약 사항을 명확하게 알려줌
- 시스템의 기능에 대해서는 다루지 않음
- 시스템의 기능에 대해서는 다루지 않음
- 법/규제에 따라서 요구사항 변경될 수 있음
- 사용자 신분 확인 방식을 로그인 이름을 사용하는 것에서 보건 신분 카드로 변경
비기능적 요구사항에서 공통적으로 발생하는 문제
- 이해당사자들이 일반적인 목표로 요구사항을 제시
- 예 ) 쉬운 사용, 고장으로부터의 시스템 복원 능력이나 빠른 사용자 반응 등
- 시스템을 인도하게 되면 해석이나 이후 논쟁에 대한 여지를 개발자가 떠맡게 됨
- 사용자 요구사항 예시
- 관리자: 시스템은 의료 직원이 사용하기 쉬워야 하고, 사용자 오류가 최소화되도록 구성되어야 한다.
- 오류 척도 추가 : 의료 직원은 두 시간의 교육 후 모든 시스템 기능을 사용해야 한다.
비기능적 요구사항을 명세하기 위한 척도
속도- 처리한 트랜잭션/초
- 사용자/사건 반응 시간
- 스크린 리프레시 시간
크기- 메가바이크/ROM 칩의 개수
- 메가바이크/ROM 칩의 개수
사용 편리성- 교육 시간
- 헬프 프레임의 수
신뢰성- 고장까지의 평균 시간
- 비가용 확률
- 가용성
- 고장 발생 비율
견고성- 고장 후 재가동 시간
- 고장 원인 사건의 백분율
- 고장에 의한 데이터 손상 확률
이식성- 타깃 시스템에 종속된 문장의 백분율
- 타깃 시스템의 수
비기능적 요구사항 명세의 어려움
- 대부분의 시스템 사용 고객이 목표를 측정 가능한 요구사항을 바꾸는 것을 어렵게 생각
- 단순한 척도가 없는 경우
- 정량적인 명세가 가능해도 고객이 요구사항에 이에 맞추어 작성하기 어려움
- 객관적으로 검증하는 비용이 매우 높은 경우
- 요구사항 문서에서 기능적/비기능적 요구사항을 분리하기 어려움
- 비기능적 요구사항은 다른 기능적 비기능적 요구사항과 충돌하거나 상호연관되기도 함
- 분리해서 작성할 경우 둘 사이의 관계 이해가 어려움