일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- MAC
- unity
- DP
- OSI 7계층
- Trap
- 게임 개발
- 컴퓨터 네트워크
- MLFQ
- stride
- protection
- Unity #Indie Game
- FIFO
- DSP
- AINCAA
- SDLC
- OWASP
- 메카님
- 배경 그림
- link layer
- 운영체제
- Waterfall
- polymorphism
- SJF
- frequency-domain spectrum analysis
- 게임개발
- STCF
- Security
- 유스케이스
- information hiding
- 유니티
- Today
- Total
다양한 기록
요구사항 정의 개요, 산출물 본문
요구사항 정의의 역할
- 사용자들의 요구를 명세, 검증, 확인하는 활동
- 소프트웨어가 제공하는 특성으로 명확한 기준 정립
- Stakeholders (이해 당사자)
분류
요구사항
- 기능정 요구사항
- 비기능적 요구사항
- 품질 요구사항
- 제약사항
유형
기능적 요구사항
- 사용자가 직접 이용하는 개별적인 기능에 대한 정의
- 시스템에 주어지는 특정 입력에 시스템이 산출하는 출력에 의해 정의
식별자 | 입력 | 출력 |
Req-1 | 사용자가 휴대폰의 통화 버튼을 누른다 | 시스템은 최근 통화 목록을 표시한다. 첫 항목을 선택시킨다. |
Req-2 | 사용자가 한 번 더 통화 버튼을 누른다. | 시스템은 선택된 항목의 전화 번호로 통화를 시도한다. 통화 연결음을 들려준다. |
Req-3 | 사용자가 통화 중에 종료버튼을 누른다. | 시스템은 연결을 종료시킨다. |
Req-4 | 사용자가 종료 버튼을 2초동안 누른다. | 시스템은 휴대폰을 종료시킨다. |
비기능적 요구사항
품질 요구사항
- 성능 : 시스템의 자원(CPU, 메모리 등)을 효율적으로 사용하는 정도
- 신뢰성 : 시스템이 주어진 요구사항을 준수하여 동작하는 정도 (일반적으로 장애없이 동작하는 시간의 비율로서 정의)
- 보안성 : 허가되지 않은 사용자 또는 접근 권한이 없는 사용자의 시스템 및 정보 접근 방지
- 안전성 : 시스템이 주변 환경, 인명, 재산에 피해를 주지 않는 정도
- 가용성 : 사용자가 원하는 순간에 시스템이 서비스를 받을 수 있는 정도
제약 사항
- 고객은 개발 방법과 개발 및 운용 플랫폼에 대한 제약을 받음
유형 | 예 |
개발 방법론 | CBD 방법론을 선택해야 한다 |
모델링 언어 | UML 2.x를 적용해야 한다 |
개발 언어 | Java를 사용해야 한다 |
운영체제 | Linux에서 동작해야 한다 |
미들웨어 | EJB 3.0을 적용해야 한다 |
요구사항 명세서의 요건
* 요구명세서의 역할
- 고객/사용자: 사용자가 기대하는대로 동작하는지에 대한 기준
- 개발자: 기능적/비기능적 요구사항 제공
- 테스트: 소프트웨어의 오류에 대한 정확한 판단 및 기대되는 동작 기능
* 요구명세서의 특징
- 소프트웨어 개발, 테스팅, 개발 완료에 대한 승인 기준으로서 사용되기 위해 가져야할 특징
1. 명확성: 문서를 읽는 모든 사람에게 동일한 의미로 해석
2. 완전성: 고객/사용자가 기대하는 모든 요구사항을 기술
3. 일관성: 동시에 충족시킬 수 없는 상충되는 요구 사항을 포함해서는 안됨
4. 검증 가능성: 시스템의 요구사항이 정확하게 구현되는지 판단 가능해야 함 (ex. 최대한 빨리?)
5. 요약
이후 단계와의 차이점
- 요구사항 정의 단계와 개발 단계를 구분짓는 차이점은 가시성
- 이후엔 분석, 설계, 구현, 테스팅 수행
- 요구사항 정의 단계는 시스템의 외적의 특성만 도출/정의
개발 단계에서는 시스템 내부의 요소 정의 및 구현
산출물
요구사항 명세서
- 기능적 요구사항: 유스케이스 모델과 명세서로 구성
- 시스템 품질 요구사항: 시스템 전체의 품질 요구사항 기술
- 개발 제약사항: 적용할 개발 방법, 운영 플랫폼, 관련 법규 등
유스케이스 모델
- 액터 .. 사용자, 외부 시스템, 디바이스
- 유스케이스 .. 시스템이 제공할 기능적 단위
액터/유스케이스 간 관계
- 액터~유스케이스 간 연관 관계
- 액터~액터 사이의 일반화 관계
- 유스케이스 사이의 포함 관계
- 유스케이스 사이의 확장 관계
유스케이스 명세서
유스케이스 모델에 기술된 개별 유스케이스에 대한 구체적이고 상세한 기능을 정의한 문서
항목: 이름, 개요, 관련 액터, 우선 순위, 선행 조건, 후행 조건, 시나리오 비기능적 요구사항..
유스케이스 모델의 작성
-> 상세화
-> 구조화
-> 조직화
작성
- 사용자/고객의 기능적/비기능적 요구사항을 도출해 유스케이스 모델 작성
상세화
- 요구사항을 구체화하여 유스케이스 명세서 작성
구조화
- 유스케이스 모델과 유스케이스 명세서의 가독성과 확장성을 높임
조직화
- 패키지를 활용해 모델을 조직화해 유스케이스 모델의 규모와 복잡성 관리
'소프트웨어공학' 카테고리의 다른 글
유스케이스 모델 상세화 (0) | 2024.10.24 |
---|---|
유스케이스 모델의 작성 (1) | 2024.10.23 |
유스케이스, 클래스 등등 다이어그램 기초 (0) | 2024.10.20 |
UML 개요 (0) | 2024.10.20 |
OOP #3 : Class, Instance, Polymorphism (0) | 2024.10.20 |