[소프트웨어공학] 요구공학

요구공학

요구사항 엔지니어링

• 고객이 시스템에서 요구하는 서비스와 시스템이 운영되고 개발되는 제약 조건을 설정하는 프로세스다.

• 시스템 요구사항은 요구사항 엔지니어링 프로세스 중에 생성되는 시스템 서비스 및 제한조건에 대한 설명이다(기능 명세).
  
  

요구 사항이란 무엇인가?

요구사항은 단순히 시스템이 제공하는 서비스에 대한 고수준의 추상적 서술이거나 시스템에 대한 제약사항으로 간주하기도 한다. 또한 시스템 기능에 대한 상세하고 정형화된 정의에 해당한다.

이러한 차이가 발생하는 이유로 예시를 보자면 회사가 소프트웨어 개발 프로젝트에 대한 계약을 허용하려고 하면 아직 솔루션이 정의되어있지 않기 때문에 추상적인 방식으로 필요한 요구들을 정의해야 한다.

• 요구사항이 작성되어야만 계약자들이 계약이나 제시한 가격에 참여하거나 고객의 요구를 만족시킬 수 있는 여러 방법들을 제시할 수 있다.
• 계약 후에는 고객에 대한 시스템 정의를 더 상세하게 작성해 시스템 정의를 더 상세하게 작성해야 한다.
  
  

이러한 두 문서 모두 시스템에 대한 요구사항 문서에 해당된다

요구사항 종류

사용자 요구 사항

• 시스템이 제공하는 서비스와 작동 제약에 대한 다이어그램과 자연어로 된 설명
• 고객을 위해 작성됨
  
  

시스템 요구 사항

• 시스템의 기능, 서비스 및 운영 제한 사항에 대한 자세한 설명을 설명하는 구조화된 문서
• 클라이언트와 계약자 간의 계약의 일부가 될 수 있도록 구현해야 하는 항목을 정의
  
  

시스템 이해당사자

시스템 이해당사자는 어떤 식으로든 시스템의 영향을 받아 정당한 이익이 있는 사람이나 조직이다. 이해관계자 유형

• 최종 사용자, 시스템 관리자, 시스템 소유자, 외부 이해관계자, 법률 자문가 등등…
  
  

애자일 방법과 요구 사항

• 많은 애자일 방법은 요구 사항이 너무 빨리 변경되기 때문에 자세한 시스템 요구 사항을 생성하는 것은 시간 낭비라고 주장한다.

• 애자일 방법은 일반적으로 점진적 요구 사항 엔지니어링을 사용하며 요구 사항을 ‘사용자 스토리’로 표현할 수 있다(3장에서 설명).

• 이는 비즈니스 시스템에는 실용적이지만 프리딜리버리 분석이 필요한 시스템이나 여러 팀에서 개발한 시스템에는 문제가 있습니다(ex. critical 시스템).

기능적/비기능적 요구사항

기능적 요구사항

• 시스템이 특정 입력에 반응하는 방식으로 특정 상황에서 시스템이 어떻게 작동해야 하는지에 대한 기능
• 시스템이 하지 말아야 할 것에 대한 기능
  
  

비기능적 요구사항

• 서비스에 대한 제약, 타이밍 제약, 개발 프로세스에 대한 제약, 표준 등과 같은 시스템에서 제공하는 기능
  
  

기능적 요구사항

기능 또는 시스템 서비스를 설명한다. 소프트웨어의 유형, 누가 사용할 것인지, 소프트웨어가 어디에 쓰이는지에 따라 달라진다.

기능적 사용자 요구사항은 하이레벨로 작성되며, 기능적 시스템 요구사항은 매우 디테일하게 작성해야 한다.

요구사항 부정확성

• 기능적 요구 사항이 정확하게 명시되지 않은 경우 문제가 발생한다.
• 모호한 요구 사항은 개발자와 사용자가 서로 다른 방식으로 해석할 수 있다.
  
  

요구 사항 완전성 및 일관성

완벽성

• 필요한 모든 시설에 대한 설명이 포함되어야 합니다.

일관성

• 시스템 시설에 대한 설명에는 충돌이나 모순이 없어야 합니다.
  
  

비기능적 요구사항

비기능적 요구사항은 시스템 속성 및 제약 조건을 정의한다.

• 안정성, 응답 시간 및 스토리지 요구 사항. 제약 조건은 I/O 장치 기능, 시스템 표현 등

• 특정 IDE, 프로그래밍 언어 또는 개발 방법
  
  

비기능적 요구사항은 기능적 요구사항보다 더 중요할 수 있다. 시스템이 무용지물이 될 수 있다.

비기능적 요구사항 구현

때로는 비기능적 요구 사항은 시스템의 전체 아키텍처에 영향을 미칠 수 있다.

하나의 비기능적 요구사항이 다수의 요구사항을 만들어낼 수 있다.

비기능 분류

제품 요구 사항

• 배송된 제품이 특정 방식으로 작동해야 함을 지정하는 요구 사항(예: 실행 속도, 신뢰성 등) 조직 요구 사항

• 조직 정책 및 절차의 결과인 요구 사항(예: 사용된 프로세스 표준, 구현 요구 사항 등) 외부 요구 사항

• 시스템 및 개발 프로세스 외부 요인에서 발생하는 요구 사항(예: 상호 운용성 요구 사항, 법적 요구 사항 등)
  
  
  

요구공학 프로세스(RE)

RE에 사용되는 프로세스는 애플리케이션 도메인, 관련된 사람 및 요구 사항을 개발하는 조직에 따라 크게 다르다.

• 요구사항 도출

• 요구사항 분석

• 요구 사항 검증

• 요구 사항 관리.

실제로 RE는 이러한 프로세스가 인터리브되는 반복 활동이다.

요구사항 도출 및 분석

요구사항 도출 프로세스의 목적은 이해당사자들이 하는 업무와 그들이 업무 지원을 위해 신규 시스템을 활용하는 방식을 이해하는 것이다.

애플리케이션 도메인, 시스템이 제공해야 하는 서비스 및 시스템의 운영 제약 조건에 대해 알아보기 위해 고객과 함께 일하는 테크니컬스테프를 포함한다.

요구사항 도출의 문제

• 조직 및 정치적 요인이 시스템 요구 사항에 영향을 줄 수 있다.

• 요구 사항은 분석 프로세스 중에 변경된다.

• 새로운 이해당사자가 등장하고 비즈니스 환경이 바뀔 수 있다.

요구사항 도출 과정

요구사항 도출 단계

1. 요구사항 발견(검색)

• 필수 및 기존 시스템에 대한 정보를 수집하고 이 정보에서 사용자 및 시스템 요구 사항을 추출하는 프로세스다.
• 상호 작용은 관리자에서 외부 규제자에 이르기까지 시스템 이해 관계자와 이루어진다.(인터뷰, 문화기술적 연구)

1. 요구 사항 분류 및 구성

2. 요구 사항 우선 순위 지정 및 협상,

3. 요구 사항 명세화.
   
   

요구사항 도출 기법

인터뷰

이해관계자와의 공식 또는 비공식 인터뷰는 대부분의 RE 프로세스의 일부다.

인터뷰 유형

• 미리 결정된 질문 목록을 기반으로 한 비공개 인터뷰
• 이해관계자와 다양한 이슈를 탐구하는 공개 인터뷰.
  
  

일반적으로 비공개 및 개방형 인터뷰가 혼합되어 있다. 인터뷰는 이해 관계자가 수행하는 작업과 시스템과 상호 작용하는 방법을 전반적으로 이해하는 데 유용하다.

인터뷰하는 사람은 시스템이 무엇을 해야 하는지에 대한 선입견 없이 열린 마음을 가져야 한다.

단순히 원하는 것을 묻는 것이 아니라 요구 사항을 제안하여 사용자가 시스템에 대해 이야기하도록 유도해야 한다.

인터뷰 문제점

1. 애플리케이션 전문가는 요구 사항 엔지니어가 이해하기 쉽지 않은 작업을 설명하기 위해 언어를 사용할 수 있다.

2. 인터뷰는 도메인 요구 사항을 이해하는 데 좋지 않다.

   • 요구 사항 엔지니어는 특정 도메인 용어를 이해할 수 없다.
   • 일부 도메인 지식은 너무 친숙해서 사람들이 설명하기 어렵거나 설명할 가치가 없다고 생각한다.
     
     

문화기술적 연구

사회 과학자는 사람들이 실제로 일하는 방식을 관찰하고 분석하는 데 상당한 시간을 보낸다. 사람들은 자신의 작업을 설명하거나 명확하게 설명할 필요가 없다. 중요한 사회적 및 조직적 요인을 관찰할 수 있다.

프로토타이핑과 문화기술적 연구 결합

문학기술적 연구의 문제는 그것이 더 이상 관련이 없는 역사적 근거를 가질 수 있는 기존 관행을 연구한다는 것이다.

스토리와 시나리오

시나리오와 사용자 스토리는 시스템이 어떻게 사용될 수 있는지에 대한 실제 사례다.

스토리와 시나리오는 시스템이 특정 작업에 어떻게 사용될 수 있는지에 대한 설명이다.

실제 상황을 기반으로 하기 때문에 이해 당사자가 공감할 수 있고 이야기와 관련하여 자신의 상황에 대해 언급할 수 있다.

시나리오

구조화된 형태의 사용자 스토리로 시나리오에는 다음이 포함되어야 합니다.

• 시작 상황에 대한 설명
• 이벤트의 정상적인 흐름에 대한 설명
• 무엇이 잘못될 수 있는지에 대한 설명
• 다른 동시 활동에 대한 정보
• 시나리오 완료 시 상태에 대한 설명
  
  
  

요구사항 명세

요구 사항 문서에 사용자 및 시스템 요구 사항을 기록하는 프로세스다.

• 사용자 요구 사항은 기술적 배경이 없는 최종 사용자와 고객이 이해할 수 있어야 한다.
• 시스템 요구 사항은 더 자세한 요구 사항이며 더 많은 기술 정보를 포함할 수 있다.
• 요구 사항은 시스템 개발 계약의 일부일 수 있다.(가능한 한 완벽하게 작성하는 것이 중요!!)
  
  

요구사항과 디자인

원칙적으로 요구 사항은 시스템이 수행해야 하는 작업을 명시해야 하며 설계는 이를 수행하는 방법을 설명해야 한다.

• 실제로 요구 사항과 디자인은 분리할 수 없다.
• 요구 사항을 구조화하도록 시스템 아키텍처를 설계할 수 있다.
• 시스템은 설계 요구 사항을 생성하는 다른 시스템과 상호 운용될 수 있다.
• 비기능적 요구 사항을 충족하기 위해 특정 아키텍처를 사용하는 것은 도메인 요구 사항일 수 있다.
  
  

자연어 명세

• 요구 사항은 다이어그램과 표로 보완된 자연어 문장으로 작성된다.

• 표현력이 풍부하고 직관적이며 보편적이기 때문에 요구 사항 작성에 사용된다.
  
  

요구사항 작성 가이드라인

• 표준 형식을 발명하고 모든 요구 사항에 사용

• 일관된 방식으로 언어를 사용. (필수 요구 사항에는 shall을 사용하고 바람직한 요구 사항에는 should를 사용)

• 텍스트 강조 표시를 사용하여 요구 사항의 핵심 부분을 식별

• 컴퓨터 전문 용어의 사용을 피함.

• 요구 사항이 필요한 이유에 대한 설명(근거)을 포함
  
  

자연어의 문제

• 명확성 부족
• 요구사항 혼동(헷갈리는 경우)
• 요구사항 통합
  
  

구조적 명세

요구 사항 작성자의 자유가 제한되고 요구 사항이 표준 방식으로 작성되는 요구 사항 작성에 대한 접근 방식이다. 기능적 요구사항을 명세하기 위해 표준 서식을 사용할 때는 다음 정보들을 포함해야 한다.

1. 명세를 하는 기능이나 개체에 대한 설명
2. 입력과 출력의 목적지에 대한 설명
3. 출력과 출력의 목적지에 대한 설명
4. 계산에 필요한 정보나 시스템에서 필요한 다른 개체들에 대한 정보
5. 수행해야 하는 동작에 대한 설명
6. 사전조건과 사후조건
7. 동작으로 인한 부작용에 대한 설명
   
   

Usecases(유스케이스)

• 유스케이스는 UML(Unified Modeling Language)에 포함된 일종의 시나리오다.

• 사용 사례는 상호 작용에서 액터를 식별하고 상호 작용 자체를 설명한다.

• 일련의 사용 사례는 시스템과의 가능한 모든 상호 작용을 설명해야 한다.

• 보다 자세한 표 설명으로 보완된 높은 수준의 그래픽 모델

• UML 시퀀스 다이어그램은 시스템에서 이벤트 처리 시퀀스를 표시하여 사용 사례에 세부 정보를 추가하는 데 사용할 수 있다.
  
  

소프트웨어 요구사항 문서

• 소프트웨어 요구 사항 문서는 시스템 개발자에게 요구되는 사항에 대한 공식적인 설명이다.

• 사용자 요구 사항의 정의와 시스템 요구 사항의 사양을 모두 포함해야 한다.

• 디자인 문서가 아니다, 가능한 한 시스템이 어떻게 해야 하는지보다는 무엇을 해야 하는지 설정해야 합니다.

  요구사항 문서 가변성

  요구 사항 문서의 정보는 시스템 유형과 사용된 개발 방식에 따라 다르다. 요구 사항 문서 표준이 설계되었다.(E.g. IEEE standard.)
  
  
  
  

요구사항 검증

요구사항 검증은 요구사항이 고객이 정말 원하는 시스템을 제대로 정의하고 있는지를 점검하는 과정이다.

요구 사항 확인(checking)

• 타당성. 시스템이 고객의 요구를 가장 잘 지원하는 기능을 제공합니까?

• 일관성. 요구 사항 충돌이 있습니까?

• 완전성. 고객이 요구하는 모든 기능이 포함되어 있습니까?

• 현실성. 사용 가능한 예산과 기술을 고려하여 요구 사항을 구현할 수 있습니까?

• 검증 가능성. 요구 사항을 확인할 수 있습니까?
  
  

요구 사항 검증 기술

요구 사항 검토(reviews)

• 요구 사항에 대한 체계적인 수동 분석.

프로토타이핑

• 시스템의 실행 가능한 모델을 사용하여 요구 사항을 확인(프로토타입을 만든다.)

테스트 케이스 생성

• 테스트 가능성을 확인하기 위해 요구 사항에 대한 테스트를 개발합니다.
  
  
  

요구사항 변경

시스템의 비즈니스 및 기술 환경은 설치 후 항상 변경된다.

• 시스템에 비용을 지불하는 사람과 해당 시스템의 사용자가 같은 사람인 경우는 드물다

• 대규모 시스템에는 일반적으로 다양한 사용자 커뮤니티가 있으며 많은 사용자가 서로 상충되거나 모순될 수 있는 서로 다른 요구 사항과 우선 순위를 가지고 있다.
  
  

요구사항 관리 계획

요구사항 관리는 요구사항 엔지니어링 프로세스 및 시스템 개발 중에 변화하는 요구사항을 관리하는 프로세스다.

시스템이 개발되고 사용된 후에 새로운 요구 사항이 나타나면, 개별 요구 사항을 추적하고 종속 요구 사항 간의 연결을 유지 관리해야 한다.

요구사항 관리 결정

요구 사항 식별

• 각 요구 사항은 다른 요구 사항과 상호 참조할 수 있도록 고유하게 식별되어야 한다.
  
  

변경 관리 프로세스

• 변경 관리 프로세스는 변경의 영향과 비용을 평가하는 일련의 활동으로 다음 섹션에서 이 프로세스에 대해 자세히 설명
  
  

추적 가능성 정책

• 이러한 정책은 각 요구 사항 간의 관계 및 기록해야 하는 요구 사항과 시스템 설계 간의 관계를 정의한다.
  
  

도구(Tool) 지원

• 사용할 수 있는 도구는 전문가 요구 사항 관리 시스템에서 스프레드시트 및 간단한 데이터베이스 시스템에 이르기까지 다양하다.