요구사항 공학

요구사항이란 무엇인가

요구되는 것; 원하는 것 또는 필요한 것
시스템이 무엇을 할 것인지 완전히 설명하지만 어떻게 할 것인지 언급하지 않음

ex) 온라인 서점 요구사항

• 온라인 서점 시스템은 고객이 인터넷을 이용하여 도서검색과 주문 등이 가능하도록 구축된 시스템이다.
• 고객은 회원가입과 로그인을 통해 회원이 되며, 가입한 회원은 고객 정보 관리를 통해 자신의 정보를 관리할 수 있다.
• 고객은 원하는 도서가 있는 경우 시스템 내 검색 화면에서 도서를 검색하며, 도서 장르에 따라 카테고리별 검색도 가능하다.
• 회원은 도서검색 이후 구매를 원하는 도서는 장바구니에 담아 효율적으로 도서 주문할 수 있도록 한다.

엔지니어링 후 요구사항

• 온라인 서점시스템은 전반적인 온라인서점운영을 대상으로 하며 인증된 회원이면 인터넷 환경에서 누구나 온라인 결제가 가능한 웹 브라우저를 통해 온라인 서점에 접근하여 도서검색과 카테고리검색, 주문, 조회, 취소가 가능하며 시스템 내부는 컴포넌트 기반으로 구축한다.

• 고객은 회원가입을 통해 자신의 아이디와 password를 입력하여 회원만의 서비스를 이용할 수 있게 로그인을 하며, 가입한 회원들의 정볼는 고객 정보 관리를 통해 자신의 정보를 수정 및 조회할 수 있다. 모든 회원들의 개인정보는 서점관리자만 접근할 수 있다.

실제 문제는 무엇인가?

• 고객은 요구되는 것이 무엇인지에 대해 모호한 생각만 가지고 있다.
• 개발자는 "우리는 자세한 내용은 진행하면서 채울 것입니다"라는 가정하에 "모호한 생각"으로 진행할 의향이 있습니다.
• 고객은 요구사항을 계속 변경합니다.

요구사항 공학의 중요성

• 사용자와 개발자 간의 요구사항에 대한 오해는 상당한 비용으로 이어질 수 있습니다.
  불충분한 요구사항 -> 프로젝트 실패의 주요원인
  

요구사항 단계의 문제

• 복잡성
  - 문제를 이해하고 명확히 설명하기 어려움
  • 응용 프로그램 도메인을 이해해야 함
• 요구사항의 변화하는 성격
  - 변경은 사라지지 않고 무시할 수 없음
  • 최종 사용자는 얻기 전까지 무엇을 원하는지 모름
• 의사소통
  - 다양한 배경을 가진 다수의 인간 인터페이스
  

요구사항의 종류

기능적 요구사항

시스템에 주어지는 특정 입력에 대해서 시스템이 산출하는 출력에 의해서 정의됨

비기능적 요구사항

시스템의 특성과 제약 조건을 정의하는 것.

품질

대표적인 품질 요구사항

• 성능 : 시스템의 자원을 얼마나 효율적으로 사용하는가?
• 신뢰성 : 시스템이 주어진 요구사항을 준수하여 동작하는 정도를 뜻한다.
• 보안성 : 허가되지 않은 사용자가 시스템에 접근하거나, 사용자가 접근 권한이 없는 시스템의 정보를 접근하거나 해서는 안된다.
• 안전성 : 시스템이 주변 환경, 인명, 재산에 피해를 주지 않아야 한다는 요구사항이다.
• 가용성 : 사용자가 원하는 순간에 시스템은 서비스를 제공해야 한다는 요구사항이다.

예시

성능
사용자가 통화버튼을 누르면 2초 이내에 통화 연결이 성립되어야 한다.
통화 연결 기능은 20KB 이내의 메모리만을 사용해야 한다.
엘리베이터 버튼을 누르면 해당 층으로 10초 이내에 엘리베이터가 이동해야 한다.
도서 검색은 3초 이내에 검색 결과를 화면으로 출력해야 한다.

신뢰성
지대공미사일은 100개를 발사하면 90개는 목표에 명중해야 한다.
100 통화 연결을 시도하면 95번은 성공해야 한다.

보안성
등록된 사용자 만이 시스템에 접근할 수 있어야 한다.
보안 등급이 A, B인 정보는 OO, OO 그룹의 등록된 사용자 만이 접근할 수 있어야 한다.
네트웍을 통하여 송수신되는 데이터가 노출되어서는 안된다.

안전성
엘리베이터 문이 열린 상태에서는 엘리베이터는 이동해서는 안된다.
엘리베이터가 이동중일때는 문이 열려서는 안된다.
원자로의 온도와 압력이 정상 범위를 벗어나면 자동으로 원자로를 종료시켜야한다.

가용성
인터넷 뱅킹 시스템은 1년 365, 하루 24시간 동안 서비스를 제공해야 한다.
수강신청시스템은 수강신청 기간 동안에는 중단 없이 서비스를 제공해야한다.

제약 사항

개발 방법과 개발 플랫폼에 대한 제약을 할 수가 있다.

요구사항 명세서의 요건

• 소프트웨어 개발, 소프트웨어 테스팅, 소프트웨어 개발 완료에 대한 승인 기준으로서 사용되기 위해서는 요구사항 명세서는 다음과 같은 특징을 갖추어야 한다.

명확성 : 기술된 요구사항은 항상 동일한 의미로 해석되어야 한다. 즉 모호하지 않아야 한다.
완전성 : 사용자가 기대하는 모든 기능/비기능적 요구사항이 기술되어야 한다. 즉 누락되어서는 안된다.
일관성 : 서로 상층되는 요구사항이 있어서는 안된다.
검증가능성 : 객관적으로 검증할 수 있도록 구체적이어야 한다.
구현가능성 : 가용된 기술과 한정된 일정/비용으로 구현이 가능해야 한다.

요구사항 프로세스 - 1

1. 시작 - 문제의 기본적인 이해를 확립하기 위한 질문 세트를 제시합니다. 해결책을 원하는 사람들, 원하는 해결책의 성격, 고객과 개발자 간의 예비 의사소통과 협력의 효과를 확인합니다.
2. 수집 - 모든 이해관계자로부터 요구사항을 도출합니다.
3. 세부화 - 데이터, 기능 및 행위 요구사항을 식별하는 분석 모델을 작성합니다.
4. 협상 - 개발자와 고객 모두에게 현실적인 납품 가능한 시스템에 동의합니다.

요구사항 프로세스 - 2

명세 - 다음중 하나 이상일 수 있습니다:

• 문서
• 모델의 집합
• 형식적인 수학적 모델
• 사용자 시나리오의 집합
• 프로토타입

검증 - 다음중 하나 이상일 수 있습니다:

• 내용이나 해석상의 오류
• 명확화가 필요한 부분
• 누락된 정보
• 일관성 부족
• 상충되거나 현실적이지 않은 요구사항

요구사항 도출

요구사항 도출 과정에서 다음과 같은 단계들이 포함됩니다.

• 소프트웨어 엔지니어와 고객이 참석하는 회의를 진행합니다.
• 준비와 참여를 위한 규칙이 수립됩니다.
• 회의 안건이 제안됩니다.
• 회의를 이끄는 사람이 회의를 주도합니다.
• 정의 매커니즘이 사용됩니다.
• 목표는 문제를 식별하고 솔루션의 요소를 제안하며, 다양한 접근방식을 협상하고, 요구사항의 초기집합을 명시하는 것입니다.

FAST 지침

• 참가자들은 전체 회의에 참석해야 합니다.
• 모든 참가자는 동등합니다.
• 준비가 회의만큼 중요합니다.
• 회의 전 문서는 제안된 것으로 간주됩니다.
• 원격 회의 장소가 선호됩니다.
• 의제를 설정하고 유지해야 합니다.
• 기술적 세부사항에 빠지지 말아야 합니다.

요구사항 정의/명세

요구 정의

• 요구사항의 고수준 추상적인 설명
• 자연어로 된 진술
• 전문가가 아닌 직원이 이해할 수 있는 내용

요구 명세

• 시스템이 숳ㅇ해야 하는 내용에 대한 상세한 설명
• 보다 정확하고 형식적인 표현으로 된 진술

소프트웨어 명세

• 소프트웨어 디자인에 대한 추상적인 설명
• 디자인과 구현의 기초
• 주로 소프트웨어 디자이너들으 ㄹ대상으로 함
• 직접적으로 요구명세에 기반을 둔 디자인일 수 있어서, 명세서가 작성되지 않을 수 있음.

UML

• 객체 지향 시스템
• 요구분석, 시스템설계, 시스템구현등의 시스템 개발과정에서 개발자 간의 의사소통을 위한 시스템

UML Diagram

• UML을 사용하여 시스템 상호 작용, 업무 흐름, 객체 간의 메시지 전달, 시스템의 구조, 컴포넌트 관계 등을 그린 도면

requirements engineering process

요구사항 공학 프로세스(Requirements Engineering Process)는 소프트웨어나 시스템 개발의 초기 단계로서, 사용자와 시스템 간의 요구사항을 정의하고 관리하기 위한 체계적인 방법론을 의미합니다. 이 프로세스는 아래와 같은 주요 활동을 포함합니다:

요구사항 도출 (Requirements Elicitation): 사용자, 이해관계자 및 기타 관련자들과의 대화, 설문조사, 인터뷰 등을 통해 시스템에 대한 요구사항을 수집하고 도출합니다.

요구사항 분석 (Requirements Analysis): 수집된 요구사항을 검토하고 분석하여 명확하고 일관된 요구사항으로 정제합니다. 이는 모호한 요구사항을 식별하고 이해관계자 간의 모순된 요구를 해결하기 위한 과정입니다.

요구사항 명세화 (Requirements Specification): 분석된 요구사항을 형식적인 명세로 문서화합니다. 이는 요구사항이 명확하게 이해될 수 있도록 하고, 개발자들이 이를 구현할 수 있도록 지침을 제공합니다.

요구사항 검증 (Requirements Validation): 명세화된 요구사항이 실제 시스템이나 소프트웨어와 일치하는지 검증하는 과정입니다. 이는 요구사항이 완전하고 정확하며 현실적인지를 확인합니다.

요구사항 관리 (Requirements Management): 요구사항의 변경 관리, 추적 및 협업을 위한 프로세스를 관리합니다. 새로운 요구사항이나 변경 사항이 발생할 때 이를 추적하고 관리하여 프로젝트의 효율성을 유지합니다.

이러한 단계들은 요구사항이 명확하게 이해되고 프로젝트에 반영될 수 있도록 보장하기 위한 중요한 프로세스입니다. 이를 통해 프로젝트의 성공 확률을 높일 수 있으며, 요구사항 변경으로 인한 프로젝트 위험을 줄일 수 있습니다.

Davis` Principles

기능성 (Functionality): 소프트웨어가 사용자나 시스템의 요구에 맞게 기능을 제공해야 합니다. 이는 사용자가 원하는 작업을 수행할 수 있는 능력을 의미합니다.

신뢰성 (Reliability): 소프트웨어는 정확하고 예상 가능한 결과를 제공해야 합니다. 사용자와 시스템의 요구에 부합하며, 오류가 최소화되어야 합니다.

사용성 (Usability): 소프트웨어는 사용자가 쉽게 이해하고 사용할 수 있어야 합니다. 인터페이스는 직관적이고 효율적이어야 하며, 사용자의 편의성을 고려해야 합니다.

효율성 (Efficiency): 소프트웨어는 자원을 효율적으로 활용하여 작업을 수행해야 합니다. 작업 처리 시간이나 자원 사용량을 최소화해야 합니다.

유지보수성 (Maintainability): 소프트웨어는 변경이나 업데이트를 위해 쉽게 수정할 수 있어야 합니다. 코드가 명확하고 구조화되어 있어서 유지보수 비용이 최소화될 수 있어야 합니다.

이동성 (Portability): 소프트웨어는 다른 환경이나 플랫폼으로 쉽게 이전할 수 있어야 합니다. 다양한 시스템에서 실행될 수 있도록 설계되어야 합니다.

이러한 Davis의 원칙들은 소프트웨어 요구사항의 품질을 향상시키고 프로젝트의 성공을 증진하기 위해 고려해야 할 중요한 측면들을 강조합니다.

Use case model 이란?

Use Case Model은 시스템이나 소프트웨어의 동작을 기능적인 관점에서 표현하는 방법 중 하나입니다. Use Case Model은 시스템이 어떻게 사용될 것인지를 논리적이고 구조화된 방식으로 설명합니다. 주로 사용자가 시스템과 상호 작용하는 방식을 보여줍니다.

Use Case Model은 다음과 같은 요소로 구성됩니다:

Use Case (사용 사례): Use Case는 시스템이 사용자 또는 다른 시스템과 상호 작용하는 시나리오를 나타냅니다. 각 Use Case는 시스템이 수행할 수 있는 특정 기능이나 작업을 나타냅니다. 예를 들어, 고객이 주문을 생성하는 기능이나 관리자가 사용자를 추가하는 기능 등이 Use Case가 될 수 있습니다.

액터 (Actor): 액터는 시스템 외부에서 시스템과 상호 작용하는 사용자나 다른 시스템을 나타냅니다. 주로 사람, 외부 시스템, 다른 소프트웨어 등이 액터가 될 수 있습니다.

관계 (Relationships): Use Case와 액터 간의 관계를 나타냅니다. 주로 사용자가 특정 Use Case를 실행하는 경우를 나타내는 포함 관계 (include), 확장 관계 (extend), 일반화 관계 (generalization) 등이 있습니다.

Use Case Model은 소프트웨어 요구사항을 수집하고 명세화하는 데 사용됩니다. 이 모델을 사용하면 개발팀은 사용자 요구사항을 이해하고 시스템의 기능을 정의할 수 있습니다. 또한, Use Case Model은 소프트웨어 개발의 초기 단계에서 요구사항 검증과 공유에 도움이 됩니다.

use case model 예시 첨부

https://buma.wiki
부마위키 use case