이건 기능이 아닌데
2009/08/03 23:14 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
의례 스펙, 기능요구사항 등을 정리한 문서를 보면 기능만 잔뜩 나열되어 있는 것은 매우 흔한 일입니다.
RSS Feed
의례 스펙, 기능요구사항 등을 정리한 문서를 보면 기능만 잔뜩 나열되어 있는 것은 매우 흔한 일입니다.
소프트웨어를 만든다고 하면 구현해야 할 기능만 알면 제대로 잘 만들 수 있을 것으로 생각하기 십상입니다. 상식적으로 생각해도 기능면 제대로 구현하면 되겠지요. 여기에 UI는 살짝 추가하고요.
하지만, 분석을 할 때 기능보다 더 중요한 것이 비기능 요구사항입니다. 즉, 기능은 아닌데, 요구사항 즉, 스펙인 겁니다. 기능이 중요하기는 하지만, 기능 하나가 잘못되면 이를 고치는 것은 그렇게 어렵지 않습니다. 그런데 비기능에서 잘못되면 소프트웨어를 완전히 뒤엎어야 하는 일이 발생할 수도 있습니다.
이렇듯 비기능이 기능보다도 더 중요한 측면이 있는데, 눈에 바로 보이지 않는 다는 이유로 간과되기 쉽습니다. 그럼 이렇게 중요한 비기능 요구사항에는 어떤 것들이 있는지 몇 가지만 알아 보겠습니다.
첫째 성능입니다. 소프트웨어가 얼마나 빨리 반응을 보이며 단위 시간당 얼마나 많은 데이터를 처리해야 하는지 정의해야 합니다. 또한 이를 검증하기 위한 기준도 마련이 되어야 합니다.
둘째 안정성입니다. Database와 위젯 시계는 요구되는 그 안정성이 다릅니다. Database는 시스템이 정전이 되어도 데이트가 파손이 되어서는 안됩니다. 그러한 안정성을 보장하기 위한 요구사항도 자세히 기술이 되어야 합니다.
셋째 보안입니다. 데이터는 암호화 되어서 저장이 되어야 하는지? 암호키는 어떻게 보관을 하는지? 프로토콜은 암호화 되어야 하는지? 시스템은 인증을 거쳐서 접근해야 하는지? 등등의 보안 요구사항은 각 소프트웨어마다 다른 요구사항을 가지고 있습니다.
그 외에도 많은 비기능 요구사항은 있습니다. 가용성은 시스템이 24시간 동작하는 것인지 MS-Word처럼 필요할 때 사용하고 종료하는 것인지 기술합니다. 또, 이식성은 현재 지원해야 하는 것이 아니고 향후 미래에 Porting을 하기 용이하도록 만들기 위한 요구사항입니다. 미래에 Windows에서 Linux로 포팅을 할 수도 있고, 여러 언어를 지원하도록 확장할 수도 있습니다. 또 64bit를 지원할 수도 있고, Unicode를 지원하게 될 수도 있습니다. 따라서 미래에 어떻게 할지 계획이 아무것도 없다면 이식성을 정의할 수가 없습니다. 다국어, 개발표준, 메모리 사용제한, 소스코드 재사용성, 유지보수 편의성 등 많은 비기능 요구사항이 있습니다.
딱 보시면 아시겠지만, 하나하나가 잘못 적히면 완전히 소프트웨어 전체를 뒤집어야 하는 것들입니다. 이런 것들이 눈에 보이지 않는다고 기능만 보고 제품을 만들었다가는 앞은 안보고 땅만 보고 달리는 자동차와 같습니다. 조금만 고개를 들면 보이는 막다른 골목으로 가고 있을지도 모릅니다.
기능 신경쓰기도 바쁜데 이러한 수많은 비기능까지 어떻게 신경을 써서 만드냐고요?
그럼, 신경 안쓰고 그냥 만들면 그 요구사항이 사라지나요? 무시된겁니다. 요구사항을 고스란히 남아 있고 나중에 비용을 수십,수백,수천배를 치러야 합니다.
비기능 요구사항을 잘 적는 방법은 그러한 비기능 요구사항에 대하여 경험이 있을 수 있도록 소프트웨어를 개발한 상당한 경력이 필요하고, 적는 방법에 대하여 배우거나 학습이 필요합니다. 또, 이런 과정을 통해서 과거에 간과된 비기능 요구사항이 현재 얼마나 많은 손해를 끼치는 깨우치면서 배워나가게 됩니다. 하지만 이런 과정을 거쳐야 시행착오가 최소화 되지, 비기능 요구사항을 고려하지도 않는다면 항상 바쁘고 앞으로 잘 나아가지 못하는 굴레를 벗어나기 어려울 겁니다.
이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
'프로젝트 > 요구사항분석' 카테고리의 다른 글
| 개발문서를 만들기는 했는데 업데이트가 안되는 이유 (16) | 2010/03/24 |
|---|---|
| SRS에 대한 인식의 변화 (10) | 2009/11/13 |
| 이건 기능이 아닌데 (4) | 2009/08/03 |
| 고객이 요구사항을 너무 자주 바꿔요. (4) | 2009/07/30 |
| Track me, if you can (0) | 2009/05/04 |
| 개발자들이 바글바글한 외딴섬에 떨어진다면 (20) | 2009/04/22 |
Trackback Address: http://allofsoftware.net/trackback/136
비기능이라고 해서 무슨 개념인가 했는데
정말 기능보다 더 중요한 내용들이군요.
그나저나.. 멀티플랫폼은 개발자의 악몽이죠 ㅋ
구차니님 안녕하세요.
멀티플랫폼 개발을 하고 있다면 중요시 되는 비기능들이 더욱 많죠. 멀티플랫폼은 개발, 빌드, 테스트에 더 많은 시간은 들어가지만 익숙해지면 크게 문제 없지 않나요? 개발자에게는 좋은 경험이죠.
기능제공을 잘 하는 것도 중요하지만 RFP를 잘 분석하고 클라이언트와 미팅을 잘해서 리스크가 될만한 것들을 모두 정리한 다음에 명확하게 계약서와 SoW를 작성해서 '사인 받는게' 중요한 것 같습니다.
그러지 않으면 끝없이 이어지는 고객의 추가요구사항을 감당해 낼 수가 없지요.
특히 개발자들이 약한 부분이 클라이언트와의 미팅 후 회의결과 정리 및 쌍호간 확인싸인 하기, 이거 정말 중요합니다.
우울한딱따구리님 안녕하세요.
우리나라 고객들은 왠만하면 사인을 잘 안하려고 하지만, 그래도 회의록 작성하고 사인하고 사인하지 않더라도 배포만 하는 것도 나름 효과는 있죠. 계약할 때 SRS와 ATP를 첨부하는 외국과는 아직 거리는 멀죠.