사용자 스토리와 요구 사항


33

User Story는 사용자가 시스템에서 수행하려는 작업을 높은 수준으로 캡처합니다. 사용자 스토리는 여러 가지 낮은 수준의 요구 사항을 추가로 추진할 것임을 이해합니다. 사용자 스토리는 시스템의 높은 수준의 요구 사항과 동일합니까?


"사용자 스토리는 사용자가 시스템으로하고 싶은 일을 높은 수준으로 포착합니다 ." 나는이 논쟁을 고려한다. 상위 레벨기능 레벨 로 바꾸면 나에게 동의합니다 .
8bitjunkie

답변:


52

솔직히 말해서 민첩한 개발에 2 년 가까이 투자 한 후에도 "사용자 사례"는 "기능적 요구 사항"이라는 멋진 용어라고 생각합니다.

피상적 인 수준에서는 다릅니다 . 예를 들어 항상 특정 형태 ( "X, Y는 Z를 원합니다 ..." )를 취하지 만, 이해 관계자와 이론적 근거를 식별하는 핵심 요소도 고유하게 내재되어 있습니다. 서면 기능 요구 사항. 나쁜 요구 사항을 작성하는 것만 큼 나쁜 사용자 스토리를 작성하는 것만 큼 쉽습니다 ( "[회사 이름], [모호한 기능]을 원합니다. '고객에게 더 많이 판매하십시오'] " ).

내 경험상 사용자가 거의 포착 하지 못하는 것은 성능 및 보안과 같은 비 기능적 요구 사항입니다. 이러한 종류의 요구 사항은 제대로 작성하기가 매우 어렵고 사용자 스토리의 형식은 특정 사용자의 요구를 충족시키기보다는 일반적인 제품 품질과 위험을 완화 (그러나 제거하지는 않음)에 관한 것이기 때문에 단순히 캡처하기에 좋지 않습니다. 필요한 것.

따라서 저는 사용자 사례를 특정 공식을 사용하여 요구 사항 의 하위 집합 으로 생각 하며 용어를 거의 상호 교환 적으로 사용합니다.

사용자 요구 사항이 요구 사항을 능가하는 주요 이점 중 하나는 "요구 사항"이라는 단어 가 종종 원하는 곳에 기능이 필요 하다는 것을 나타냅니다 . 이론적으로 사용자 스토리는 모든 릴리스에 대해 우선 순위를 매기고 슬롯에 넣을 수 있지만 요구 사항은 모든 릴리스 의 전제 조건 인 것으로 보입니다 .

물론, 위에서 언급 한 차이가 중요하기 위해서는 고객 및 / 또는 고위 경영진이이를 수용해야합니다. 30 개의 사용자 스토리가 모두 동시에 완료되어야하는 "프로젝트"로 그룹화되어 있다면 아무 소용이 없습니다. 이 경우에는 실제로 필요하기 때문에 "요구 사항"이라고도합니다.


모든 답변은 내 이해에 도움이되었고, 모두 올바른 것으로 표시하고 싶었습니다 :)
Punter Vicky

5
동의하지 않습니다. 요구 사항은 사용자가 시스템과 상호 작용하는 방식, 기능의 목적에 대한 이야기에 중점을 둡니다. 그것들은 완전히 다릅니다.
Sklivvz

1
@ Sklivvz : 나는 사용자가 시스템과 상호 작용하는 방식에 대해 말하지 않는 사용자 이야기를 읽은 적이 없다고 생각합니다. 앞서 말했듯이 좋은 요구 사항에는 목적 진술이있어서 이해할 수 있습니다. 문맥. 어떤 이유로 많은 사람들이 "전통적인 요구 사항 = 나쁜 요구 사항"과 "사용자 사례 = 좋은 요구 사항"이라고 자동으로 가정하는 것 같습니다. 반드시 사실도 아닙니다. 예를 들어 "EVO" 를 예로 들어 모든 요구 사항을 비즈니스 목표뿐만 아니라 실제 메트릭과 연결합니다.
Aaronaught

1
@ 한 졸로 : 이제 그것은 바보입니다. 작업은 방식으로 기능 요구와 같은 유용 할 너무 세분화. 작업은 "지 블러 라이브러리를 사용하여 프린지 파서를 구현"과 같이 고도의 기술 수준에서 자주 언급됩니다. 당신은 할 수 어쩌면 좀-그렇다고-거의 같은 것으로 작업을위한 케이스 만들기 사양을 하지만, 사람들은 온 요구 사항. 사용자 스토리는 함께 해야하는 허용 기준 - 사람들은 더 많은 / RUP 형 모델 폭포에 사용 된 상세한 기능 요구 사항 등이다.
Aaronaught

2
@ Sklivvz : "무엇"은 일반적으로 사용자와 시스템 간의 상호 작용입니다. "응답에 대한 총 투표 수를보고 싶습니다"는 사용자 스토리의 중간 부분에 대한 전형적인 예이며 기능 요구 사항과 거의 동일하게 표시됩니다 ( "사용자가 답변에 대한 총 투표 수를 볼 수 있어야합니다") . 만 부분이다 "이유는"은과 "사람" 표면 상 추적 시스템 다른 많은 요구 사항 / 방법론 다른 사용자 스토리보다는 그 잘 제공 할 것으로 기대합니다.
Aaronaught

16

Ron Jeffries는 카드에 중점을 둔 사용자 설명 ( http://xprogramming.com/articles/expcardconversationconfirmation/ ) 에 대해 오래 전에 글을 썼습니다. 대화가 끝난 후 실행 가능한 스토리가 확인되었습니다.

본질적으로 대화하기 전에 사용자 스토리는 계획된 범위입니다. 대화가 끝나면 이야기가 완료되었음을 확인할 수있는 방법이 있어야합니다. 따라서이 타임 라인에서 스토리를 볼 때 시간에 따라 스토리는 범위 또는 자세한 요구 사항에 대한 광범위한 아이디어 일 수 있습니다.

요즘 "사용자 이야기"의 의미는 Jeffries 3C의 "카드"부분으로 좁혀진 것 같습니다. 이 경우 사용자 스토리는 요구 사항이 아니라 요구 사항에 대한 대화를 약속합니다.

C2 Wiki ( http://xp.c2.com/UserStory.html ) 에서 사용자 스토리에 대한 수많은 지식을 얻을 수 있습니다.


7

사용자 스토리와 요구 사항은 매우 다릅니다.

요구 사항

요구 사항은 응용 프로그램의 디자인이 미리 수행되고 개발이 해당 디자인의 구현임을 전제로합니다. 따라서 요구 사항 은 기능을 구현하는 방법 에 중점을 둡니다 .

요구 사항의 예 :

  • 이름, 성, 이메일, 자유 텍스트 및 제출 버튼 필드를 사용하여 사용자 문의 양식을 작성하십시오. 제출 버튼을 누르면 지원팀으로 이메일이 전송됩니다.

사용자 스토리

사용자 스토리는 무엇 을 달성 해야하는지 에 초점을 맞추고 제품 설계는 마지막 순간에 수행되며 제품 담당자와 개발자 간의 공동 작업이라고 주장합니다. 세부 사항은 기회를 기반으로 구현 중에 결정됩니다.

이야기의 예 :

  • Jimmy 사용자로서 사이트를 제대로 사용할 수 없어 도움을 줄 수있을 때 지원 팀에 문의하고 싶습니다.

차이점은 무엇입니까?

보시다시피, 제공된 세부 사항의 양에는 분명히 차이가 있지만 이야기에서만 사용할 수있는 많은 정보, 즉 우리 가이 기능으로 달성하려고 하는 목적 이 있습니다.

목적이 상대적으로 중요하지 않은 것으로 보이지만 민첩한 개발에서는 잘못된 가정입니다. 일반적으로 목적을 아는 것이 중요하다는 두 가지 경우가 있습니다. 기회 비용을 줄이고 민첩성을 가능하게합니다.

기회 비용

요구 사항에 숨겨진 가정이있는 경우 달성하기가 매우 어려울 수 있습니다. 예를 들면 다음과 같습니다. 사용 가능한 메일 서버가 있습니까? 그렇지 않은 경우 요구 사항을 개발하는 데 시간이 훨씬 오래 걸릴 수 있습니다. 다른 경우에는 설계로 인해 동일한 목표를 달성하는 간단한 방법을 놓칠 수 있습니다.

반대로 사용자 스토리는 지원 부서에 문의하는 사용자에 관한 것입니다. 메일을 발송할 수 없거나 너무 비싸다면 다른 해결책을 찾아 낼 수 있습니다. 예를 들어, 데이터베이스에 쓰거나 Google 문서를 통해 양식을 사용하거나 양식 대신 이메일 주소를 입력하십시오. 요구 사항으로는 쉽게 수행 할 수 없지만 스토리와 제품 담당자가 쉽게 수행 할 수 있습니다.

민첩

이러한 이유로 요구 사항이있는 경우 일반적으로 이러한 숨겨진 가정을 미리 생각하고 장애가 없는지 확인합니다. 따라서이 경우 미리 예약 된 다른 요구 사항이있을 수 있으므로 메일 서버가 있어야합니다.

인 이야기와 요구 사항 사이의 또 다른 큰 차이점이 리드 우리를 계층 구조 . 위에서 예시 한 바와 같이, 요구 사항은 그 자체의 특성상 의존성이 충족되도록 일부 자연 계층 구조로 정렬되어야합니다. 반면에 이야기는 목적에 중점을 두며 그러한 제약은 없습니다.

민첩하게 설계되었으므로 프로젝트 실행 중에 필요에 따라 스토리를 추가, 제거, 일정 변경 및 수정하는 것이 기본적으로 중요합니다. 일반적으로 요구 사항을 추가하거나 수정하거나 제거 할 수 있지만 모든 종속성으로 인해 요구 사항을 옮기는 것은 일반적으로 매우 고통스러운 일입니다. 단순히 자주 수행되지는 않습니다. 요구 사항을 다루는 경우 변화를 수용 할 수 있다는 의미에서 민첩한 구현에 어려움이 있거나 전혀 민첩하지 않을 수 있습니다.


6
요구 사항이 "사용자 연락 지원을 받자"라는 잘못된 길을 찾았다 고 이야기합니다. 이야기는 세부 사항을 추가하여 의미가있는 것으로 정의하는 방법입니다. 어쩌면 그것은 용어에 달려 있기 때문에 우리는 아무것도 아닌 것에 대해 모든 것을 망칠 것입니다.
gbjbaanb

2
나는 그들이 틀리지 않았다고 확신합니다.
Sklivvz


15
"따라서 요구 사항은 기능 구현 방법에 중점을 둡니다." -이것은 매우 잘못되었습니다. 요구 사항이 무언가를 수행하는 방법을 말하면 좋은 요구 사항이 아닙니다. 알려진 제한 조건이없는 한 요구 사항에는 설계 또는 구현 세부 사항이 포함되지 않습니다. 샘플 "요구 사항"을 본 경우 바로 그 사실을 거부합니다. 구현 세부 사항을 지정합니다.
Thomas Owens

4
요구 사항 엔지니어링에 대한 교육 및 경험과 여러 (고평가되고 자주 인용되는) 소스가 다른 점을 알려줍니다. 무언가를 성취하는 방법에 대해 말하면 디자인 작업을 완료 한 것입니다. 모형은 디자인이며 요구 사항이 아닙니다. 형식에 관계없이 요구 사항은 디자인 선택 자체가 아니라 "디자인 선택을 주도하는 모든 것"입니다. 본인은 사용자 사례가 기능 요구 사항을 캡처하는 한 가지 형식에 불과하다는 Aaronaught의 답변에 전적으로 동의합니다.이 답변의 대부분은 일반적으로 허용되는 용어와 관련하여 잘못되었습니다.
Thomas Owens

6

나에게 사용자 스토리의 중요한 요소는 사용자가 시스템을 사용하는 이유와 방법을 캡처한다는 것입니다. 시스템이 필요한 기능을 제공하는 방식을 많이 지정하지 않기 때문에 특히 유용합니다. UI 및 사용성 테스트가 필요한 경우 사용자 스토리가 가장 중요한 문서 일 수 있습니다.

물론 셀레늄이 특정 노드가 HTML에 있는지 확인하거나 스크린 샷을 찍거나 특정 픽셀이 원하는 위치에 있는지 확인할 수 있습니다. 그러나 오해의 소지가있는 텍스트가 있거나 사용자가 시스템을 어떻게 사용해야하는지 명확하지 않거나 목표를 달성하는 방법을 이해하기 어려운 경우 갑자기 더 이상 완전한 시스템이 없습니다. 이제 시스템을 사용하려면 교육이 필요합니다. 사용자 시나리오에 대해 완성 된 시스템을 검토하는 것은 수동 테스트의 중요한 구성 요소입니다.

사용자 스토리 / 시나리오에는 캡처에 대한 많은 세부 설계 결정에 영향을 미치는 사고 방식이 있습니다. 개발자가 사용자와 직접 대화하거나 시스템을 사용하는 것을 관찰하지 않는 한 사용자 시나리오는 사용자 요구를 이해할 수있는 유일한 링크 일 수 있습니다.

마지막으로, 비즈니스 사람들은이를 달성하는 방법을 제안하지 않고도 필요한 것을 지정할 수 있습니다. 요구보다 솔루션을 설명하는 것이 훨씬 쉽고 사용자 시나리오는 특정 솔루션을 제안하지 않고 요구를 설명하기위한 프레임 워크를 제공합니다. 내가 들었던 가장 일반적인 비즈니스 요구 사항은 "실제로는 실제로는 필요하지 않은 Excel과 같지만 웹에 있기를 원합니다."입니다.

따라서 좋은 이야기에는 시스템 구현 방법에 대한 특정 세부 정보가 포함되어서는 안된다고 말하고 싶습니다. "한 달에 한 번 시스템 A는 시스템 B의 새 데이터로 업데이트해야합니다. 해당 데이터를 수정해야 할 수 있습니다. 클라이언트에 잘못된 데이터를 입력 한 기록이 있지만 몇 주 동안 문제를 실현하지 못했습니다." "시스템은 적어도 한 달에 한 번은 latin1 CSV 파일을 수락하고 열 3이 숫자가 아닌 경우 NumberFormatException을 발생시켜야합니다." 차이점이 보입니까? 시나리오는 특정 솔루션이 아니라 필요를 설명합니다. 그런 다음 테스트에서 시나리오로 돌아가 솔루션이 필요에 맞는지 확인하십시오. 요구 사항은 일부 요구 사항을 일부 솔루션과 혼합하거나 솔루션에 전적으로 집중할 수도 있습니다.


고마워 글렌! 그러나 그 문제에 대한 요구 사항이나 사용자 스토리가 시스템 / 솔루션에 무관심해서는 안됩니까? 이 질문은 사용자 스토리 / 요구 사항을 만들 때 계속해서 고민하고 있지만 여러 사례에서 성공적으로 할 수 없었던 질문입니다.
Punter Vicky

시스템이 해결할 비즈니스 문제에 대해 사용자에게 물어 보면서 시작할 수 있습니다. 지금이 문제를 어떻게 처리합니까? 시스템이 있으면 같은 방식으로 작업 하시겠습니까? 이제 누가 이런 일을합니까? 그들은 어디에서합니까? 가장 일반적인 과제는 무엇입니까? 이론적으로 요구 사항은 시스템에 무관심해야한다. 그러나 연습은 더 지저분합니다. 나는 아무것도하지 않아도 돈을받을 수있는 방식으로 나를 위해 모든 일을하는 시스템을 원합니다. 그것은 시스템에 무관하지만 쓸모가 없습니다. 우리가 관심을 갖는 것은 개발 팀이 구축 할 수있는 요구 사항입니다.
GlenPeterson

3

Google 검색 중이 문제에 걸려서 내 의견을 던질 것이라고 생각했습니다.

요구 사항과 사용자 스토리 사이에는 실제로 차이가 없습니다. 둘 다 사용자 관점에서 원하는 결과 또는 목표를 나타냅니다.

유일한 차이점은 비즈니스 분석가가이 목표 또는 결과를 포착하는 방식입니다. 이 경우 그것은 표현에있다.

예:

팀장으로서, 저의 팀 중 어느 팀이 모기지 사건을 다루고 있는지보고 그들의 성과를 모니터 할 수 있기를 원합니다.

이 솔루션은 모기지 사건에 대해 작업하는 팀원을 표시해야합니다.

위의 두 가지 모두 같은 방식으로 해석 될 수 있지만 두 가지 모두 모호합니다. 여기서 중요한 점은 스타일의 차이입니다. 우리가 주로 보는 문제는 요구 세계에서 기능 설계 세계로 이동하기 전에 솔루션을 정의하는 데 얼마나 먼가입니다. 비즈니스 분석가가 "기본 응용 프로그램 메뉴에 이름으로 로그인 한 사용자를 나열"하거나 너무 많은 정보를 표시 하는가? 우리가 이해 관계자들과 대화를 나눌 때 우리 모두가 해결책을 알고 그것이 어떻게 보일지, 가능한 코드 언어와 전개 방법을 해석 할 수있을 때, " 솔루션이 아닌 목표를 정의 해 봅시다. " 이것이 내가 혼란을 느끼는 곳입니다.

요구 사항은 종종 솔루션에 대해 원하는 결과 만 알지 못한다고 가정합니다. 예, 이것이 모든 솔루션을 불가피하게 만들지 만 개발주기에서 실제로 우리에게 도움이됩니까? 무언가를 정확하게 정의 할 수 있다면 왜 그렇게하지 않습니까?

사용자 스토리와 요구 사항의 차이점에 대해 걱정하지 않아도됩니다. 궁극적으로 솔루션을 개발하기 위해 충분한 정보를 정의하려고합니다. 너무 높은 수준의 사용자 스토리는 단순히 취소되고 더 작은 사용자 스토리로 분류되도록 요청됩니다. "시스템은"스타일과 동일합니다. 세부 사항이 충분하지 않으면 요구 사항이 너무 모호한 것으로 간주 될 수 있습니다.

결국 개발자와 이해 당사자가보고 싶어하는 일과 함께 진행하십시오.


3

고전 교과서에서도 단어 요구 사항의 의미에 대해 많은 불일치가 있다고 생각합니다. 사용자 사례에도 동일한 불일치가 적용됩니다. 여러 조직과 교과서에서 이러한 용어를 다르게 취급합니다. 예를 들어 Roger Pressman의 고전적인 소프트웨어 엔지니어링 교과서에서 요구 사항에 대해 말하는 방식은 Dean Leffingwell의 Agile Software Requirements 책과는 상당히 다릅니다. 나는 둘 다 존중하고 둘 다 유효 할 수 있습니다.

요구 사항은 상상력에 거의 남지 않고 특별한 특이성을 갖는 코딩 대상이 될 수 있습니다. 반면에 요구 사항은 비즈니스 문제점을 지정하고 솔루션을 지정하지 않아야한다고 주장 할 수 있습니다. 나는 그것이 더 뉘앙스가 있다고 생각하며 대답은 각 회사와 산업에 고유 한 스펙트럼에 있습니다 (모든 소프트웨어 개발이 IT에서 발생하는 것은 아닙니다).

요구 사항 추출 은 분석으로 이어지고, 디자인으로 이어지며, 요구 사항을 구체화 하는 아키텍처로 이어집니다. 하거나 사양화하여 코딩 할 수있는 무언가로 이어지는 . 나는 이것이 민첩하게 사라진다고 생각하지 않습니다. 이런 일이 발생하는시기는 변하기 때문에 가장 중요한 차이점입니다. 폭포수 모델에서는 추출과 정교화가 일찍 발생합니다. 린 (lean)과 스크럼 (scrum)에서는 스프린트에서 구현에 가까워 질수록 정교함과 정교함이 다양한 단계에서 발생합니다. 새로운 디자인 작업과 마찬가지로.

우리 조직에서는 Leffingwell의 Epics, 기능 및 스토리 모델을 요구 사항이 아니라 작업 분류 및 우선 순위 지정으로 기울이고 있습니다. 요구 사항은 다릅니다. 규제 기관에 대한 요구 사항이 있기 때문에 요구 사항은 별도로 관리됩니다. 그러나 일부 팀은 프로그램 증분 및 스프린트 계획 중에 사용자 스토리 내에서 요구 사항을 확실히 개발하고 있습니다.


2

기능 요구 사항은 일반적으로 소프트웨어가 작동하는지 여부를 정확하게 알 수있는 공식 사양입니다. 사용자 스토리는 일반적으로 사용자 스토리의 필요성을 설명하는 훨씬 비공식적 인 방법입니다. 소프트웨어가 "유효한지"또는 "유효하지 않은지"확인하기 위해 엄격한 사양을 지정하지 않습니다. 당신은 그것의 일부를 테스트 할 수 있지만, 사용자 스토리 (실제로 올바르게 수행하는 경우)의 실제 완성은 사용자가 "그래, 내 문제를 해결한다!"라고 말할 때입니다. 민첩한 선언문을 기억하십시오.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Mike Cohn은 자신의 저서 인 "User Story Applied"에서 일부 내용은 사용자 사례에 매핑되지 않으므로 그저 사용할 필요는 없다고 구체적으로 말합니다.

우리 팀에서는 다음을 사용합니다.

  • 사용자 스토리 : 어떤 종류의 사용자의 비즈니스 요구. 여기에서 강조는에 필요 하고, 하지 그는 그것을해야합니다. 다른 사람들이 말했듯이 여기서 중요한 것은 수행 방법을 지정하지 않고 사용자의 실제 요구에 깊이 들어가는 것입니다 (예 : 테이블에서 데이터를 볼 필요 가 없으며 정확한 값을 볼 필요가 있음) 데이터, 그리고 그는 그 일을하는 테이블에 익숙합니다).
  • 버그 : 정상적인 사용을 방해하는 소프트웨어의 예기치 않은 동작. 일반적으로 "중요도"(개발 우선 순위와 무관)가 사용자 워크 플로우에 미치는 영향을 평가합니다.
  • 기술 부채. 사용에게 소프트웨어의 사용을 방해하지 않고 손상됩니다 뭔가 우리 미래에, 개발자를. 예 : 일부 클래스는 읽기가 어렵고 빌드가 느리고 코드가 단위 테스트되지 않았으며 IDE에 이상한 경고가 표시됩니다 ...
  • 개선 : 새로운 시나리오를 허용하지 않지만 더 나은 경험을 제공하는 소프트웨어 변경. 예 : 글꼴 변경, 더 명확하게 만들기 위해 양식 디자인, 응용 프로그램에 적절한 기본값 추가 등

기능적 요구 사항으로 인해 오이 테스트를 통과하고 모든 서면 단어를 구현하더라도 구현 한 기능으로 사용자의 요구를 해결할 수는 없습니다. 이야기는 토론이며 비공식적입니다. 요점은 구현 담당자가 문제가 무엇인지 이해하는 것입니다. 계약 도구가 아닙니다. "스크럼 하지만 ... "을하고 당신의 이야기가 단순히 소프트웨어의 요구 사항을 작성하는 재미있는 방법이라면, 그렇습니다 . 차이 는 없습니다 .

요점은 사용자 이야기가 아니라 요점은 수행하려는 작업에 접근하는 방식에서 패러다임의 큰 변화입니다. 계약을 체결하지 않고 일부 사용자가 문제를 해결하도록 돕고 있습니다. 사용자 스토리가 실제 사용자 와의 토론 도구로 표시 되지 않으면 사용자 스토리를 사용하지 않고 펑키 한 요구 사항 구문을 사용하는 것 입니다.

나머지는 제 의견입니다. 사용자 이야기는 결코 일방적으로 성공할 수 없습니다. 고객과 함께 일해야합니다. 워터 스크럼 폴은 이상한 요구 사항이지만 요구 사항은 아닙니다. 당신이 반복하고 사용자 스토리를 사용하지 않는 특정 요구 사항에 고정 입찰 계약을하는 경우가 없다 어떤 점 . 자동화 된 장치 / 기능 테스트, 코드 검토, 지속적인 통합, 리팩토링 등의 민첩한 툴킷의 나머지 부분을 사용하십시오. 소프트웨어가 지속적으로 작동하고 즉시 통지 할 수 있는지 확인하십시오. 고객에게 가능한 한 많은 피드백을 제공 할 수 있도록 완성되지 않은 형태로 제공하십시오. 만약 당신이 내 친구라면 "User story"와 "Scrum"을하지 않더라도 소위 "Agile"상점보다 더 민첩했을 것입니다.


2

나는 모든 사람들이 과거 경험에 따라 다르게 모든 것을 구현하고 레이블을 붙일 것이라고 믿고, 그 회사에서 어떤 언어를 사용하든 그 일을 끝내는 것은 가치가 없다고 생각합니다.

그러나 IMO, 사용자 스토리는 Agile의 "건물에있는 고객 또는 고객이 즉시 이용 가능"접근 방식을 따르며, 세부 사항은 고객의 머리에 있고 쉽게 이용할 수 있으므로 문서가 필요하지 않은 공식 SRS 필요하지 않습니다. 이제 "사용자 스토리"의 "작업"은 개발자가 소화 가능한 사용자 스토리를 구축하는 방법입니다.

사용자 스토리의 예는 다음과 같습니다.

관리자로 그리드에 나열된 고객 데이터를보고 싶습니다

"작업"은 다음과 같습니다.

  1. 표시 할 데이터를 나열하는 그리드 만들기

  2. 선택한 열을 정렬하는 그리드에서 정렬 사용

이제 각 작업은 각각의 스프린트로 추정되고 완료됩니다.

"고객"이 파악하기 어려운 "전통적인"관점에서, 우리는 계획 / 코딩을 시작하기 바로 전에 고객이 보유하고 있음을 확인할 수 있도록이를 기록해야합니다. 고객의 머리 속에 떠오른 아이디어가 될 것입니다.

이 경우 "기능 요구 사항"은 해당 SRS의 핵심 세부 사항이며 더 큰 아이디어의 일부입니다. 제 생각에 사용자 스토리는 공식적인 "요구 사항"의 일부로 볼 수 있으며 해당 사용자 스토리의 작업은 기능적 요구 사항 중 하나입니다.

예제 사용자 사례에서 공식 "요구 사항"은 플로우 차트가 포함 된 긴 문서이며 일반적으로 고객 중심의 "애자일"접근 방식과 달리 문서 중심적입니다.

차이점은 공식적인 "요구 사항"은 일부 목록이 필요함을 나타내는 앱의 관리 섹션과 역할 기반 보안 등을 나타내는 약 10 페이지 문서의 행을 따라가는 것입니다. 요구 사항은 "목록 그리드 정렬 가능", "사용자 정보가 그리드에 나열되어야 함"등입니다.

그리고 요즘에는 용어가 모두 섞여 섞여 있다고 믿습니다.


2
"고객이 이용 가능하므로 정교화 할 필요가 없습니다"라는 개념은 제가 "나쁜 애자일"이라고 부르는 것의 일부입니다. 애자일의 진정한 본질은 "빅뱅"으로 모든 것을하는 것과 달리 스프린트로 계획하고 기능을 점진적으로 제공한다는 것입니다. 그러나 실제로 장기적으로 민첩하게하려면 테스트가 필요하며 테스트를 작성하거나 수행하려면 애자일 랜드에서 요구 사항과 동일한 수락 기준의 형태로 제공되는 사양이 필요합니다. 시스템이나 프로젝트보다는. "요구 사항"이 거대하고 먼지가 많은 오래된 문서라는 아이디어는 단지 FUD입니다.
Aaronaught

@Aaronaught 동의합니다. 고정 구현 예산이있는 상황에서 특히 범위가 제한되는 지점이 있어야합니다. 예산이 고정되어 있지만 제품 설계를 알 수없고 프로젝트가 빨리 진행되어야하는 경우 민첩한 작업 (및 스프린트에서 진행중인 지속적인 소프트웨어 제품 개발 활동 인 경우 (예 : 실제 프로젝트가 아닌 경우)) 범위를 사용하여 제한해야합니다. 폭포 접근 방식을 사용하는 경우 요구 사항 자체 (
구체적

@Aaronaught-당신은 절대적으로 옳습니다 .. 그러나 애자일은 XP 방법론에서 비롯된 것이며 당신이 언급 한 프로세스는 두 세계의 최고로부터 빌려온 하이브리드입니다. "문서가 많은"문서가 있습니다. 균형을 찾는 것은 프로세스를 정의하는 회사에 의해 결정됩니다.
hanzolo

@ ssbrewster-나도 동의합니다. 각 방법론, 워터 폴 및 애자일의 순수한 형태에서, 하나는 문서화 된 요구 사항에 대한 문서화 및 검증이 필요하고, 다른 하나는 개발 노력에 대한 문서화 및 검증이 거의 필요하지 않을 것이다.
hanzolo

1
@ssbrewster 그것은 단지 범위를 제한하는 것이 아니라 이야기가 실제로 끝났을 때 말할 수있는 것입니다. 비즈니스에서 손을 떼지 않고 결정을 내릴 수 없다면 일관된 품질의 제품을 만들거나 속도와 같은 것을 정확하게 측정 할 기회가 없습니다. 우리는 합격 시험 에 합격 기준을 문서화하는 것을 선호 하지만 여전히 기록되어 있습니다.
Aaronaught
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.