당신들이 외주나 여러 프로젝트를 하다 보면 수많은 요구사항의 요청을 받게 될 것이다. 그러한 요구사항들을 정확하게 따지지 않고 프로젝트를 진행하게 되면 위 그림과 같이 대형사고가 발생할 수 있다. 오늘은 이 요구사항에 대해 알아보자.
요구사항의 중요성
요구사항은 왜 중요한걸 까? 먼저 요구사항이 뭔지 보자.
요구 사항이란, 소프트웨어를 사용할 고객 또는 개발과 관련되는 사람들이 출시 될 소프트웨어에 대해 바라는 모든 것들을 가르킨다. 요구사항을 수집하는 것은 소프트웨어를 개발하기 위한 시작점이다. 그리고 어떤 사항들이 수집되는지, 그 중 어떤 것들을 구현하기로 결정하는가에 따라 소프트웨어의 개발 방향이 달라진다.
그럼 요구사항의 중요성은 뭘까?
- 요구사항을 정확하고 분명하게 작성하지 않고 작업에 들어가면 수많은 문제가 발생한다.
- 제품의 전체적 파악을 위해 의사소통 시간 절약이 가능하다.
- 앞서 언급한 이유에서 프로젝트 진행 중 가장 중요한 과정이다.
요구사항 엔지니어링
요구사항 엔지니어링은 소프트웨어나 시스템을 개발할 때 필요한 요구사항을 정의, 분석, 문서화하고 관리하는 과정을 말한다. 이는 프로젝트의 성공을 위해 매우 중요한데, 요구사항이 명확하지 않거나 부족하면 프로젝트가 예산을 초과하거나 일정이 지연될 수 있다.
요구사항 엔지니어링의 주된 활동을 알아보자.
요구사항 수집
이 단계에서는 고객, 사용자, 이해관계자와의 대화, 문서 검토, 설문조사 등을 통해 요구사항을 수집한다. 이를 통해 시스템이나 소프트웨어가 무엇을 해야 하는지를 이해하고 문제점을 파악한다.
요구사항
분석 수집된 요구사항을 분석하여 충돌되는 요구사항이나 모호한 부분을 해결하고 이해관계자들 간에 합의점을 찾는다. 요구사항을 구조화하고 우선순위를 부여하여 이해관계자의 요구사항을 충족시키는 최적의 해결책을 도출한다.
요구사항 문서화
분석된 요구사항을 명확하고 이해하기 쉬운 형태로 문서화한다. 이는 요구사항 명세서를 작성하는 것을 포함하며, 이 문서는 개발자, 테스터, 프로젝트 관리자 등 프로젝트의 모든 이해관계자들에게 사용된다.
요구사항 검증 및 검토
작성된 요구사항이 정확하고 완전한지를 검증하고 이해관계자들과 함께 요구사항을 검토하여 오류나 누락된 부분을 발견하고 수정한다.
요구사항 관리
프로젝트의 진행 과정에서 요구사항이 변경될 수 있으므로 이를 관리하는 것이 중요하다. 변경 요청을 추적하고 승인 프로세스를 관리하여 변경이 프로젝트에 미치는 영향을 파악하고 조절한다.
요구사항의 종류
요구 사항은 크게 세 가지 유형으로 나뉜다.
기능 요구 사항
시스템이나 소프트웨어가 어떤 작업을 수행해야 하는지에 관한 요구 사항이다.
기능 요구 사항은 시스템이나 소프트웨어가 제공해야 하는 기능, 작업, 프로세스 등을 명시한다.
비기능 요구 사항
시스템이나 소프트웨어의 동작에 대한 제한, 제약, 성능 측면 등을 설명한다.
제약 조건
프로젝트나 시스템 구축에 적용되는 제한 사항을 기술한다.
요구 사항 공학 프로세스
요구 사항 공학 프로세스는 소프트웨어 개발 라이프사이클의 초기 단계 중 하나로, 소프트웨어 시스템이나 제품에 대한 요구 사항을 파악하고 문서화하는 과정을 말한다.
요구 사항 공학 프로세스의 단계들을 알아보자.
-
요구 사항 수집
이해 관계자와의 소통을 통해 시스템에 대한 요구 사항을 수집하는 단계 -
요구 사항 분석 및 명세
수집된 요구 사항을 분석하고 명세서를 작성하는 단계.
요구 사항을 분류하고 우선순위를 지정하여 명확하고 일관된 형식으로 문서화함. -
요구 사항 검증
수집된 요구 사항이 완전하고 일관되며 현실적인지를 검증하는 단계. -
요구 사항 관리
요구 사항이 프로젝트의 진행과 함께 변경되는 경우, 이를 관리하여 프로젝트의 범위와 일정을 유지. -
요구 사항 협상
다양한 이해 관계자 간에 요구 사항에 대한 의견이 분분할 때, 이를 조율하고 협상하는 단계.
FAST guidelines
FAST guidelines을 공부하기 위해서 검색해봤는데 뇌졸증이 나와서 당황했다.
사실 FAST guidelines은 이런거라고 한다.
- 참가자들은 전체 회의에 참석해야 한다.
- 회의 전 문서는 제안된 것으로 간주된다.
- 원격 회의 장소가 선호된다.
- 의제를 설정하고 유지해야 한다.
Davis Principles
"디비스의 원칙"이라고도 알려진 "Davis' Principles"는 소프트웨어 개발과 관련된 개발 방법론의 기본 원리를 제시한 것이다. 이 원칙은 1988년에 Wayne Davis에 의해 처음 제안되었다. Davis는 소프트웨어 공학 분야에서 소프트웨어 개발 프로세스의 핵심 원칙을 명확하게 정리하고 강조하기 위해 이러한 원칙을 개발했다. 위 사진의 저 분은 Davis가 아니고 그냥 모르는 사람이다.
디비스의 원칙은 다음과 같다.
고객 중심성 (Customer Focus)
소프트웨어 개발은 최종 사용자의 요구사항을 충족시키는 것이 주요 목표여야 한다. 개발된 소프트웨어는 사용자의 요구사항을 만족시키거나 그 이상의 가치를 제공해야 한다.
프로세스 제어 (Process Control)
효율적인 소프트웨어 개발을 위해서는 적절한 프로세스 제어가 필요하다. 이는 개발 과정의 관리와 제어를 통해 일정, 비용 및 품질을 유지하고 최적화하는 것을 의미한다.
인적 요소 (People Factor)
소프트웨어 개발은 사람들 사이의 협력과 의사소통에 크게 의존한다. 효과적인 팀워크와 팀원 간의 협력이 소프트웨어 개발의 핵심 요소다.
기술 (Technology)
적절한 기술과 도구를 사용하여 소프트웨어를 개발해야 한다. 기술은 소프트웨어 개발의 효율성과 품질에 직접적인 영향을 미친다.
관리 (Management)
효과적인 관리는 소프트웨어 개발 프로세스를 계획하고 조직화하는 데 필수적이다. 이는 리스크 관리, 일정 관리, 리소스 할당 등을 포함한다.
use case model
유스케이스 모델(Use Case Model)은 소프트웨어 요구사항 분석 및 설계에서 사용되는 중요한 개념 중 하나다. 이 모델은 시스템이 어떻게 사용되는지, 시스템의 기능적 요구사항이 무엇인지를 기술하는 데 사용된다. 각각의 유스케이스는 시스템의 특정 기능 또는 사용 사례를 나타낸다.
유스케이스 (Use Case)
시스템에서 사용자 또는 외부 시스템이 수행하는 특정 작업이나 기능을 나타낸다. 각각의 유스케이스는 시스템이 제공해야 하는 서비스 또는 기능을 설명하는데 사용된다.
액터 (Actor)
시스템과 상호작용하는 외부 역할이나 개체를 나타냅니다. 액터는 주로 사용자, 다른 시스템, 또는 외부 장치가 될 수 있다. 각 유스케이스는 하나 이상의 액터와 연관될 수 있다.
관계 (Relationships)
액터와 유스케이스 간의 상호작용을 설명합니다. 이는 액터가 특정 유스케이스를 통해 시스템과 어떻게 상호작용하는지를 보여준다.
확장 (Extensions)
유스케이스가 발생할 수 있는 다양한 시나리오를 포착하기 위해 사용된다. 이는 유스케이스의 기본 흐름을 확장하거나 변형할 수 있는 대안적인 경로를 나타낸다.
use case model 예시
예시로 use case model을 작성해보자.
우리학교에서 제일 유명한 서비스인 부마위키를 use case model 로 작성해보자.
다음에 또보도록.
