컴퓨터(Computer Science)/소프트웨어공학(Software engineering)

프로젝트 계획(6) - 요구 분석(Requirement Analysis) [소프트웨어공학]

게임이 더 좋아 2020. 4. 17. 20:31
반응형
728x170

이제 계획은 다 세웠으니까 

실제로 프로젝트를 진행해봐야겠지?

 


그러면 이제 고객의 요구(requirement)가 뭔지를 분석해야 요구에 맞는 소프트웨어를 개발하겠지?

그래서 이번엔 요구분석에 대해 알아보려고 한다.

 

요구 분석이란 새 시스템이나 변경할 시스템의 요구를 결정하는 작업으로 개발자, 관리자, 사용자 모두가 참가해서 서로의 상충되는 요구를 조정하는 단계이다.

이 단계를 잘못하면 프로젝트를 완료해도 망한 소프트웨어가 나올 게 뻔해지니까. 정말 중요한 단계다.

 

실제로 개발의 첫 단계로 요구 분석을 진행한다.

 

요구 분석은 다시 두 가지 단계로 나뉜다. 

분석 단계와 요구 명세서 작성 단계

 

분석 단계에서는

현재 상태를 파악하고 요구를 정의하고 문제 해결과 구현될 시스템의 목표를 도출한다. 

 

명세서 작성 과정에서는

완성될 소프트웨어가 어떤 기능을 가져야 하는지를 정확하게 작성하는 일이다.

명세서에는 기술적 요구와 제약 조건, 개발자와 사용자가 합의한 성능에 관한 사항 등 시스템 설계 시 

참조할 사항들 포함 전반적으로 알아야할 것들이 적혀있다.

 

**요구의 변경은 개발 전체에 영향을 끼치기 때문에 요구 분석은 정확하게 완벽하게 작성을 목표로 해야한다.

 

 

소프트웨어 요구 사항의 분석은 5가지 분야로 나눌 수 있다.

1. 요구추출 - requirement elicitation

2. 도메인분석 - domain analysis

3. 모델링 - modeling

4. 프로토타이핑과 시험 - prototyping & testing

5. 문서화 및 검토 - documentation & validation

 


 

5가지에 대해서 더 자세히 알아보자

 

요구 추출 –  기능적인 요구와 비기능 요구 조건 추출

다시 말해서 계획 단계에 정의한 문제 범위 안에서 사용자의 요구를 찾는 것이다.


도메인 분석 – 요구에 대한 정보를 수집하고 배경을 분석

사용자의 요구와 관련된 개체(entity), 관계(relation), 기능(function), 프로세스(process), 제약(constraints) 을 인식하기 위하여 분석하고 이를 토대로 모델링을 하고자 하는 것이다

 

모델링 – 도메인 분석을 통해 얻은 자료를 개념화  

다이어그램을 이용하여 모델화한다고 볼 수 있다.

 

프로토타이핑과 시험 – 분석된 기능적 요구의 타당성시험을 위한 프로토 타입 생성


문서화 검토 – 요구 분석서를 작성

시스템의 기능, 성능, 정보 표현, 제약, 검증 평가 기준에 대하여 검토

 

 

* 요구는 개발 전체과정에서 중요한 요소이므로 변경이 되더라도 관리가 되어야하기에 요구 관리(requirement management)가 필요하다

 


 

 

요구를 다시 정의하자

사전적인 뜻이 아니라 소프트웨어의 요구란 시스템이 제공해야 할 역량(capability)를 뜻한다.

외형적으로 나타내는 기능이나 성능 또한 뜻한다.

 

아까 위에서 요구를 추출할 때 기능적 요구와 비기능적 요구를 구분을 했는데 

요구의 종류에 대해 알아보자

 

 

 

기능적 요구(functional)
 시스템과 외부 요소들 간의 인터랙션(interaction)이라고 말할 수 있다.
 시스템이 어떤 상태일 때 외부의 데이터나 명령에 대해 어떤 반응을 하는지 기술할 수 있는 것인가? 
 기능적 요구 항목으로 제기되는 문제들은 사용자의 문제를 해결하기 위한 구현 기술과는 독립적인
사항이어야 함

 

다시 말하자면 결국 외부 사용자에게 직접적으로 혜택을 줄 수 있는 시스템의 기능을 말한다.

 

기능적 요구와 사례

 

비기능적 요구(non-functional)
 시스템 구축에 대한 성능, 보안, 품질, 안전 등에 대한 요구 사항을 말한다


 성능 요구  – 시스템의 처리량, 반응시간, 실시간 처리, 자원 이용률

ex) 하루에 1만건 처리 요구


 품질 요구 – 신뢰성, 가용성, 사용시 오류 발생률

ex) 시스템은 99% 이상 가동디어야 한다

 

 안전  요구 – 의도하지 않은 오퍼레이션으로 인하여 원치 않는 상태에 있는 것을 방지하는 역량

ex) 트랜젝션이 성공적으로 수행되지 못했을 때 트랜젝션의 히스토리를 저장하고 보호해야한다


 보안  요구 – 시스템의 자원을 악의적인 공격으로부터 보호할 수 있는 역량

ex) 전달되는 파일들은 암호화 되어야 한다


 사용성 요구 – 인터페이스. 동작, 보고 느끼는 것(look and feel)

사용자 인터페이스 포함 하드웨어와 소프트웨어 사이의 인터페이스도 해당된다.

 

 

 


 

 

그러나 요구를 추출하는 것 자체가 어렵다.

원인은 여러가지가 있는데 몇개 추려보자면

 

 

1. 개발 팀이 응용 도메인에 대하여 충분히 알지 못함

응용 도메인에 대하여 이해하는 것이 필수라 할만큼 중요한 사항이지만

이러한 도메인 지식은 오랜 기간 경험을 통해서 얻어지는 것이다. 

+고객과의 협업, 사용자의 적극적인 참여를 강조하는 이유가 도메인 지식을 얻기 위한 효과적인 방법임

 

 2. 고객과 사용자가 소프트웨어가 무엇을 하는지 또한 어떻게 요구를 표현할 지 모름

대안으로 프로토타입을 개발해서 요구를 얻어내기도함


3. 공통 배경지식 부족으로 개발 팀과 사용자 사이의 대화 장벽이 생김

같은 단어도 자신이 속해있는 분야에 따라 다르게 사용할 수 있음

ex)testing이란 단어도 다르게 쓰임


4. 소프트웨어 요구에 대한 명세와 구현이 분리될 수 없어 정확히 명시하기 어려움

프로토타입 개발로 완화가능


5. 요구 추출 작업을 관리자, 사용자, 개발자 모두 과소평가하는 경우가 많음


6. 비기능적 요구를 파악하고 이해하지 못함

비기능적 요구는 무시되는 경우가 많음


7. 요구가 계속해서 변경됨

실제로 많이 변경이됨

 

 

728x90
반응형
그리드형