2.8 소프트웨어 요구사항

개요와 동기

소프트웨어 요구사항은 시스템이 이해관계자에게 받아들여지기 위해 제공하거나, 충족하거나, 갖추어야 하는 능력이나 조건에 대한 진술입니다. 그 진술을 도출하고, 분석하고, 명세하고, 검증하고, 관리하는 규율 있는 일인 요구공학은 가치 사슬의 맨 앞에 있습니다. 아키텍처에서 코드, 인수 테스트에 이르는 모든 하류의 일은 요구사항을 충족하려는 시도입니다. 그래서 요구사항이 틀렸거나, 불완전하거나, 모호하면, 잘못된 것을 올바르게 만드는 데 쓴 모든 노력은 순전한 낭비이며, 가장 늦게 발견되므로 가장 비싼 낭비입니다. 소프트웨어 엔지니어링 지식체계(SWEBOK)의 소프트웨어 요구사항 지식 영역은 이것을 진짜 일의 사무적인 서막이 아니라 실제 엔지니어링 규율로 다룹니다.

큰 팀에서 요구사항은 많은 사람이 하나의 일관된 시스템을 만들 수 있게 하는 공유된 이해입니다. 개발자 한 명은 의도를 머릿속에 담을 수 있지만, 많은 팀에 걸친 수백 명은 그럴 수 없습니다. 요구사항은 능력을 필요로 하는 사람과 만드는 사람 사이의 계약, 팀 간에 일을 나누는 기준, 무언가가 “완료”되었는지 판단하는 잣대가 됩니다. 요구사항은 문제와 기회가 드러나는 디스커버리(11.1장), 사용자 필요를 이해하는 UX 기초(5.1장), 인터페이스 의무가 고정되는 API와 인터페이스 설계(2.3장), 비기능 요구사항이 구조를 이끄는 아키텍처와 품질 속성(3.1장), 범위, 비용, 일정이 그 주변에서 계획되는 프로젝트 관리(10.6장)에 직접 연결됩니다.

기업과 정부 환경에서 요구사항은 법적, 계약적, 안전의 무게를 집니다. 규제 시스템은 의무화된 모든 의무(접근성, 프라이버시, 보안, 기록 보존, 재무 통제)가 요구사항으로 포착되고, 구현되고, 증거로 검증되었음을 보일 수 있어야 합니다. 정부 조달은 요구사항 명세 주변에 구축되는 경우가 많고, 지불, 감사, 인증 모두 각 요구사항을 그것이 충족되었다는 증거까지 추적하는 데 달려 있습니다. 여기서 요구사항은 좋은 관행 이상입니다. 책임성의 척추입니다.

핵심 원칙

요구사항은 해법이 아니라 필요나 제약을 표현합니다. 무엇을 왜인지를 말하지, 어떻게인지를 말하지 않습니다.
모든 요구사항은 필요하고, 모호하지 않고, 검증 가능하고, 실현 가능하고, 추적 가능해야 합니다.
요구사항은 고립되어 발명되는 것이 아니라 이해관계자와 함께 발견되고 협상됩니다.
비기능 요구사항과 제약은 기능만큼 아키텍처를 형성합니다.
요구사항은 진화합니다. 변경을 얼리거나 무시하지 말고 의도적으로 관리하십시오.
필요에서 요구사항, 설계, 테스트, 증거까지의 추적성은 책임성의 결합 조직입니다.
알맞은 형식성의 수준은 습관이 아니라 위험, 규모, 규제 맥락에 달려 있습니다.

권장 사항

요구사항을 분명히 정의하고 분류한다

범주에 의도적으로 이름을 붙이십시오. 기능 요구사항은 시스템이 해야 하는 것, 즉 제공하는 동작, 변환, 서비스를 진술합니다. 비기능 요구사항(품질 속성)은 그것을 얼마나 잘 해야 하는지를 진술합니다. 성능, 가용성, 보안, 사용성, 접근성, 유지보수성 등이며, 이는 아키텍처(3.1장)에 강하게 묶입니다. 제약은 해법에 대한 협상 불가한 경계입니다. 의무화된 기술, 표준, 예산, 법 규칙, 기존 시스템에 대한 인터페이스입니다. 그리고 비즈니스 요구사항(조직이 왜 시스템을 원하는가)과 사용자 요구사항(사용자가 달성해야 하는 것)과 시스템 요구사항(그래서 소프트웨어가 해야 하는 것)을 구분하십시오. 이 수준을 뒤섞으면 곧 범위 혼란이 따릅니다.

가정이 아닌 실제 출처에서 도출한다

도출은 적극적인 발견입니다. 인터뷰, 워크숍, 관찰, 프로토타입, 기존 시스템과 문서의 분석을 통해 이해관계자로부터 요구사항을 끌어내십시오. 간과하기 쉬운 이들을 포함해 모든 관련 이해관계자를 찾아내십시오. 운영자, 감사자, 지원 직원, 시스템의 영향을 받지만 직접 쓰지 않는 사람들입니다. 도출을 디스커버리 파이프라인(11.1장) 및 UX 리서치(5.1장)와 연결해, 말해진 바람이 기저의 필요까지 추적되게 하십시오. 각 요구사항의 출처와 근거를 기록하십시오. 요구사항이 왜 존재하는지 아는 것이 바로 나중에 그것을 안전하게 바꿀 수 있게 하기 때문입니다.

분석하고, 협상하고, 우선순위를 정한다

날 것으로 도출된 필요는 충돌하고, 겹치고, 합치면 실현 가능한 것보다 많습니다. 분석은 그것들을 조정하는 방법입니다. 요구사항을 분류하고, 충돌을 알아채고, 실현 가능성과 위험을 저울질하고, 이해관계자와 우선순위를 협상합니다. 공개적으로 우선순위를 정하십시오. 예컨대 must/should/could 구분이나 가치 대 비용 순위로, 시간이 모자랄 때 올바른 범위를 잘라 내게 하십시오. 그리고 모델이 명확성을 더하는 곳 어디서나 요구사항을 모델링하십시오. 프로세스 흐름, 상태 다이어그램, 데이터 모델, 인터페이스 정의는 산문이 감추는 간극을 드러냅니다.

알맞은 형식성의 수준으로 명세한다

위험과 독자에 맞는 형태로 요구사항을 적으십시오. 높은 보증이 필요한 정부 시스템은 IEEE 29148 같은 표준에 따라 구조화된 형식 명세가 정당할 수 있고, 빠르게 움직이는 제품 팀은 백로그에 인수 기준과 함께 사용자 스토리로 요구사항을 포착할 수 있습니다. 어느 쪽이든 각 요구사항은 원자적이고, 검증 가능하며, “빠른”, “사용자 친화적”, “등등” 같은 미끄러운 말이 없어야 합니다. 인수 기준을 첨부해, 요구사항을 쓰는 바로 그 순간에 그것을 어떻게 검증할지 정의하십시오. 그리고 요구사항이 이메일, 티켓, 슬라이드에 흩어지게 두지 말고 하나의 권위 있는 출처를 유지하십시오.

만들기 전에 검증한다

검증은 명세한 요구사항이 올바른 것이고 서로 맞는지 확인합니다. 이해관계자와 함께 검토하고, 시나리오를 따라가 보고, 가능하면 프로토타입으로 추상적인 진술을 구체적으로 만드십시오. 검증은 어떤 나중의 수정보다 쌉니다. 요구사항 리뷰에서 잡은 결함은 프로덕션에서 잡은 같은 결함의 비용의 일부에 불과합니다.

요구사항을 관리하고 추적성을 유지한다

요구사항은 변합니다. 여러분의 일은 그 변화에 저항하는 것이 아니라 통제하는 것입니다. 변경 프로세스를 세우십시오. 제안된 각 변경을 수용하기 전에 영향, 비용, 하류의 효과를 저울질하십시오. 합의된 시점에 요구사항을 기준선으로 삼고 버전을 관리하십시오. 각 요구사항을 설계, 코드, 테스트까지 앞으로, 그것이 나온 필요까지 뒤로 잇는 양방향 추적성을 유지하십시오. 추적성은 큰 팀이 의지하는 두 질문에 답합니다. 이 필요가 바뀌면 무엇이 영향을 받는가, 그리고 이 전달된 기능을 어떤 필요가 정당화했는가? 규제 맥락에서는 추적을 인수 증거(테스트 결과, 감사 기록, 승인)까지 끝까지 확장해, 단지 주장하는 것이 아니라 컴플라이언스를 입증할 수 있게 하십시오.

애자일과 계획 주도 맥락에 적응한다

계획 주도 및 규제 프로그램에서는 요구사항을 비교적 일찍 명세하고 기준선으로 삼으며 공식 변경 통제를 둡니다. 애자일 맥락에서 요구사항은 우선순위가 매겨지고 진화하는 백로그로 살며, 구현 직전에 구체화되고 동작하는 소프트웨어를 통해 지속적으로 검증됩니다. 기저의 활동은 둘 다 같고, 시기, 형식성, 산출물만 다릅니다. 큰 조직은 둘을 섞는 경우가 많습니다. 안정적이고 높은 보증이 필요한 의무는 공식적으로 명세하고 추적하면서, 제품 동작은 반복적으로 구체화합니다. 이념이 아니라 위험으로 균형을 고르십시오.

장단점

접근 방식	가장 적합한 용도	장점	단점
공식 선행 명세	높은 보증, 규제, 고정 범위 계약	강한 추적성. 분명한 인수 기준. 감사 가능	바꾸기 느림. 배우기 전에 과명세할 위험
애자일 백로그	참여하는 이해관계자가 있는 진화하는 제품	빠른 피드백. 학습에 적응. 만들지 않은 범위에 대한 낭비 감소	장기 추적성이 약함. 감사와 계약이 더 어려움
하이브리드 (공식 제약 + 애자일 동작)	의무가 섞인 기업	중요한 곳에는 엄밀함, 다른 곳에는 유연성	어느 부분이 어느 것인지 판단이 필요

핵심 긴장은 안정성과 학습 사이에 있습니다. 요구사항을 일찍 고정하면 단단한 인수 기준과 감사 가능성을 사지만, 만드는 동안 배운 것에 적응할 능력을 잃습니다. 미루면 적응성을 사지만, 장기 추적성과 계약상의 명확성을 잃습니다. 요구공학에 더 투자하는 것은 단기 속도를 나중의 더 적은 재작업과 맞바꾸기도 하며, 시스템의 규모, 수명, 실패의 결과가 커질수록 본전을 뽑는 거래입니다. 가장 큰 프로젝트와 가장 규제가 심한 것은 확고히 높은 투자 쪽에 있습니다. 위험이 낮은 내부 도구는 그렇지 않습니다.

팀과 논의할 질문

가장 위험이 큰 시스템에서 누가 이해관계자로 꼽히며, 인수 때까지 계속 빠뜨리는 이들은 누구입니까? 큰 프로그램에서 건너뛰는 사람은 눈에 띄는 사용자인 경우가 드뭅니다. 새벽 3시에 그것을 운영하는 운영자, 인증해야 하는 감사자, 실패를 받아 내는 지원 직원, 로그인하지 않지만 여러분이 데이터를 쥐고 있는 영향받는 비사용자입니다. 그들을 놓치면 가장 비싼 순간, 즉 인수 중이나 규제 기관이 물은 뒤에 그들의 요구사항을 발견합니다. 구체적인 이해관계자 지도를 회의에 가져와 압박 시험을 하십시오. 의무화된 각 의무(접근성, 프라이버시, 기록 보존, 보안)에 대해 그것을 소유한 사람과 그것을 포착한 요구사항의 이름을 대십시오. 소유자의 이름을 댈 수 없다면 간극을 찾은 것이며, 해법은 고정된 아키텍처에 나중에 그들의 필요를 소급 적용하는 대신 지금 그 이해관계자를 도출에 추가하는 것입니다.
요구사항이 바뀔 때, 변경을 승인하기 전에 그것이 무엇에 영향을 주는지 답할 수 있습니까? 이것은 양방향 추적성이 진짜인지 장식인지에 대한 실용적 시험입니다. 크거나 규제를 받는 시스템에서 규칙 하나의 변경이 설계, 코드, 테스트, 인수 증거로 파급될 수 있고, 앞을 보지 않고 승인하는 것이 예전에는 충족하던 규칙을 조용히 위반하는 컴플라이언스적으로 보이는 시스템을 출시하는 방법입니다. 최근 변경 요청을 가져와 회의에서 앞으로 추적해 보십시오. 한나절의 고고학이 필요하다면 추적성은 제 역할을 하지 못하고 있습니다. 답은 변경 프로세스를 재편해, 영향 평가가 수동 탐색이 아니라 살아 있는 추적에 대한 빠른 질의가 되고, 기준선과 버전 관리가 변경의 안정된 기준점이 되게 해야 합니다.
요구사항의 단일 권위 있는 출처는 어디에 있으며, 그 밖에 흩어진 진실은 얼마나 됩니까? 요구사항의 난립(진짜 명세가 이메일, 티켓, 슬라이드, 누군가의 기억에 걸쳐 사는 것)은 큰 팀에서 가장 흔한 실패 중 하나이며, 합의된 내용을 보여야 하는 감사 시스템에서는 치명적입니다. 어느 기록 시스템이 정본인지 소리 내어 정하고, 다른 곳에서 말해진 모든 것은 출처와 근거가 붙어 거기에 착지할 때까지 초안으로 다루십시오. 증거를 가져오십시오. 최근 범위 분쟁 중 두 사람이 서로 다른 “최종” 버전을 인용한 건이 몇 개인지 세어 보십시오. 0보다 크다면 행동은 하나의 출처로 통합하고 각 요구사항의 근거를 적는 것입니다. 요구사항이 왜 존재하는지 아는 것이 나중에 그것을 안전하게 바꾸거나 버릴 수 있게 하기 때문입니다.
비기능 요구사항을 아키텍처를 이끌 만큼 일찍 포착합니까, 아니면 구조가 고정된 뒤에 계속 발견합니까? 성능, 가용성, 보안, 접근성 의무는 대부분의 기능보다 더 아키텍처를 형성하며, 큰 프로그램에서는 그것을 충족해야 할 구조가 이미 콘크리트로 굳어진 뒤에야 너무 늦게 드러나는 요구사항인 경우가 가장 많습니다. 상충하는 끌림은 실제입니다. 기능적 동작은 이해관계자가 소리 내어 요청하고 시연이 잘 되는 반면, “피크 부하에서 1초 미만 응답”이나 “WCAG 접근성 적합” 요구사항은 위반되기 전까지 보이지 않습니다. 가장 위험이 큰 시스템의 비기능 요구사항의 현재 목록, 각각이 쓰인 일정상의 시점, 아키텍처(3.1장)가 그것을 명시적 동인으로 받았는지 추론했는지를 가져오십시오. 기업과 정부 환경에서는 의무화된 품질 의무(암호화, 기록 보존, 접근성 법)를 더하고, 각각이 가정이 아니라 설계에 건네지는 서면의 측정 가능한 요구사항인지 확인하십시오. 인수 후에 품질 속성을 소급 적용하는 것이 예산과 일정이 조용히 죽는 곳이기 때문입니다.
우리가 소유한 각 시스템에 알맞은 형식성의 수준은 무엇이며, 위험으로 고릅니까 습관으로 고릅니까? 단일 큰 조직은 보통 버려도 되는 내부 도구에서 생명 또는 안전이 걸린 규제 플랫폼까지 걸친 시스템을 운영하며, 모두에 하나의 의식을 적용하면 위험이 낮은 일을 서류 작업에 묻거나 위험이 높은 일을 과소 명세로 남깁니다. 긴장은 공식 선행 명세의 감사 가능성과 단단한 인수 기준 대 진화하는 백로그의 빠른 피드백과 줄어든 낭비 사이에 있고, 대부분의 기업에 대한 정직한 답은 의도적인 혼합입니다. 안정적이고 높은 보증이 필요한 의무는 형식화하고 추적하면서 제품 동작은 반복적으로 구체화하는 것입니다. 실패의 결과, 규제 노출, 변화 속도로 순위를 매긴 시스템의 짧은 목록을 가져와, 각각에 대해 실제로 쓰는 형식성과 위험이 정당화하는 형식성을 대조하십시오. 공고와 IEEE 29148 같은 표준에 묶인 정부 프로그램에서는 형식성이 부분적으로 계약에 의해 정해지므로, 논의는 감사가 의존하는 추적성을 깨지 않고 어디에 애자일 구체화를 얹을 수 있는가입니다.
가장 위험이 큰 시스템의 모든 요구사항을 검증할 수 있으며, 각각이 요구사항이 쓰인 순간에 쓴 인수 기준을 지닙니까? 검증할 수 없는 요구사항은 요구사항이 아니라 바람이며, “빠른”, “안전한”, “사용자 친화적” 같은 미끄러운 말은 아무도 실패시킬 수 없기 때문에 리뷰를 통과합니다. 큰 팀에서 이것은 두 배로 중요합니다. 검증 불가능한 요구사항은 인수에서 범위 분쟁을 낳고, 기능이 진정으로 완료되었는지 말할 수 없게 만듭니다. 상충하는 고려는 속도입니다. 각 요구사항에 측정 가능한 기준과 검증 방법을 붙이는 것은 산문을 쓰는 것보다 선행으로는 느리지만, 가장 비싼 늦은 재작업에 대한 가장 싼 방어입니다. 최근 요구사항 표본을 가져와 각각을 단순한 기준으로 시험하십시오. 원자적인가, 측정 가능한가, 어떻게 확인할지 이름을 붙였는가. 규제와 정부 맥락에서는 시험을 증거까지 확장하십시오. 추적되고 통과하는 인수 증거가 없는 요구사항은 소프트웨어가 무엇을 하는 것처럼 보이든 전달된 것으로 간주되지 않으므로, 인수 기준은 결국 만들어야 할 컴플라이언스 기록의 씨앗입니다.

분야별 관점

스타트업. 작은 팀과 짧은 런웨이라면 요구사항을 통할 수 있는 가장 가볍게 유지하십시오. 명세 문서가 아니라 하나의 공유 백로그에 인수 기준이 있는 사용자 스토리입니다. 여기서도 본전을 뽑는 규율은 만들기 전에 실제 사용자와 이야기하고 각 스토리의 출처와 근거를 기록하는 것입니다. 그러면 잘못된 기능을 만드는 데 낭비했을 한 주가 아끼는 한 주가 됩니다. 공식 추적성은 건너뛰되, 실제 필요가 무엇인지 알려 주는 대화는 절대 건너뛰지 마십시오.

소기업. 비즈니스 분석가나 요구사항 전문가가 없을 가능성이 크니, 일은 고객과 가장 가까운 사람에게 떨어지고 구매 대 개발의 질문이 지배합니다. 요구사항을 필요한 성과의 짧고 우선순위가 매겨진 목록으로 설명하고, 맞춤 구축을 명세하는 대신 기성 도구를 평가하는 데 쓰십시오. 기저의 필요와 벤더의 기능 목록을 엄격히 구분하십시오. “우리는 제품 X가 필요하다”로 쓰인 요구사항은 진짜 필요를 충족했을 더 싼 선택지를 조용히 막기 때문입니다.

대기업. 규모는 요구사항을 많은 팀이 하나의 일관된 시스템을 만들 수 있게 하는 계약으로 바꾸므로, 일관되게 적용되는 표준 프로세스가 우선입니다. 정의된 범주, 필요에서 테스트까지의 양방향 추적성, 단일 권위 있는 출처, 기준선이 있는 통제된 변경입니다. 비즈니스, 사용자, 시스템 요구사항을 명시적으로 구분하고 비기능 요구사항을 동인으로 아키텍처에 건네, 범위와 품질 의무가 팀 전반에 흩어지지 않게 하십시오. 안정적이고 높은 보증이 필요한 의무에는 공식 명세를, 제품 동작에는 애자일 구체화를 섞고, 어느 한 팀의 선호가 아닌 위험으로 균형을 다스리십시오.

정부. 조달 규칙은 전체 계약을 요구사항 명세 주변에 구축하는 경우가 많고, 흔히 IEEE 29148 같은 표준에 따라 구조화되므로, 정밀성과 완전성은 선택 사항이 아니라 계약적입니다. 각 요구사항을 설계, 테스트 케이스, 인수 증거에 연결하는 요구사항 추적성 매트릭스를 유지하십시오. 벤더 지불, 감사, 운영 허가가 모두 입증된 커버리지에 달려 있기 때문입니다. 투명성과 공적 책임성은 기준을 더 높입니다. 접근성, 프라이버시, 기록 보존에 대한 의무는 각각 명시적이고 검증 가능한 요구사항으로 나타나야 하며, 추적되고 통과하는 증거가 없는 요구사항은 그저 전달되지 않은 것입니다.

사례

스타트업. 일정 관리 앱을 만드는 네 명 규모의 스타트업은 요구사항을 공식 명세가 아니라 공유 백로그의 인수 기준이 있는 사용자 스토리로 포착합니다. 캘린더 동기화 기능을 쓰기 전에 창업자는 오후 한나절을 잠재 고객 다섯 명과 이야기하며 보내고, 진짜 필요가 가정했던 동기화가 아니라 두 도구에 걸친 이중 예약을 피하는 것임을 알게 됩니다. 그 한 번의 대화가 스토리를 재구성하고 잘못된 것을 만드는 한 주를 아낍니다. 이 규모에서도 각 스토리의 출처와 근거를 적어, 우선순위가 바뀔 때 왜 존재했는지 다시 따지지 않고 범위를 버리거나 다시 작업할 수 있습니다.

대기업. 다국적 은행이 대출 개시 플랫폼을 교체합니다. 요구사항 팀은 비즈니스 요구사항(승인 시간 단축, 대출 규제 충족), 사용자 요구사항(대출 담당자가 하나의 화면에서 제안을 비교해야 함), 시스템 요구사항(플랫폼이 세 개의 핵심 시스템과 통합되어야 함)을 구분합니다. 비기능 요구사항(일반 쿼리의 1초 미만 응답, 99.95% 가용성, 개인 데이터 암호화)은 명시적으로 포착되어 동인으로 아키텍처(3.1장)에 건네집니다. 모든 요구사항은 백로그를 거쳐 자동 인수 테스트까지 추적됩니다. 그래서 규제 기관이 특정 대출 규칙이 어떻게 시행되는지 물으면, 팀은 단지 규칙에서 그것을 검증하는 테스트까지의 추적을 따라가면 됩니다.

정부. 한 국가 기관이 공식 공고를 통해 급여 자격 시스템을 조달합니다. 계약은 IEEE 29148에 따라 구조화된 요구사항 명세에 정박되어 있으며, 기능적 자격 규칙, 의무화된 접근성 적합성, 프라이버시와 기록 보존 제약, 보안 통제를 다룹니다. 요구사항 추적성 매트릭스가 각 요구사항을 설계 요소, 테스트 케이스, 인수 증거에 연결합니다. 벤더 지불과 시스템을 프로덕션에서 운영하는 공식 승인인 운영 허가가 모두 입증된 커버리지에 달려 있습니다. 추적되고 통과하는 인수 증거가 없는 요구사항은 소프트웨어가 무엇을 하는 것처럼 보이든 단순히 전달된 것으로 간주되지 않습니다.

비즈니스 사례: 동기, ROI, TCO

요구공학의 경제적 논거는 결함을 늦게 고치는 비용에 있습니다. 산업 연구는 요구사항 결함이 프로젝트 실패의 가장 흔하고 가장 비싼 원인에 속하며, 결함을 고치는 비용이 요구사항 단계에서 프로덕션까지 자릿수 단위로 오른다는 것을 일관되게 발견합니다. 그러니 요구사항을 명확히 하고 검증하는 데 쓴 돈은 사실 지렛대입니다. 초기의 소소한 투자가 잘못된 것을 만들고, 테스트하고, 운영하는 일을 면하게 해 줍니다.

요구사항의 총소유비용에는 시스템의 전체 수명에 걸친 도출, 명세, 도구, 변경 관리의 지속적 노력이 포함되며, 일회성 비용이 아닙니다. 이에 맞서는 것이 나쁜 요구사항의 비용입니다. 재작업, 범위 분쟁, 일정 초과, 실패한 인수, 계약상 위약금, 규제 환경에서는 벌금이나 인가 상실입니다. 리더십에게는 요구사항 성숙도를 위험 감소와 예측 가능성으로 설명하십시오. 요구사항 변동성, 결함 기원, 검증된 필요까지 추적 가능한 전달된 작업의 비율을 추적하고, 이를 프로젝트 관리 예측(10.6장)에 연결하십시오. 수익은 기능으로 나타나지 않습니다. 일어나지 않은 실패와 재작업으로 나타납니다.

안티패턴과 함정

요구사항으로 위장한 해법: 기저의 필요 대신 선택된 기술이나 화면 배치를 명세하여 더 나은 선택지를 막는 것.
모호한 언어: 측정 가능한 기준 없는 “빠른”, “안전한”, “직관적”으로, 요구사항을 검증 불가능하게 만드는 것.
골드 플레이팅: 어떤 이해관계자도 실제로 필요로 하지 않는 요구사항을 포착해 범위와 비용을 부풀리는 것.
누락된 비기능 요구사항: 아키텍처가 고정된 뒤에야 성능, 보안, 접근성 의무를 발견하는 것.
요구사항 난립: 권위 있는 출처 없이 이메일, 티켓, 슬라이드에 흩어진 진실.
얼어붙거나 통제되지 않는 변경: 모든 변경을 거부하거나 영향 평가 없이 모든 변경을 수용하는 것.
추적성 없음: 변경이 무엇에 영향을 주는지, 기능이 왜 존재하는지 답할 수 없음. 감사 시스템에서 치명적입니다.
분석 마비: 동작하는 소프트웨어에서 배우는 것을 늦추는 끝없는 명세.
무시된 이해관계자: 인수 때까지 빠뜨려진 운영자, 감사자, 영향받는 비사용자.

성숙도 모델

1단계, 시작. 요구사항이 암묵적이거나 구두이며, 일관되지 않고 반응적으로 포착됩니다. 범위 분쟁과 재작업이 흔하고, 추적성도, 인수 기준도, 정의된 프로세스도 없습니다.
2단계, 발전. 일부 팀이 요구사항을 적어 두고 프로젝트별로 추적하며, 기본적인 우선순위 지정과 임시방편의 변경 처리가 있습니다. 관행은 있지만 팀과 사람마다 달라서, 범주, 형식성, 품질이 조직 전반에서 일관되지 않습니다.
3단계, 표준화. 표준 요구사항 프로세스가 문서화되어 조직 전체에서 시행됩니다. 정의된 범주, 도출 및 검증 관행, 작성 시점에 첨부되는 인수 기준, 단일 권위 있는 출처, 필요에서 테스트까지의 양방향 추적성이 애자일이나 계획 주도 맥락에 일관되게 맞춰집니다.
4단계, 관리. 프로세스가 데이터로 측정되고 통제됩니다. 요구사항 변동성, 결함 기원, 추적성 커버리지, 검증된 필요까지 추적 가능한 전달된 작업의 비율이 기준선에 대해 추적되고, 추적성은 인수 증거와 컴플라이언스까지 확장되며, 요구사항 지표는 프로젝트 예측(10.6장)에 공급되어 변경과 품질 결정이 의견이 아닌 증거에 근거합니다.
5단계, 오케스트레이션. 요구사항 실천이 지속적으로 개선되고 조직 전체에 통합됩니다. 형식성은 위험과 성과에 따라 적응적으로 조정되고, 도출 및 추적성 도구는 디스커버리, 아키텍처, 전달에 연결되며, 조직은 자신의 측정 이력을 사용해 반복되는 요구사항 결함이 코드에 닿기 전에 예방합니다.

논의를 위한 아이디어

선임 이해관계자가 해법으로 진술할 때, 진짜 요구사항과 성급한 해법을 어떻게 구분합니까?
가장 위험이 큰 시스템과 가장 위험이 낮은 시스템에 알맞은 요구사항 형식성의 수준은 무엇이며, 누가 결정합니까?
빠르게 움직이는 애자일 백로그에서 관료적 오버헤드가 되지 않으면서 양방향 추적성을 어떻게 최신으로 유지합니까?
조직에서 어떤 비기능 요구사항이 가장 자주 너무 늦게 발견되며, 그 이유는 무엇입니까?
규제 프로그램에서 요구사항이 충족되었다는 충분한 인수 증거는 무엇입니까?
AI 지원 도출 및 명세 도구가 요구사항 실천을 어떻게 바꿔야 하며, 어떤 새 위험을 도입합니까?

핵심 요점

요구사항은 해법이 아닌 필요와 제약을 진술합니다. 필요하고, 모호하지 않고, 검증 가능하고, 추적 가능해야 합니다.
기능, 비기능, 제약 요구사항과 비즈니스, 사용자, 시스템 수준을 구분하십시오.
실제 이해관계자에게서 도출하고, 분석하고 우선순위를 정하고, 알맞은 형식성으로 명세하고, 만들기 전에 검증하고, 변경을 관리하십시오.
필요에서 인수 증거까지의 양방향 추적성은 특히 규제 환경에서 책임성의 척추입니다.
애자일과 계획 주도 맥락은 같은 활동을 공유합니다. 시기, 형식성, 산출물이 다르니 위험으로 고르십시오.
나쁜 요구사항의 비용은 늦게 치러지고 곱해집니다. 일찍 투자하는 것은 재작업과 실패한 인수에 대한 지렛대입니다.

참고 문헌과 더 읽을거리

IEEE and ISO/IEC, Guide to the Software Engineering Body of Knowledge (SWEBOK), Software Requirements knowledge area
Karl Wiegers and Joy Beatty, Software Requirements
ISO/IEC/IEEE 29148, Systems and software engineering: Life cycle processes: Requirements engineering
Suzanne Robertson and James Robertson, Mastering the Requirements Process
Dean Leffingwell, Agile Software Requirements
Mike Cohn, User Stories Applied
Ian Sommerville, Software Engineering (requirements engineering chapters)