예제를 통한 소프트웨어 요구사항 분석
찰스 무어
예를 들어, 뱅킹 애플리케이션과 관련하여 기능 요구 사항은 고객이 "잔액 보기"를 선택할 때 최신 계좌 잔액을 볼 수 있어야 한다는 것입니다.
소프트웨어 요구사항은 비기능적 요구사항일 수도 있고 성능 요구사항일 수도 있습니다. 예를 들어, 비기능적 요구 사항은 시스템의 모든 페이지가 5초 이내에 사용자에게 표시되어야 하는 것입니다.
그래서 기본적으로 소프트웨어 요구 사항은
- 기능적이거나
- 비 기능
필요한 것 시스템에 구현해야 하는 것입니다. 소프트웨어 요구사항은 일반적으로 설명으로 표현됩니다.
요구 사항 유형
- 비즈니스 요구 사항: 이들은 프로젝트의 비즈니스 사례에서 가져온 상위 레벨의 요구 사항입니다. 예를 들어, 모바일 뱅킹 서비스 시스템은 동남아시아에 은행 서비스를 제공합니다. 인도에 대해 결정된 비즈니스 요구 사항은 계좌 요약 및 자금 이체이고, 중국의 경우 계좌 요약 및 청구서 지불이 비즈니스 요구 사항으로 결정됩니다.
| 국가 | 은행 기능 또는 서비스를 제공하는 회사 |
|---|---|
| India | 계좌 요약 및 자금 이체 |
| China | 계정 요약 및 Bill 결제 |
- Archi구조적 및 디자인 요구 사항: 이러한 요구 사항은 비즈니스 요구 사항보다 더 자세합니다. 비즈니스 요구 사항을 구현하는 데 필요한 전반적인 디자인을 결정합니다. 교육 기관의 경우 아키텍처 및 디자인 사용 사례는 로그인, 과정 세부 정보 등입니다. 요구 사항은 아래와 같습니다.
| 뱅킹 사용 사례 | 요구 사항 |
|---|---|
| Bill 결제 | 이 사용 사례에서는 고객이 넷 뱅킹에 로그인하고 Bill 결제 시설.
고객은 등록된 청구자의 미지불 청구서 대시보드를 볼 수 있습니다. 그는 청구자 세부 정보를 추가, 수정 및 삭제할 수 있습니다. 고객은 다양한 청구 작업에 대한 SMS, 이메일 알림을 구성할 수 있습니다. 그는 과거 지불된 청구서의 내역을 볼 수 있습니다. 이 사용 사례를 시작하는 행위자는 은행 고객 또는 지원 담당자입니다. |
- 시스템 및 통합 요구 사항: 가장 낮은 수준에서는 시스템 및 통합 요구 사항이 있습니다. 이는 각 요구 사항에 대한 자세한 설명입니다. 이는 일상적인 비즈니스 언어를 실제로 설명하는 사용자 스토리 형식일 수 있습니다. 요구 사항은 개발자가 코딩을 시작할 수 있도록 자세한 내용이 풍부합니다. 다음은 예입니다. Bill 추가 요구 사항이 언급되는 결제 모듈 Biller
| Bill 결제 | 요구조건 니즈 |
|---|---|
| 추가 Bill |
|
때로는 일부 프로젝트의 경우 작업에 필요한 요구 사항이나 문서를 받지 못할 수도 있습니다. 그러나 요구 사항 또는 정보에 대해 고려할 수 있는 다른 요구 사항 소스가 있으므로 이러한 요구 사항을 기반으로 소프트웨어 또는 테스트 설계를 기반으로 할 수 있습니다. 따라서 신뢰할 수 있는 요구 사항에 대한 다른 소스는 다음과 같습니다.
기타 요구 사항 소스
- 이미 해당 프로젝트에 참여하고 있는 동료나 직원으로부터 지식 이전
- 비즈니스 분석가, 제품 관리자, 프로젝트 리더 및 개발자와 프로젝트에 대해 이야기하십시오.
- 이미 시스템에 구현된 이전 시스템 버전을 분석합니다.
- 프로젝트의 이전 요구사항 문서를 분석합니다.
- 과거 버그 리포트를 살펴보면 일부 버그 리포트는 현재 버전에 구현될 수 있는 개선 요청으로 바뀌었습니다.
- 설치 가이드가 있으면 설치에 필요한 사항을 확인하세요.
- 팀이 구현하려는 도메인 또는 산업 지식을 분석합니다.
요구 사항의 소스가 무엇이든 어떤 형식으로든 문서화하고 경험이 풍부하고 지식이 풍부한 다른 팀 구성원의 검토를 받으십시오.
요구 사항을 분석하는 방법
학생이 다양한 강좌에 등록할 수 있는 교육 소프트웨어 시스템의 예를 생각해 보세요.
요구사항을 분석하는 방법을 연구해 보겠습니다. 요구사항은 요구사항의 표준 품질을 유지해야 하며 다양한 유형의 요구사항 품질에는 다음이 포함됩니다.
- Atomic
- 고유하게 식별됨
- 완료
- 일관되고 모호하지 않음
- 추적 가능
- 우선 순위
- 테스트 가능
예를 들어 이해해 보겠습니다. 여기에 표시된 테이블에는 세 개의 열이 있습니다.
- 첫 번째 열은 "요구사항 품질"을 나타냅니다.
- 두 번째 열은 "일부 문제가 있는 잘못된 요구 사항"을 나타냅니다.
- 세 번째 열은 두 번째 열과 동일하지만 “좋은 요구 사항으로 변환”되었습니다.
| 요구사항 품질 | 잘못된 요구사항의 예 | 좋은 요구사항의 예 |
|---|---|---|
| Atomic |
|
|
| 고유하게 식별됨 | 1- 학생들은 학부 과정에 등록할 수 있습니다. 1- 학생들은 대학원 과정에 등록할 수 있습니다. |
|
| 완료 | 교수 사용자는 사용자 이름, 비밀번호 및 기타 관련 정보를 제공하여 시스템에 로그인합니다. | 교수 사용자는 사용자 이름, 비밀번호 및 학과 코드를 제공하여 시스템에 로그인합니다. |
| 일관되고 모호하지 않음 | 학생은 학부 과정이나 대학원 과정 중 하나만 수강할 수 있지만 둘 다 수강할 수는 없습니다. 일부 과정은 학부 및 대학원생 모두에게 공개됩니다. | 학생은 학부 또는 대학원 중 하나를 취득해야 하지만 둘 다 취득할 수는 없습니다. |
| 추적 가능 | BRD req.ID에 매핑된 학생 정보를 유지하시겠습니까? | 학생 정보 유지 - BRD req ID 4.1에 매핑됨 |
| 우선 순위 | 재학생-우선 1사용자 정보관리-우선 1수강신청-우선 1성적표 조회-우선 1 | 학생 등록-우선 1사용자 정보 관리-우선 2강좌 등록-우선 1성적표 조회-우선 3 |
| 테스트 가능 | 시스템의 각 페이지는 허용되는 시간 내에 로드됩니다. | 시스템의 학생 등록 및 강좌 등록 페이지가 5초 이내에 로드됩니다. |
이제 각 요구 사항을 자세히 살펴보겠습니다. AtomIC.
Atomic
따라서 모든 요구 사항은 원자적이어야 하며, 이는 매우 낮은 수준의 세부 정보여야 하며 구성 요소로 분리할 수 없어야 함을 의미합니다. 여기서는 요구 사항에 대한 두 가지 예를 살펴보겠습니다. AtomIC 및 고유하게 식별된 요구 사항 수준.
교육 도메인을 위한 시스템 구축의 예를 계속 살펴보겠습니다. 여기서 나쁜 요구 사항은 "학생들은 학부와 대학원 과정에 등록할 수 있어야 합니다"입니다. 이것은 원자적이지 않기 때문에 나쁜 요구 사항입니다. 왜냐하면 학부와 대학원 과정이라는 두 가지 다른 엔터티에 대해 이야기하기 때문입니다. 따라서 분명히 좋은 요구 사항은 아니지만 나쁜 요구 사항이므로, 좋은 요구 사항은 두 가지 요구 사항으로 분리하는 것입니다. 즉, 하나는 학부 과정 등록에 대해 이야기하고 다른 하나는 대학원 과정 등록에 대해 이야기합니다.
고유하게 식별됨
마찬가지로 다음 요구 사항 품질은 고유하게 식별되었는지 확인하는 것입니다. 여기에는 두 가지 별도의 요구 사항이 있지만 둘 다 동일한 ID#1을 갖습니다. 따라서 ID#을 참조하여 요구 사항을 참조하고 있지만 문서나 시스템의 다른 부분을 참조하는 정확한 요구 사항이 둘 다 동일한 ID#1을 가지고 있으므로 정확히 어떤 요구 사항을 참조하는지 명확하지 않습니다. 따라서 고유 ID로 분리하면 좋은 요구 사항이 섹션 1 과정 등록으로 다시 반환되며 1.1 ID는 학부 과정 등록이고 1.2 ID는 대학원 과정 등록이라는 두 가지 요구 사항이 있습니다.
완료
또한 각각의 요구사항을 모두 충족해야 합니다. 예를 들어, 여기에서는 "교수 사용자가 자신의 사용자 이름, 비밀번호 및 기타 관련 정보를 제공하여 시스템에 로그인합니다"라는 잘못된 요구 사항이 있습니다. 여기서 다른 관련 정보는 명확하지 않으므로 요구사항을 완성하려면 다른 관련 정보를 좋은 요구사항에 명시해야 합니다.
일관되고 모호하지 않음
다음으로 각각의 모든 요구 사항은 일관되고 명확해야 합니다. 예를 들어 여기에는 "학생은 학부 과정이나 대학원 과정 중 하나만 이수해야 하지만 둘 다 이수할 수는 없습니다."라는 요구 사항이 있습니다. 이것은 한 가지 요구 사항이며 "일부 코스는 학부생과 대학원생 모두에게 열려 있어야 합니다.”
이 요구 사항의 문제점은 첫 번째 요구 사항에서 코스가 대학원 과정과 대학원 과정의 두 가지 범주로 나뉘며 학생은 둘 중 하나만 선택할 수 있지만 둘 다 선택할 수는 없다는 것입니다. 그러나 다른 요구 사항을 읽으면 첫 번째 요구 사항과 충돌하며 일부 과정이 대학원 및 학부 모두에게 공개된다는 내용이 표시됩니다.
따라서 이 나쁜 요구 사항을 "학생은 학부 과정이나 대학원 과정 중 하나를 이수하지만 둘 다 가질 수는 없습니다"라는 좋은 요구 사항으로 변환하는 것이 분명합니다. 이는 모든 과정이 학부 과정 또는 대학원 과정으로 표시된다는 것을 의미합니다.
추적 가능
모든 요구사항은 추적 가능해야 합니다. 요구사항에는 여러 수준이 있기 때문입니다. 맨 위에는 비즈니스 요구사항이 있고, 그 아래에는 아키텍처 및 디자인 요구사항이 있으며, 그 아래에는 시스템 통합 요구사항이 있습니다.
이제 비즈니스 요구 사항을 아키텍처 및 디자인 요구 사항으로 변환하거나 아키텍처 및 디자인 요구 사항을 시스템 통합 요구 사항으로 변환할 때 추적성이 있어야 합니다. 즉, 모든 비즈니스 요구 사항을 가져와 해당 하나 이상의 소프트웨어 아키텍처 및 디자인 요구 사항에 매핑할 수 있어야 합니다. 따라서 "학생 정보 유지 관리 - BRD 요구 사항 ID에 매핑?"이라고 말하는 잘못된 요구 사항의 예가 있습니다. 요구 사항 ID는 여기에서 제공되지 않습니다.
따라서 이를 좋은 요구 사항으로 변환하면 동일한 내용이 표시되지만 요구 사항 ID 4.1과 매핑됩니다. 따라서 각각의 모든 요구 사항에 대해 매핑이 있어야 합니다. 높은 수준 및 낮은 수준 매핑 요구 사항이 있는 것과 마찬가지로 시스템 요구 사항과 해당 요구 사항을 구현하는 코드에 대한 통합 요구 사항 사이에도 매핑이 있으며 특정 요구 사항을 테스트하는 테스트 케이스에 대한 시스템 요구 사항과 통합 요구 사항 간의 매핑도 있습니다. .
따라서 이 추적성은 전체 프로젝트에 걸쳐 적용됩니다.
우선 순위
| 우선 순위 | 재학생-1순위 사용자 정보 유지 - 우선순위 1 강좌 등록 - 우선순위 1 성적표 보기 - 우선순위 1 |
학생 우선 등록 1 사용자 정보 유지 - 우선순위 2 강좌 등록 - 우선순위 1 성적표 보기-우선순위3 |
그런 다음 각 요구 사항을 우선순위로 지정해야 하므로 팀은 먼저 구현할 수 있는 요구 사항과 나중에 구현할 수 있는 요구 사항에 대한 지침을 갖게 됩니다. 여기서 나쁜 우선순위는 학생 등록, 사용자 정보 유지 관리이고 각 요구 사항에 우선순위-1이 지정되어 있습니다. 모든 것이 동일한 우선순위일 수는 없으므로 요구 사항을 우선순위로 지정할 수 있습니다. 따라서 여기서 좋은 요구 사항의 예는 학생 등록 및 과정 등록이 가장 높은 우선순위 1이 지정되고 사용자 정보 유지 관리가 우선순위 2에 있고 보고서 카드 보기가 우선순위-3에 지정되어 있습니다.
테스트 가능
| 테스트 가능 | 시스템의 각 페이지는 허용되는 시간 내에 로드됩니다. | 시스템의 학생 등록 및 강좌 등록 페이지가 5초 이내에 로드됩니다. |
각각의 모든 요구 사항은 테스트 가능해야 합니다. 여기서 나쁜 요구 사항은 "시스템의 각 페이지가 허용 가능한 시간 내에 로드됩니다"입니다. 이제 이 요구 사항에는 먼저 두 가지 문제가 있습니다. 각 페이지는 많은 페이지가 있을 수 있음을 의미하므로 테스트 노력이 폭증할 수 있다는 것입니다. 다른 문제는 페이지가 허용 가능한 시간 프레임에 로드될 것이라고 말하는 것입니다. 이제 허용 가능한 시간 프레임은 무엇입니까? 누구에게나 허용됩니다. 따라서 우리는 테스트할 수 없는 주장을 테스트 가능한 주장으로 변환해야 합니다. 이는 "학생 등록 및 강좌 등록 페이지"에 대해 이야기하고 있는 페이지를 구체적으로 알려주고 허용 가능한 시간 프레임도 5초로 제공됩니다.
결론
따라서 이것이 우리가 적절한 수준에서 각각의 요구 사항을 살펴봐야 하는 방식입니다. 예를 들어, 시스템 및 통합 요구 사항과 관련하여 소프트웨어를 빌드하려는 경우 소프트웨어 요구 사항 사양 또는 사용자 스토리에 제공된 시스템 및 통합 요구 사항을 살펴보고 각각의 요구 사항 품질에 적용해야 합니다. 그런 다음 각각의 요구 사항이 원자적이고 고유하게 식별되었으며 완전한지 등을 확인합니다.
