Search
🏫

[소프트웨어 공학] 6. 사용자 요구 분석

Created
2023/05/11 13:18
Tags
CS
Software Engineering
Last edited time
2023/06/17 07:35
Status
Done
Search
[소프트웨어 공학] 12. 상호작용 다이어그램
CS
Software Engineering
2023/06/11 15:16
[소프트웨어 공학] 12. 상호작용 다이어그램
CS
Software Engineering
2023/06/11 15:16

1. 요구사항

1.1. 요구사항

문제 해결이나 목적 달성을 위해 사용자가 필요로 하는조건이나 는ㅇ력
고객이 원하는 것이 무엇인지?
WHAT에 대한 것
요구 분석과 명세 단계는 요구사항을 찾아 분석하고 문서화하는 과정
요구 공석
요구사항 명세서
시스템이 제공해야하는 서비스나 제약 조건 기술
개발과 유지보수 작업의 기초 문서

1.2. 요구사항의 종류

기능적 요구사항
기능에 대한 요구사항
입출력 양식, 저장 구조, 계산 능력 등 기능적 요인 정의
예)
사용자가 티켓을 구입할 수 있어야한다.
사용자가 지방세 정보를 볼 수 있어야 한다
비기능적 요구사항
제품의 품질, 기능상의 제약, 법률이나 표준의 준수에 관한 내용
사용성, 효율성, 신뢰도, 보안 등 프로세스 관련 요구사항 및 하드웨어 사용에 관한 것
예)
사용자에게 1초 내로 피드백이 주어져야 한다
인터페이스 색상이 회사의 공식 색상과 일관성이 있어야 한다.

1.3. FURPS+

HP에서 개발한 요구사항 분류 모델
Functionality는 기능적 요구사항
Usability, Reliability, Performance, Supportability와 + 는 비기능적 요구사항
사용성, 신뢰성, 성능, 지원성, +(설계, 구현, 인터페이스, 물리적 제약사항)
비기능적 요구사항이 기능적 요구사항보다 중요함

2. 요구 공학 프로세스

2.1. 요구 공학

요구 공학 프로세스
시스템의 목표와 기능 및 제약조건 결정 과정
반복적이고 협력적인 프로세스 강조
겨로가의 문서화와 변화하는 요구사항에 대한 이해를 강조한 용어
입력
고객이 준비한 문제 기술서
출력
요구사항 명세서 (SRS)

2.2. 타당성 조사

시스템이 기관의 목적에 부합하는지, 현재의 기술가 비용으로 일정에 맞춰 개발 될 수 있는지, 다른 시스템과 통합될수 있는지 판단
문제 기술서 → 타당성 조사 → 요구사항 수집과 분석 → 문서화(사용자/시스템 요구사항) → 검토 → 관리 → SRS

2.3. 요구사항 수집과 분석

요구사항 수집
고객이나 사용자와 의사소통하여 시스템이 제공해야하는 서비스, 요구되는 시스템의 성능 및 제약사항 등을 찾는 것
분석가가 도메인에 대한 지식을 갖고 있어야함
이해 관계자
시스템에 관심을 갖고 직간접적으로 영향을 받는 사람
요구사항 분석
요구사항 분류 → 요구사항들 간의 충돌 해결 → 우선수위 선정
JAD (Joint Application Design)
애플리케이션 설계와 개발 과정에서 고객과 사용자를 참여시키는 방법
모든 관련자들이 참여하는 JAD 세션에서 요구사항 추출
3~5일 정도 회의 진행
최종 JAD 문서는 합의된 요구사항 명세서임

2.3. 요구사항 문서화

사용자 요구사항
고객이나 사용자를 위해 작성
고수준의 추상적 요구사항
예) 제안 요청서(RFP)
시스템 요구사항
개발자 대상으로 작성
서비스와 제약조건 상세 기술
설계와 개발 작업 기초가 되며 계약서의 역할
시스템 모델을 사용하여 표현

2.4. 요구사항 검토

개발팀이 요구사항의 의미를 설명하고, 고객, 계약자, 사용자 등이 오류가 있는지 시스템 요구사항 검토
요구사항 명세서는 고객과 개발자 모두 상세히 검토 해야함

2.5. 요구사항 관리

요구사항 관리
요구사항의 변화를 이해하고 통제하는 프로세스
요구사항을 조직화 문서화 하고 요구사항 변경 관리
초기 요구사항은 불오나전하고 불일치가 존재하므로 요구사항은 변경되고 진화함
문제 초기 인식 → 초기 요구사항 → 문제 이해도와 변경과 개선 → 요구사항 변경
요구사항이 변경될 때 영향 받는 모든 정보를 추적하여 함께 수정해야함
추적성 정보
요구사항 변경을 관리하기 위한 정보
요구사항들 간에, 그리고 요구사항, 시스템 설계, 코드 사이에는 다양한 의존 관계가 존재
요구사항 변경 시 그것에 영향을 받는 관련 요구사항(또는 설계 요소)를 파악할 수 있어야 함
추적성 정보의 유형
소스 추적성
요구사항 추적성
설계 추적성

3. 요구사항 모델링

3.1. 요구사항 모델링

시스템을 명확히 이해하거나 명세화 위해 모델 사용
자연언어를 이용한 명세의 문제점
모호성, 요구사항 혼합, 과도한 유연성, 모듈화 어려움
테이블, 구조화된 언어, 설계 기술 언어 사용

3.2. 시스템 모델

업무 프로세스, 해결할 문제, 시스템 자체를 그래픽 사용해 표현
정확한 기술 방법 표현 → 검증 쉬움
그림은 자연언어 보다 이해 용이
분석과 설계 과정의 다리 역할

3.3. 객체지향 분석

요구사항 분석 작업에 객체 지향 방법 적용
객체를 찾고, 객체 간의 관계를 바탕으로 요구사항 구조화, 정형화하여 시스템의 모델 만듦
요구사항 정형화 과정
분석 모델
객체 지향 분석의 결과물
시스템을 사용자 관점에서 표현
기능 모델(유즈케이스와 시나리오)은 분석 과정의 입력물이자 결과물
결과물은 분석 객체 모델 (클래스 다이어그램)과 동적 모델 (상태 다이어그램, 시퀀스 다이어그램)

3.4. 구조적 분석

시스템 요구사항 정의를 위해 분할 정복과 하향식 분해 방법을 사용한 요구사항 분석 방법
결과를 그래픽 표현에 기초한 시스템 모델로 표현
시스템 모델을 사용해 분석가와 사용자가 의사 소통
기능적 분해에 의해 시스템을 다루기 쉬운 조각들로 나눔
구조적 분석에 사용된 소프트웨어공학 원리
추상화 - 핵심적인 부분만 간추림
형식화 - 엄격한 접근 방법으로 단계별로 결과물 문서화
분할과 정복
계층화 - 분할된 모듈을 트리 구조로 구성

3.5. 데이터 흐름도

DFD (Data Flow Diagram)
구조적 분석에서 사용되는 기능 관점의 시스템 모델
시스템에서 데이터 흐름과 변환을 보여주는 네트워크 형태 다이어그램
입력 데이터에 대하여 어떤 계산을 통해서 결과가 나오는지에 관한 단계적 처리를 보여줌
정보 처리 시스템의 기능 명세에 주로 사용
데이터 저장소에 저장되거나 프로세스 사이에서 전달되는 데이터는 데이터 사전에 정의
표기법
프로세스는 데이터의 변환 작업을 의미
최상위 수준의 데이터 흐름도에서 시작하여 확장됨
최하위 수준의 데이터 흐름도에 존재하는 프로세스를 기능 단위라 함
최하위 프로세스에 대해 프로세스 명세서 작성
프로세스 명세서는 의사 코드 등을 사용하여 프로그램 논리를 보여줌

3.6. 구조적 분석과 객체지향 분석의 비교

구조적 분석은 기능 관점에서 시스템을 표현
객체지향 분석은 기능과 데이터를 함께 캡슐화된 객체를 가지고 시스템 표현
구조적 분석은 기능 분해 또는 합성에 의한 표현 방법을 사용
객체 지향 분석은 상속 개념 사용 가능