Software Engineering - Requirement Engineering part - 1

• Requirement를 정의하는 것은 계약과 같은 부분에 연계될 수 있기 때문에 중요하다.
• 개인이 설계하고 만드는 경우보다 SI업체와 같이 다른 회사로부터 수주를 받아 갑을관계가 형성되는 경우 갑의 요구사항을 을이 제대로 정의하는 것이 중요하다.

Requirement Engineering

• 고객이 소프트웨어에서 기대하는 요구 사항과 제한 사항을 개발할 수 있는 형태로 옮겨가는 것

• 요구 사항은 고객 입장에서 잘 사용하고 이해하는 기능이라면 쉽고 기술적으로 자세하게 이야기하지만, 소프트웨어가 만들어져 있지 않거나 이해도가 낮은 상태라면 추상적으로 표현될 수 있다. 또는 기존 시스템의 개선이나 구체적인 목표에서 구체적인 숫자를 요구하는 정량적 기준이 있는 요구 사항도 있다.

• 큰 프로젝트를 계약함에 있어 추상적, 구체적 요구사항을 빠짐없이 정의해야 한다.

• 요구 사항은 고객에게 소프트웨어의 이해에 대한 기초자료 및 결과에 대한 검증 자료로 사용되며, 제작자 입장에서는 만들어야 되는 내용으로 사용된다.

• 높은 추상화 수준에서 세세한 정량적 기준까지 요구 사항은 다양하기 때문에, 다양한 요구사항을 듣고 구현할 수 있도록 system requirement에 담는 것이 필요하다.

System Requirements

• 소프트웨어를 구현하는 기술적 단계로 넘어가 소프트웨어 개발 중에 발생하는 고객의 요구사항과 제한 사항에 대해 기술한다.

Plan-based에서 Requirement가 중요한 이유

• Requirement 자체로 계약에 사용될 수 있으며, 해야 할 일을 정의할 수 있고 후속작업의 기초로 사용된다.
• Requirement 자체가 기술적 계약서로 사용되어 계약을 맺거나 요구사항의 변화에 있어서 누가 더 부담을 질 지에 대해서도 정하며, 프로젝트 실패 시의 책임의 소재로 사용될 수 있다.

Types of Requirements

User requirement (사용자 및 시스템 전체 관점에서 보는 이해 당사자들이 본다)

• 고객의 요구 사항을 기술하며 대부분 자연어로 작성된다.
• 자연어의 모호성을 피하기 위해 다이어그램과 같은 그림을 활용한다.
• 가능한 구현에 대한 언급을 자제하고 무엇을 시스템이 해야하는 지에 대해 집중한다.
• Client manager, System end-users, Client engineers, Contractor managers, System architects

System requirement

• User Requirement를 바탕으로 소프트웨어로 구현하기 위해 어떤 기능과 규칙이 필요한지에 대해 기술
• 개발자에게 전달되기 때문에 구조화되어 있고, 구체적이고 세부적으로 기술된다.
• 소프트웨어의 동작 가능한 기능과 운영의 제한사항들이 구체적으로 기술된다.
• system end-users, client engineers, system architects, software developers)

예시

• 육하원칙에 따라 / 제한조건에 따라
• User Requirement에서 넘버링이 된 구체적인 문장으로부터 System Requirement에 서브 넘버링을 부여함으로써 세부적으로 추출한다. 넘버링을 통해 관리하며 추적/작업/할당/검증이 진행된다.

System stakeholders(이해 당사자)

• End-users, 시스템 매니저, 시스템 소유주, 외부 이해당사자의 요구 사항을 모두 고려해야 한다.
  또한 법규 및 규정, 윤리 등 또한 충족해야 한다.

Agile methods and requirements

• 변화가 빨리 일어나기 때문에 세세한 system requirements는 중요하지 않으며, user stories를 나타내는 용도로 사용된다.

Functional and non-functional requirements

Functional requirement

• 시스템이 제공해야할 기능들(클래스나 메소드와 매핑)
• 특정 입력이 주어지면 어떤 행동을 취해야 하는지에 대해서 기술한다.
• 어떤 것을 하면 안되는 지에 대한 제한사항도 기술한다.
• 소프트웨어의 유형, 잠재고객, 소프트웨어가 사용되는 시스템에 따라 달라진다.
• 시스템이 무엇을 해야하는지 매우 구체적으로 서술되어야한다.
• 서로 다르게 해석할 수 있기 때문에 새로운 단어를 정의해 명확한 의미를 파악하는 것이 좋다
  Complete : 가능한 모든 기능들에 대해서 상세하고 명확하게 기술되는 것이 좋다(오해의 여지 제거)
  Consistent : 명세서에 있는 다른 기능들과 충돌이나 모순을 일으켜서는 안된다.

Non-functional requirement

• 소프트웨어나 functions에 대한 상위 제한 사항으로 제한 조건, 표준, 개발 프로세스상의 제한 조건(AGILE등), 시간 제한, 보안, 용량, 개발 도구, 프로그래밍 언어, 개발방법론 등에 대한 외적인 요구사항(지키지 않으면 소프트웨어가 무용지물이 된다)
• 소프트웨어의 전체적인 구조에 영향을 주며 새로운 기능을 도출하거나 인증을 받아야할 수도 있다.
  
• Product requirements
  • 결과물인 소프트웨어가 반드시 특정 방식을 구체화 (실행 속도, 안정성 등)
  • 프로그램이 큰 틀에서 지켜야할 요구사항
• Organisational requirements
  • 회사나 집단의 표준이나 절차에 대한 요구(회사 표준, 구현의 표준 등)
• External requiremnets
  • 지켜야하는 법규, 규제, 윤리 등

Domain requirements

• 해당 영역에서 암묵적으로 지켜져야 할 요구사항

Usability requirements

• non functional requirements는 정확하게 설명하기 힘들며 부정확한 요구도 검증하기 어렵다
  • 고객이 달성하고자 하는 요구 사항을 최대한 구체적(정량적 수치 등)으로 기술하며, 결과물도 객관적으로 검증이 가능하도록 구현(정량적 수치 등)

metrics for specifying non-functional requirements

• 스피드(transaction/ response time/ refresh time)
• 크기(bytes/ chips)
• 사용이 쉽거나(training time/ help frame)
• 신뢰성(time to failure/ probability of unavailability/ Rate of failure occurrence/ Availability)
• 안정성(정상화까지의 시간)
• 포터블(Number of target systems/ 의존성) 처럼 추상적인 것을 정량적인 수치로 변경