[Software Engineering] 요구공학(Requirements Engineering)

2019년 2학기 고려대학교 차성덕 교수님 소프트웨어 공학

왜 요구 공학이 중요한가?

• 소프트웨어 품질을 판단하는 기초가 된다.
• 테스트 케이스를 만드는데 기초가 된다. 요구 사항에 대한 설명이 빠져있으면 테스트케이스를 만들 수 없다.
• 입장에 따라(유저 / 개발자) 필요한 문서가 다를 수도 있다.
• 요구사항은 대개 자연어로 서술하는데 그러다보면 같은 얘기도 다르게 해석하는 경우가 있다.
• 기준 없이 여러 명이 요구사항을 작성한다면 추상화나 자세함의 정도가 다르기 때문에 이상해질 수 있다.
• 시간이나 보안 등과 같이 놓치기 쉬운 비기능적인 요구사항을 파악하고 예외적인 이벤트에 대해 적절히 대응할 수 있어야 한다.

스마트 키 개발을 할때 요구되는 비기능 요구사항들. 이러한 것들은 쉽게 파악하기 어렵다.

📌 중간고사 pick : 티켓 발권 상황에서 생각할 수 있는 비기능요구사항을 분류와 구체적인 예를 들어 작성하라

소프트웨어 요구 사항 명세

거의 시스템 동작에 대한 high-level description으로 시작한다. 자연어가 주로 많이 쓰이긴 하지만 다이어그램과 모델이 사용되기도 한다. 자연어로 처리하기 애매한 부분을 다이어그램을 통해 설명할 수도 있고, 다이어그램과 자연어의 의미가 맞지 않는 부분을 확인할 수도 있다.

요구 사항 관리

• 처음 요구사항을 도출해 낼때는 베이스라인을 정한다.
• 요구사항이 바뀔때는 영향 받는 다른 요구사항이 무엇이 있나 확인한다. 상호 의존성 체크가 필요하다.

요구 사항의 source

• 잠재 고객과의 인터뷰 및 소통
• 경쟁 제품에 있는 요구사항

RE(Requirement Engineering) Process

요구사항을 한번에 제대로 파악하는 것은 어렵기에 단계적으로 진행하는 것이 도움이 된다. Re Process를 위한 10단계가 있고 그 중 일부는 다음과 같다.

1. 미션과 범위를 정한다. 바깥 틀이 제대로 잡히지 않으면 프로젝트를 진행하는데 흔들리기 쉽다.
2. 이해당사자가 누구인지 파악한다.
3. 이해 당사자의 목표를 정의한다.
4. 충돌되는 목표를 일찍 발견하고 해결한다.
5. 목표를 시나리오로 바꾼다.
6. Requirements. 인터페이스, 제약사항, 비기능 요구사항, usecase description등 각각에 대한 자세한 기능을 기술한다.
7. Justification. 요구사항들에 대해 정말 꼭 필요한것인지 파악하고 핵심 기능과 부가 기능을 구분해야한다. 그 과정에서요구사항을 더 잘 이해하고 중요도 또한 결정할 수 있다.

SRS (Software Requirement Specification, 소프트웨어 요구사항 명세서)

요구사항 명세서를 작성하는 이유 중 하나는 서로 다르게 이해하지 않도록 하는데 있다.

요구 사항을 작성할때 어떤 내용이 포함되어야할지 구체적으로 기술한 문서나 템플릿을 보면 도움이 된다. 체크리스트로 활용하며 놓치기 쉬운 부분을 생각해낼 수 있다.

Specific Requirements / A Vision Statement Template

특히 위성이나 자동차와 같은 곳에 들어가는 소프트웨어는 제약 사항 (ex. cpu나 메모리 사용률은 70%를 넘으면 안됨) 등에 대해 명확히 기술하는 것이 중요하다. 또한 해당되지 않는 사항에 대해서는 작성하지 않는 것이 아니라, ‘해당사항 없음’ 이라고 쓰고 그 이유를 간단하게라도 작성하는 것이 좋다. TBD(To Be Determined, 미정)개수의 파악을 통해 요구 공학의 완성도 측정이 가능하다.

요구 사항에서 (특히 trigger conditions에서) 완성도(completeness)와 일관성(consistency)을 달성하는것은 복잡하고 어려운 문제이다. 두개가 서로 충돌하지 않도록 자동화된 툴을 이용해 검증해볼 수 있는데, 이러한 검증이 일어날때 hidden assumptions(이야기 하지 않아도 당연히 알 것이라고 생각하는 부분)들이 분명하게 드러난다.

왼쪽 상황은 모든 조건을 포함하지 않아 완성도가 깨진 경우이다. 두개의 트리거에 대해 or 연산을 했을때 true 가 나와야한다. 하지만 x가 0일때를 가정해보면 false, false 상황이므로 or 연산시 false 가 나온다.

오른쪽은 겹치는 조건이 있어 일관성이 깨진 경우이다. 두개의 트리거에 대해 and 연산을 했을때 false가 나와야한다. 하지만 x가 15일때를 가정해보면 true, true 상황이므로 and 연산시 true 가 나온다.

Use Case Diagram

Use case는 시스템과 actor의 상호작용을 서술한다. 여기서 actor는 사람, 다른 시스템, 하드웨어 기기가 될 수 있다. 전반적인 큰 그림을 보여주는데 적당하기에 이해당사자와 이야기하기는 좋다. 하지만 전달하는 정보의 양이나 디테일은 한정되어 있어서 요구사항 문서로 쓸 수는 없다. 각 기능에 대한 설명은 use case description에 기술한다.

사람은 actor, 동그라미는 use case가 된다. 오른쪽에 동그라미를 감산 네모는 system의 바운더리(optional)를 뜻한다.

use case가 너무 많거나, 복잡하지 않도록 구성하는 것이 중요하며, 인터페이스 디자인과 같은 너무 디테일 한 사항도 포함되지 않도록한다.

use case diagram. 노란색 노트는 program의 comment이다.

Use Case Description

📌 중간고사 pick : 티켓 발권 상황에서 환불 기능을 추가한다고 할때 use case description의 flow 부분을 작성하라

위의 문서는 자동차 스마트키의 use case 중 하나에 해당 되는 키 인증 시나리오 시나리오이다. 0.7m 근거리로 써있는 것과 같이 단순히 ‘가까이’가 아닌 구체적인 수치가 명시 되어야한다.

Alt는 플로우에서 발생 가능한 예외 사항들을 기술한다. 만약 Flow-Basic-1에서 발생할 수 있는 에러 사항이 여러개면 1-a, 1-b, 1-c 이런식으로 번호를 매긴다.

요구공학에서 겪는 어려움

• 개발팀과 고객의 소통 문제
• 불완전하거나 기술되지 않은 요구사항
• 팀 내 소통 문제
• 고객의 불완전한 지지
• 계속 변하는 요구사항
• 부족한 시간

생각해볼점

• 어떤 요구사항이 있을때 특정한 use-case 형식에 맞게 쓸 수 있어야한다
• 매니저 입장에서 요구사항이 어느 정도면 만족할만한 수준인지, 그래서 다음 단계로 넘어가도 되는지 알고 싶을때 어떻게 할까? (‘이정도면 됐다’ 하는 기준이 필요할 것)
• 아래 표에서 best practice(두번째 column)라고 생각하는 두개 고르고 그 이유

• 어떤 제품(스마트 키 등)을 개발한다고 할때 필요한 비기능 요구사항을 3개정도 생각해보기
• use case description을 작성할 수 있다
• use case diagram을 그릴 수 있다
• 요구사항이 주어졌을때 완전한지 불완전한지 판단할 수 있다
• 요구공학에서 겪는 어려움과 그것이 왜 일어나는지, 그리고 3개 정도를 골라 그 리스크를 줄이기 위해 내가 할 수 있는일이 뭔지 생각해보기