요구사항 포착
Requirements를 다른 말로 specification이라고도 할 수 있다.
요구 사항을 들어준 것이 소프트웨어의 기능과 마찬가지이기 때문이다.
그렇기에 requirements를 정의하고 들어가는 것은 굉장히 중요하다.
그럼 requirements는 어떻게 찾을 수 있을까?
1. 단체가 현재 어떻게 돌아가고 있는지 이해해야 한다.
학교 관련 시스템을 개발한다고 해보자.
학교와 관련된 시스템을 만들기 위해서는 어떻게 돌아가는지를 알아야 하는데, 단순히 어떻게 돌아가겠지 하고 상상하는 것으로 학교가 어떻게 운영되고 있는지 알 수 없다.
직접 가서 학교가 어떻게 운영되고 있는지를 확인해봐야한다.▼
2. 현재 시스템의 문제점이 무엇일까?
문제점이 없는데 개선할 필요가 있을까?
새로운 기능, 새로운 시스템은 현재 시스템에 문제가 있기에 이를 해결하고자 만드는 것이다.
문제점 없이는 새로운 기능을 만들어봤자기에 문제점을 찾아야 한다. ▼
3. 현재 시스템에 없는 사용자 요구의 새 시스템은?
문제점을 찾았어도 그에 대한 해결책이 이미 있을 수 있다.
하지만 그 해결책이 완전하지 않기에 문제점으로 대두됐을 것이다.
거기서 개발자들이 필요로 하는 기능이 아닌 유저가 필요로 하는 기능을 알아야 한다.
그 중에서도 현재 시스템에 없는 유저의 요구를 알아야 한다.
“이것도 개발자가 해야하는건가요? 이런건 기획자가 하는거 아니에요?”
Requirement 찾는 일도 개발자가 하는 것이다.
기획자가 물론 어느정도 요구사항을 찾아서 기획을 해 오긴 하겠지만, 단순히 기획자가 만들어달라고 하는 것들을 만드는 존재가 되고 싶지는 않을 것이다.
개발자도 문제점에 대해 인식을 하고 있어야하고 그에 대한 사용자들의 요구사항도 찾아올 필요가 있다.
현재 시스템을 조사해야하는 이유들
현재 시스템을 조사해야하는 이유는 무엇일까?
어차피 기존 시스템을 버리고 새로운 시스템을 만들거면 굳이 현재 시스템에 대해서 알 필요가 있을까?
그 이유는 다음과 같다.
- 기존 시스템의 기능이 새 시스템에 사용될 수 있다.
- 기존의 시스템에 있는 데이터베이스 정보를 이전해야한다.
- 기존의 기술 문서들이 처리 알고리즘에 대한 정보를 제공해준다.
- 현재 시스템의 결점들을 다시 구현하지 않아야한다.
- 버그와 성능상의 문제가 Defect에 해당한다.
- 현재 직원들이 어떻게 작업을 하고 있는지에 대한 이해가 필요하다.
- 기존의 Baseline 정보가 새로운 시스템의 성능 목표를 설정하는것을 도와준다.
새로운 요구사항
기업들은 빠르게 변화하는 비지니스 환경에서 운영이 된다.
이 글을 작성하는 최근 시점에서는 인공지능이 뜨거운 감자로 각종 미디어에서 언급이 되고 있으며, 많은 서비스에서 인공지능 기능들을 사용하고 있다.
그런데 만약에 요즘 쇼핑몰들에서 인공지능 추천 기능이 없다면? OTT 서비스에 추천 기능이 없다면?
사람들은 그 서비스를 사용하지 않을 것이다. ▼
기업들은 빠르게 변화하는 하드웨어 환경에서 운영이 된다.
하드웨어 성능도 계속해서 증가하고 있고, 특히나 애플의 M1, M2칩, NVIDA의 RTX3000번대와 4000번대 그래픽 카드는 그 성능이 폭발적으로 증가했다.
게다가 이런 프로세서들 외에도 USB타입의 변화, A타입에서 C타입으로의 변화와 같은 것들도 있다.
기업들은 정부나 기관의 규제에 따라 운영이 된다.
규제에 관한 요즘 가장 뜨거운 주제는 EU의 아이폰 C타입 규제가 있을 것이다.▼
이런 규제 외에도 정부에서 법을 제정하게 되면, 제 아무리 거대한 기업이라도 그 법에 따라야 한다.
GPT의 경우에도 현재는 별 규제없이 운영이 되고 있지만, 저작권 문제가 발생하여 각 국 정부가 규제를 하기 시작하면 그 몸집도 수그러들 수 있을 것이다.
TV 드라마에 나오는 PPL도 이런 규제로 막혀있다.
PPL로 나오는 옷들을 스마트 티비를 통해 클릭 한 번에 구매할 수 있는 서비스를 개발하면 떼돈을 벌지 않을까 하는 생각을 해봤을 것이다.
꽤나 좋은 아이디어인데 왜 아무도 만들지 않았을까?
이는 법적으로 규제되어있기 때문이다.
이런 예시와 같이 서비스를 만들기 위해서는 만들고자 하는 서비스가 법적으로 막혀있지는 않은 지 확인해볼 필요가 있기에 그 절차가 굉장히 복잡해질 수 있다.
요구사항의 타입
Functional
Function이라고 하면 함수도 맞지만, 여기서는 기능이라고 생각하면 편할 것이다.
요구사항에서 기능 부분을 작성할 때는 사용자가 할 수 있는 기능, 행동들을 작성하고, 어떤 데이터를 처리하는지에 대해서도 작성을 해야한다.
또한 이 역시도 함수단위로 구현이 되기 때문에 인풋과 아웃풋도 작성을 해야한다.
어떤 데이터가 들어가면 어떤 데이터가 산출되는지에 대한 것도 작성을 해야한다.
Input
키보드, 마우스, 스크린 터치, 파일 읽기, 네트워크로 파일 받아오기, 센서, VR 조종, 등등
output
화면 출력, 파일로 쓰기, 네트워크로 파일 주기, 등등
이런 기능들은 다이어그램으로 표현한다.
Non-functional
기능을 얼마나 잘 제공하는지를 말한다.
Performance criteria (response times)
Performance criteria는 직역하면 성능 기준이다.
이 기능이 어느정도의 성능을 낼 수 있는지를 이야기하는 것이다.
그 중에서도 반응 속도에 대한 성능 기준을 말한다.
수강 신청 시스템을 예로 들어보겠다.
수강 신청 인원을 1만명이 동시에 할 수 있게 하겠다! 라고 해보자.
그렇다면 이는 기능인가?
여기 중 기능은 수강 신청 이라는 단어이고, 1만명이 동시에 할 수 있게는 그 기능의 성능을 나타내는 수식어 정도가 될 것이다.
1만명이 동시에 할 수 있게는 스펙은 맞지만 기능은 아니다.
그 중에서도 1만명이 동시에가 Performance criteria가 말하는 부분이다.
Anticipated volumes of data
Anticipated volumes of data는 처리하는 데이터의 양을 말한다.
위의 예시를 그대로 따오면, 수강 신청 인원을 1만명이 동시에 할 수 있게 하겠다에서 1만명을 말한다.
이 정도의 데이터를 처리하는 시스템을 만들거다라는 말이며, 이것또한 스펙은 맞지만 기능은 아니다.
Security considerations
보안에 대한 이야기인데, 이는 기능자체에는 직접적인 영향을 주지는 않는다.
보안이 허술하다고 수강신청 기능 구현이 불가능한 것은 아니기 때문이다.
허술한 보안에 대해서는 나중에 생각할 부분이긴 하지만 보안이 좋은지 나쁜지에 따라 내가 쓰는 기능이 달라지는 건 아니다.
위의 정보들은 다이어그램으로 그리기 보다 글로 적는다.
Usability Requirements
이는 얼마나 사용하기 쉬운지, 사용할 만 한지를 말한다.
유저 친화적인가에 대한 내용이다.
“Usability = User’s acceptability”
유저가 얼마나 받아들일 수 있느냐로도 말할 수 도 있다.
예를 몇 개 들어보자.
주식 시장의 모니터는 굉장히 크다.
그리고 이 모니터에 굉장히 큰 글씨로 주식 현황에 대해 알려준다.
이 모니터가 일하는데 쓰이는 것은 공공연하게 아는 사실이다.
하지만 일하는데는 “모니터 한 화면에 최대한 많은 정보를 담는게 좋겠지?” 라는 생각으로 모니터의 폰트를 줄여버리면 주식 시장에서 일하는 사람들의 업무 효율을 떨어뜨리게 된다.
아니면 오히려 반대로 “일반 사무직에 사용되는 프로그램에서 글씨가 크게 보이면 좋겠지?” 라는 생각으로 폰트를 키워버리면 업무 효율이 떨어지게 된다.
게임은 일반적으로 취미활동이며 시각적이든 청각적이든, 감각적 즐거움을 위해 하는 경우가 많다.
그런데 캐릭터가 말이 엄청나게 많고 실제로 유저가 플레이 하는 시간이 적으면 별로 하고 싶어하지 않을 것이다. ▼
노인을 위한 앱인데 폰트가 굉장히 작고 버튼도 작다면 노인 입장에서 쓰기 힘들 것이다.
그래서 이런 상황을 방지하기 위해 프로토 타입을 만들어서 테스트를 해야한다.
Fact Finding Techniques
Background Reading
조직, 비지니스의 목표가 무엇인지를 파악하는 것을 말한다.
Background를 파악하기 위해 아래의 것들을 참고할 수 있다.
- reports
- organization charts
- policy manuals
- job descriptions
- documentation of existing systems
이걸 읽고 어떤 조직이고 목표가 뭔지를 파악한다.
컨설팅 회사가 주로 이런 일들을 한다고 한다.
그런데 Background Reading을 하면 그 조직에 대해 다 알 수 있는 것일까?
장점
- Background Reading은 팩트 파인딩 하는 것들을 도와준다.
사람을 만나기 전에 그 사람이 속한 단체에 대한 지식을 가질 수 있다는 장점이 있다.
단점
- 하지만 시간이 오래된 문서가 많아서 위의 정보들을 다 믿을 수 없다.
2023년에 2016년 기사를 읽고 해당 단체에 대해 이해해봤자, 이미 그 단체는 방향성을 바꾸고 다른 일을 하고 있을 지도 모른다.
"그렇다면 해당 단체에 대해서 확실하게 알기 위해선 어떻게 해야할까?"
Interviewing
단체에 대한 이해를 심도있게 해주는 것으로는 인터뷰가 있다.
다른 뜻이 있는게 아니라 말 그대로 인터뷰 하는 것을 말한다.
인터뷰를 하는 이유는 해당 단체에 대한 심도있는 이해를 하기 위함이다.
앞에서 봤던 Background reading은 단체에 대해 개괄적으로 알아내는 것이다.
"그렇다면 누구와 인터뷰를 할까?"
인터뷰 대상
- 매니저
- 실제 일하는 스태프
- 고객이나 잠재적 고객들이 일반 대중
꼭 해당 업계에서 일하고 있는 사람과 인터뷰를 하는 것이 아니라 제품을 사용하는 고객과 잠재적 고객들과 같은 일반 대중들과의 인터뷰도 필요하다.
이를 잘 보여주는 사례는 아래와 같다.
홈 네트워킹을 할 때에는 광 케이블을 이용하는 것이 보안에도 좋고 설치에도 용이하다.▼
선이 조금 보인다는 것이 단점이지만, 이 역시도 설치 과정에서 선을 감쪽같이 숨길 수 있다.
홈 네트워킹을 할 때는 무선보다 광케이블이 보안에도 좋고, 설치에도 용이하다.
따로 페어링이나 별도의 연결이 필요없기 때문이다.
엔지니어들은 당연히 이 방식이 기능상 더 좋으니 많은 사용자가 사용해줄 것이라고 생각 했는데, ▼
인터뷰를 해보니 일반 사용자들은 싫다는 의견이 많았다고 한다.
어째서인지 그 이유를 물어봤더니 그냥 선 있는게 지저분해보여서 싫다는 의견이 대다수였다고 한다. ▼
광케이블의 장점에 대해 이야기를 했지만 사용자들은 광케이블로 설치를 하게 되면 설치를 안할 거 같다는 의견을 내보였고, 결국에는 무선으로 경로를 바꿨다고 한다.
이렇듯 실제 고객들은 생각이 다를 수 있다.
기술이 아무리 좋아봤자 고객들이 싫어하면 말짱 꽝이 된다.
만약에 인터뷰를 안하고 엔지니어들의 의견대로 유선으로, 광 케이블로 냈다면 아마 제품을 구매하는 소비자는 없었을 것이다.
장점
- 인터뷰에 나온 대답에 맞춰 기존의 제품을 깊이 있게 수정할 수 있다.
단점
- 인터뷰를 하는데에 시간이 오래 걸린다.
시간 뿐만 아니라 전체적인 비용이 많이 들어가게 된다. - 인터뷰가 한 쪽으로 치우칠 수 있다.
위의 예시로 다시 예를 들면, 고객이 원하는 것이 광케이블인 것 처럼 유도할 수 있다. - 고객들의 답변에 통일성이 없으면, 어떤 방향성이 옳은 건 지 결정을 쉽게 내릴 수 없다.
적용
인터뷰는 처음부터 바로 시작하는 것이 아니라, 어느정도 제품이 완성되고 자료가 쌓여 충분히 준비 됐을 때 시작한다.
Observation
관찰로, 뜻 그대로 실제로 확인하는 것을 말한다.
사람들이 어떻게 프로세스를 수행하는지, 쉽게 말하면 제품을 어떻게 사용하는지 혹은 발전을 위해 새 시스템에서 제공하는 데이터를 얻는 행위를 말한다.
예를 들어서 수강신청이라고 했을 때, 수강신청을 1000명까지 가능한다고 하면 이를 직접 가서 정말로 1000명까지 가능한지 확인하는 과정을 말한다.
장점
- 시스템이 실제로 어떻게 동작하는지 확인할 수 있다.
- 정보 검증도 가능하다.
- baseline data를 수집할 수 있다.
단점
- 실제 사용이 왜곡될 가능성이 있다.
- 누가 보고 있으면 수행 능력이 저하되거나 향상되는 사람들이 있는 것 처럼, 관찰할 때만 그렇게 행동/사용 하고 관찰하지 않을 땐 다르게 사용할 가능성도 있다.
적용
관찰을 하면 정보를 정확히 얻을 수 있지만, 항상 사용하기 보다는 상충되는 정보들이 있을 때 어느 것이 맞는 지 확인할 때 사용하는 것이 좋다.
Questionnaires
설문조사 하는것을 말한다.
굉장히 많은 사람들의 의견을 모으고 싶을 때 여러 사람들의 의견을 모으고 통계적으로 분석하여 하나의 자료로 사용한다.
설문 조사를 할 때는 웹이나 이메일을 통해 최대 다수에게 물어본다.
설문 조사 시에는 사실 뿐만 아니라 의견도 수집할 수 있다.
장점
- 경제적이다.
여러 사람에게 이메일을 보내거나, 웹사이트를 만들어 배포하는 것은 인터뷰에 비해 비용이 많이 들어가지 않는다.
인터뷰는 1:1인 반면 이 방법은 1대 다수이기 때문이다. - 전세계에 떨어져 있는 사용자들에게 의견을 묻고 싶을 때 유용하다.
단점
- 좋은 질문을 만들기 어렵다.분석하기 좋은 질문을 만드는 것이 쉽지 않기에 질문 제작 자체에 어려움이 생긴다.
좋은 질문은 분석하기 쉬운 질문을 말한다. - 조금 더 깊이 물어보는 작업을 수행하기 쉽지 않다.
질문들이 무거워지면 사용자들이 답변에 어려움을 겪는다.
적용
굉장히 많은 사람의 의견을 묻고 싶을 때 사용을 한다.
지역적으로 분산되어있는 경우에도 웹과 이메일의 특성을 이용하여 유용하게 사용할 수 있다.
customized된 프로그램보다는 generic프로그램에 좀 더 적합하다.
유저 프로파일링에도 유용하여 유저 프로파일링이 필요한 경우에도 사용하면 좋다.
마치며
이렇게 위의 4가지 방법으로 requirement를 찾는 것이 requirement capture다.
유저들이 좋아하는 스펙을 찾는게 쉽지 않기에 많은 시간과 기술이 들어가는 작업이다.
'CS > 소프트웨어 공학' 카테고리의 다른 글
| 10. 객체 지향 프로그래밍 (Object-Orientation Programming) (0) | 2024.01.31 |
|---|---|
| 9. 요구사항 문서화 (0) | 2024.01.29 |
| 7. Modeling Concepts (0) | 2024.01.26 |
| 6. Agile (0) | 2024.01.21 |
| 5. Process Iteration (0) | 2024.01.21 |
