요구공학(Requirements Engineering) 1

1. Introduction to Requirements Engineering

Our Goal

Customer Needs -> Software Design

 

요구 사항이란 무엇인가요?

✓ 시스템에 의해 충족되거나 제공되어야 하는 특성이나 서비스입니다.

✓ "사용자가 문제를 해결하거나 목표를 달성하기 위해 필요한 조건이나 기능" [IEEE610.12]

✓ "계약, 표준, 명세서, 또는 기타 공식적으로 부과된 문서를 만족시키기 위해 시스템 또는 시스템 구성 요소가 충족하거나 갖추어야 하는 조건이나 기능" [IEEE610.12]

✓ 요구사항 공학(RE)은 시스템의 필요한 서비스와 제약 조건을 찾아내고, 분석하고, 문서화하고 검사하는 과정입니다 [Som11]

 

사용자 요구사항 (User requirements)

✓ 시스템이 사용자에게 제공할 것으로 예상되는 서비스와 이러한 서비스가 작동해야 할 제약 조건에 대한 설명

✓ 주로 자연어와 다이어그램으로 표현됩니다.

✓ 시스템 요구사항

✓ 소프트웨어 시스템의 기능, 서비스, 및 운영 제약 조건에 대한 더 자세한 설명

✓ 구현해야 할 내용(기능 명세)을 정확하게 정의합니다.✓ 일반적으로 시스템 구매자와 소프트웨어 개발자 간의 계약의 일부입니다.

 

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

기능 요구사항 (FR)

✓ 시스템이 제공해야 하는 활동 및 서비스에 대한 설명

✓ 시스템이 특정 입력에 어떻게 반응하고, 특정 상황에서 시스템이 어떻게 작동하는지에 대한 설명

✓ 시스템이 하지 말아야 할 것들에 대한 설명

 

비기능 요구사항 (NFR)

✓ 시스템이 제공하는 서비스 또는 기능에 대한 제약사항

✓ 타이밍 제약, 개발 프로세스에 관한 제약, 표준에 의해 부과되는 제약 등을 포함

✓ 대개 전체 시스템에 적용되며, 개별 시스템 기능이나 서비스보다는 전체 시스템을 기준으로 합니다.

 

기능 요구사항 특징(Functional Requirements)

✓ 시스템이 제공해야 하는 특정 기능들을 정의합니다.

✓ 모호하지 않을 정도로 정확해야 합니다.

✓ 원칙적으로, 기능 요구사항은 완전하고 일관되어야 합니다.

✓ 새로운 요구사항이 설정되고, 시스템의 변경이 필요합니다.

 

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

✓ 비기능 요구사항은 시스템이 사용자에게 제공하는 특정 서비스와 직접적으로 관련되지 않습니다.

✓ 신뢰성, 응답 시간, 저장 공간 점유 등의 시스템 특성이 포함됩니다.

✓ I/O 장치의 기능이나 다른 시스템과의 인터페이스에서 사용되는 데이터 표현과 같은 시스템 구현에 대한 제약 사항이 있습니다.

✓ 개별 구성 요소보다 시스템 전체의 아키텍처에 영향을 주는 경우가 있습니다.

✓ 보안 요구사항과 같은 단일 비기능 요구사항은 필요한 새로운 시스템 서비스를 정의하는 관련 기능 요구사항을 생성할 수 있습니다.

비기능 요구사항 분류 (Classification of Non-functional Requirements)

✓ 제품 요구사항

- 소프트웨어의 동작을 지정하거나 제약합니다.

예) 성능, 신뢰성, 보안, 사용성 요구사항

✓ 조직 요구사항

- 고객 및 개발자 조직의 정책 및 절차로부터 파생된 광범위한 시스템 요구사항

예) 운영 프로세스, 개발 프로세스, 표준, 운영 환경

✓ 외부 요구사항

- 시스템 및 개발 프로세스 외부 요인에서 파생된 요구사항

- 시스템이 규제기관(예: 중앙은행)의 승인을 받기 위해 충족해야 하는 요구사항

- 시스템이 법률 내에서 운영되도록 보장하기 위해 따라야 하는 법률 요구사항

- 시스템이 사용자와 일반 대중에게 인정되도록 보장하는 윤리적 요구사항

 

측정 가능한 비기능 요구사항 (Measurable Non-functional Requirements)

✓ 비기능 요구사항은 '테스트 가능한' 또는 '측정 가능한' 요구사항으로 표현되어야 합니다.

✓ 측정 가능한 비기능 요구사항을 객관적으로 검증하는 비용이 매우 높을 수 있습니다.

✓ 비기능 요구사항은 종종 다른 기능적 또는 비기능적 요구사항과 충돌하거나 상호 작용합니다.

- 관련 요구사항을 명확하게 명시해야 합니다.

 

2. Requirements Engineering Process

좋은 소프트웨어를 만드는 것이 어려운 이유

✓ 소프트웨어는 무형적이다

소프트웨어는 물리적 형태가 없어 직접 조작하거나 관찰할 수 없습니다. 이로 인해 오류 찾기 및 수정이 까다롭고, 개발 과정에서 발생한 문제를 파악하기 어려울 수 있습니다.

✓ 형식적인 소프트웨어 개발 방법이 없다

소프트웨어 개발에는 다양한 패러다임, 도구 및 프레임워크가 존재하므로, 모든 상황에 적합한 일관된 형식적 방법이 없습니다. 결과적으로 개발자 간의 경험, 지식, 선호도 차이로 인해 동일한 문제를 해결하는 방식이 달라질 수 있습니다.

✓ 소프트웨어는 시간이 지남에 따라 변경되어야 한다

기술의 발전, 시장의 변화, 사용자 요구사항의 변화 등 다양한 이유로 소프트웨어는 지속적으로 수정 및 개선되어야 합니다. 이 과정에서 기존 코드와 새로운 코드 간의 상호작용으로 인해 버그가 발생하거나, 성능 저하 등의 문제가 발생할 수 있습니다.

이러한 이유로 인해 좋은 소프트웨어를 만드는 것은 어려운 작업이지만, 철저한 요구사항 분석, 계획, 테스트, 품질 관리 등의 절차를 통해 개선할 수 있습니다.

 

소프트웨어 프로세스 - 진화적 개발을 위한 스파이럴 모델 (Software Process – Spiral Model for Evolutionary Development)

스파이럴 모델은 반복적인 소프트웨어 개발 접근 방식입니다. 이 모델은 각각의 순환을 거침으로써 조금씩 발전해가는 소프트웨어 프로젝트를 지원합니다. 각 순환은 네 가지 주요 단계로 구성되어 있습니다.

1. 계획(Planning): 현재 순환에서 개발할 기능과 기술을 확인하고 목표를 설정합니다. 이 단계에서 리소스, 시간, 예산 등도 고려합니다.

2. 위험 분석(Risk Analysis): 프로젝트 시행에 있어 가능한 위험 요소를 확인하고, 해결책이나 완화 방법을 찾습니다. 이를 통해 프로젝트 진행 시 미리 예상하지 못한 문제가 발생하더라도 빠르게 대응할 수 있는 기반을 마련합니다.

3. 공학적 개발(Engineering): 이 단계에서 소프트웨어 설계, 구현, 테스트가 이루어집니다. 소프트웨어를 실제로 구축하는 단계로, 전체 프로젝트에서 가장 중요한 부분입니다.

4. 고객 평가(Customer Evaluation): 완성된 소프트웨어를 고객에게 제공하여 피드백을 받습니다. 피드백을 통해 추가 개선이 필요한 부분을 파악하고, 다음 순환에 반영하여 프로젝트를 지속적으로 개선해 나갑니다.

스파이럴 모델은 진화적 개발에 효과적인 방법으로, 고객의 요구 사항이 불분명하거나 경험이 부족한 프로젝트에서 특히 유용합니다. 프로젝트를 순환적으로 수행하면서 시스템의 완성도를 서서히 높여 나가는 방식으로, 개발 과정에서의 불확실성을 줄일 수 있습니다.

 

요구공학(Requirements Engineering)

시스템의 필요한 서비스와 제약 조건을 찾아내고, 분석하고, 문서화하고 검증하는 과정입니다.

 

요구사항 도출 및 분석 (Requirements Elicitation and Analysis)

✓ 요구사항 발견 (도출)

 - 이해관계자들과 상호 작용하여 요구사항을 수집하는 과정

 - 이해관계자로부터 도메인 요구사항과 문서를 발견합니다.

✓ 요구사항 분류 및 조직화

 - 관련 요구사항을 분류하고, 응집력 있는 요구사항 군집을 조직화합니다.

 - 아키텍처 모델을 사용하여 각 하위 시스템과 요구사항을 연관시킵니다.

✓ 요구사항 우선순위 및 협상

 - 요구사항의 우선순위를 결정하고, 협상을 통해 요구사항 간의 충돌을 찾아 해결합니다.

 - 이해관계자들은 차이를 해결하고 타협 요구사항에 동의하기 위해 만납니다.

✓ 요구사항 명세

 - 요구사항을 공식적으로 또는 비공식적으로 문서화합니다.

 

이해관계자 (Stakeholders)

✓ 이해관계자는 소프트웨어 개발 결과로 이익을 얻는 사람입니다.

✓ 이해관계자를 정확하게 파악하는 것은 문제의 범위를 정의하는데 도움이 됩니다.

 - 올바른 사람들에게 질문하기

 - 결정권자와 사업 사례 및 요구사항 협상하기

 - 서로 다른 이해관계자들은 종종 상충하는 제약 조건을 제시할 것입니다. : 재정, 기술, 장기 영향, 개인 정보 보호 등

✓ 사용자는 사용자 인터페이스를 통해 시스템과 직접 상호 작용합니다.

✓ 시스템은 사용자를 위해 설계되어야 합니다.(사용자는 이해관계자중 가장 중요)

 

이해관계자와 상호작용하기 어려운 이유(Difficulties of Interacting with Stakeholders)

✓ 이해관계자들은 대체로 원하는 것을 정확하게 모르거나 현실성이 없는 요구를 할 수 있습니다.

✓ 이해관계자들은 자신들의 용어로 요구사항을 표현하고, 자신들의 작업에 대한 암묵적 지식이 포함된 상태에서 이를 전달합니다.

✓ 서로 다른 이해관계자들은 다른 요구사항을 가지고 있고 이를 다양한 방식으로 표현할 수 있습니다.

✓ 조직 내 정치적 요인이 요구사항에 영향을 줄 수 있습니다.

✓ 경제 및 사업 환경의 변동성 때문에 특정 요구사항의 중요성이 변할 수 있고, 새로운 요구사항이 등장할 수 있습니다.

 

3. Requirements Elicitation Techniques

요구사항 도출 기법 (Requirements Elicitation Techniques)

✓ 인류학 관찰법 (Ethnographic Observation)

✓ 인터뷰 (Interview)

✓ 시나리오 (Scenario)

✓ 요구사항 워크샵 (Requirements Workshop)

✓ 브레인스토밍 (Brainstorming)

✓ 스토리보딩 (Storyboarding)

✓ 사용 사례 (Use Cases)

✓ 롤플레잉 (Role Playing)

✓ 프로토타이핑 (Prototyping)

✓ 작업 분석 (Task Analysis)

✓ 상황별 디자인 (Contextual Design)

✓ 기타...

 

인류학 관찰법 (Ethnographic Observation)

✓ 작업 프로세스를 이해하고 이러한 프로세스에 대한 지원 요구사항을 도출하는 데 사용할 수 있는 관찰 기법입니다.

✓ 시스템의 실제 운영에 영향을 주는 사회적 및 조직적 맥락을 이해하는 데 도움이 됩니다.

✓ 분석가는 시스템이 사용될 작업 환경에 스스로를 녹여내립니다.

✓ 일상 업무를 관찰하고 참여자가 참여하는 실제 작업에 관한 메모를 작성합니다.

✓ 암시적인 시스템 요구사항을 발견하는 데 도움이 됩니다.

 - 사람들이 실제로 작동하는 방식에서 도출되는 요구사항 (프로세스 정의에서 도출되지 않음)

 - 협력 및 다른 사람들의 활동 인식에서 도출되는 요구사항

 

암시적 요구사항(Implicit Requirements)

이미지, 상황을 보고 암시하여 요구사항을 도출합니다.

 

인류학 + 프로토타이핑 (Ethnography + Prototyping)

✓ 인류학은 프로토타이핑과 결합할 수 있습니다.

✓ 인류학은 프로토타입 개발에 정보를 제공하여 프로토타입 개선 주기를 줄일 수 있습니다.

✓ 프로토타이핑은 문제와 질문을 발견함으로써 인류학자와 논의할 수 있는 인류학에 집중시킵니다.

 

스승/제자 모델 (Master/Apprentice Model)

✓ 스승과 제자 간의 관계에 기반한 관찰 방법입니다.

 - 스승은 작업을 하며 설명해 가며 가르칩니다.

 - 관찰자는 작업장을 방문하고, 왜 거기에 있는지, 어떻게 진행하길 원하는지 설명합니다.

✓ 구체적인 것들을 관찰하는 데 집중하세요.

 - 스승의 개념화가 아닌 실제 이벤트를 원합니다. –> 진행 중인 작업이나 총체적인 상황을 관찰하세요.

✓ 이해되지 않는 부분이 있을 때 질문하세요.

✓ 스승과 함께 자신의 해석을 확인합니다.

 

인터뷰 (Interviewing)

✓ 시스템에 관한 이해관계자에게 질문을 하고, 그들의 어려움과 필요를 이해합니다.

✓ 면담 유형

 - 폐쇄적 면담 : 이해관계자들은 미리 정의된 질문 세트에 답합니다.

 - 개방적 면담 : 정해진 주제가 없으며, 이해관계자들과 다양한 문제를 살펴보며 그들의 필요를 파악합니다.

✓ 이해관계자와 면담하는 어려운 점

 - 전문가들은 특정 영역에 해당하는 전문 용어와 전문 언어를 사용합니다.

 - 어떤 도메인 지식은 이해관계자들에게 너무 익숙해서 언급할 가치가 없다고 생각할 수 있습니다.

✓ 요구사항 도출 기법과 함께 사용되어야 합니다.

 

인터뷰 팁 (Interview Tips)

✓ 개방적인 마음을 갖고, 요구사항에 대한 선입견을 피하며, 이해관계자들의 말에 주의 깊게 들으세요.

✓ 스프링보드 질문, 요구사항 제안 또는 프로토타입 시스템에서 협업함으로써 면담자가 논의를 시작하도록 유도하세요.

✓ 일반적인 용어보다는 정의된 맥락에서 이해관계자와 대화하세요.

✓ 관련된 데이터를 수집하는데 집중하면서도, 중요하지만 예기치 않은 정보를 포착하는 것 사이에 균형을 유지하세요.

✓ 인터뷰의 가장 큰 팁은 고객의 공감입니다.

 

인터뷰 포커스(Focus of an Interview)

✓ 포커스는 면담자가 이해관계자와 면담할 때 취하는 관점을 정의합니다.

✓ 포커스는 면담자가 대화를 주제에 맞게 유지하는 방법을 제공합니다.

✓ 포커스는 면담자에게 고객의 업무를 이해하는 데 도움이 되는 체계를 제공합니다.

✓ 포커스 문장: 업무의 주요 특성을 나타내는 짧은 문장입니다.

 - 예시: "사람들이 자신의 업무를 수행하는 데 필요한 것들에 대해 알아보고, 결정하고, 요청하는 방법."

 - 면담 동안 포커스 문장을 계속해서 확인하세요.

 

PEACE 모델 (PEACE Model)

✓ 모든 상황에서 어떤 종류의 면담자와도 면담할 수 있는 프레임워크입니다.

✓ PEACE 모델은 1990년대 초 영국과 웨일스의 법 집행 기관과 심리학자들의 협력 노력으로 개발되었습니다. PEACE 모델의 각 요소는 다음과 같습니다.

1. 준비 (Preparation): 면담 전에 목표를 설정하고, 필요한 정보와 자료를 수집하며, 적절한 질문 리스트를 준비합니다.

2. 설명 (Engage): 면담을 시작할 때, 면담자와 면담 대상자 간의 신뢰를 쌓고, 이해관계자들과 긍정적인 관계를 형성하여 원활한 의사소통을 가능하게 합니다.

3. 계정 (Account): 이 단계에서는 면담자가 이해관계자로부터 사실과 관련된 정보를 수집하고, 구체적인 질문을 사용하여 주요 사항에 대한 주요 정보를 얻습니다.

4. 확인 (Closure): 면담을 마무리하는 동안, 면담자는 이해관계자에게 중요한 정보를 확인하고, 면담 과정에서 발생한 이슈를 정리하며, 차후 행동에 대한 안내를 제공합니다.

5. 평가 (Evaluate): 면담이 종료된 후, 면담자는 수집된 정보를 평가하고, 다양한 소스의 정보를 종합하여 최종 결론에 도달합니다.

PEACE 모델은 면담 도구로서 다양한 상황에 적용할 수 있으며 복잡한 상황에서도 효과적인 결과를 도출할 수 있게 도와줍니다.

 

시나리오 (Scenario)

✓ 예시 상호 작용 세션의 설명

✓ 추상적 설명보다 실생활 예시에서 요구사항을 도출하기 위한 목적

✓ 다양한 형태의 시나리오는 시스템에 대해 다른 종류의 정보를 다른 수준의 세부 정보로 제공합니다.

✓ 개요 요구사항 설명에 세부 정보를 추가하는 데 유용합니다.

✓ 시나리오는 다음과 같은 설명으로 구성됩니다:

 - 시스템과 사용자가 기대하는 것

 - 정상적인 이벤트 흐름

 - 잘못될 수 있는 것과 이를 처리하는 방법

 - 동시에 진행 중일 수 있는 기타 활동

 - 시나리오 종료 시의 시스템 상태

 

스토리보드 (Storyboard)

✓ 일련의 순서로 표시되는 그림이나 이미지 형태의 그래픽 정리 도구입니다.

✓ 1930년대 초 월트 디즈니 프로덕션에서 개발되었습니다.

✓ 스토리보딩을 통해 사용자의 반응을 개발 주기 초기에 쉽게 관찰할 수 있습니다.

 - 주요 인물이 누구인지, 그들에게 무슨 일이 일어나며, 어떻게 일어나는지

✓ 스토리보딩

 - 비용이 매우 저렴합니다.

 - 사용자 친화적이며, 비공식적이고, 상호 작용적입니다.

 - 시스템의 사용자 인터페이스에 대한 초기 검토를 제공합니다.

 - 만들기 쉽고 수정하기 쉽습니다.

 

스토리보드 종류

✓ 수동 스토리보드 (Passive storyboards)

 - 스케치, 사진, 스크린샷, PPT 슬라이드 또는 샘플 출력

 - 분석가가 시스템 역할을 맡아 사용자를 스토리보드를 통해 안내합니다.

✓ 활성 스토리보드 (Active storyboards)

 - 애니메이션 또는 자동화된 프리젠테이션(애니메이션 슬라이드, 녹화된 컴퓨터 스크립트나 시뮬레이션, 비디오 클립)

 - 대표적인 사용 또는 운영 시나리오에서의 시스템 행동을 보여줍니다.

✓ 상호작용 스토리보드 (Interactive storyboards)

 - 시뮬레이션, 목업 또는 일회용 코드 (프로토타입)을 사용하여, 사용자가 실제와 같은 방식으로 시스템을 경험하게 합니다.

 

스토리보딩 도구

✓ 수동 스토리보딩 도구

 - 종이와 연필

 - 포스트잇 메모

✓ 활성 스토리보딩 도구

 - 프리젠테이션 관리자 (PowerPoint) -> 사용자 화면 및 출력 보고서

✓ 상호 작용 스토리보딩 도구

 - 상호 작용 프로토타이핑을 위한 전문 소프트웨어 패키지 (예: IBM Rational, Macromedia의 Director, Cinemation from Vividus, Corporation)

 

스토리보드 작성 팁

✓ 스토리보드에 너무 많은 시간과 노력을 투자하지 마세요

 - 실제 작업 결과물처럼 보이면 고객들이 변경에 대해 주저할 수 있습니다.

 - 스토리보드를 다소 거칠고 스케치 상태로 유지하는 것도 괜찮습니다.

✓ 변화가 없다면 배울 것이 없습니다.

 - 스토리보드를 쉽게 수정할 수 있도록 만드세요(스토리보드는 몇 시간 안에 수정 가능해야 함)

✓ 스토리보드를 너무 기능적으로 만들지 마세요.

 - 그렇게 하면 일부 이해 관계자가 "출시하라"고 요구할 수 있습니다.

 - 스토리보드를 스케치 상태로 유지하고, 필드에서 사용할 위험이 없는 도구와 기법을 사용하세요.

✓ 가능한 경우 스토리보드를 상호 작용적으로 만드세요.

 - 고객의 사용 경험은 고객이 스토리보드를 사용해 얻는 피드백과 새로운 요구사항보다 더 많은 피드백을 생성합니다.

 

브레인스토밍(Brainstorming)

✓ "구성원들이 자발적으로 아이디어 목록을 수집하여 특정 문제에 대한 결론을 찾기 위해 노력하는 그룹 창의성 기법입니다." [위키백과]

✓ 1938년, 광고 최고 경영자인 알렉스 F. 오스본이 '조직화된 아이디어 생성' 과정을 발명했습니다.

 - 초기 참가자들은 그들의 시도를 '뇌폭풍 세션'(뇌를 사용하여 문제를 해결하는 것)이라고 불렀습니다.

✓ 단순한 문제에 대한 가능한 해결책을 찾기 위해 사용할 수 있습니다.

✓ 계획, 과정, 해결책 또는 접근 방식의 구성 요소를 생성하고 체크리스트를 작성하는 데 사용됩니다.

✓ 일반적인 회의나 컨퍼런스에서 생산될 것보다 더 많은 좋은 아이디어가 적은 시간에 생성됩니다.

✓ 아이디어는 연관성(히치하이킹, 따라서기)을 통해 더 많은 아이디어를 생성합니다.

 

브레인스토밍 과정

✓ 패널 형식

최적의 그룹 규모는 남녀 6~12명입니다.

✓ 역할

 - 리더

  ▪ 세션을 오프 트랙으로 이어지지 않게 관리합니다.

  ▪ 그룹이 지연되는 것 같을 때 해결책에 대한 아이디어를 제시합니다.

 - 기록자

  ▪ 모든 아이디어를 목록으로 작성합니다(제안자는 제외) 및 모든 구성원이 목록을 볼 수 있게 합니다.

  ▪ 테이프 레코더를 사용하여 아이디어가 누락되지 않도록 합니다.

✓ 시작

 - 고려해야 할 문제를 기술하고 브레인스토밍 절차를 개요한 1페이지 메모를 제공합니다.

 - 구성원들끼리 서로 소개하고 워밍업 활동을 실시합니다.

✓ 시간

 - 세션은 30분 정도가 가장 효과적입니다.

 - 한 멤버가 한 번에 한 아이디어씩 제안하는 것이 가장 좋습니다(이전 아이디어에 따라서기를 격려합니다).

 

브레인스토밍 규칙 (오스본의 방법)

✓ 그룹의 전반적인 창의력 향상

 - 양으로 가기: 더 많은 아이디어를 생성하여 급진적이고 효과적인 해결책을 제작할 확률을 높입니다.

 - 비판 금지하기: 판단을 보류함으로써 참가자들은 독특한 아이디어를 자유롭게 제시할 수 있습니다.

 - 환영하는 야생의 아이디어: 새로운 관점에서 보고 가정을 보류하여 야생의 아이디어가 생성될 수 있습니다.

 - 아이디어 결합 및 개선: 연관 과정을 통해 아이디어 구축이 자극된다고 믿어집니다.

✓ 아이디어 생성 (창의력) 자극하기

 - 프로세스를 열어 놓고 세션을 비공식적이고 재미있게 만들기

✓ 이후 아이디어

 - 가장 가치있는 아이디어는 브레인스토밍 그룹의 구성원들이 문제를 "고민한" 후에 생성됩니다.

 - 멤버들이 카테고리에 따라 분류된 모든 아이디어를 공유할 수 있도록 허용합니다.

 

아이디어 평가 및 선택

✓ 동일한 구성원에 의해 이루어짐

 - 문제에 충분히 익숙한 경우에

 - 이렇게 하면 아이디어 생성, 평가 및 개발 간의 연결이 생성됩니다.

✓ 다른 사람들에 의해 수행됨

 - 실현 가능성과 객관성이 더 높은 사람들에 의해

 - 문제에 직접적으로 책임이 있는 사람들에 의해

 - 그러면, 브레인스토밍 그룹의 구성원들은 그들의 아이디어의 최종 처분에 대해 알려져야 합니다.

✓ 여러 그룹의 사람들에 의해 수행됨

 - 예를 들어, 기능 관리자, 고객, 개발자 등에 의해

✓ 평가 기준

 - 실행 가능성, 복잡성, 비용, 인적 요소, 타이밍, 품질, 개선, 자원, 안전, 작업 흐름 등

 

친화도 다이어그램 (Affinity Diagram)

✓ 많은 수의 아이디어를 수집하고 구성하는 방법 (지로 가와키타에 의해 개발됨)

✓ 과정

 - 주제에 대해 브레인스토밍하고 아이디어 목록을 만듭니다.

 - 각 아이디어를 카드나 노트에 기록합니다.

 - 관련성이 있는 것 같은 아이디어를 찾습니다.

 - 모든 카드를 사용할 때까지 카드를 그룹으로 정렬합니다 (각 그룹의 머릿말을 만듭니다).

✓ 시간 제한을 설정합니다.

✓ 팀원들이 볼 수 있도록 합니다.

 

마인드 맵

✓ 정보를 시각적으로 구성하는 데 사용되는 다이어그램입니다.

✓ 각 부분 간의 계층적 관계

✓ 마인드 맵을 작성하는 지침:

 - 중심부터 주제의 이미지로 시작하세요.

 - 이미지, 기호, 코드, 차원을 사용하세요.

 - 핵심 단어를 선택하세요.

 - 각 단어/이미지는 각각의 줄에 혼자 표시되는 것이 가장 좋습니다.

 - 선들이 중앙 이미지에서 시작하여 연결되어야 합니다.

 - 선들을 그들이 지지하는 단어/이미지와 같은 길이로 만드세요.

 - 마인드 맵 전체에 다양한 색상을 사용하세요.

 - 강조하고 관련성을 보여줍니다.

 - 방사형 계층 구조 또는 개요를 사용하여 가지를 포함함으로써 마인드 맵을 명확하게 유지하세요.

 

프로토타이핑

✓ 프로토타입: 소프트웨어 시스템의 초기 형태이며, 시스템의 일부 기능을 보여줍니다. 요구사항을 더 받기 위해 필요합니다.

✓ 바람직한 특성

 - 구축 비용이 저렴함

 - 거칠게 보임

 - 대체 방안 탐색 가능한 유연성을 가짐

✓ 목적

 - 사용자 요구 사항 이해

 - 대안 접근법 평가, 예를 들어,

• 그래픽 사용자 인터페이스(GUI)

• 명령행 인터페이스

 - 인터페이스 아이디어 조정, 예를 들어,

• 기능 묶음

• 상호작용 메커니즘 선택, 예: 버튼이나 메뉴

• 누락된 요소 확인

 

프로토타입 종류

✓ 버릴 수 있는(Throwaway) 프로토타입 vs. 진화형(Evolutionary) 프로토타입

 - 버릴 수 있는 프로토타입은 실현 가능성을 점검하기 위해 만 들어집니다(대안 기술, 시뮬레이션 등을 사용).

 - 진화형 프로토타입은 최종 시스템에 사용될 것과 동일한 아키텍처를 기반으로 합니다.

✓ 수평(Horizontal) 프로토타입 vs. 수직(Vertical) 프로토타입

 - 수평 프로토타입은 시스템의 광범위한 기능을 보여주기 위한 것입니다.

 - 수직 프로토타입은 일부 요구사항을 고품질로 보여주기 위한 것입니다.

✓ 사용자 인터페이스(User interface) 프로토타입 vs. 알고리즘(Algorithmic) 프로토타입

 - 사용자 인터페이스 프로토타입은 시스템의 사용자 인터페이스를 보여주고 테스트하는 데 사용됩니다.

 - 알고리즘 프로토타입은 로직, 알고리즘을 구현하거나 다른 장치나 시스템과의 인터페이스를 구현합니다.

 

Paper Prototypes

종이에 작성한 프로토타입

Low Fidelity Prototypes

✓ 장점

 - 구축 비용이 매우 저렴함

 - 프로토타입 인터뷰 도중 변경 가능

 - 빠르게 반복 가능

✓ 단점

 - 사용자 행동을 포착하기 어려움

 - 실행할 수 없음

 

Façade Prototypes

PPT 또는 전문 프로토타입 프로그램으로 만든 프로토타입

 

Medium Fidelity Prototypes

화면 외관을 만들고 보관형 데이터를 사용합니다. 예를 들면, 파워포인트 애니메이션 등

✓ 장점

 - 실행하는 것처럼 보임

 - 전체 상호작용의 “비디오”를 캡처할 수 있음

✓ 단점

 - 재사용 가능한 것이 없음

 - 너무 “완성된” 외관을 만들 수 있음

 - 즉시 편집하기 어려움

 - 애플리케이션에 과대 판매 가능성이 있음

 

High Fidelity Prototypes(실제 구현)

✓ 장점

 - 쉽게 편집하고 실행할 수 있음

 - 코드를 사용할 수도 있음

✓ 단점

 - 종종 설계 결정을 너무 이른 시기에 해야 함. 예: 실제 구성 요소 선택

 - 실행 가능하게 만드는 데 상당한 노력이 필요함 - 스크립트 작성

 - 사용자와 함께 편집하기 어려움

 

역할극(Role Playing)

✓ 개발 팀의 모든 구성원이 사용자의 위치를 차지하고 고객의 업무 활동을 수행합니다.

✓ 개발 팀이 사용자의 역할을 맡아 사용자의 세계를 직접 경험할 수 있게 합니다.

 - 관찰만으로는 개발자/분석가가 문제에 대한 진정한 깊이 있는 이해를 얻을 수 없습니다.

 - 물어봐야 할 모든 질문을 예측할 수 없습니다.

 - 많은 사용자들이 자신들이 따르는 절차나 충족해야 할 요구사항을 명확하게 설명하지 못할 수 있습니다.

 - 사용자가 말하는 것이 실제로 하는 것과 일치하지 않을 수 있습니다.

 - 개별 사용자들은 자신만의 고유한 업무 수행 방식이 있습니다.

시나리오별 시연(Scripted Walkthroughs)

✓ 역할에서의 오해, 정보 부족, 또는 필요한 특정 행동의 부재를 보여줍니다.

✓ 각 참가자는 "연극"에서 특정 역할을 정의하는 스크립트를 따릅니다.

✓ 필요한 만큼 스크립트를 수정하고 다시 실행하여 Actors가 올바르게 이해할 때까지 반복할 수 있습니다.

✓ 시스템의 동작을 변경해야 할 때 스크립트를 수정하여 재사용할 수 있습니다.

✓ 스크립트는 프로젝트의 실시간 스토리보드가 됩니다.

✓ 스크립트는 새로운 팀원 교육을 위해 재사용할 수도 있습니다.

클래스-책임-협력(CRC) 카드(Class-Responsibility-Collaboration (CRC) Cards)

✓ 객체 지향 분석 작업

✓ 엔티티의 외부 행동에 초점을 맞춤

✓ 각 참가자에게 클래스 또는 객체, 책임 또는 행동, 그리고 협력 또는 객체가 통신하는 대상을 설명하는 인덱스 카드 세트를 제공합니다.

✓ 초기화자가 특정 행동을 시작하면 모든 참가자는 카드에 정의된 행동을 따릅니다.

✓ 정보 부족으로 인해 프로세스가 중단되거나 한 엔티티가 다른 엔티티와 대화해야하고 협력이 정의되지 않은 경우, 카드를 수정하고 역할을 다시 실행할 수 있습니다.

✓ 시스템의 잘못되거나 누락된 요구사항을 발견하는 데 효과적입니다.

✓ 흥미로운 부작용도 발견할 수 있습니다.

Task Analysis

✓ 사용자 작업의 구조, 흐름 및 속성을 파악하고 이해하기 위함

 - 사용자가 작업을 완료하거나 특정 목표를 달성하기 위해 필요한 조치와 인지 과정을 식별합니다.

 - 현재 시스템과 그 안의 정보 흐름을 이해합니다.

 - 새 시스템에서 핵심 기능과 사용자 인터페이스의 관점에서 작업을 설계하고 적절하게 할당하는 데 도움이 됩니다.

✓ 작업 분석 결과물로는 다음과 같은 것들이 있습니다:

 - 각 작업에 관련된 물리적, 지각적, 인지적 활동의 상세 설명

 - 작업 시간, 변동성, 빈도, 순서, 할당 및 복잡성

 - 환경 조건

 - 데이터 및 정보 종속성

 - 작업에 필요한 도구

 - 사용자 기술, 교육 및 훈련

 

Cognitive Task Analysis (CTA)

✓ 사용자로부터 의사 결정, 문제 해결, 기억, 주의, 판단 등 많은 인지 활동을 요구하는 작업을 이해하기 위함

✓ 인지 작업 분석 단계: - 작업 매핑

 - 중요한 결정 포인트를 식별하고, 클러스터링, 연결 및 우선 순위 지정

 - 사용되는 전략 특성화 ✓ 인지 작업 분석은 다음을 검토하는 데 사용되었습니다: - 초보자와 전문가 간의 성능 차이

 - 복잡한 제어 및 디스플레이와 관련된 정신적 작업 부하 - 전문가의 의사 결정

 - 정신 모델의 발전과 진화

 - 명령 및 통제 시스템에 대한 정보 요구 사항 - 문제 해결, 고장 격리 및 진단 절차

 

Hierarchical Task Analysis (HTA)

✓ 고수준 작업이 하위 작업 계층으로 분해됩니다(계층적 분해)

✓ 방법론적 맥락에 의존하지 않는 단순하고 유연한 방법

✓ 작업 분해 단계:

 - 분석할 작업을 식별합니다.

 - 작업을 4개에서 8개의 하위 작업으로 분해하고 그들의 목표를 명시합니다.

 - 하위 작업을 층별 다이어그램으로 그립니다(구조를 구축하는 데 물어볼 질문: "이것이 왜 수행되나요?")

 - 분해할 세부 수준을 결정합니다(분해하는 데 물어볼 질문: "이 작업은 어떻게 수행되나요?")

 - 분해 과정을 계속합니다. 분해와 번호가 일관되게 유지되도록 합니다.

 - 분해 작업에 참여하지 않았지만 작업에 대해 충분히 이해하여 일관성을 확인할 수 있는 다른 사람에게 분석 결과를 제시합니다.

 

요구사항 워크샵(Requirements Workshop)

✓ 프로젝트의 주요 이해관계자들이 짧은 기간(1~2일) 동안 함께 모이는 워크샵입니다.

✓ 가장 강력한 요구사항 도출 기법

✓ 요구사항에 대한 합의를 촉진하고 매우 짧은 시간에 행동 계획에 대한 신속한 합의를 이루기 위함

✓ 팀 멤버 또는 경험이 풍부한 외부 전문가가 워크샵을 주도할 수 있습니다.

✓ 애플리케이션에서 제공할 고수준 기능의 생성 또는 검토에 중점을 둬야 합니다.

 

요구사항 워크샵의 이점

✓ 프로젝트의 성공을 위한 공통 목적에 전념하는 효과적인 팀 구축을 돕습니다.

✓ 모든 이해관계자들이 의견을 제시하며, 아무도 배제되지 않습니다.

✓ 이해관계자와 개발팀 간에 애플리케이션이 수행해야 할 작업에 대한 합의를 도모합니다.

✓ 정치적 문제를 드러내고 해결합니다.

✓ 바로 특징 수준에서의 예비 시스템 정의를 출력물로 만들어낼 수 있습니다.

 

요구사항 워크샵 준비 과정

✓ 컨셉의 홍보

 - 워크샵 접근 방식의 이점을 전달합니다.

✓ 적합한 이해관계자 참여 확보

 - 중요한 이해관계자들이 모두 파악되었는지 확인합니다.

✓ 물류

 - 워크샵을 올바르게 준비합니다(장소, 장비 등).

✓ 사전에 "웜업 자료" 제공 (2~7일 전)

 - 프로젝트 특정 정보 ✓ 요구사항 문서 초안

✓ 제안된 기능의 기재된 목록 ✓ 예상 사용자와의 인터뷰 복사본

✓ 업계 동향에 대한 분석가 보고서

✓ 고객의 편지

✓ 기존 시스템의 버그 보고서

✓ 새로운 경영 방침 및 마케팅 데이터 등

 - 창의적 사고 준비

✓ 사색을 자극하는 글

✓ 브레인스토밍 규칙

✓ 요구사항 관리 및 범위 관리 등

진행자의 역할(Role of the Facilitator)

✓ 요구사항 관리에 경험이 있는 외부인이거나, 합의 구축 또는 팀 빌딩 기술이 있는 팀 멤버일 수 있습니다.

✓ 회의에 전문적이고 객관적인 분위기를 조성합니다.

✓ 회의를 정시에 시작하고 종료합니다.

✓ 회의 "규칙"을 수립하고 집행합니다.

✓ 회의의 목표와 의제를 소개합니다.

✓ 회의를 관리하며 팀이 올바른 방향을 유지하도록 합니다.

✓ 결정과 합의 과정을 촉진하되, 내용에 참여하지 않습니다.

✓ 시설 및 물류 문제를 관리하여 의제에 집중이 유지되도록 합니다.

✓ 모든 이해관계자가 참여하고 의견이 들어가도록 합니다.

✓ 회의록을 배포하고 기타 출력물을 기록합니다. disruptive 또는 비생산적인 행동을 제어합니다.

follow up

✓ 프로젝트 리더는 워크샵에서 기록된 미해결 행동 항목들을 후속 조치로 처리해야 합니다.

✓ 회의 결과물(아이디어 또는 제안된 제품 기능)들을 분배할 수 있도록 정리합니다.

✓ 다른 이해관계자들과의 추가 워크샵이 예정될 수 있습니다.

✓ 워크샵에서 나온 아이디어를 더 잘 이해하기 위해 추가적인 요구사항 도출 작업이 필요할 수 있습니다.

 

브레인스토밍 워크샵 의제

1. 소개 (2분)

2. 진행자, 필기자, 시간 감독관 선출 (3분)

3. 이번 워크샵에서 다룰 "문제" 결정 (5분)

4. 문제의 맥락 논의 (5분) – 이해관계자 및 기타 외부 구성요소 파악

5. 애플리케이션 기능 브레인스토밍 (20분) – 친화도 방법 사용

6. 기능 정의 (10분)
 – 각 기능에 대해 한 두 문장 설명 작성

7.기능 우선 순위 정하기 (10분)

 – 기능 투표

8. 정리 (5분)

 

4. Requirement Analysis

Requirements Analysis

✓ 소프트웨어의 작동 특성을 명시합니다.

✓ 소프트웨어가 다른 시스템 요소와의 인터페이스를 나타냅니다.

✓ 소프트웨어가 충족해야 하는 제약 조건을 설정합니다.

✓ 요구사항 분석을 통해 소프트웨어 엔지니어는 다음 작업을 수행할 수 있습니다.

 - 이전 요구사항 공학 작업 동안 설정된 기본 요구사항을 상세히 설명합니다.

 - 사용자의 요구를 여러 가지 관점에서 보여주는 모델을 작성합니다.

요구사항 모델

✓ Scenario-based 기반 모델 – "actor"의 관점에서 요구사항을 묘사합니다.

예: 스토리보드, 유스케이스 모델

✓ Class-oriented 모델

- 객체 지향 클래스(속성 및 연산)를 표현하고 클래스 간 협력 방식을 나타냅니다.

예: 클래스 다이어그램, CRC 모델

✓ 행동(Behavioral) 모델

- 소프트웨어가 내부 또는 외부 "이벤트"에 어떻게 반응하는지를 보여줍니다.

예: 제어 흐름도, 페트리 넷, 시퀀스 다이어그램, 활동도, 상태도

✓ 데이터 모델

- 문제의 정보 도메인을 묘사합니다.

예: 개체 관계(ER) 다이어그램, 도메인 모델(클래스 다이어그램)

✓ 흐름 중심 모델

- 기능 요소를 나타내고 데이터를 어떻게 변환하는지를 표현합니다.

예: 데이터 흐름도

요구사항 모델링 원칙

✓ 원칙 1. 문제의 정보 도메인(데이터, 데이터 흐름, 데이터 저장소)은 표현되고 이해되어야 합니다.

✓ 원칙 2. 소프트웨어가 수행하는 기능은 정의해야 합니다.

✓ 원칙 3. 외부 이벤트의 결과로 인한 소프트웨어의 상호작용(행동)은 표현되어야 합니다.

✓ 원칙 4. 정보, 기능 및 행동을 묘사하는 모델은 계층적(또는 계층적) 방식으로 상세 정보를 드러내도록 분할되어야 합니다.

✓ 원칙 5. 분석 작업은 핵심 정보에서 구현 세부 정보 방향으로 진행되어야 합니다(최종 사용자 관점에서 문제를 설명하는 것에 집중).

 

5. Use Case Modeling Fundamentals

UML Models

Use Case Model은 다른 모델들과 연결이 되어야 한다.

Use Case Model -> Analysis Model -> Design Model -> Deployment Model -> Implementation Model -> Test Model

 

유스케이스 기법(Use-Case Technique)

✓ 유스케이스를 명세하는 데 사용되는 텍스트, 구조, 시각 모델링 기법 (Ivar Jacobson, 1986)

✓ 객체 지향 소프트웨어 공학 기법

✓ 다양한 사용자들이 시스템과 상호작용하는 방식의 관점에서 시스템의 동작을 설명하는 데 사용됩니다.

✓ 사용자 중심 접근 방식으로 시스템 동작을 초기 사용자 참여로 탐색할 수 있습니다.

✓ 유스케이스: 특정 'Actors'에게 가치 있는 결과를 생성하는 시스템이 수행하는 일련의 동작을 설명합니다.

✓ 유스케이스 모델: 배우와 배우가 시스템과 상호작용하는 다양한 유스케이스로 구성됩니다.

- 시스템의 기능적 동작과 유스케이스 간의 관계를 설명합니다.

 

유스케이스 모델링 (Use Case Modeling)

✓ 유스케이스 모델은 유스케이스와 배우를 표현하는 데 필요한 다이어그램과 설명의 집합입니다.

✓ 유스케이스 모델링 프로세스

1. 시스템 경계 정의하기

2. actor 찾기

3. 유스케이스 찾기

4. 각 유스케이스 설명하기

5. 유스케이스 모델 리팩터링하기

6. 유스케이스 우선 순위 정하기

7. 미래의 요구사항 추가하기(변경 사항)

8. 유스케이스 모델 구성하기(패키지화)

시스템 다이어그램(System Diagram)

✓ 시스템 경계를 설명하고 시스템의 배우들을 식별합니다.

✓ 시스템 다이어그램을 생성하는 것은 유스케이스 모델링의 첫 단계입니다.

 

Actors

✓ Actors: 시스템과 상호작용하는 개체

 - 시스템과 상호작용하는 이해관계자들은 시스템 설계 방식에 영향을 줍니다.

 - 소프트웨어 개발은 거의 처음부터 시작하는 것이 아니며, 대부분 여러 상호 작용하는 구성 요소가 있고 새로운 애플리케이션은 여러 애플리케이션의 대규모 협력 시나리오에서 일원입니다.

✓ Actors를 정의하는 것은 시스템 경계를 정의하는 데 도움이 됩니다.

✓ 시스템과 상호작용하는 Actors들은 역할이며, 일반적으로 정의된 지정만을 의미하고 특정한 사람이나 인스턴스를 의미하지 않습니다.

✓ 개성 유형(Personality Types): 각 배우가 전체 시스템과의 관계

 - 시작자(Initiator)(Primary Actor)

 - 외부 서버(External Server)

 - 수신자(Receiver)

 - 퍼실리테이터(Facilitator)(Proxy)

✓ 추상적 및 구체적 Actors

 - 경험적 규칙에 따르면, 유스케이스와 직접적인 관계가 없는 Actors는 추상적 Actors입니다.

 - 이와 같은 구분의 이점은 이해관계자 영역을 구조화하고 역할 및 책임을 세부 조정하는 데 있습니다.

✓ 이해관계자를 식별하는 것은 문제 범위를 한 단계 좁히는 데 도움이 됩니다.

✓ Actors를 식별하는 것은 문제 범위를 더 좁혀 기술적 측면에 초점을 맞춥니다.
- 시스템 사용 방식에 초점을 맞춥니다.

유스케이스(Use Cases)

✓ 유스케이스는 시스템을 사용하여 유용한 작업을 수행하는 방법에 대한 이야기입니다.

 - 시스템의 이해관계자 간의 행동에 대한 계약을 포착합니다.

 - 개념적 수준에서 시스템이 하는 일을 설명합니다.

✓ 유스케이스는 목표 지향적입니다.

 - 꼭 기능 지향적이지는 않지만, 기능이 많은 유스케이스를 포함합니다.

 - 유스케이스는 단일 목표와 사용자가 해당 목표를 달성하려고 시도할 때 발생할 수 있는 모든 가능한 것을 개요화합니다.

 - 유스케이스는 단순한 메뉴 항목이나 기능이 아닙니다.

요구사항 도출 방법으로서의 유스케이스 (Use Cases as Requirements Elicitation Method)

✓ 유스케이스는 사용자의 자연어로 작성됩니다.

✓ 유스케이스는 개발 팀과 사용자가 함께 시스템의 동작을 설명하기 위해 작업 할 수 있는 간단하고 구조화된 형식을 제공합니다.

✓ 유스케이스 방법은 사용자 인터페이스를 직접 탐색합니다.

✓ 유스케이스 명세: 유스케이스의 텍스트 및 그래픽 설명으로 구성됩니다.

Why Use Cases?

✓ 사용자 중심의 기능 요구사항 도출

 - 시스템 사용 가능한 모든 방법

 - 시스템의 개념 모델 작성

 - 분석, 설계 및 테스트 결합

 - 추적성 도입

 - 아키텍처 설계

 - 사용자 설명서 작성 도움

 

Business vs. System Use Case Modeling

✓ 비즈니스 유스케이스 모델링 -> 비즈니스 Actors 및 비즈니스 유스케이스

 - 제약과 요구사항이 계속 쌓일 때 뒤로 갈수록 분쟁 해결에 도움이 됩니다.

 - 비즈니스 목표와 시스템 목표를 분리하는 데 도움이 됩니다.

✓ 시스템 유스케이스 모델링 -> 시스템 Actors 및 시스템 유스케이스

 - 최종적으로 관심이 있는 부분입니다.

 - 직접 구축할 시스템에 초점이 맞춰집니다.

 

유스케이스 모델 장점

- 비즈니스 맥락과 시스템 맥락을 분리하는 메커니즘

- 유스케이스 모델은 클라이언트와 개발자 간의 문제 범위를 결정하는 커뮤니케이션 매체로 사용할 수 있습니다.

 

유스케이스 모델 단점

- 유스케이스를 사용자 인터페이스, 함수 호출 및 시스템 객체 분해로 직접 변환하려는 유혹

- 유스케이스가 시스템 요구사항의 비기능적 측면을 파악하는데 그다지 도움이 되지 않습니다.

- 비기능 적인 요구사항 표현하기 어려움

 

Describing a Use Case

✓ Actors와 시스템 간의 상세한 상호 작용 순서를 텍스트로 설명합니다.

✓ 중요한 요구사항 도출 도구입니다.

✓ 템플릿은 사고 과정에 대한 지침을 제공합니다.

 - 어떤 Actors(들), 다른 유스케이스가 유스케이스를 시작합니다.

 - 유스케이스의 전제 조건은 무엇인가요?

 - 유스케이스가 어떻게 진행되는지, 즉 이벤트의 흐름은 어떻게 되는가?

 - 유스케이스가 끝난 후에 어떤 일이 발생하는지, 후조건은 무엇인지

 - 이벤트의 대체 순서(예외)는 무엇이고 어떤 결정 요소가 사용자를 대체 경로로 인도할 수 있는지?

 

Use case Descrioption Example

✓ Name

예약하기(동사)

✓ Summary

예약 담당자가 호텔 고객을 위해 객실을 예약함

✓ Actor

예약 담당자

✓ Precondition

예약 담당자가 호텔 시스템에 로그인함

✓ Description

1. 고객이 예약 담당자에게 개인 정보를 제공합니다. 예를 들어 이름, 객실 유형, 투숙 인원, 도착 및 출발 날짜와 시간

2. 예약 담당자가 시스템에 정보를 입력하고 예약 가능 여부와 객실 예약 요금을 조회

3. 객실이 사용 가능한 경우 담당자가 신용카드 번호로 예약을 보장하도록 요청

4. 담당자가 고객의 신용카드 번호를 입력하여 예약을 보장

5. 신용카드 번호가 유효한 경우 담당자가 예약을 보장된 것으로 업데이트

✓ Alternatives

객실 없음: 3번 줄: 객실이 없는 경우 담당자는 고객에게 다른 도착 및 출발 날짜 및 / 또는 시간을 요청합니다.

유효하지 않은 카드: 5번 줄: 신용카드 번호가 유효하지 않은 경우, 담당자는 고객에게 다른 신용카드 번호를 요청합니다.

✓ Postcondition

고객을 위한 예약이 생성됩니다.

 

Pass/Fail Tests for Use Case Descriptions

✓ Use case title.

1. 주요 배우의 목표인 동사 목표 문구로 이름이 지정되었습니까?

2. 시스템이 해당 목표를 달성할 수 있습니까?

✓ Scope and Level:

3. 범위와 레벨 필드가 모두 입력되었습니까?

✓ Scope.

4. 사용 사례에서 범위에 언급된 시스템을 블랙 박스로 취급합니까? (사용 사례가 비즈니스 사용 사례인 경우 '예', 화이트 박스 시스

템 요구 사항 문서인 경우 '아니오'가 됩니다.)

5. 범위가 설계 중인 실제 시스템인 경우, 디자이너가 범위 내의 모든 것을 설계해야 하며 그 외에는 설계하지 않아야 합니까?

✓ Level.

6. 사용 사례 컨텐츠가 레벨에 명시된 목표 수준과 일치합니까?

7. 목표가 실제로 언급한 수준에 있습니까?

✓ Primary actor.

8. 지정된 주요 배우에게 행동이 있습니까?

9. 시스템의 서비스 약속인 시스템에 대한 목표가 있습니까?

✓ Preconditions.

10. 이러한 조건은 필수적이며 시스템에 의해 설정될 수 있습니까?

11. 사용 사례에서 이러한 조건을 확인하지 않습니까?

✓ Stakeholders and interests.

12. 언급되어 있습니까? (사용법은 격식과 관용에 따라 다름) 시스템이 해당 관심사를 만족시켜야 합니까?

✓ Minimal guarantees.

13. 있다면, 모든 이해당사자의 이익이 보호됩니까?

✓ Success guarantees.

14. 모든 이해당사자의 이익이 만족됩니까?

✓ Main success scenario.

15. 스텝 진행을 성공적으로 확인하기 위한 트리거부터 시작하나요?

16. 단계 순서가 올바른가요 (올바른 순서의 변동을 허용하나요)?

17. 단계는 3-9개로 구성되어 있나요?

 

요구공학(Requirements Engineering) 2