사용자:Teguri/요구사항 분석

시스템 공학이나 소프트웨어 공학에서의 요구사항 분석이란, 새로운 제품을 개발하거나 기존 제품에 수정을 가할 때, 자칫 서로 대립할 수도 있는 수익자나 사용자와 같은 다양한 이해관계자(stakeholders)들의 필요나 공급조건 등을 파악하여 결정하는 일련의 작업을 포괄한다.

요구사항 분석은 시스템 공학 프로세스와 소프트웨어 개발 프로세스의 첫번째 단계이다.

소프트웨어 개발 프로세스
활동과 단계
요구사항 분석 · 기능 명세 구조 · 설계 구현 · 테스팅 배치 · 유지보수
개발 모형
애자일 소프트웨어 개발 · 클린룸 DSDM · 순차점증적 개발 · 반복형 개발 RAD · RUP · 나선 모형 폭포수 모델 · 익스트림 프로그래밍 스크럼 · V 모델 · TDD
지원 활동
구성 관리 · 문서화 품질보증 · 프로젝트 관리 사용자 경험 설계
도구
컴파일러 · 디버거 · 프로파일러 GUI 디자이너 · 통합 개발 환경

시스템 요구사항 분석은 요구사항 공학이라는 용어로도 불린다. 때로 부정확하긴 하지만, 요구사항 수집(requirements gathering), 요구사항 포착(requirements capture), 요구사항 기술(requirements specification)이라는 용어를 사용하기도 한다. 또한 요구사항 분석이란 용어는 요구사항 도출이나 문서화 활동과 대비하며 특별히 분석 행위만을 의미하여 사용되기도 한다.

요구사항 분석은 모든 개발 프로젝트에 있어 매우 중요한 활동이다. 모든 요구사항은 동작가능하여야 하고, 측정 가능해야 하며, 시험이 가능해야 하며, 정의된 비즈니스 니즈나 기회와 관련있어야 하며, 시스템 설계 시에 활용이 가능한 수준으로 충분히 상세하게 정의되어야 한다.

개요

개념적으로, 요구사항 분석은 아래와 같은 세 가지 유형의 활동을 포함한다.

• 요구사항 도출하기: 고객과 사용자와의 커뮤니케이션을 통해 그들의 정확한 요구사항이 무엇인지를 파악하고 정의한다. 흔히 요구사항 수집이라고도 부른다.
• 요구사항 분석하기: 전 단계에서 기술된 요구사항이 불명확한지, 미완결인지, 모호한지, 또는 모순적인지를 검토하며, 제기된 문제들을 해결한다.
• 요구사항 기록하기: 요구사항을 다양한 형식으로 문서화한다. 문서의 형식은 자연어 형태의 문서가 될 수도 있고, 유스 케이스 형태일 수도 있으며, 사용자 스토리 또는 프로세스 기술서 형태일 수도 있다.

요구사항 분석은 많은 부분에서 섬세한 심리적 기법을 수반하는 길고 고된 과정이다. 새로운 시스템의 적용은 사람들 간의 관계나 환경에 변화를 야기하기 때문에, 모든 이해관계자를 식별하고, 그들의 모든 필요를 담아 요구사항을 정의한 후, 그들에게 새로운 시스템의 결과물에 대한 완전한 이해를 시키는 것이 매우 중요하다. 분석가들은 고객으로부터 요구사항을 도출해내기 위해 몇가지 기법을 사용할 수 있다. 이러한 기법의 오래된 예로는 인터뷰 방식이나, 포커스 그룹(또는 요구사항 워크숍), 그리고 요구사항 목록 생성 등이 있어왔다. 그리고 좀더 현대적인 기법으로는 프로토타이핑과 유스 케이스가 있다. 필요한 경우, 분석가는 이러한 여러가지 기법들을 조합하여 모든 이해관계자들의 정확한 요구사항을 파악하고, 비즈니스 필요를 만족시킬 수 있는 시스템을 만들 수 있게 한다.

요구사항 분석의 제주제

이해관계자 식별

1990년대에 들어와 새롭게 강조되기 시작한 것이 이해 관계자에 대한 식별이었다. 이해 관계자가 단순히 분석가를 고용하고 있는 조직 내로 한정되는 것이 아니라는 점이 점차 중요하게 인식되었다.

조직 외에도 다음과 같은 이해 관계자들이 있다.

• 분석가가 속한 조직이 설계한 시스템과 수평적 통합을 해야하는 시스템을 개발하는 기관
• 백 오피스 시스템이나 기관
• 경영진

이해 관계자 인터뷰

이해 관계자 인터뷰는 요구사항 분석 시 흔히 쓰이는 방법 중 하나이다. 이를 통해, 프로젝트 범위 내에서 유추하기 힘들었던 요구사항을 찾아내거나, 서로 모순적인 요구사항의 문제를 발견해낼 수 있다. 그러나 각 이해 관계자들은 그들 각자의 요구사항을 기대하거나 그려보일 수 있어, 어려움이 발생할 수도 있다.

계약 형태의 요구사항 목록

요구사항을 문서화하는 전통적인 방법 중 하나는 계약 형태의 요구사항 목록을 작성하는 것이었다. 복잡한 시스템의 경우, 요구사항 목록이 수백 페이지에 달하는 경우도 있었다.

측정 가능한 목표

요구사항 분석의 베스트 프렉티스는 실마리가 되는 몇가지 요구사항을 취한 후, 이에 대해 계속해서 "왜?"라는 질문을 던져 실질적인 비즈니스 목적과 부합될때까지 계속 정제해 나가는 것이다. 그리고 나서 이해관계자와 개발자는 각 요구사항 목표가 잘 성취되었는지를 측정/테스트하기 위한 방법을 고안한다.

프로토타입

1980년대 중반, 프로토타이핑이 요구사항 분석 시의 문제에 대한 해결책으로 보였다. 프로토타입이란 모의로 만들어본 어플리케이션이라 할 수 있다. 이를 통해 모든 구현을 완료하지 않은 상태에서도 사용자가 어플리케이션의 모습을 확인할 수 있다. 프로토타입은 사용자가 시스템의 최종형상에 대한 아이디어를 얻는데 도움을 주며, 시스템을 실제 구축하지 않고도 주요 설계에 대한 결정을 내리기 쉽게 만들어준다. 결과적으로 프로토타입을 보여주는 일은 개발자와 사용자 간의 커뮤니케이션이 큰 도움을 줄 수 있다. 조기에 어플리케이션의 모습을 보게 되면 후에 있을 수 있는 변경을 줄여 주고, 결과적으로 전체적인 개발 비용을 크게 줄여 줄 수 있다.

그러나, 이후 십여년간, 이 새로운 기법을 검증해가는 과정에서 아래와 같은 이유로 프로토타이핑이 요구사항의 문제를 해결하지는 못한다는 사실이 확인되었다.

• 일단 프로토타입이 동작하는 것을 확인한 관리자들은 실제 설계 및 구현을 위해 더 긴 시간이 필요하다는 것을 이해하기 어려워한다.
• 설계자는 흔히 만들어진 프로토타입을 이용하여 이에 코드를 추가하여 실제 시스템을 만들어 나가야한다는 압박을 받곤한다. 그들이 새로 시작할 경우 "시간을 낭비"할 것을 두려워하기 때문이다.
• 이론적으로 프로토타입은 설계나 사용자 인터페이스 상의 주요한 결정을 내릴때 도움을 줄 수 있지만, 본질적으로 원래의 요구사항이 무엇인지를 알려주지는 않는다.
• 프로토타입으로 인해 설계자와 최종 사용자 모두 사용자 인터페이스에 지나치게 집중하고, 실제 비즈니스 요구사항을 가능하게 하는 시스템 그 자체에 대해서는 소흘해질 수 있다.
• 프로토타이핑은 사용자 인터페이스, 화면 구성 및 흐름에 있어서는 순기능을 할 수 있으나, 데이터베이스 갱신이나 계산을 필요로하는 배치 작업이나 비동기적인 프로세스에는 별 도움이 되지 않을 수 있다.

유스 케이스(Use Cases)

유스 케이스는 새로운 시스템이나 소프트웨어 변경에 대한 잠재적 요구사항들을 문서화하는 하나의 기법이다. 각각의 유스 케이스는 비즈니스 목표를 달성하기 위해 시스템이 최종 사용자나 다른 시스템과 상호작용하는 하나 이상의 시나리오를 표현한다. 일반적으로 유스 케이스에서는 어려운 기술 용어의 사용을 피하고, 대신에 일반 최종 사용자들의 언어나 해당 도메인 전문가의 용어를 사용한다. 흔히 유스케이스는 요구사항 엔지니어와 이해 관계자들이 함께 협의하여 작성하게 된다.

Use cases are deceptively simple tools for describing the behavior of software or systems. A use case contains a textual description of all of the ways which the intended users could work with the software or system. Use cases do not describe any internal workings of the system, nor do they explain how that system will be implemented. They simply show the steps that a user follows to perform a task. All the ways that users interact with a system can be described in this manner.

소프트웨어 요구사항 명세서

소프트웨어 요구사항 명세(SRS: software requirements specification)는 개발할 시스템이 동작하는 방식과 기능에 대한 완전한 기술을 의미한다. It includes a set of use cases that describe all of the interactions that the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance requirements, quality standards, or design constraints).

Recommended approaches for the specification of software requirements are described by IEEE 830-1998. This standard describes possible structures, desirable contents, and qualities of a software requirements specification.

요구사항의 여러 형태

여러가지 방법으로 요구사항을 형태별로 분류할 수 있지만, 흔히 다음과 같은 유형으로 기술적으로 분류하여 관리한다.

고객 요구사항

Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions posed in the following listing:

• 운영을 위한 배포: 시스템이 사용될 장소는 어디인가?
• 임무 프로파일 또는 시나리오: 시스템은 임무 목표를 어떻게 완수할 것인가?
• 성능 관련 사항들: 임무를 완수하기 위한 중료한 시스템 상의 변수는 무엇이 있는가?
• 활용 환경: 어떤 다향한 시스템 구성요소가 사용상에 필요한가?
• Effectiveness requirements: How effective or efficient must the system be in performing its mission?
• Operational life cycle: How long will the system be in use by the user?
• Environment: What environments will the system be expected to operate in an effective manner?

기능적 요구사항

Functional requirements explain what has to be done, and identified The necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the toplevel functions for functional analysis.

성능 요구사항

The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements.

설계 요구사항

The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals.

Derived Requirements

Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.

Allocated Requirements

A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.

요구사항 분석 상의 이슈

이해 관계자 이슈

스티브 맥코넬은 그의 책 쾌속 개발에서 사용자들이 요구사항 수집을 힘들게 만드는 아래의 다양한 사례들을 상세화한 바 있다.

• 사용자들이 그들이 필요로 하는 기능을 이해하지 못하거나, 요구사항에 대한 명확한 생각을 갖고 있지 않은 경우
• 사용자들이 요구사항 문서화를 일로 받아들이고 참여하려고 하지 않을 경우
• 사용자들이 모든 일정과 예산이 확정된 이후에 또다른 새 요구사항을 주장하는 경우
• 사용자들과의 의사소통이 원활하지 않고 느릴 경우
• 사용자들이 요구사항 검토 회의에 자주 결석하거나, 출석할 만한 여유가 없는 경우
• 사용자들의 기술적 이해도가 매우 낮은 경우
• 사용자들이 개발 프로세스에 대한 이해를 가지고 있지 않은 경우
• 사용자들이 현재의 기술 수준에 대해 알지 못하는 경우

위와 같은 경우에는, 심지어 시스템 또는 제품 개발이 시작되고 나서도 사용자 요구사항이 계속해서 바뀔 수 있다.

엔지니어/개발자 이슈

Possible problems caused by engineers and developers during requirements analysis are:

• Technical personnel and end users may have different vocabularies. Consequently, they may wrongly believe they are in perfect agreement until the finished product is supplied.
• Engineers and developers may try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client.
• Analysis may often be carried out by engineers or programmers, rather than personnel with the people skills and the domain knowledge to understand a client's needs properly.

Attempted solutions

One attempted solution to communications problems has been to employ specialists in business or system analysis.

Techniques introduced in the 1990s like prototyping, Unified Modeling Language (UML), use cases, and Agile software development are also intended as solutions to problems encountered with previous methods.

Also, a new class of application simulation or application definition tools have entered the market. These tools are designed to bridge the communication gap between business users and the IT organization — and also to allow applications to be 'test marketed' before any code is produced. The best of these tools offer:

• electronic whiteboards to sketch application flows and test alternatives
• ability to capture business logic and data needs
• ability to generate high fidelity prototypes that closely imitate the final application
• interactivity
• capability to add contextual requirements and other comments
• ability for remote and distributed users to run and interact with the simulation

같이 보기

• 비즈니스 분석
• 비즈니스 프로세스 리엔지니어링
• 데이터 모델링
• 기능적 요구사항
• 비기능적 요구사항
• 프로세스 아키텍쳐
• 프로세스 모델링
• 요구사항 관리
• 요구사항 추적성
• 소프트웨어 프로토타이핑
• 소프트웨어 요구사항 명세
• 시스템 분석
• 시스템 요구사항

더 읽을 거리

• McConnell, Steve (1996). 《Rapid Development: Taming Wild Software Schedules》 1판. Redmond, WA: Microsoft Press. ISBN 1-55615-900-5.  CS1 관리 - 추가 문구 (링크)
• Wiegers, Karl E. (2003). 《Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle》 2판. Redmond: Microsoft Press. ISBN 0-7356-1879-8.  CS1 관리 - 추가 문구 (링크)
• Andrew Stellman and Jennifer Greene (2005). 《Applied Software Project Management》. Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8. 

외부 링크

• Requirements Engineering Process "Goodies"
• Requirements Engineering: A Roadmap (PDF) article by Bashar Nuseibeh and Steve Easterbrook, 2000.
• Undreamt Requirements Analysis
• Getting Started With Use Cases