반응형
1. 요구사항 분석의 개념
가. 요구사항 분석 정의
- 고객(사용자)에 의해 요구되는 소프트웨어 혹은 시스템이 가져야 하는 기능, 서비스, 제약사항 등을 정의한 명세를 분석하고 수립하는 행위
나. 요구사항 분석의 중요성
- 시스템 설계의 기준선(base line)
- 프로젝트의 다양화, 대형화에 따라 다양한 이해관계자가 존재
- 요구사항 분석의 실패는 프로젝트 실패와 직결
2. 요구사항 공학의 개념
가. 요구사항 공학의 정의
- 초기에 정한 요구사항들은 물론 이후의 상세 요구사항들이 설계와 구현 단계에서 제대로 지켜지고 있는지를 검증해 나가는 기법
나. 요구사항 공학의 필요성
- 고객의 Needs를 반영하고 문제 또는 이슈를 식별하는 관리기법의 필요
- 사용자의 필요와 기대사항의 차이를 감소
- 요구사항의 명확한 이해 및 이해관계자 간의 의사소통, 체계적 변경관리 필요
3. 요구사항 공학 프로세스와 구성도
가. 요구사항 공학 프로세스
절차 | 내용 |
요구사항 추출 | - 문제를 이해하고, 요구사항 추출 - 기법 : 인터뷰, 브레인스토밍, 질문서, 사례, 워크샵 등 |
요구사항 분석 | - 추출된 요구사항을 분석하여 요구사항을 구조화하고 각종대안들을 결정함 - 기법 : 데이터모델링, 프로토타입 |
요구사항 정의 | - 시스템이 무엇을 해야 할 지를 기술. 분석된 요구사항을 명세화 - SRS(S/W Requirment Specification)작성 - 기능적, 비기능적 요구사항으로 구분 |
요구사항 검증 | - 문제를 기술하고, 서로 다른 부분들과 일치 여부를 확인함 - 점검항목 : 유효성, 일관성, 완전성, 실현성, 증명가능성 - 검증방안 : 문서화, 시험, 인증 |
요구사항 관리 | - 요구사항에 요구사항 관리 대한 최종결정 및 베이스라인 관리, 변경통제 및 확인 기능 - 관리방안 : 변경관리, 추적관리(순방향, 역방향), 형상관리 |
나. 요구사항 공학 구성도
- SW 요구사항 공학 관련 지식 체계 및 국제표준 IEEE std 1233, IEEE 830
4. 요구사항 유형 및 요구사항 공학 주요 원리
가. 요구사항 유형
원리 | 설명 | 사례 |
비지니스 요구사항 | Why에 대한 정보로 해당 조직에서 프로젝트를 통해서 얻을 수 있는 이득에 대한 기술 비전 및 범위문서 |
범위 기술서 |
사용자 요구사항 |
What에 대한 정보로 사용자 프로젝트 결과물을 통해서 할 수 있는 것을 설명 유즈케이스 |
USE CASE 스토리 보드 이벤트 응답표 |
기능 요구사항 |
-또 다른 What에 대한 정보로 개발자가 개발해야 하는 것을 설명 -시스템이 반드시 수행되거나 시스템을 통해서 사용자가 반드시 할 수 있는 것을 설명 |
요구 사항 명세서 |
시스템 요구사항 |
-사용자 관점에서 보여지는 시스템의 행위에 대한 설명 -여러 개의 서브 시스템과 기능으로 구성되는 최상위 요구사항을 설명하기 위해서 사용 |
운영 환경 기술서 |
회사의 규칙 |
-회사의 정책, 정부 법규, 산업 표준, 연산 알고리즘 등 -비즈니스 규칙은 그 자체가 소프트웨어의 요구사항이 되지는 않음 -특정 기능의 요구사항은 어떤 비즈니스 규칙으로 파생되었는지 추적 가능 |
정부 법규/제도 산업 표준 연산 알고리즘 |
품질 속성 | -제품의 특징을 다양하게 설명함 -적용성, 성능, 사용성, 휴대성, 내구성등 |
품질 목표 |
인터페이스 | -비기능 요구사항의 분류 -다른 컴포넌트, 시스템, 사용자 인터페이스를 포함한 통신, 정보 교환 프로토콜 등 |
비기능적 요구사항 |
나. 요구사항 공학의 주요 원리
주요원리 | 설명 |
명확성 | 각각의 명세는 하나의 의미만을 가질 것 |
검증가능성 | 요구사항으 충족여부의 확인이 가능할 것 |
일관성 | 명세내용 상호간 모순성이 없을 것 |
추적가능성 | 추적과 상호 참조가 가능할 것 |
이용성 | 운영 및 유지보수에 효과적 활용이 가능할 것 |
- 방법이 아닌 무엇을 해야 하는지가 기술되어야 함
- 기능/비기능/품질적 요구사항이 명세되어야 함
다. 요구사항 공학의 주요 원리
프로세스 | 설명 |
문제분석 및 명세화 | 문제와 변경 제안이 유효한지 검사하기 위한 분석 |
변경분석 및 비용산정 | 제안된 변경의 결과가 추적 정보와 시스템 요구사항의 일반 지식을 사용하여 평가 |
변경구현 | 요구사항 문서, 시스템 설계, 구현 수정 |
5. 요구사항 명세서(SRS) 구성과 고려사항
가. 요구사항 명세서 구성
구분 | 설명 |
소개 | 목적, 범위, 정의, 관계기술 |
전체적 서술 | 제품관점, 기능, 사용자 특성, 제약사항, 가정과 이론, 요구 서브넷 |
요구명세 | 내부인터페이스요구 : 사용자 I/F, HW I/F, SW I/F, 커뮤니케이션 I/F 기능적 요구 : 사용자 class, 성능 요구사항, 설계 제약사항, SW시스템 속성, 기타 요구 |
나. 요구사항 명세서 작성 시 고려사항
- 명확, 완전, 검증 가능, 일관성 유지
- 요구사항 작성 시 가이드라인 준수(IEEE 830)
6. 요구사항의 누락방지 및 변경 영향 분석을 위한 요구사항 추적성
가. 요구사항 추적성의 정의
- 추적성은 시스템 내 서로 다른 단계의 요구사항들 사이에 관계를 제공하는 기술
나. 요구사항 추적성의 목적
- 요구사항 대비 단계별 산출물의 누락이 있는지 검토하는 것
- 요구사항 변경관리의 변경 영향도 분석 활용
- 요구사항 가시회, 산출물 누락방지, 변경 영향 분석
다. 요구사항 추적성 관리 방식
V 모델 | |
요구사항 추적 메트릭스 |
라. 요구사항 추적성 확보 방안
- 요구사항 명확화
- 각 단계별 요구사항 맵핑
- 요구사항 추적 표 관리
- 요구사항 추적성 자동화
8. Functional Requirement와 Non-Funtional Requirement
가. Functional Requirement
- 시스템이 사용자와 다른 시스템에게 제공하는 서비스에 대하여 기술한 것
구분 | 설명 |
입력 | 시스템이 받아들이는 입력의 종류, 조건, 사용자 및 타 시스템으로부터의 유입 데이터와 명령어 |
출력 | 시스템이 생성하는 출력 및 조건, 특수 입출력 장치의 유무 |
저장 | 데이터의 저장 형태 및 기간, 타 시스템을 위한 특수한 형태의 저장 |
컴퓨팅 | 시스템에서 연산이 이루어지는 방식 |
타이밍 | 리얼타임, 배치잡 등 |
- 시스템 구축에 대한 제한 사항으로 하드웨어 자원 및 소프트웨어 품질 특성에 대한 범위
구분 | 설명 |
자원 | 개발자역량, 목표 하드웨어/플랫폼의 특징, 개발 및 유지보수에 소요되는 인력/자원 |
성능 | 시스템의 속도, 반응시간, 처리율, 분당 트랜잭션 수 |
보안 | 자료 및 시스템에 대한 접근 통제,시스템의 백업 및 재해방지대책, 물리적 보안 |
품질 | 기능성, 신뢰성, 사용성 효율성, 유지보수성, 이식성 |
비용 및 납기 | 계약서 또는 별도의 프로젝트 계획서에 명기 |
9. 효율적 Functional/Non-Functional Requirement)의 추출
- 도메인 분석에서 활용되는 관련 당사자, 유사 소프트웨어 시스템 등에서 요구의 추출
방법 | 작업 | 특징 |
관찰 | 사용자 업무 관찰 | 감추어진 문제의 노출 용이 |
인터뷰 | 관련 당사자와의 질의/응답 | 정확한 요구도출 가능 |
브레인스토밍 | 여러 사람의 의견 및 아이디어 청취 | 효과적 정보 추출 |
프로토타이핑 | 시범적으로 시스템 구현 | 요구에 대한 빠른 피드백/자원의 낭비 |
Use-Case 분석 | 시스템의 외부기능 파악 | 체계적 요구 구성 |
10. 요구사항 분석을 위한 페르소나
가. 페르소나 개념
- 사용자나 서비스를 사용하는 사람에 대한 가상 인물
- 특정한 환경에서 어떻게 행동할 것인가에 대한 예측을 위해 실제 사용자 정보를 기반으로 그 인물이 가지는 Needs를 구성
나. 페르소나 방법론의 이점
- 브레인스토밍, 유즈 케이스 분석, 요구사항 정의 등에 활용 가능, 공통된 타깃
- 사용자 이해를 위한 상호 소통 도구로서 유용함, 니즈 파악, 커뮤니케이션 원할
다. 페르소나 절차
가상화 | |
리서치 | 기본이 되는 사항으로, 고객 설문이나 사용 후기의 양식을 통해 얻은 자료를 통해 고객의 과거 경험을 파악하고 이를 통해 니즈를 분석하고 최종적으로 가상의 고객(메타포)을 설정하는 것 |
실체화 | 유저 리서치를 통해 얻은 정성, 정량 조사 자료를 기반으로 하여 만들어지는 것이기 때문에 신뢰성 있는 리서치 필요 |
다양한 요구사항 |
최대한 다양한 요구사항을 고려하여 한 제품/서비스에 대해 하나 이상의 페르소나가 존재한다는 사실을 충분히 인지 |
재구성 | 페르소나로 재구성하는 과정에서 조사자 임의에 맞게 자료를 재구성하는 일이 없도록 주의하여 마지막까지 요염되지 않은 페르소나를 뽑아내는 것이 중요 |
반응형
'TechNote > 소프트웨어 공학(SW)' 카테고리의 다른 글
006. 소프트웨어 아키텍처 평가 방법론 (0) | 2022.09.30 |
---|---|
005. 소프트웨어 아키텍처 스타일 (0) | 2022.09.30 |
004. 소프트웨어 아키 (0) | 2022.09.29 |
002. Software Development Life Cycle의 정의 (0) | 2022.09.29 |
001.소프트웨어 공학 (0) | 2022.09.29 |
댓글