예제를 통한 소프트웨어 요구사항 분석
찰스 무어
⚡ 스마트 요약
소프트웨어 요구사항 분석은 이해관계자의 요구사항을 기능적 요구사항과 비기능적 요구사항으로 나누고, 비즈니스, 아키텍처, 시스템 수준에서 우선순위를 정한 다음, 각 요구사항을 품질 속성과 비교하여 테스트 가능한 요구사항을 보장합니다. trac실행 가능하고 우선순위가 지정된 사양.
소프트웨어 요구사항이란 시스템에 반드시 구현되어야 하는 기능적 또는 비기능적 요구사항을 말합니다. 기능적 요구사항이란 사용자에게 특정 서비스를 제공하는 것을 의미합니다.
예를 들어, 은행 애플리케이션의 경우, 고객이 "잔액 조회"를 선택하면 최신 계좌 잔액을 볼 수 있어야 한다는 기능적 요구 사항이 있습니다.
소프트웨어 요구사항은 성능 요구사항과 같은 비기능적 요구사항일 수도 있습니다. 예를 들어, 비기능적 요구사항에는 시스템의 모든 페이지가 사용자에게 5초 이내에 로드되어야 한다는 내용이 포함될 수 있습니다.
그래서 기본적으로 소프트웨어 요구 사항은
- 기능적인 또는
- 비 기능
필요한 것 시스템에 구현해야 하는 것입니다. 소프트웨어 요구사항은 일반적으로 명세 형식으로 표현됩니다.
요구 사항 유형
비즈니스 요구 사항이는 프로젝트의 사업 타당성 분석에서 도출된 상위 수준 요구사항입니다. 예를 들어, 모바일 뱅킹 서비스 시스템은 동남아시아에 은행 서비스를 제공합니다. 인도에 대한 사업 요구사항은 계좌 요약 및 자금 이체이고, 중국에 대한 요구사항은 계좌 요약 및 청구서 결제입니다.
| 국가 | 은행 기능 또는 서비스를 제공하는 회사 |
|---|---|
| India | 계좌 요약 및 자금 이체 |
| China | 계정 요약 및 Bill 결제 |
Archi구조적 및 디자인 요구 사항이러한 요구사항은 비즈니스 요구사항보다 더 상세하며 솔루션 아키텍처를 결정하는 데 중요한 역할을 합니다. 또한 비즈니스 요구사항을 구현하는 데 필요한 전반적인 설계 방향을 제시합니다. 교육 기관의 경우, 일반적인 아키텍처 및 설계 사용 사례에는 로그인, 코스 상세 정보, 등록 등이 포함됩니다. 요구사항은 아래와 같습니다.
| 뱅킹 사용 사례 | 요구 사항 |
|---|---|
| Bill 결제 | 이 사용 사례에서는 고객이 넷 뱅킹에 로그인하고 Bill 결제 기능. 고객은 등록된 청구 기관의 미결제 청구서 현황을 대시보드에서 확인할 수 있습니다. 청구 기관 정보를 추가, 수정 및 삭제할 수 있으며, 다양한 청구 관련 작업에 대한 SMS 및 이메일 알림을 설정할 수 있습니다. 또한, 과거 결제 내역을 조회할 수 있습니다. 이 사용 사례를 시작하는 주체는 은행 고객 또는 지원 담당자입니다. |
시스템 및 통합 요구 사항가장 하위 수준에서는 시스템 및 통합 요구사항이 있습니다. 이는 모든 요구사항에 대한 상세한 설명을 제공하며, 일상적인 비즈니스 언어로 작성된 사용자 스토리 형태로 나타낼 수 있습니다. 요구사항에는 개발자가 코딩을 시작할 수 있도록 풍부한 세부 정보가 포함되어 있습니다. Bill 아래 결제 모듈 예시는 청구기관 추가에 필요한 사항을 보여줍니다.
| Bill 결제 | 요구조건 니즈 |
|---|---|
| 추가 Bill | 공공 서비스 제공업체 이름, 고객 관계 번호, 자동 이체 여부(예/아니오), 전액 납부 Bill – 예/아니오, 자동 결제 한도 – 다음 조건에 해당하면 결제하지 마십시오. Bill 지정된 금액을 초과했습니다. |
프로젝트를 진행하다 보면 요구사항이나 관련 문서를 전혀 받지 못하는 경우가 있을 수 있습니다. 하지만 그런 경우에도 소프트웨어 또는 테스트 설계를 위한 기초 자료로 활용할 수 있는 다른 요구사항 정보 출처들이 있습니다. 아래에 그 목록을 제시합니다.
기타 요구 사항 소스
- 이미 해당 프로젝트에 참여하고 있는 동료나 직원으로부터 지식 이전
- 비즈니스 분석가, 제품 관리자, 프로젝트 리더 및 개발자와 프로젝트에 대해 논의하십시오.
- 이미 구현된 시스템의 이전 버전을 분석합니다.
- 프로젝트의 이전 요구사항 문서를 분석합니다.
- Rev이전 버그 보고서를 확인하세요. 일부 버그 보고서는 현재 버전에 구현될 수 있는 기능 개선 요청으로 전환됩니다.
- 설치 가이드가 있다면 해당 가이드를 참조하여 필요한 설치 사항을 확인하십시오.
- 팀이 구현하려는 도메인 또는 산업 지식을 분석합니다.
어떤 방식으로 요구사항을 수집하든, 공통된 형식으로 문서화하고 경험이 풍부한 팀원들에게 검토를 받으십시오.
요구 사항을 분석하는 방법
학생이 다양한 강좌에 등록할 수 있는 교육용 소프트웨어 시스템을 예로 들어보겠습니다.
요구사항을 분석하는 방법을 살펴보겠습니다. 각 요구사항은 다음과 같은 표준 품질 속성을 유지해야 합니다.
- Atomic
- 고유하게 식별됨
- 완료
- 일관되고 모호하지 않음
- Trac먹을 수 있다
- 우선 순위
- 테스트 가능
다음 표는 각 속성을 세 개의 열로 나타냅니다.
- 첫 번째 열은 "요구사항 품질"을 나타냅니다.
- 두 번째 열은 "일부 문제가 있는 잘못된 요구 사항"을 나타냅니다.
- 세 번째 열은 동일한 요구사항이 "좋은 요구사항으로 변환된" 모습을 보여줍니다.
| 요구사항 품질 | 잘못된 요구사항의 예 | 좋은 요구사항의 예 |
|---|---|---|
| Atomic | 학생들은 학부 및 대학원 과정에 등록할 수 있습니다. | 학생들은 학부 과정에 등록할 수 있습니다. 학생들은 대학원 과정에 등록할 수 있습니다. |
| 고유하게 식별됨 | 1. 학생들은 학부 과정에 등록할 수 있습니다. 1. 학생들은 대학원 과정에 등록할 수 있습니다. | 수강 신청. 학생들은 학부 과정에 등록할 수 있습니다. 학생들은 대학원 과정에도 등록할 수 있습니다. |
| 완료 | 교수 사용자는 사용자 이름, 비밀번호 및 기타 관련 정보를 제공하여 시스템에 로그인합니다. | 교수 사용자는 사용자 이름, 비밀번호 및 학과 코드를 제공하여 시스템에 로그인합니다. |
| 일관되고 모호하지 않음 | 학생은 학부 과정이나 대학원 과정 중 하나만 수강할 수 있지만 둘 다 수강할 수는 없습니다. 일부 과정은 학부 및 대학원생 모두에게 공개됩니다. | 학생은 학부 또는 대학원 중 하나를 취득해야 하지만 둘 다 취득할 수는 없습니다. |
| Trac먹을 수 있다 | BRD req.ID에 매핑된 학생 정보를 유지하시겠습니까? | 학생 정보 유지 - BRD req ID 4.1에 매핑됨 |
| 우선 순위 | 등록된 학생 - 우선순위 1. 사용자 정보 관리 - 우선순위 1. 수강 신청 - 우선순위 1. 성적표 보기 - 우선순위 1 | 학생 등록 - 우선순위 1. 사용자 정보 관리 - 우선순위 2. 수강 신청 - 우선순위 1. 성적표 보기 - 우선순위 3 |
| 테스트 가능 | 시스템의 각 페이지는 허용되는 시간 내에 로드됩니다. | 시스템의 학생 등록 및 강좌 등록 페이지가 5초 이내에 로드됩니다. |
이제 각 속성을 좀 더 자세히 살펴보겠습니다. 먼저 다음부터 시작하겠습니다. AtomIC.
Atomic
모든 요구사항은 원자적이어야 합니다. 즉, 가장 낮은 수준의 세부 정보를 포함해야 하며 더 이상 구성 요소로 분해될 수 없어야 합니다. 다음 예시에서는 원자적 요구사항과 비원자적 요구사항을 비교합니다.
교육 영역 시스템 사례를 계속해서 살펴보겠습니다. 여기서 잘못된 요구사항은 "학생들은 학부 및 대학원 과정에 등록할 수 있어야 한다"입니다. 이는 학부 과정과 대학원 과정이라는 두 가지 서로 다른 항목을 혼합하여 명시적으로 구분하지 못하는 요구사항이기 때문에 잘못된 것입니다. 반면, 올바른 요구사항은 이를 두 가지로 분리합니다. 하나는 학부 과정 등록에 대한 요구사항이고, 다른 하나는 대학원 과정 등록에 대한 요구사항입니다.
고유하게 식별됨
다음으로 중요한 품질 속성은 고유 식별입니다. 잘못된 예시에서는 두 개의 서로 다른 요구사항이 동일한 ID#1을 공유합니다. 팀에서 요구사항을 ID로 참조할 경우, 어떤 요구사항을 의미하는지 불분명해집니다. 올바른 요구사항은 이 두 요구사항을 섹션 1 - 수강 신청으로 재분류하고, 하위 요구사항으로 1.1(학부 과정 수강 신청)과 1.2(대학원 과정 수강 신청)를 포함합니다.
완료
모든 요구사항은 완전해야 합니다. 예를 들어, 잘못된 요구사항은 "교수 사용자는 사용자 이름, 비밀번호 및 기타 관련 정보를 제공하여 시스템에 로그인해야 합니다."라고 되어 있습니다. "기타 관련 정보"는 모호합니다. 완전한 요구사항은 교수가 제공해야 하는 학과 코드와 같은 정확한 항목들을 명시해야 합니다.
일관되고 모호하지 않음
모든 요구 사항은 일관성이 있고 명확해야 합니다. 잘못된 예시를 들자면, 한 요구 사항은 "학생은 학부 과정 또는 대학원 과정 중 하나만 수강할 수 있으며 둘 다 수강할 수는 없다"라고 명시되어 있는 반면, 다른 요구 사항은 "일부 과정은 학부생과 대학원생 모두에게 개방된다"라고 명시되어 있습니다.
첫 번째 요건은 강좌가 두 가지 배타적인 범주로 나뉜다는 것을 의미하지만, 두 번째 요건은 일부 강좌를 두 그룹 모두에게 개방함으로써 첫 번째 요건과 모순됩니다.
이 좋은 요건은 모든 강좌가 학부 과정 또는 대학원 과정으로 명확하게 표시되고 학생은 한 범주의 강좌에만 등록할 수 있다는 점을 명시함으로써 갈등을 해결합니다.
Trac먹을 수 있다
모든 요구 사항은 다음과 같아야 합니다. trac요구사항이 비즈니스, 아키텍처 및 디자인, 시스템 및 통합 등 여러 수준에 존재하기 때문에 실현 가능합니다.
비즈니스 요구사항을 아키텍처 및 설계 요구사항으로 변환하거나, 아키텍처 및 설계 요구사항을 시스템 및 통합 요구사항으로 변환할 때, trac실행 가능성을 반드시 유지해야 합니다. 모든 비즈니스 요구사항은 하나 이상의 아키텍처 및 설계 요구사항에 매핑되어야 합니다. "학생 정보 유지 - BRD 요구사항 ID에 매핑?"이라는 잘못된 예시에서는 요구사항 ID가 누락되었습니다.
올바른 요구사항은 동일한 내용을 기록하지만 BRD 요구사항 ID 4.1에 명시적으로 매핑됩니다. 모든 요구사항에는 다음이 포함되어야 합니다. trac능력 지도ping시스템 및 통합 요구사항은 해당 요구사항을 구현하는 코드와 이를 검증하는 테스트 케이스와도 연관되어야 합니다.
Trac따라서 안정성은 프로젝트 전반에 걸쳐 적용됩니다.
우선 순위
모든 요구사항은 우선순위가 정해져 있어야 팀이 무엇을 먼저 구현하고 무엇을 나중에 구현할지 알 수 있습니다. 잘못된 예시에서는 학생 등록, 사용자 정보 관리, 수강 신청, 성적표 보기 모두 우선순위 1로 설정되어 있습니다. 모든 것을 우선순위 1로 설정할 수는 없으므로 요구사항에 현실적인 순위를 부여해야 합니다. 좋은 예시에서는 학생 등록과 수강 신청에 최우선 순위 1을, 사용자 정보 관리에 우선순위 2를, 성적표 보기에 우선순위 3을 부여합니다.
테스트 가능
모든 요구사항은 테스트 가능해야 합니다. "시스템의 각 페이지가 허용 가능한 시간 내에 로드되어야 한다"라는 잘못된 예시는 두 가지 이유로 테스트 불가능합니다. 첫째, "각 페이지"는 수십 개의 페이지를 의미할 수 있으므로 테스트 노력이 엄청나게 늘어납니다. 둘째, "허용 가능한 시간"이 명확하게 정의되지 않았습니다. 누구에게 허용 가능한 시간인지, 그리고 어떤 기준에 따라 허용되는 시간인지 명확하지 않습니다. 좋은 요구사항은 특정 페이지("학생 등록 페이지" 및 "수강 신청 페이지")를 명시하고 5초라는 측정 가능한 목표를 설정함으로써 이 두 가지 문제를 모두 해결합니다.
