기능 요구 사항에 대한 사용자 스토리 [폐쇄

Question

우리는 소규모 회사 인 것처럼 프로젝트 관리자와 개발자로 일하고 있습니다. 클라이언트를 위해 제작 한 사양에는 프로젝트를 설명하고 정의하는 데 사용되는 여러 요소가 포함되어 있으며, 프로젝트 (예 : 와이어 프레임, 사용자 플로우, 사이트 맵 등)를 클라이언트에 정의하기 위해 포함되어야한다고 생각하는 다른 요소와 함께 사용자 스토리를 포함하여 프로젝트를 정의합니다.

기능 사양이“제품의 관점에서 전적으로 작동하는 방법을 설명하는 경우. 사물이 어떻게 구현되는지는 신경 쓰지 않습니다. 그것은 특징에 대해 이야기합니다. 그렇다면 사용자 스토리를 사용하여 웹 사이트의 기능 사양을 정의하는 데 문제가있는 사람이 있습니까? 실제로 이런 식으로 기능 사양을하는 사람이 있습니까?

실제로 나는 내 게임을 조금씩 올리려고 노력하고 있으며, 이것이 기능 사양에 포함되어야하는 내용에 대한 더 엄격한 아이디어를 가지고있는 더 큰 고객에게는 이것이 접근 할 것인지 궁금해하며 공식적인 접근이 필요할 수 있습니다. 현재 고객이 문서를 작성하는 방법에 잘 대응합니다.

프로젝트 관리를하는 사람들이 이것에 대해 전문적으로 생각하는 것을 듣는 데 관심이 있습니다.

Answer 1

나는 다른 두 사람이 말한 것과 상충됩니다.

먼저 내가 동의하는 비트는 - 스토리는 기능적 요구 사항을 진술하는 좋은 방법입니다. 내 돈을 위해 그들은 최종 사용자가 실제로 취할 수있는 방식으로 실제로 요구 사항을 전달하는 가장 좋은 방법 중 하나입니다. 나는 읽지 않고 서명 된 너무 많은 사양을 보았습니다.

내가 그들에게 추가하고 싶을 수도있는 한 가지는 성능, 보안, 데이터 볼륨, 감사, 아카이브 등을 다루는 비 기능적 요구 사항입니다. 그들은 이야기로 덮을 수 있지만 때로는 모든 이야기를 가로 지르는 방식으로 더 잘 포함됩니다.

대기업에게 적합한 지에 대한 측면에서 이것은 내가 동의하지 않는 곳입니다. 내 경험에 따르면 (그리고 나는 Shell, American Express, 다국적 은행 및 기타 몇 개를위한 프로젝트를 수행했습니다) 그들은 종종 소규모 회사보다 더 공식적이지 않으므로 이야기에 괜찮을 것입니다. 현실은 대기업의 사용자가 다른 곳보다 클래스 및 시퀀스 다이어그램을 읽는 데 더 나은 장비 (또는 관심이 없음)가 아니라는 것입니다.

프로젝트의 규모와 복잡성에는보다 자세한 요구 사항이 필요할 수 있지만 요구 사항을 문서화하는 방법을 결정할 때 중요한 회사 규모가 아니라 프로젝트의 규모입니다.

저에게 가장 좋은 요구 사항 문서는 청중에게 적합한 문서입니다. 저에게 사용자 이야기는 대부분 머리에 못을 박았습니다. 서명 할 때 서명 할 때 무언가를 의미 할 정도로 충분히 짧고 분명합니다. VE는이를 읽고 이해했습니다 (100 페이지 사양의 사인과는 반대로 실제로 읽지 못했음을 의미하는 100 페이지 사양의 사인과는 반대로). 그러나 개발자가 작업하기에 충분히 좋습니다.

Answer 2

예, 기능 요구에 사용자 스토리를 사용할 수 있습니다. 나는 항상 그것을하고 몇 년 동안 그랬습니다. 제 생각에는 제가 사용한 다른 시스템보다 실제로 잘 작동하며 더 잘 작동합니다.

이 접근법이 더 큰 고객에게 효과가 있을까요? 심한 일반화를 위해, 아니요. 그들은 요구 사항을 정의하는 데 사용하는 일부 시스템을 가질 것이며 아마도 사용자 스토리가 아닐 것입니다. 사용자 스토리가 들어 오면 현재 관행과 연결이 끊어 질 것입니다.

나는 대규모 조직과의 사용자 스토리를 사용하여 성공했지만 양 당사자가 약속 해야하는 공동 노력이 필요합니다.

Answer 3

당신이 설명하는 것은 기능을 정의하는 사용 시나리오입니다. 이것은 사용성 관점에서 요구되는 것이며 클라이언트가 이해하고 동의 할 것입니다. 화면 모형 및 흐름도는 클라이언트와 개발자 모두에게 도움이됩니다.

그런 다음 실제 구성에 포함되어야 할 사항을 개발자에게 지시하려면 구현 사양이 필요할 수 있습니다.이 깊이는 집 아키텍처/프레임 워크 및 방법론/관습에 대한 지식을 포함하는 개발자 기능에 의해 결정됩니다. 응용 프로그램의 다양한 부분에 어떤 영향을 미치는지.

우리는 또한 소규모 팀 (때로는 하나 또는 두 개의 개발자)에서 일하며 위의 내용 이이 경우에 필요한 전부라고 생각합니다.

팀이 훨씬 큰 대기업은 모델링 소프트웨어, UML 다이어그램 및 기타 자세한 사양을 사용할 수 있습니다. 기본 개발자 인 경우 애플리케이션을 설계하는 데 시간을 보내야하지만 아무도 디자인을 검토하고 모든 형식을 고집하지 않으면 소프트웨어를 구현하는 데 더 나은 시간을 소비합니다.