정보처리기사 PART 1 정리 - 요구사항

1. 요구사항

문제를 해결하고 목적을 달성하기 위하여 고객의 요구 또는 명세나 표준을 만족하기 위하여 시스템이 가져야 하는 서비스또는 제약사항을 요구사항이라 부릅니다.

 

요구사항을 파악하기 위해서는 시스템의 요구사항에 대한 파악을 기본적으로 해야하며, 기능적 요구사항과 비기능적 요구사항으로 요구사항이 분리됩니다.

 

- 기능적 요구사항

 기능적 요구사항은 시스템이 제공하는 기능과 서비스에 대한 요구사항입니다. 즉, 특정 입력에 대해 시스템이 어떻게 동작하고 반응하는지를 기술합니다. 기능적 요구사항에서는 기능성, 완전성, 일관성이 지켜져야합니다.

 

- 비기능적 요구사항

 비기능적 요구사항은 기능적 요구사항에서 다루는 내용 이외의 사항이나 시스템 구축에 대한 제약사항에 대한 요구사항입니다.  시스템이 준수해야할 제약조건과 품질과 관련된 시스템이 갖춰야할 사항을 기술합니다. 비기능적 요구사항에서는 신뢰성, 사용성, 효율성, 유지보수성, 이식성이 비기능적 요구사항에서는 지켜져야합니다. 

 

 

기능적 요구사항에서 지켜져야하는 특징인 기능성, 완전성, 일관성과 비기능적 요구사항에서 지켜져야 되는 신뢰성, 사용성, 효율성, 유지보수성, 이식성은 암기해두면 두 방법을 이해하는데에 큰도움이 됩니다.

 

 

2. 요구사항 개발 프로세스

 

도출, 분석, 명세, 확인 총 4단계의 순서로 요구사항 개발 프로세스가 진행됩니다.

 

- 도출 (Elicitation)

도출은 요구사항이 어디에 있는지 확인하고, 수집방법을 파악하는 단계입니다. 이해관계자는 도출된 정보를 가지고 요구사항을 식별하고, 개발팀은 고객과의 효율적인 의사소통을 하기 위해 필요한 단계이기도 합니다. 

 

요구사항에서 가장 중요하게 봐야할 부분은 도출기법입니다.

첫번째 도출기법은 인터뷰입니다. 인터뷰는 1:1 관계에서 사용자와의 대화를 통해 시스템 요구사항을 추출하는 방법입니다.

두번째 도출기법은 설문조사입니다. 설문지나 여론조사를 통해 다수의 의견을 수집하기 때문에 많은 데이터를 다른 기법보다 간편하게 얻을 수 있다는 특징이 있습니다.

다음 도출기법은 브레인 스토밍입니다. 브레인 스토밍이 효율적이기 위한 전제조건으로는 말을 꺼내기 쉬운 분위기의 회의여야만 한단는 것입니다. 그런 분위기에서 상대방의 아이디어를 비판보다는 긍적적으로 수용하는 방법입니다.

마지막 도출기법은 워크숍입니다. 프로젝트의 핵심인물이 참여하여 짧은 기간동안 전문적인 정보를 공유하는 방식으로 단기간이기 때문에 집중하는 노력이 필요하지만 그만큼 짧은 시간안에 지식을 얻을 수 있다는 장점을 가지고 있습니다.

 

도출 단계의 산출물로는 요구사항 소스와 도출기법이 나옵니다.

 

- 분석 (Analysis)

서로 상충되는 요구사항을 해결하기위해 필요한게 바로 분석단계입니다. 분석 단계에서는 소프트웨어의 범위를 파악을 통해 어떤 상황에서 소프트웨어가 동작하고 어떻게 상호작용하는지 이해하는 과정입니다.

 

요구사항 분석은 두 가지 기법으로 분류됩니다.

자료 흐름 지향 분석 기법은 시스템 구성요소 프로세스와 다른 프로세스 간 데이터 흐름을 표현하는 DFD(Data Flow Diagram)에서 소프트웨어 구조를 유도하는 방식입니다.

객체지향 분석 기법은 시스템의 기능과 데이터를 함계 분석해 소프트웨어 공학에서 사용되는 표준화된 범용 모델링 언어인 UML(Unified Modeling Language)로 표준화 변환을 하는 방법이 있습니다. 

 

분석 단계는 요구사항을 분류와 개념모델링, 기술 구조의 설계 및 요구사항의 할당 마지막으로 요구사항 협상이 진행됩니다. 

 

- 명세 (Specification)

 명세 단계에서는 체계적인 검토와 평가되며 승인 받을 문서를 작성하는 단계로 시스템 정의를 하고 시스템 요구사항과 소프트웨어 요구사항을 작성하는 단계입니다.

 

요구사항 명세 기법은 사람의 이해도에 따라 분류됩니다.

자연어에 의한 방법은 사용자, 개발자와 같이 사람들이 이해하기 쉽지만 명확성 검증에 있어서는 문제가 발생할 수 있습니다.

그 반대의 방법은 정형화 기법 사용 방법 입니다. 이 방법을 이용하면 명확성과 검증에는 용이하지만 기법을 이해하기 어려워 사람들이 이해하지 못합니다.

 

명세 단계의 산출물로는 시스템 정의성와 시스템 요구사항 명세서, 소프트웨어 요구사항 명세서 등 명세서와 관련된 모든 자료가 나오게 됩니다.

 

- 확인 (Validation) 

 마지막으로 진행되는 요구사항의 확인 단계에서는 요구사항 문서가 표준에 적합한지 확인하며, 문서가 이해가능하고 일관성이 있는지 완전성을 검토하는 단계입니다.

 

요구 사항 확인 기법의 경우 3가지 진행방식이 존재합니다.

첫번째 방식은 동료검토(Peer Review)입니다. 2명에서 3명 사이의 적은 인원이 모여 진행하는 리뷰 형태로 명세서 작성자의 설명을 직접 들으며 결함이 발견되는지 확인합니다.

두번째 방식은 워크 스루(Walk Through)입니다. 오류를 초기에 검출하기 위해 진행되는 방법으로 회의가 시작되기 전에 검토 자료 배포를 통해 미리 검토 자료를 숙지하고 짧은 시간의 회의를 통해 오류를 검출하는 방법으로 최종적으로 문서화합니다.

마지막으로 소개할 방식은 인스펙션(Inspection)입니다. 인스펙션 방식은 소프트웨어 요구, 설계, 원시 코드 등의 저작자를 제외한 다른 전문가나 팀이 개입해서 오류를 찾아내는 방법입니다.

 

확인 단계에서는 검토와 프로토 타이핑, 모델검증과 인수테스트가 진행이 됩니다.

 

 

요구사항 개발 프로세스에서는 반드시 알아야할 내용을 정리하면 다음과 같습니다.

도출단계의 기법인 인터뷰, 설문조사, 브레인 스토밍, 워크숍이 어떤 방식으로 진행되는지 알아야합니다.

또한 확인단계에서 사용되는 기법인 동료검토와 워크 스루, 인스펙션도 반드시 구분하고 어떻게 진행되는지 알아놓으시면 시험 기출 문제를 푸는데 큰 도움이 됩니다.

 

 

3. 비용산정 모델

소프트웨어의 규묘 파악을 통해 투입할 자원과 소요 시간을 파악하고 실행가능한 계획을 수립하기 위해서는 비용산정 모델을 통해서 이 프로젝트에 들어갈 비용을 구해야합니다. 

 

비용산정 모델은 전문가의 도움이 필요한 하향식과 세부적인 요구사항을 통해 구하는 상향식 산정방법으로 분류가됩니다.

 

- 하향식 비용산정 모델

하향식 산정방법은 위에서 이야기 한대로 경험이 많은 전문가에게 비용산정을 의뢰를 하거나 여러명의 전문가와 조정자를 통해 비용산정을 하는 두가지 방법이 존재합니다.

 

두가지 방법 중 조직 내의 경험이 많은 두명 이상의 전문가에게 의뢰하는 방식은 전문가 판단 기법이라 불리며 분위기나 편견에의해 결과가 바뀌지 않도록 여러명의 전문가와 한사람의 조정자가 자신의 경험이 담긴 지식을 바탕으로 문제를 해결하고 미래를 예측하는 방법을 델파이 기법이라 이야기합니다.

 

- 상향식 비용산정 모델

상향식 비용산정 방법은 요구사항과 기능을 포함한 계산식을 이용해 프로젝트에 필요한 비용을 구하는 방법입니다. 

 

상향식 비용산정 모델은 5가지 방법이 존재합니다.

 

첫번째 방법인 LoC(Lines of Code)는 소프트웨어 각 기능의 라인 수에 대한 비관치와 낙관치, 중간치를 이용해 예측치를 구하는 방법입니다. LoC방법은 라인을 기반으로 한 방법이며 계산식이 이해하기가 쉬워 자주쓰이기도합니다. 식을 계산하면 결과 값으로 생산성과 노력, 개발 기간에 대한 비용을 구할 수 있습니다.

 

식에 사용되기 위해 구해야하는 낙관치는 가장 적은 코드의 라인 수이며 비관치는 그와는 반대되게 가장 많이 측정된 코드의 라인 수입니다. 중간치는 모든 코드의 평균을 이야기합니다.

 

두번째 방법은 Man Month입니다. 시험에서 계산 식으로 자주등장하는 Man Month는 한 사람이 한달동안 할 수 있는 일량을 기준으로 프로젝트의 비용을 산정합니다.

 

한달의 코드수를 한 사람의 월간 생산성으로 나눈값을 Man Month라 부르며 프로젝트의 총 인력으로 Man Month를 나눈 값으로 프로젝트 기간을 구할 수 있습니다.

• Man Month = LoC ÷ 한 프로그래머의 월간 생산성
• 프로젝트 기간 = Man Month ÷ 프로젝트 총 인력 

 

세번째 방법은 COCOMO방식입니다. COCOMO는 COnstructive COst MOdel의 약자로 개발 노력의 승수를 결정하는 방식입니다. 프로그램 규모에 따라 단순형, 중간형, 임베디드형으로 나눠 비용을 산정하는 이보헴(Bohem)이 제안한 모형입니다.

 

단순형(Organic Mode)은 기관 내부에서 만들어진 중 · 소규모의 소프트웨어로 5만 라인 이하의 소프트웨어 입니다. 단순형은 일괄 자료처리나 과학 기술 계산과 비즈니스 자료 처리 개발에 적용됩니다.

 

중간형(Semi-Detached Mode)은 말 그대로 단순형과 임베디드의 중간을 말합니다. 30만 라인 이하의 소프트웨어를 개발하는 유형으로 트랜잭션 처리 시스템이나 운영체제 데이터베이스 관리 시스템 개발에 적용됩니다.

 

가장 큰 유형인 임베디드형(Embedded Mode)은 30만 라인 이상의 소프트웨어를 개발하는 유형입니다. 이 개발 방법은 초대형 규모의 트랜잭션 처리 시스템이나 운영체제 개발에 적용됩니다.

 

네번째 방법은 푸트남(Putnam)모형입니다.  푸트남 모형은 소프트웨어 개발 주기별로 요구할 인력 분포를 가정하는 모형입니다. 이때 사용하는 자동화 추청 도구로는 SLIM이 있습니다.

 

마지막 방법은 기능점수(Function Point)모형입니다. 요구기능을 증가시키는 인자에 가중치를 부여해 기능의 점수를 계산하는 방식입니다. 소프트웨어의 규모를 입력, 출력, 정의, 파일, 인터페이스의 개수로 표현합니다. 원시코드 구현에 이용되는 프로그래밍 언어와 독립적이며 경험을 바탕으로 단순, 보통, 복잡한 정도에 따른 가중치를 부여합니다. 또한 프로젝트의 영향도와 가중치의 합을 이용하여 기능점수를 계산할 수 있습니다.

 

기능점수를 구하는 방식중 정규법은 각 기능 속성을 정의한 후 기능적 복잡도에 의한 기능 점수를 산정하는 방식으로 진행되며 이 계산식을 통해 상세한 기능점수 측정이 가능합니다.  

 

다른 방식인 간이법은 사용자의 요구사항을 바탕으로 기능점수를 도출하는 방법입니다. 평균 복잡도에 의한 기능 점수를 산정합니다. 이 방법을 통해서는 프로젝트 초기의 개발비용을 측정할 수 있습니다.

 

 

시험을 준비하기 위해 비용산정 모델에서 알아둬야 할 내용은 하향식 비용산정 모델의 전문가 판단기법과 델파이 기법의 정의를 이해해야합니다.  상향식 비용산정 방법에서는 비용산정 모델 5가지를 구별할 수 있어야 하며 LoC와 Man Month의 계산식은 한번씩 직접 문제를 풀어보시는거를 추천합니다. 또한 COCOMO방식에서 프로그램의 규모를 나누는 기준을 암기하셔야합니다.