소프트웨어 공학 이론 정리 -7장- <요구사항 분석 2부>

UML Use Case Diagram

-      Scenario Based Analysis에 속하는 Diagram 이다.

-      Actor : 시스템과 소통하는 내부에 있는 모든 요소

 

Negotiating Requirements(요구사항 협상)

-      협상 결과가 stakeholder 모두에게 ‘win-win’한 결과가 나와야 한다.

• Stakeholder는 만족스러운 결과물을 얻고, developers는 deadline에 맞춰 생산하는 것이 ‘win-win’ 이다.
• 이런 결과를 만드는 건 Handshaking 이 거의 유일하다.

-      Developers가 요구사항을 분석하고 솔루션을 제시한다. 이 때 묘사하는 것은 효과와, Developer가 솔루션을 구상하며 가진 생각이다.

-      Customer는 솔루션을 분석하고, 놓친 features가 없는지에 집중하며 피드백을 제시한다.

-      최종적으로 customer가 developer가 제시한 솔루션을 받아들이면서 협상이 이뤄진다.

-      Handshaking(합의)는 Stakeholder로 하여금 요구사항을 구체화, 분석, 최적의 옵션을 고를 수 있게 한다.

 

 

Requirements Monitoring

변화되는 요구사항을 추적 관찰하는 것을 말하며, 요구사항이 증가할 때 개발에 용이하다.

1.     Distributed debugging – 개발자뿐만 아니라, stakeholder 모두가 요구사항에서 벗어난 개발 요소를 찾아낸다.

2.     Run-time verification – 소프트웨어가 설계에서 맞춘 규격을 지키도록 감시/관찰한다.

3.     Run-time validation – ‘맞다. 안맞다.’ 가 아니라 소프트웨어가 user의 goal을 달성시킬 수 있는지 관찰하는 것이 다.

4.     Business activity monitoring – 상업적인 목표를 달성할 수 있는 시스템인지 관찰한다.

5.     Evolution and codesign - stakeholder에게 추가된 요구사항에 의해 변화된 시스템에 대한 정보를 제공한다.

Validating Requirements

유저의 목표를 가치 있게 하는 솔루션/요구사항을 만드는 것

-      시스템의 전반적인 목표에 맞게 요구사항들이 일관성 있게 구성되어 있는가?

-      모든 요구사항이 단계별로 적절히 추상화 되어있는가? 즉, 요구사항이 현재 위치에 적절한 기술적 구체성을 띄고 있는가? 를 말한다.

-      요구사항이 실제로 필요한지, 시스템에 굳이 필요 없는 feature가 추가되어 있는 건 아닌가?

-      요구사항의 경계가 분명하고 명확한가?

-      각 요구사항이 고유의 속성을 갖고 있는가? [다른 요구사항과 속성이 독립 되어야 한다.] 즉, 각 요구사항이 제시될 때, 요구사항이 나오게 된 배경과 목적이 분명히 나타나야 한다.

-      각 요구사항간 중첩되거나 갈등을 빚는 부분이 있는가?

-      기존 기술적인 환경에 생산한 소프트웨어가 사용될 때, 요구사항을 잘 만족시킬 수 있는가? (Standalone이 아니라, 다양한 환경에서도 적용 가능한가)

-      각각의 요구사항이 테스트할 수 있고, 한 번씩은 구현됐는가?

-      요구사항 모델이 정보, function, 시스템 행동을 잘 반영해 보여줄 수 있는가?

-      요구사항 모델이 시스템의 디테일한 부분을 보여주기 위해 잘 ‘partitioned’ 되었는가?