Software Engineering

사용자 요구 사항

taey 2024. 10. 26. 18:08

요구 사항 개요

요구 사항의 특징

  • 요구 사항 : 소프트웨어 시스템이 수행해야 할 것과 소프트웨어 시스템에 있어야 할 특성을 기술한 문장
  • 특성 
    • 전체 소프트웨어 개발 수명주기에서 가장 중요한 요소, 소프트웨어 개발의 기준
    • 다양한 스테이크홀더로부터 도출, 소프트웨어가 무엇을 해야 하는가를 표현
    • 초기 시스템 요청보다 상세한 요구사항 목록으로 구체화
    • 기능적인 요구사항, 비기능적 요구사항
    • 소프트웨어에 대한 품질 요소 포함 가능
    • 고객과 개발자 간 의사소통의 수단, 분석 과정과 설계 과정을 거치며 지속적으로 변화
    • 요구사항의 문제점을 늦은 단계에서 발견하면 이를 수정하기 위한 많은 비용 발생
    • 프로젝트 실패의 가장 중요한 이유 : 명확하지 못한 요구사항 정의 

요구사항의 분류

  • 기능적 요구사항
    • 사용자의 업무 처리와 직접 관련되어 소프트웨어 시스템이 수행해야 하는 요구 내용
    • 소프트웨어 개발에서 반드시 구현되어야 하는 항목
    • 예) 성적 처리 소프트웨어 : 석차를 구하거나 등급을 부여하는 기능
      • 기능성(Functionality) : 시스템이 해야 하는 것은 무엇인가?
      • 데이터(Data) : 시스템의 입력과 출력 데이터는 무엇이고, 그 형식(formats)은 어떻게 정의되는가?
      • 사용자(Users) : 시스템을 사용하고 관리하는 사람은 누구인가?
  • 비기능적 요구사항
    • 소프트웨어 시스템이 제공해야 하는 행위적 속성
    • 운영 요구사항 : 윈도우, 리눅스, Max OS에서 동작 가능해야 함. 문서 형식에 제한받지 않고 사용 가능함. JPEG, GIF, BMP의 그래픽 파일을 처리 가능해야 함
    • 자원 요구사항 : 소프트웨어 실행을 위해 최소한의 메모리를 제공해야 함. 터치 스크린 등 다양한 방식의 입력 장치를 제공해야 함, 음성 출력 장치를 제공해야 함
    • 성능 요구사항 : 질의에 대한 응답 시간은 1초를 넘지 말아야 함, 데이터베이스는 실시간 업데이트가 가능해야 함
    • 보안 요구사항 : 사용자 유형별 접근 권한을 제한해야 함, 저장되는 데이터는 암호화해야 함
    • 문화적/정책적 요구사항 : 한글과 영어를 지원, 모든 날짜의, 표기는 MM/DD/YYYY의 형식, 도덕적 • 법적 문제를 일으키지 말아야 함
  • 인터페이스 요구 사항
    • 시스템을 사용하는 과정에서 지원해야 하는 GUI 요구 사항
      • 표준 인터페이스 구조를 정의하고 모든 소프트웨어 개발 과정에서 이러한 표준을 따르도록 함
    • 시스템이 수행하는 과정에서 발생할 수 있는 기존 시스템과의 연동 요구사항
  • 기타 제약 사항
    • 조직의 지침에 대한 적용의 필요성
    • 국내, 국제 표준(Standards)에 대한 적용 필요성

 

 


요구사항 정의 품질

요구 사항 정의 시 나타나는 치명적 과실

  • 노이즈 발생 : 관련 없는 정보가 포함되거나 모호한 표현이 존재하는 경우
  • 침묵 발생 : 언급되어야 할 사항이 누락되는 경우
  • 과도한 스펙 명세 : 아직 결정되지 않는 구현 관련 사항이 포함되는 경우
  • 모순 발생 : 전후 내용에 일관성이 없는 경우
  • 모호성 : 하나의 표현이 여러 가지 의미로 해석되는 경우
  • 전방 참조 : 아직 정의하지 않은 사항을 앞서 참조하는 경우
  • 사실이 아닌 기대 사항 : 사실에 근거하지 않고, 막연한 추측과 기대에 근거하는 경우 

 

요구 사항을 정의하는 문서에 대한 품질 요소

  • 정확성을 갖춘 문서
    • 스테이크 홀더가 원하는 모든 요구가 정의되었고, 이 요구들이 구축하는 시스템의 기능으로 모두 반영되어 표현되었음
  • 모호성(Ambiguity)이 없는 문서
    • 정의된 모든 요구사항이 한 가지 의미로만 해석됨
  • 완전성(Completeness)을 갖춘 문서
    • 시스템이 제공하고자 하는 모든 것이 요구사항 정의서에 포함되어야 한다.
    • 시스템으로 보내지는 모든 가능한 입력에 대하여 구현 가능한 정당한 결과가 제시되어야 한다.
    • 페이지 번호, 그림과 표 제목 및 번호, 사용하는 척도의 단위, 참고 문헌 등이 모두 정확히 표현되어야 한다.
    • 문서 내용 상에 'To Be Determined'가 나타나지 않아야 한다.

 

일관성을 갖춘 문서

  • 현재 문서의 내용이 이전 문서의 내용과 충돌하지 않아야 함
  • 문서의 세부 절 간에 내용 상 충돌이 없어야 함
  • 사용되는 모든 용어는 문서 또는 프로젝트에서 정의하는 표준 영어 사전을 기반으로 해야 하며, 동일한 단어가 다른 의미로 사용되지 않아야 함

 

추적성을 갖춘 문서

  • 하나의 요구 사항이 분석과 설계, 구현 과정을 거쳐먼서 어떻게 변하고 있는지, 정보의 양은 정확하게 유지되고 있는지를 확인하기 위해 지원되는 특성
  • 추적성 매트릭스 : 소프트웨어 개발의 구현 단계에서 발생하는 요구 사항 변경을 어떻게 처리할지 결정할 때 중요한 역할

 


요구 사항 수집 기법

 

대면 수집 방법

  • 인터뷰
    • 시스템 개발과 관련된 이해 관계자들에 대한 대면 인터뷰
    • 준비 단계 → 실시 단계 → 정리 단계로 구성

  • 인터뷰 준비 단계
    • 인터뷰 대상자 선정 : 대상자를 선정하고, 대상자들의 근무 상황을 파악하여 인터뷰 스케줄 작성
    • 인터뷰 계획 수립 : 대상자별 질문 주제를 정하고, 세부 질문 작성 및 정리, 질문 형태는 수집하려는 정보 형태에 따라 단답형, 설명형, 확인형 등으로 구분하여 작성, 대상자들에게 어떤 질문을 할 것인지에 대해 사전에 공지
    • 인터뷰 준비 : 인터뷰 대상자의 업무에 대한 기초 지식의 사전 학습, 인터뷰 대상자의 임무 및 역할, 조직 구성 등을 미리 파악하고 대상자 및 소속 부서의 담당자 이름을 기억
  • 인터뷰 실시 단계
    • 인터뷰 시작 : 인터뷰를 수행하는 사람들을 소개하고, 왜 인터뷰를 수행하는지 설명
    • 인터뷰 실시 : 준비한 질문을 이용하여 권위적인 느낌이 들지 않게 대화식으로 진행
    • 인터뷰 종료 : 인터뷰 내용을 정리함으로써 인터뷰 수행 내용을 확인, 인터뷰 시간을 내준 것에 대해 대상자에게 감사 표시
  • 인터뷰 정리 단계
    • 인터뷰 결과 정리 : 수집한 정보의 체계화, 구조적 정리, 미해결된 사항 점검한다. 인터뷰가 종료된 직후에 바로 수행
    • 결과 공지 : 결과를 인터뷰 참여자에게 전자 메일로 공지
    • 인터뷰 과정 평가 : 준비 ~ 결과 저일까지의 전체 과정에서 어떤 사건이 발생했는지, 어떤 어려운 점, 개선할 부분 식별
  • JAD (Joint Application Development) 세션
    • 프로젝트 관리자, 사용자, 개발자가 모여 요구 사항 도출을 위해 상호 토론하는 방법
    • 시스템 요청에 의거하여 정리된 요구사항 초안을 바탕으로 추가적인 요구 사항, 수정 요구 사항, 요구 사항들을 정리하여 최종 요구사항을 확정
    • 3주에 걸쳐서 총 5일 정도 수행
    • U자형 배치 : 의견 교환이 쉽고, 회의에 집중할 수 있음
    • 모든 사람이 의견을 제시할 수 있도록 유도
    • 무조건적 동의를 강요하지 않음

 

 


비대면 수집 방법

  • 관련자를 만나지 않고, 설문지나 문서 분석을 통해 요구 사항을 수집하는 전략
  • 다양한 정보를 수집하기가 용이하며 시간을 절약할 수 있음
  • 문서 분석
    • 개발 대상 소프트웨어를 사용할 업무에서 현재 사용하고 있는 다양한 종류의 문서를 분석함으로써, 구체적인 요구 사항을 확보하는 방법
    • 소프트웨어 기반의 사업 계획서, 사업 추진 정책 및 절차, 사용하는 양식이나 보고서, 기존에 활용하고 있는 전산 도구 및 보조 프로그램 등 확인
    • 1주일 정도 집중 분석 필요
    • 의문점은 담당자를 통해 즉시 해결
  • 설문지 활용
    • 설문 대상 선정 : 설문지 배포 대상을 적절히 선정. 대상자의 연령, 직업군, 역할 등을 고려하여 대상자 그룹을 선정
    • 설문 문항 작성: 설문 문항의 구조화 필요, 설문 문항에서 요구하는 정보 이외의 정보를 확보하기 어렵기 때문에 문항 설계에 집중 필요
    • 설문지 회수 방법 : 설문 결과를 회수하기 위한 전략 필요
    • 관심 있고, 쉬운 질문으로 시작. 서로 관련성 있는 질문 내용을 그룹으로 묶어 구성
    • 끝부분에 중요한 설문 내용을 두지 않음, 한 페이지에  너무 많은 설문을 담지 않음
    • 어렵거나 전문적인 약어 사용 자제 ,편향된 질문이나 답을 유도하는 형식의 질문 금지
    • 답의 기재 방식을 타당하고, 판단하기 쉽게 선정
    • 모든 질문에 고유 번호를 부여, 사전 테스트 실시, 응답자는 익명으로 처리   
  • 관찰
    • 소프트웨어의 미래 사용자가 수행하는 활동을 살펴보는 활동
    • 관찰의 목적 : 매일 수행하는 일이라 중요하다고 생각하지 않는 업무 처리 과정을 찾기
    • 업무 수행 주기 (예: 월간, 분기)를 파악해서 해당 시기를 놓치지 말아야 함
  • 소셜 네트워크
    • 시간과 공간의 제약 없이 다수 사용자에게 요구 사항을 수집하고자 할 때 활용
    • 다수 고객에게서 다양한 정보를 얻을 수 있음
    • 비정형 데이터 형식으로 정보가 포스팅되고, 응답 내용에 약어나 비속어 등이 포함될 수 있음, 수집 정보를 웹 크롤링하여 자연어 처리 기법 등을 이용해 정보를 추출하는 과정 필요

 


요구사항 정의서 작성

  • 요구 사항 정의서
    • 사용자의 요구 사항과 개발 관련 요구 사항을 정의한 문서
  • 준수해야 할 사항
    • 모든 요구사항에 유일한 식별자를 부여
    • 각 요구 사항은 문장의 5형식에 따라 그 의미를 정확히 표현
    • 각 요구 사항을 정의하는 문장은 복문이 아닌 단문으로 작성
    • 요구 사항에 대하여 우선 순위를 부여
    • 요구 사항을 그룹핑하여 체계화

'Software Engineering' 카테고리의 다른 글

UML 모델링 언어  (3) 2024.10.26
소프트웨어 개발 프로세스 모델  (3) 2024.10.26