초보 개발자
요구사항을 분석할 때 생길 수 있는 어려움들 본문
** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. **
요구공학 단계에서 발생하기 쉬운 위험요인 - Lawrence
- Overlooking a crucial requirements 중요한 요구 사항 간과
- Inadequate Customer representation 불충분한 고객 표현
- Modeling only functional requirements
비기능 요구사항 + 예외상황 시나리오 파악 필요 - Not inspecting requirements 점검하지 않는 것
- Attempting to perfect requirements before beginning construction
요구사항 완벽하게 만들고 다음 단계로 넘어가려고 하면 안 됨 - Representing requirements in the form of designs 디자인 형태로 요구 사항 표현?
요구사항과 디자인의 내용이 섞이는 것을 경계해야 함. 요구공학에서는 What, 디자인에서는 How
what, how의 구분이 명확하지 않다. (UML의 use case diagram, sequence diagram, state transition diagram) - 빈번한 요구사항 변경 요청: stakeholder 입장에서 요구사항을 분석하고 파악, 설명, 리뷰하는 과정이 필요함 (2, 4 동일)
실제 브라질/독일 산업계에서는? -Fermandez
- Poor communication between team and customer - 소규모에서는 순위가 낮음 (시스템 복잡도 하락)
- Moving targets (요구사항의 변경) - 소규모에서는 순위가 낮음
- Incomplete requirements / hiddden requirements - 소규모 1순위
- Underspecified requirements
- Poor communication within the team
- Insufficient support by the customer
- Insuffiecient time
- Stakeholders with dificulties in separating requirements from known solutions
Incomplete or hiddden requirements의 원인 / 영향


예외적인 상황을 파악하는 것은 어려울 수밖에 없으므로, 항상 "What if?"라는 건강한 의심이 필요하다.
Underspecified requirements
요구사항의 설명이 충분하지 않다. → 판단 기준이 애매하므로 원천적 해결은 불가능하다.
customer를 포함한 stakeholder들이 참여하여 요구사항에 대해 검토하고 설명하는 회의를 가지며 이해를 높인다
SRS: 고객과 개발팀과의 대화를 위한 수단 + 요구공학팀과 디자인팀의 소통을 위한 수단
요구사항을 바탕으로 테스트케이스를 만들어보는 것도 좋은 이해 방법이 된다.
Poor communication within the team
서로를 잘 이해하고 오해가 없을 것이라 착각하는 경우가 많다.
팀 전체가 전체 시스템에 대한 토론을 하고, 역할을 분배해 개별적으로 명세를 하고 통합하는 경우가 많다
→ 각 기능별 내용이나 완성도 측면에서는 나름 수준급이다. 그러나 합치면 일관성이나 가독성 면에서 문제가 있다.
→ Level of detail/abstraction가 다르다. 용어에 대한 의미가 확실하지 않다.
제일 먼저 기술적인 용어 및 약자에 대한 정의하기. - Terminology, Abbreviaiton
자연어 명세의 애매모호함을 보조하기 위해 UML 다이어그램을 적극적으로 활용하기
추가 자료 리스트
- Article "The Top Risks of Requirements Engineering" - Lawrence, IEEE Software
- Article "Naming the Pain in Requirements Engineering: Comparing Practices in Brazil and Germany" - IEEE Software
'컴퓨터공학 전공 > 소프트웨어공학' 카테고리의 다른 글
인스펙션을 효과적으로 할 수 있는 방법들 (0) | 2022.10.13 |
---|---|
소프트웨어 인스펙션 기법이란? (0) | 2022.10.13 |
요구사항의 분석과 건강한 의심 (0) | 2022.10.13 |
요구사항을 체계적으로 분석하는 방법은? (0) | 2022.10.13 |
소프트웨어의 오류와 심각한 사고 (0) | 2022.10.13 |