소프트웨어 공학 3(요구분석)

• 요구
• 요구 추출
• 도메인 분석
• Use Case
• 요구 명세 및 검증

요구 분석

• 소프트웨어 개발의 실질적인 첫 단계
• 사용자의 요구에 대하여 이해하고 체계화하는 작업
• 세 가지 작업
  • 요구 추출
  • 요구 분석 및 정의 (도메인 정의 => use case 작성)
  • 요구 검증
• 요구의 변경은 파급효과가 큼

순서 암기

• 요구 추출 – 기능적인 요구와 비기능 요구 조건 추출
• 도메인 분석 – 요구에 대한 정보를 수집하고 배경을 분석
• 모델링 – 도메인 분석을 통해 얻은 자료를 개념화
• 프로토타이핑과 시험 – 분석된 기능적 요구의 타당성시험을 위한 프로토타입 생성
• 문서화 검토 – 요구 분석서를 작성

요구(Requrements)

시스템에 대한 고객의 요청을 확정한 것

기능적(functional) : 서비스

비 기능적(non-functional) : 성능, 신뢰도, 품질

기능 요구

SW의 기능, 서비스(USECASE), 동사 형식

내부적으로 SW가 사용자에게 지원하는 기능(혜택)

• 시스템이 외형적으로 나타내는 기능과 동작
  • 현금인출기: 현금의 인출, 잔금 조회, 계좌 이체, 현금 서비스
• 시스템과 외부 요소들 간의 인터랙션
  • 어떤 상태일 때 외부의 데이터나 명령을 받아들여 (input) 어떤 반응을 하는지(output) 기술
• 입력 자료가 제공되어 이를 변환 처리하여 결과를 출력
  • ‘시스템은 ...을 해야 한다’

비기능 요구

시스템 구축에 대한 성능, 보안, 품질, 안전 등에 대한 요구 사항

기능적 요구를 제외한 요구

• 종류(성능과 품질이 중요)
  • 성능 – 시스템의 처리량, 반응시간, 실시간 처리, 자원 이용률
  • 품질 – 신뢰성, 가용성, 사용시 오류 발생률
  • 안전 – 의도하지 않은 오퍼레이션으로 인하여 원치 않는 상태에 있는 것을 방지하는 역량
  • 보안 – 시스템의 자원을 악의적인 공격으로부터 보호할 수 있는 역량
  • 사용성 – 인터페이스. 동작, 보고 느끼는 것(look and feel)

요구 추출

• 개발 팀이 응용 도메인에 대하여 충분히 알지 못함
• 고객과 사용자가 소프트웨어가 무엇을 하는지 또한 어떻게 요구를 표현할 지 모름
• 공통 배경지식 부족으로 개발 팀과 사용자 사이의 대화 장벽이 생김(프로토타입이 대화에 도움을 줌)
• 소프트웨어 요구에 대한 명세와 구현(HOW)이 분리될 수 없어 정확히 명시하기 어려움
• 요구 추출 작업을 관리자, 사용자, 개발자 모두 과소평가하는 경우가 많음
• 비기능적 요구를 파악하고 이해하지 못함
• 요구가 계속해서 변경됨

추출 세 가지 단계

• 응용에 대한 정보 출처 파악
• 응용에 대한 정보 취합
• 요구와 제한 사항(도메인)의 정의, 중요한 규칙, 명사, 관계를 정의하는 것

정보 수집 방법

• 고객의 발표
• 문헌 조사
• 업무 절차와 양식 조사
• 관련자들 설문지
• 사용자와의 인터뷰
• 브레인 스토밍 회의
• 사용 스토리 또는 사용사례 작성(UML - USECASE)
  • 사용자와 SW간의 interaction 시나리오를 작성한 것

요구정보 출처

• 고객
• 도메인 전문가 – 비즈니스 도메인을 지원하는 시스템을 구축하기 위하여 필요한 사람(예, 회계 시스템을 구축하 기 위하여 회계사가 필요)
• 이해당사자(stakeholder) – 시스템 운용으로 인하여 영향 받는 사람
• 사용자 – 시스템을 직접 사용하는 사람
• 역공학(기존 legacy 시스템을 통해 새로운 시스템을 만들때, 기존 legacy시스템을 이용해 요구사항 추출)
  • 소스코드로 부터 설계문서를 도출 가능 => 요구사항 도출

요구 수집 : 고객 발표

개발팀이 구축하는 시스템에 대하여 초기에 개념을 잡을 수 있음

고객 업무를 잘 알고 있는 운영 책임자나 관리자가 발표

요구 수집 : 문헌 양식 조사

유사한 프로젝트를 조사

산업 및 기업 표준 조사

업무 관련 문서, 절차, 양식, 운영 매뉴얼 조사

요구 수집 : 설문 조사

관리자나 사용자와 같은 이해 당사자를 대상

기능, 비기능적 요구사항 도출

요구 수집 : 브레인 스토밍

아이디어를 낼 목적으로 여러 명으로부터 정보를 얻기 위한 회의

토론보다는 아이디어를 쏟아놓는 회의, 익명성 보장

요구 수집 : 프로토타이핑

프로토타입 : 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램

• 모의 사용자 인터페이스
  • 모의 사용자 인터페이스를 써서 개발자와 사용자의 대화를 도움(요구사항의 구체화)
  • 프로토타이핑 언어로 작성
  • 컴퓨팅, 데이터베이스 접근, 다른 시스템과의 상호작용은 불가능
  • 시스템의 특별한 측면을 프로토타이핑 하기도 함
    • 알고리즘, 데이터베이스 등

요구 수집 : 인터뷰

• 인터뷰 수행 가이드 라인
  • 대상자 선정 👉 일정 계획 👉 질문 작성 👉 인터뷰 👉 분석 및 정리
  • 가능하면 많은 당사자와 인터뷰
  • 여유로운 인터뷰 일정
  • 인터뷰 약속 시간을 넘기더라도 여유롭게
  • 중요한 관련자와는 여러 차례 인터뷰

요구 분석

요구 후보를 분석하고 결정하여 요구로 확정

• 요구 품질
  • 원자적(atomic)
  • 완전성(complete)
  • 비모호성(unambiguous)과 통일성(consistent) => 도메인 개념(표준용어 개념 포함)
  • 추적성(traceable)
  • 우선순위화(prioritize)
  • 테스트 가능성(testable) (system testing 단계에서 testcase 필요, 요구분석단계에서 해당 case 정의)
    • testcase : 주어진 사용자 입력에 어떻게 응답할지 정해놓은 것

📌 요구 사항 정리

• 요구 사항 👉 기능적 요구사항 : 기능, 서비스(동사)
• ​ 👉 비기능적 요구사항 : 성능, 품질, 제약조건, 개발환경(형용사), 가용성(availability, 서버가 죽지 않도록 관리)
• 사용자와 시스템의 interaction에 집중(특정 알고리즘 적용 요구 x, UseCase에 어떤 알고리즘, 어떻게 구현해달라와 같은 요구는 x)

도메인 분석

요구의 배경

중요한 명사 도출

• 설계 모델링에 필요한 여러 개념과 비즈니스 룰을 파악
  • 계획 => 요구사항 분석 => 설계 ...
• 응용 분야에 존재하는 개념(도메인)을 잘 정의하고 분석하여 시스템에 존재하는 개념으로 정립하는 단계

도메인 배경 파악 세가지 단계

• 도메인 개념찾기
• 도메인 사전 작성
• 비즈니스 규칙 정리

도메인 정의

• 업무 작업 영역을 파악하고 범위를 규정
  • 정보 시스템을 구축하는데 필요한 개념적인 프레임워크 제공
• 정보 시스템의 서브시스템 개념이 되는 프레임워크 제공
• 넓은 범위의 개념을 더 좁은 범위의 지식들로 체계화 하는 작업

1. 도메인 개념

도메인의 목적, 구조, 동작을 구성하는 객체, 프로세스, 사람, 룰 같은 것

객체 : 계좌, 의사, 학생

프로세스 : 인출, 대출, 저축, 수강, 진료(절차나 과정을 포함하는)

사람 : 고객

• 도메인 개념 발견을 위한 주의사항
  • 요구의 핵심을 발견해야 함
  • 요구가 해결될 것 같은 문제를 발견
  • 문제의 요소를 발견
  • 관련된 도메인의 개념을 발견

2. 도메인 사전

표준화의 역할 : user와 개발자가 회의를 할때 user의 요구사항이 잘 전해지도록 표준화할 필요 있음

도메인 개념을 조직화한 결과물

• 각 항목은 용어가 사용될 때는 언제든 같은 의미로 통하게 하는 간결한 정의
• 요구, 인터뷰, 매뉴얼로 부터 추출
• 도메인 정의에서 표현된 문장, 어절, 제목에 초점을 두고 개념 추출
  • <예> 의료 정보 시스템에서 도메인 개념 추출
  • 진료와 검사 의료 서비스의 성격에 따라 의사, 간호사, 검사원 이 환자에게 적절한 예약된 의료 서비스를 제공한다.
  • 도메인 개념: 의료 서비스, 의사, 간호사, 검사원, 환자, 예약

사전 양식

• 표로 구성
  • 세가지 항목 포함
    • 명칭(도메인 개념)
    • 타입(프로세스, 객체, 사람, 기능...)
    • 설명(설명할때 새로운 도메인 개념이 추출됨 => 아래에 계속 정의할 필요 있음)

3. 비즈니스 규칙

• 업무에서 지키기로 한 규정
• 기업이 운영되는 자세한 정책, 규정, 절차, 가이드라인, 표준의 집합
• 사용자에게 요구해도 준비된 전체 목록을 받기 어려움

비즈니스 규칙 종류

• 사실(fact) – 개념이 무엇인지 설명(도메인 개념 자체)
• 추론(inference) – 다른 사실로 부터 얻은 사실(fact에 의해 유도되는 새로운(만들어진) fact)
• 액션 구동자(action enabler) – 조건이 일치되면 액션이 수행(if문)
• 제약(constraints) – 시스템이나 외부 요소가 수행할 또는 수행하지 않을 제약을 가하는 규칙
• 계산(computation) – 공식이나 알고리즘
• 유추 - 특정 조건에 따른 비즈니스 규칙

Usecase

시스템의 기능을 나타내기 위해 사용자의 요구를 추출하고 분석하는데 사용

• 도메인 분석과 모델링 사이의 관문
• 도메인 분석의 결과를 액터, 사용사례 , 관계들로 구성된 시스템 명세로 매핑하는 작업
  • 테스트할때 사용
  • 외부 시스템이나 기타 요소들과의 상호 작용

구성

• 사용 사례(use case) - 시스템 기능
• 액터(actor)
  • 시스템과 상호작용 하는것(사용자, 외부 시스템)
• 시작조건
• 사건의 흐름
  • 위 그림처럼 한번에 다 표현해도 좋고, 사용자와 각 시스템을 나눠서 흐름(1, 2, 3과 같은 번호)에 따라 기능을 명세하면 더 좋음
• 종료조건

사용 사례 관계 찾기

포함 관계

• 사용사례 사이의 중복을 제거
  • 어떤 사용 사례가 다른 사용사례를 포함하는 관계

📌 화살표 방향으로 "주어 - 동사 - 목적어"

• Rent Video include Get Video ID

확장관계

• 사용 사례가 일정한 조건 아래 확장된 동작을 포함한다면 다른 사용 사례를 확장하는 관계에 있다.
• 사용자 정보 입력 중 미성년자를 위하여 부모 허락을 받는 사용 사례가 확장되는 경우

상속관계

• 부모쪽이 화살표를 받음
• 부모는 포괄적, 자식은 세부적

사용사례 다이어그램