요구사항
소프트웨어 개발에서 만들고자 요구하는 사용자는 적은 비용으로 원하는 기능들이 모두 들어가있는 소프트웨어를 만들어주기를 바랍니다.
개발자는 이러한 요구사항들을 정확하게 파악해서 원하는 비용에 높은 품질의 소프트웨어를 개발할 수 있어야합니다.
소프트웨어 개발에서 요구사항은 사용자와 개발자가 합의한 범위 내에서 사용자가 필요로 하는 기능을 의미하며, 시스템이 제공하는 기능 요구와 품질과 같은 비기능 요구를 의미합니다.
요구사항을 파악하는 것은 요구분석 단계에서 이루어지게 됩니다.
요구분석의 이해
요구분석의 정의
요구분석은 (컴퓨터 공학의)사전적으로는 시스템이나 소프트웨어의 요구사항을 정의하기 위해 사용자 요구사항을 조사하고 확인하는 과정 또는 사용자와 개발자 간에 합의된 개발 범위에서 시스템이 제공해야하는 기능이라고 정의하고 있습니다.
요구분석이 잘못되면 아무리 잘 만든 소프트웨어라고 하더라도 실패한 개발이 되어버립니다. 그러므로 사용자 요구를 정의하는 일은 소프트웨어 개발에서 아주 중요한 첫 번째 작업이라고 할 수 있습니다.
다시 요구분석을 정의하면 소프트웨어 개발 주기의 첫 번째 단계로 현 상태를 파악하고 사용자가 잠재적 또는 명시적으로 원하는 요구를 파악한 후 소프트웨어에 반영할 사용자 요구를 결정하는 것이라고 할 수 있습니다.
요구분석의 목적
개발 주기로서의 요구분석의 목적은 요구분석명세서를 산출하기 위해서입니다. 요구분석명세서는 요구분석 단계에서 생성되는 최종 산출물로 시스템의 기능이 무엇인가에 대해서만 초점을 두고 정리합니다.
어떻게 구현하는 가는 요구분석 단계 다음 단계인 설계 단계에서 설계서를 통해 이루어집니다.
요구분석의 어려움
문제 영역에 대한 분석가의 이해력 부족
소프트웨어 개발에서 분석가는 IT 전공자가 주를 이루므로, 개발을 요구하는 사용자 측(금융, 경제, 회계, 경영 등)의 지식이 부족한 경우가 많습니다. 이런 경우 때문에 요구분석 단계에서 의사소통이 원활하지 않을 수 있으며 이는 요구분석을 잘못 이해하는 경우가 생기기도 합니다.
문제를 해결하기 위해서는 해당 분야의 분석 경험이 많은 분석가를 프로젝트에 투입하는 것이 좋습니다.
사용자와 분석가의 의사소통 문제
소프트웨어 개발에서는 상상도/청사진/도면 등의 견본이 없기 때문에 사용자가 요구사항을 분석가에게 정확하게 설명하기가 어렵습니다.
사용자의 계속되는 요구사항 추가
처음 요구는 간단하고 적을 수 있지만 개발이 진행되가면서 점점 요구사항이 추가될 수 있습니다.
이러한 변경사항들을 제대로 기록하지 않으면 요구사항 간 충돌, 일관성 무시 등의 문제가 발생할 수 있습니다.
최근에는 다양한 개발 방법론들이 등장하면서 도중에 추가되는 요구사항에 유연하게 대처할 수 있는 방법들이 많아지고 있습니다.
사용자의 모호한 요구사항
모호한 요구사항은 여러의미로 해석될 여지가 많기 때문에 요구사항은 정확하게 전달되어야합니다. 분석가는 이러한 요구사항을 정확하게 조율하고 분석해서 정리할 수 있는 능력이 필요합니다.
다양한 사용자의 다양한 요구사항
사용자의 요구를 충분히 반영하고 산출물을 내도 사용자가 다르게 받아들일 수도 있습니다. 이때는 서로간의 의사소통이 중요합니다.
요구분석 절차와 요구사항 종류
요구분석 절차
요구분석 절차는 다음 순서대로 이루어집니다.
- 자료 수집: 현재 시스템 문제점 도출, 인터뷰, 설문 조사, 문서 검토 등을 통해 자료를 수집합니다.
- 요구사항 도출: 수집한 자료를 정리하고 분류해서 개발에 사용할 요구사항을 도출합니다.
- 문서화: 도출한 요구사항을 요구분석명세서로 만듭니다.
- 검증: 요구분석명세서를 가지고 사용자와 요구사항을 점검합니다.
요구분석 종류
사용자의 요구사항은 기능과 비기능 요구분석으로 나뉘어집니다.
기능 요구사항
기능 요구사항은 사용자가 원하는 기능을 의미합니다.
기능 요구사항을 만족시키기 위해 요구를 빠짐없이 도출하고 완전하고 일관성 있게 요구분석명세서에 기록합니다. 요구분석명세서에는 요구한 모든 기능이 포함되어있어야하고 요구사항 간에 모순이 존재해서는 안됩니다.
비기능 요구사항
비기능 요구사항은 수행 가능한 환경, 품질, 제약 사항 등을 의미합니다. 극지에서 실험하는데 사용되는 소프트웨어나 군사 작전 또는 병원 응급실 등에 사용되는 소프트웨어 같은 것이 비기능 요구사항을 중요하게 봐야하는 소프트웨어입니다.
제약 사항은 소프트웨어가 실행되는 환경 조건. 품질은 신뢰성, 성능, 보안성, 안정성, 편리성을 의미합니다.
요구사항 표현
요구사항이 정리가 되면 보기 편하도록 기록해야합니다. 이때 사용하는 기록과 표현 방법도 다양합니다.
모델
모델은 대상의 핵심 특징만 골라 특정 관점으로 단순화하고 기호나 그림을 이용해서 표현한 것입니다. 모델은 개발 전에 완성된 실제 모습을 미리 확인하고자 사용합니다. 또한 하나의 설계를 여러 관점에서 보고자할 때도 모델을 사용합니다.
소프트웨어 개발에서 모델을 사용하면 다음과 같은 장점이 있습니다.
- 이해도 향상
- 유지보수 용이
단점은 다음과 같습니다.
- 과도한 문서 작업으로 인한 개발 일정 지연
- 형식적인 산출물로의 전락 가능성
모델링
모델링은 모델을 제작하는 과정을 의미합니다. 소프트웨어 개발에서 모델링은 다음과 같은 방법을 사용합니다.
-
자연어 표현
기술이나 도구를 따로 익힐필요가 없지만, 표현이 애매모호해질 수 있습니다. -
형식 언어 표현
모호한 표현에서 벗어나 오류를 줄이고 내용 검증 가능하지만, 표기법을 별도로 학습해야 합니다. -
UML 다이어그램 표현
개발을 가시적으로 볼 수 있고 문서화가 가능합니다.
모델링 언어
모델링 언어는 모델링을 할 때 사용하는 표현 도구입니다.
구조적 방식의 DFD(자료 흐름도), 정보공학 방식의 E-R 다이어그램, 객체지향의 UML 표기법이 있습니다.
요구사항 문서화
요구분석 단계의 최종에서는 요구분석명세서가 산출됩니다. 요구분석명세서는 사용자에게는 계약서, 개발자에겐 설계와 구현을 위한 문서로 사용하기 때문에 개발과 관련되는 모든 이해 당사자간에 중요한 기준이 됩니다.
요구분석명세서를 작성할 땐 다음과 같은 주의사항이 있습니다.
- 사용자가 읽고 이해하기 쉽도록 작성
- 개발자가 설계와 구현에 효과적으로 사용할 수 있도록 작성
- 비기능 요구를 명확히 작성
- 테스트 기준으로 사용할 수 있도록 정량적으로 작성
- 품질에 대한 우선순위 명시
잘 만든 요구분석명세서의 특성은 다음과 같습니다.
- 완전성
기능과 비기능 요구사항을 빠짐없이 기록해야한다. - 일관성
상반된 요구사항이 없이 일관성을 띄어야한다. - 명확성
모호한 표현을 배제하고 표현을 명확히한다. - 추적가능성
오류를 찾아서 어느 단계에서 오류가 발생했는지 찾을 수 있어야한다. - 변경 용이성
요구사항은 변경이 쉽게 작성되어야한다. 즉, 변경 용이성이 좋으면 - 검증 가능성
시스템이 요구사항을 만족하는지 체계적으로 검증이 가능하다면 검증 가능성이 높다.
요구 명세 기법
비정형 명세 기법
자연어, 작업 흐름도와 같은 다이어그램으로 표현한다.
요구사항 작성이 쉽고 이해하기가 쉽다. 그러나 표현이 모호해 해석의 여지가 다를 수도 있으며, 일관성이 떨어지고 명세가 불충분할 수도 있다.
정형 명세 기법
수학적 원리와 표기법을 이용해서 표현한다.
요구를 정확하고 간결하게 표현할 수 있고 다양하게 요구사항을 검증할 수 있다. 하지만 표기법을 따로 배워야 제대로 이해하고 표현할 수 있다.
