[소프트웨어 공학] 05. Requirements engineering

Requirements engineering(요구 공학)

• 고객이 요구하는 서비스를 제공(establishing the services)하고 운영되는 제약 조건(the constraints)을 설정하는 과정입니다.
• 시스템 요구사항은 요구 공학 과정에서 생성된 시스템 서비스 및 제약 조건의 설명입니다.

What is a requirement?(요구사항이란?)

• 시스템 제약에서 상세한 수학적 기능 사양에 이르기까지 다양할 수 있습니다.
• 요구사항은 이중 기능을 수행할 수 있으므로 피할 수 없습니다(요구사항이 제공하는 두 가지 기능).
  • 계약 입찰의 기초가 될 수 있으며 해석의 여지가 있어야 합니다(이해할 수 있어야 한다);
  • 계약 자체의 기초가 될 수 있으며 상세하게 정의되어야 합니다;
  • 이 두 명제 모두 요구사항이라고 할 수 있습니다.

Types of requirement(요구사항의 유형)

• 사용자 요구사항
  • 시스템이 제공하는 서비스와 운영상의 제약 조건에 대한 자연어와 다이어그램의 명제입니다.
  • 고객을 위해 작성됩니다.
• 시스템 요구사항
  • 시스템의 기능, 서비스 및 운영상의 제약 조건에 대한 상세한 설명을 담은 구조화된 문서입니다.
  • 클라이언트와 계약자 간의 계약의 일부가 되어야 할 구현 사항을 정의합니다.

Agile methos and requirements(애자일 방법론과 요구사항)

• 많은 애자일 방법론은 상세한 시스템 요구사항을 생산하는 것은 요구사항이 너무 빨리 변하기 때문에 시간 낭비라고 주장합니다.
• 요구사항 문서는 따라서 항상 구식입니다.
• 애자일 방법론은 일반적으로 점진적 요구 공학을 사용하며, '사용자 스토리'(3장에서 논의됨)로 요구사항을 표현할 수 있습니다.
• 이는 비즈니스 시스템에는 실용적이지만, 전달 전 분석이 필요한 시스템(예: 중요 시스템)이나 여러 팀이 개발하는 시스템에는 문제가 될 수 있습니다.

Functional and non-functional requirements(기능적 및 비기능적 요구사항)

• 기능적 요구사항(Functional requirements)
  • 시스템이 제공해야 하는 서비스, 특정 입력에 대한 시스템의 반응 및 특정 상황에서 시스템의 동작에 대한 명제입니다.
  • 시스템이 하지 말아야 할 것을 명시할 수도 있습니다.
• 비기능적 요구사항(Non-functional requirements)
  • 시스템이 제공하는 서비스나 기능에 대한 제약 조건, 개발 과정에 대한 제약 조건, 표준 등입니다.
    • ex) 페이지 로딩 제한시간, 원자로 제어 SW를 개발하는 과정에서 제약 조건
  • 종종 시스템 전체에 적용되는 경우가 많으며 개별 기능이나 서비스보다는 시스템 전체에 적용됩니다.
• 도메인 요구사항(Domain requirements)
  • 운영 영역의 시스템에 대한 제약 조건입니다.
  • ex) 모바일 SW의 경우 저전력 상태로 작동할 수 있어야 함

Functional Requirements(기능 요구 사항)

• 기능성이나 시스템 서비스를 설명한다.
• 사용되는 소프트웨어의 종류, 예상 사용자, 그리고 소프트웨어 사용 환경에 따라 달라진다.
• 사용자 기능 요구 사항은 시스템이 수행해야 할 작업에 대한 고수준의 진술일 수 있다.
• 시스템 기능 요구 사항은 시스템 서비스를 상세히 기술해야 한다.

Functional Requirements for a Tetris Game(테트리스 게임의 기능 요구 사항)

1. 현재 블록은 초당 한 줄의 속도로 떨어져야 한다.
2. 사용자는 다음과 같이 현재 블록을 제어할 수 있어야 한다.
   1. 블록을 왼쪽, 오른쪽 및 아래로 이동한다.
   2. 시계 방향으로 90도 회전한다.
   3. 블록을 한 번에 떨어뜨린다.
3. 현재 게임을 일시 중지할 수 있는 키가 있어야 한다.
4. 플레이 중이거나 일시 중지 중에 현재 게임을 종료할 방법이 있어야 한다.

Requirements Imprecision(요구 사항의 불명확성)

• 기능 요구 사항이 정확하게 명시되지 않을 때 문제가 발생한다.
• 모호한 요구 사항은 개발자와 사용자에 의해 다르게 해석될 수 있다.
• 팀 프로젝트 요구 사항에서 '게임 종료'라는 용어를 고려해보자.
  • 사용자 의도 - 프로그램을 완전히 종료한다.
  • 개발자 해석 - 현재 게임을 중지하고 시작 메뉴로 돌아간다.
• 일관되게, 혼동되지 않게 명세를 작성해야 한다

Requirements Completeness and Consistency(요구 사항의 완전성 및 일관성)

• 원칙적으로, 요구 사항은 완전(Complete)하고 일관(Consistent)되어야 한다.
• 완전함(Complete)
  • 필요한 모든 시설에 대한 설명을 포함해야 한다.
• 일관성(Consistent)
  • 시스템 시설의 설명에 충돌이나 모순이 없어야 한다.
• 실제로, 시스템과 환경의 복잡성 때문에 완전하고 일관된 요구 사항 문서를 만드는 것은 불가능할 수 있다.

Non-functional Requirements(비기능적 요구 사항)

• 시스템의 속성과 제약을 정의한다.
  • 예를 들어, 신뢰성, 응답 시간 및 저장 요구 사항 등이다.
  • 제약 사항은 I/O 장치 능력, 시스템 표현 등이 될 수 있다.
• 프로세스 요구 사항도 특정 IDE, 프로그래밍 언어 또는 개발 방법을 지정하여 명시될 수 있다.
• 비기능적 요구 사항은 기능 요구 사항보다 더 중요할 수 있다.
  • 이러한 요구 사항이 충족되지 않으면 시스템은 무용지물이 될 수 있다.

Types of Nonfunctional Requirement(비기능적 요구 사항의 유형)

Non-functional requirements implementation(비기능적 요구 사항의 구현)

• 비기능적 요구 사항은 개별 구성 요소보다는 전체 시스템 아키텍처에 영향을 줄 수 있다.
  • 예를 들어, 성능 요구 사항이 충족되도록 하기 위해 구성 요소 간의 통신을 최소화하도록 시스템을 조직해야 할 수도 있다.
• 단일 비기능적 요구 사항은 필요한 시스템 서비스를 정의하는 관련 기능적 요구 사항을 여러 개 생성할 수 있다.
  • 예) 보안 요구 사항 → 비밀번호 제약 조건 검증.
  • 이는 기존 요구 사항을 제한하는 요구 사항을 생성할 수도 있다.

Goals and requirements(목표와 요구사항)

• 비기능적 요구사항은 매우 명확히 제시하기 어렵고, 모호한 요구사항은 검증하기가 어려울 수 있습니다.
• 목표(Goal)
  • 사용 편의성 등 사용자의 일반적인 의도
• 검증 가능한 비기능적 요구사항(Verifiable non-functional requirement)
  • 객관적으로 테스트할 수 있는 어떤 측정 방법을 사용한 명세.
  • ex) Ease of use를 측정
• 목표들은 시스템 사용자의 의도를 전달함으로써 개발자에게 도움이 됩니다.

Metrics for specifying nonfunctional requirements(비기능적 요구사항을 정의하기 위한 메트릭)

속도(Speed)	초당 처리 트랜잭션, 사용자/이벤트 응답 시간, 화면 새로고침 시간
크기(Size)	메가바이트, ROM 칩의 수
사용의 용이성(Ease of use)	교육 시간(Training time), 특정 메뉴까지의 단계 수(Number of steps to certain menu), 도움말 프레임 수
신뢰성(Reliaability)	평균 고장 시간, 불가능성 확률, 고장 발생률, 가용성
강건성(Robustnes)	고장 후 회복 시간(Time to recovery after failure. ex 재부팅 시간), 고장을 일으키는 이벤트의 비율, 고장 시 데이터 오류 확률
이식성(Portability)	타겟 종속 명령문의 비율, 타겟 시스템 수

Requirements engineering processes(요구 공학 프로세스)

• 요구 공학(RE)에 사용되는 프로세스는 응용 프로그램 도메인, 관련된 사람들, 그리고 시스템을 개발하는 조직에 따라 매우 다양합니다.
• 하지만 모든 프로세스에 공통적으로 있는 몇 가지 일반적인 활동들이 있습니다.
  • 요구사항 도출;
  • 요구사항 분석;
  • 요구사항 검증;
  • 요구사항 관리.
• 실제로, RE는 이러한 프로세스가 상호 연계되어 있는 반복적인 활동입니다.

Requirements elicitation and analysis(요구사항 도출과 분석)

• 소프트웨어 엔지니어는 다양한 시스템 이해관계자들과 함께 일하면서 다음과 같은 다양한 정보를 알아냅니다.
  • 응용 프로그램 도메인, 시스템이 제공해야 할 서비스, 필요한 시스템 성능, 하드웨어 제약조건, 다른 시스템들 등.
• 즉, 기능적 및 비기능적 요구사항입니다.

Problems of requirements elicitation(요구사항 도출의 문제점)

• 이해관계자들은 그들이 정말로 원하는 것을 모릅니다.(don't know what they really want)
• 이해관계자들은 자기 나름대로 요구사항을 표현합니다.(express requirements in their own terms)
• 다른 이해관계자들은 서로 상충하는 요구사항을 가질 수 있습니다.(conflicting requirements)
• 조직적 및 정치적 요인이 시스템 요구사항에 영향을 줄 수 있습니다.
• 분석 과정 동안 요구사항이 변경됩니다.(The requirements change)
  • 새로운 이해관계자들이 등장하거나 비즈니스 환경이 변할 수 있습니다.
  • ex) 검색 엔진을 GPT가 대체?

Requirements discovery(요구사항 발견)

• 필요한 및 기존 시스템에 대한 정보를 수집하고 이 정보에서 사용자 및 시스템 요구사항을 추출하는 과정입니다.
• 이 과정은 관리자부터 외부 규제기관에 이르기까지 시스템 이해관계자와의 상호작용을 포함합니다.
• 시스템은 일반적으로 다양한 이해관계자를 가지고 있습니다.

Interviewing(인터뷰)

• 이해관계자와의 공식적 또는 비공식적 인터뷰는 대부분의 RE 과정에 포함됩니다.
• 인터뷰 유형
  • 미리 정해진 질문 목록을 기반으로 한 닫힌 인터뷰(Closed interview).
  • 이해관계자와 함께 다양한 이슈를 탐색하는 열린 인터뷰(Open interview).
  • 질문을 미리 만들었는지에 대한 여부에 따라 open / Closed

Interviews in practice(인터뷰 실제)

• 일반적으로 닫힌 인터뷰와 열린 인터뷰의 혼합입니다.
• 인터뷰는 이해관계자가 무엇을 하는지, 시스템과 어떻게 상호 작용할지에 대한 전반적인 이해를 얻는 데 좋습니다.
• 인터뷰어는 시스템이 무엇을 해야 하는지에 대한 선입견 없이 개방적이어야 합니다.
• 사용자가 시스템에 대해 이야기하도록 유도함으로써 요구 사항을 제안(suggesting requirements)하는 것이 그들에게 무엇을 원하는지 단순히 묻는 것(simply asking them what they want.)보다 낫습니다.

Problems with interviews(인터뷰의 문제점)

• 도메인 전문가는 요구 사항 엔지니어가 이해하기 어려운 언어로 작업을 설명할 수 있습니다.
• 인터뷰는 도메인 요구 사항을 이해하는데 좋지 않습니다.
  • 요구 사항 엔지니어는 특정 도메인 용어를 이해할 수 없습니다.
  • 어떤 도메인 지식은 인터뷰이에게 너무 익숙해서 말로 표현하기 어렵거나 언급할 가치가 없다고 생각할 수 있습니다.

Ethnography(인류학)

• 사회 과학자는 사람들이 실제로 어떻게 일하는지를 관찰하고 분석하는 데 상당한 시간을 보냅니다.
• 사람들은 자신의 작업을 설명하거나 말로 표현할 필요가 없습니다.
• 중요한 사회적 및 조직적 요인이 관찰될 수 있습니다.
• 인류학적 연구는 작업이 단순한 시스템 모델로 제안된 것보다 훨씬 풍부하고 복잡하다는 것을 보여줍니다.

Scope of ethnography(인류학의 범위)

• 사람들이 실제로 어떻게 일하는지로부터 파생된 요구 사항은, 프로세스 정의가 제안하는 방식으로 일해야 한다는 것보다 중요합니다.(the way that people actually work rather than the way which process definitions suggest)
• 다른 사람들의 활동에서 파생된 요구 사항입니다.
  • 다른 사람들이 무엇을 하는지에 대한 인식은 우리가 일을 하는 방식에 변화를 초래합니다.
• 인류학은 기존 프로세스를 이해하는데 효과적이지만(effective for understanding existing processes), 시스템에 추가해야 할 새로운 기능을 식별하는 데는 적합하지 않습니다(cannot identify new features).

Stories and scenarios(스토리와 시나리오)

• 시나리오와 사용자 스토리는 시스템이 사용될 수 있는 실제 예입니다.
• 스토리와 시나리오는 특정 작업에 시스템이 어떻게 사용될 수 있는지에 대한 설명입니다.
• 그것들은 실제 상황을 기반으로 하기 때문에, 이해관계자들은 그것과 관련하여 자신의 상황에 대해 코멘트할 수 있습니다.

Scenarios(시나리오)

• 사용자 스토리의 구조화된 형태입니다.
• 시나리오는 다음을 포함해야 합니다:
  • 시작 상황(starting situation)에 대한 설명;
  • 정상적인 이벤트 흐름(normal flow)에 대한 설명;
  • 문제가 발생할 수 있는 상황(what can go wrong)에 대한 설명;
  • 다른 동시 활동에 대한 정보;
  • 시나리오가 끝났을 때의 상태(the state when the scenario finishes에 대한 설명;
• SE 시험공부 할 때 user story를 보고 scenario를 작성하는 연습을 해보자

---

자취방 구하기 서비스 Story

• 사용자는 자취방을 구하려고 하고 있다.
• 자신이 원하는 조건을 필터링하여 원하는 매물을 찾으려고 한다
  • 이 중, 카드 사용내역을 바탕으로 자주 이용하는 상점과의 거리를 파악해 생활권 내에 자취방이 위치하는지 판단하려고 한다.

Starting Situation

• 사용자 정보, 관련 데이터를 초기화 후 지도를 출력

Normal flow

• 서비스에 들어가서 지도를 확인
• 여유자금, 조건, 임대기간 등의 옵션을 입력하여 자취방 매물을 필터링
• 필터링된 매물을 보고 사용자가 매물(원하는 방)을 클릭
• 해당 자취방이 자주 가는 상점들과 얼마나 떨어져있는지 계산된 값을 통해 확인
  • 카드가 등록되어있지 않은 경우 카드를 등록
  • 사용 내역이 남지 않는 상점의 경우 사용자가 직접 입력함
• 계약 관련자와 연락할 수단을 출력

What can go wrong

• 실시간으로 자취방의 매물이 업데이트가 되지 않을 수 있다
  • ex) 이미 계약이 완료된 자취방일 수 있음
• 등록된 매물에 원하는 세부사항들이 등록되어 있지 않아 방이 누락될 수 있다.
• 카드 내역을 불러오는데 실패할 수 있다

the state when the scenario finishes

• 원하는 자취방을 선택하면 자주 가던 상점과 떨어진 거리를 출력

Initial assumption

• A user or a group of users have one or more debit cards or credit caards to reflect usage
• They may have some locations to register not appeared on card usage
• They have successfully logged on to Rent room service
• They select a room which they want to check

Normal flow

• Card usage of the logged user is loaded coreectly, and shown as a list
• If a location where a card was used is a store with branches, then the nearest branch is shown onthe map and the location list.
• a location is a unique store, then that location is shown on the map and list
• The user can click "register" button to open a registration window, and register a location
• the list is sorted based on the frequency of visits, and the distance to the room.

what can go wrong

• No branch or the original location is acaliabe on the current map data
• Card payment was for subscription or membership, hence frequency only doesn't reflect the situation correctly
• Consider type and amount of payment
• Adjust the data with location information collected by the app
• The nearest branch is not actually the nearest.
  • Add option to use actual path length instead of Euclidean distance on the map.
• If users register a wrong location, they may want to remove them

Other activites

• The administrator may want to see users registered locations and statistics

System state on completion

• User is logged on
• A sorted list of locations reflecting the user's card usage is shown to the user
• A map marked with the locations is shown to the user.

the state when the scenario finishes

• Tip : Story를 넘어서지 않는 범위 내에서 디테일하게 작성하면 된다

---

Requirements specification(요구 사항 명세)

• 사용자 및 시스템 요구 사항을 문서로 작성하는 과정입니다.
• 사용자 요구 사항은 비기술적 배경을 가진 최종 사용자들에게 이해 가능해야 합니다(User requirements have to be understandable by end-users and customers without a technical background).
• 시스템 요구 사항(System requirements)은 더 상세한 요구 사항을 포함하고 기술적 정보가 더 많을 수 있습니다(include more technical information).
• 요구 사항은 시스템 개발 계약의 일부가 될 수 있습니다
  • 따라서 이러한 사항들이 가능한(as comple as possible) 한 완전해야 합니다.

Ways of writing a system requirements specification(시스템 요구 사항 명세 작성 방법)

Notation	Description
Natural language(자연어)	요구 사항은 자연어로 번호가 매겨진 문장(numbered sentences in natural language)을 사용하여 작성됩니다. 각 문장은 하나의 요구 사항을 표현해야 합니다. ex) 자취방 구하기 user story
Structured natural language(구조화된 자연어)	요구 사항은 자연어로 표준 양식 또는 템플릿(natural language on a standard form or template)에 따라 작성됩니다. 각 필드는 요구 사항의 한 측면에 대한 정보를 제공합니다.
Design description languages(설계 설명 언어)	이 접근법은 프로그래밍 언어와 같은 언어를 사용(language like a programming language)하지만 시스템의 운영 모델을 정의함으로써 요구 사항을 보다 추상적으로 명시(with more abstract features to specify the requirements)합니다. 이 방법은 이제 거의 사용되지 않지만(now rarely used) 인터페이스 명세를 위해 유용할 수 있습니다.
Graphical notations(그래픽 표기법)	그래픽 모델은 텍스트 주석과 함께 사용되어 시스템의 기능 요구 사항을 정의합니다; UML 사용 사례 및 순서 다이어그램(UML use case and sequence diagrams)이 일반적으로 사용됩니다.
Mathematical specifications(수학적 명세)	이러한 표기법은 유한 상태 기계 또는 집합과 같은 수학적 개념을 기반으로 합니다(mathematical concepts such as finite-state machines or sets). 이 불확실하지 않은 명세는 요구 사항 문서에서 모호성을 줄일 수 있지만, 대부분의 고객은 공식 명세를 이해하지 못합니다(most customers don't understnad a formal specification). 그들은 그것이 자신이 원하는 것을 대표하는지 확인할 수 없으며, 시스템 계약으로 받아들이기를 꺼립니다.

Requirements and design(요구 사항 및 설계)

• 원칙적으로, 요구 사항은 시스템이 무엇을 해야 하는지 명시해야 하고, 설계는 이를 어떻게 실행하는지 기술해야 합니다.
• 실제로, 요구 사항과 설계는 불가분의 관계입니다(requirements and design are inseparable).
  • 시스템 아키텍처는 요구 사항의 구조를 설계하는데 사용될 수 있습니다;
  • 시스템은 설계 요구 사항을 생성하는 다른 시스템과 상호 작용할 수 있습니다;
  • 특정 아키텍처 사용은 비기능적 요구 사항을 만족시키기 위한 도메인 요구 사항일 수 있습니다.
  • 이는 규제 요구 사항의 결과일 수 있습니다.

Natural language specification(자연어 명세)

• 요구 사항은 자연어 문장으로 작성되며, 다이어그램과 표로 보완됩니다.
• 표현력이 있고 직관적이며 보편적(expressive, intuitive and universal)이기 때문에 요구 사항 작성에 사용됩니다.
  • 이는 사용자와 고객이 요구 사항을 이해할 수 있다는 것을 의미합니다.

Guidelines for writing requirements(요구 사항 작성 지침)

• 모든 요구 사항에 사용할 표준 형식을 만드세요.
• 일관된 방식으로 언어를 사용하세요.
  • 필수 요구 사항에는 'shall'을, 바람직한 요구 사항에는 'should'를 사용하세요.
• 요구 사항의 핵심 부분을 식별하기 위해 텍스트 강조를 사용하세요.
• 컴퓨터 전문 용어 사용을 피하세요.
• 요구 사항이 필요한 이유(근거)를 포함하세요.

Problems with natural language(자연어의 문제점)

• 명확성 부족(Lack of clarity)
  • 문서를 읽기 어렵지 않게 하면서 정밀함을 달성하기 어렵습니다.
• 요구 사항 혼동(Requirements confusion)
  • 기능적 및 비기능적 요구 사항이 혼합되기 쉽습니다.
• 요구 사항 병합(Requirements amalgamation)
  • 여러 가지 다른 요구 사항이 함께 표현될 수 있습니다.

Structured specifications(구조화된 명세)

• 요구 사항 작성자의 자유를 제한하고 요구 사항을 표준적인 방식으로 작성하는 접근법입니다.
• 이 방법은 일부 유형의 요구 사항에 잘 맞습니다.
  • 예를 들어, 내장형 제어 시스템 요구 사항에 적합하지만 비즈니스 시스템 요구 사항 작성에는 너무 굳건할 수 있습니다.

Form-based specifications(양식 기반 명세)

• 기능 또는 실체의 정의.
• 입력과 그 출처에 대한 설명.
• 출력과 그 도착지에 대한 설명.
• 계산에 필요한 정보 및 사용되는 기타 실체에 대한 정보.
• 취할 조치에 대한 설명.
• 적절한 경우 전제 조건 및 결과 조건.
• 함수의 부작용(있을 경우).

Tabular specification(표 형식 명세)

• 자연어를 보완하기 위해 사용됩니다.
• 특히 여러 가지 가능한 행동 과정을 정의해야 할 때 유용합니다.
• 예를 들어, 인슐린 펌프 시스템은 혈당 수준의 변화율에 따라 계산을 기반으로 하며,
  • 표 형식 명세는 다양한 시나리오에 대한 인슐린 요구 사항을 계산하는 방법을 설명합니다.

Tabular specification of computation for an insulin pump(인슐린 펌프의 계산을 위한 표 형식 명세)

 

Condition(조건)	Action(행동)
혈당 수준 하락 (r2 < r1)	CompDose = 0
혈당 수준 안정 (r2 = r1)	CompDose = 0
혈당 수준 증가 및 증가율 감소 ((r2 – r1) < (r1 – r0))	CompDose = 0
혈당 수준 증가 및 증가율 안정 또는 증가 ((r2 – r1) ≥ (r1 – r0))	CompDose = round((r2 – r1) / 4) 만약 반올림 결과 = 0이면 CompDose = MinimumDose

 

Use cases(사용 사례)

• 사용 사례는 UML에 포함되는 시나리오의 한 형태입니다.
• 사용 사례는 상호작용에 있는 액터들을 식별하고 상호작용 자체를 기술합니다.
• 사용 사례 집합은 시스템과의 모든 가능한 상호작용을 기술해야 합니다.
• 고수준 그래픽 모델이 더 상세한 표 형식 설명을 보완합니다(5장 참조).
• UML 순서 다이어그램은 시스템 내의 이벤트 처리 순서를 보여주기 위해 사용될 수 있습니다.

 

Use cases for a medical info. system

 

The software requirements document(소프트웨어 요구 사항 문서)

• 소프트웨어 요구 사항 문서는 시스템 개발자에게 요구되는 사항의 공식적인 진술입니다.
• 사용자 요구 사항의 정의와 시스템 요구 사항의 명세를 포함해야 합니다.
• 이는 디자인 문서가 아닙니다.(Not a design document)
  • 가능한 한, 시스템이 무엇을 해야 하는지에 대해 설명해야 하며(WHAT the system shoud do), 어떻게 해야 하는지(HOW it should do it)에 대해서는 설명하지 않아야 합니다.

 

Requirements document variability(요구 사항 문서의 다양성)

• 요구 사항 문서의 정보는 시스템의 종류와 사용된 개발 접근 방식에 따라 달라집니다.
• 점진적으로 개발된 시스템들은 일반적으로 요구 사항 문서에서 더 적은 세부 사항을 가질 것입니다.
• 요구 사항 문서 표준이 설계되었습니다.
  • 예를 들어, IEEE 표준. 이들은 대부분 대형 시스템 엔지니어링 프로젝트에 적용됩니다.

 

Requirements validation(요구 사항 검증)

• 요구 사항 검증은 고객이 진정으로 원하는 시스템을 정의하는 요구 사항을 보여주는 데에 관련됩니다.
• 요구 사항 오류 비용이 높기 때문에 검증은 매우 중요합니다.
  • 배송 후 요구 사항 오류를 수정하는 비용은 구현 오류를 수정하는 비용의 최대 100배까지 될 수 있습니다.
• 이 단계에서 validation을 하는 것이 cost를 줄일 수 있다.

 

Requirements checking(요구 사항 확인)

• 유효성(Validity): 시스템이 고객의 요구를 가장 잘 지원하는 기능을 제공합니까?
• 일관성(Consistency): 요구 사항 간에 충돌이 있습니까?
• 완성도(Completeness): 고객이 요구한 모든 기능이 포함되어 있습니까?
• 현실성(Realism): 요구 사항이 사용 가능한 예산과 기술을 고려할 때 구현될 수 있습니까?
• 검증 가능성(Verifability): 요구 사항을 확인할 수 있습니까?

 

Requirements validation techniques(요구 사항 검증 기법)

• 요구 사항 검토(Requirements reviews)
  • 요구 사항의 체계적인 수동 분석.
• 프로토타이핑(Prototyping)
  • 요구 사항을 확인하기 위해 시스템의 실행 가능한 모델 사용.
• 테스트 케이스 생성(Test-case generation)
  • 요구 사항의 검증 가능성을 확인하기 위한 테스트 개발.
  • (TDD에서 이 기법 사용)

 

Changing requirements(요구 사항 변경)

• 시스템의 비즈니스 및 기술 환경은 설치 후 항상 변경됩니다.
  • 새로운 하드웨어가 도입될 수 있음,
  • 시스템을 다른 시스템과 인터페이스해야 할 수 있음,
  • 사업 우선순위(business priorities)가 변경될 수 있음(시스템 지원 요구 사항의 결과적 변경 포함),
  • 시스템이 반드시 준수해야 하는 새로운 법률 및 규정(new legislation and regulations)이 도입될 수 있음.

• 시스템을 위해 지불하는 사람들과(The pepole who pay for a system) 그 시스템의 사용자(the users of that system)는 같지 않습니다.
  • 시스템 고객은 조직적 및 예산적 제약으로 인해 요구 사항을 부과합니다.
  • 이것은 최종 사용자의 요구 사항과 충돌할 수 있습니다.
  • 배포 후, 시스템이 목표를 달성하기 위해 사용자 지원을 위한 새로운 기능을 추가해야 할 수 있습니다.
• 대규모 시스템은 보통 다양한 사용자 커뮤니티를 가지고 있으며, 많은 사용자들이 서로 충돌하거나 모순되는 요구 사항과 우선순위를 가질 수 있습니다.
  • 최종 시스템 요구 사항은 그들 사이의 타협일 수밖에 없습니다.
  • 종종 다른 사용자에게 제공되는 지원의 균형이 변경되어야 한다는 것이 발견됩니다.

 

Requirements management(요구 사항 관리)

• 요구 사항 관리는 요구 엔지니어링 과정 및 시스템 개발 중 변경되는 요구 사항을 관리하는 과정입니다.
• 새로운 요구 사항은 시스템이 개발되고 사용에 들어간 후에 나타납니다.
  • 스크럼 때 바뀐 requirements를 스프린트에 넣자
• 개별 요구 사항을 추적하고 종속 요구 사항 간의 연결을 유지하여(keep track of individual requirements and maintain links between dependent requirements) 요구 사항 변경의 영향을 평가할 수 있어야 합니다.
  • 변경 제안을 위한 공식적인 프로세스를 설정하고 이를 시스템 요구 사항에 연결해야 합니다.
• 시험에 RE 1문제는 꼭 나오니 열심히 보자

요약

• 기능 요구 사항과 비기능 요구 사항이 있습니다.
  • 목표에서, 우리는 검증 가능한 비기능 요구 사항을 생각할 수 있습니다.
  • NFR은 때때로 기능 요구 사항으로 표현됩니다.
• 요구 사항 엔지니어링 과정은 요구 사항 도출, 명세화, 검증 및 변경의 네 가지 주요 활동으로 구성됩니다.
  • Requirement elicitation, specification, validation and change 
  • 각 활동에 사용할 수 있는 기술을 이해해야 합니다.