프로젝트 요구 사항을 이해하는 방법을 보여주는 방법

Question

고객/고용주가 자신의 요구 사항을 어떻게 이해했는지 어떻게 나타 냅니까?

무엇을 사용 하시겠습니까? 유스 케이스 다이어그램? 흐름 차트? 데이터 흐름 다이어그램? 결정 나무?

저는 매우 자세한 답변을 요구하지 않았습니다. 요구 사항을 작성한 사람과 의사 소통하고 두 사람이 같은 페이지에 있는지 확인할 수있는 간단한 내용.

Answer 1

저는 보통 프로젝트의 초기 단계에서 프로젝트의 고차원적인 개요와 몇 가지 아키텍처 다이어그램 (더 간단할수록 좋음) 및 스크린 모형/와이어 프레임을 제공합니다. 그런 다음 요구 사항 검토를위한 "시작"회의를 가지며 비즈니스 문제와 제안 된 솔루션을 통해 이야기합니다.

Answer 2

흐름도는 기술 흐름이 아닌 사람 (예 : 클라이언트)과 데이터 흐름 다이어그램을 혼동하는 경향이 있습니다. 사용 사례는 비즈니스 요구 사항 및 기술 요구 사항 문서뿐만 아니라 이해할 만하고 이해하기 쉽고 일종의 대략적인 와이어 프레임 스케치가 가능합니다.

Answer 3

간단히 말해서 자신의 언어로 요구 사항을 설명하고, 가정을 제공하고 제한을 추가합니다.

요구 사항이

나는 사용자가 버튼을 클릭하면 좋아, 그래서, 버튼의 배경색이 녹색으로 바뀌면 "물어 보곤"클릭시 버튼이 녹색으로 바뀌면 "하지만 텍스트가 같은 색을 유지 할 수있다 ? "

기본적으로 요구 사항을 제시하는 사람에게 어떻게 작동하는지 설명하는 메시지를 표시합니다.

Answer 4

정말 필요한 요구 사항에 따라 달라집니다.

• 기능 요구 사항? 어쩌면 그 UML을위한 도구입니다. 하지만 테스트를 선호하는 테스트 사양
• GUI 요구 사항? 아무것도 종이와 연필을 이겼습니다.
• 보안 요구 사항? 보안 한계를 설명함으로써 예기치 않은기만을 피할 수 있습니다.
• 신뢰성 요구 사항? 테스트 메카니즘과 소프트웨어/하드웨어 백업/복구 계획.
• 기타 요구 사항 : 클라이언트에 따라 다릅니다.

어쨌든, 개발 단계에서 요구 사항이 변경되고 항상 비용과 기능성간에 토론 및 절충안임을 클라이언트에게 설명하십시오. 정직하게 행동하면 고객에게 더 많은 확신을 줄 수 있습니다.

Answer 5

나는 클라이언트의 아이디어를 실제로 이해하고 있다는 것을 보여주는 가장 좋은 방법은 프로토 타입을 만드는 것이라고 생각한다.

내가 요구 공학 컨퍼런스의 마지막 에디션과 워크샵 (MERE) 중 한 곳에서 지낸대로, 지멘스는 클라이언트 아이디어 비디오를 제작하여이를 기반으로 흥미로운 소프트웨어를 보여주었습니다 (프로젝트가 아니라 소프트웨어에만 국한) 모든 요구 사항을 완벽하게 이해할 수 있습니다.

어떤 방법 으로든, 어떤 경우에는 그 (것)들을 보여주는 창조적 인 방법이 더 낫다. 자신을 표준 다이어그램으로 제한하지 마십시오.

Answer 6

내 역할에 많은 요구 사항이 있습니다. 내가 찾은 가장 좋은 방법은 두 가지 갈래의 접근 방법이며, PowerPoint 프레젠테이션을 통해 간단하고 높은 수준으로 유지하면서 개념 증명 또는 실물 크기의 모형을 보여주는 것입니다. 고객을 걷고 이야기하면 "나는 색을 틀어 줄 수 있습니까?"와 같은 많은 "what if 's"로 응답하는 것을 볼 수 있습니다. 이것은 모두에게 그들이 얻고있는 것에 대한 폭 넓은 아이디어를 제공합니다. 뭔가를 얻을 수 있다면 사용자는 터치하고 놀 수 있습니다. 정말 잘 작동하면 숨겨진 것을 밝혀 낼 수 있습니다.

그런 다음이 세부 수준을 매우 세부적인 하위 수준 요구 사항으로 되돌립니다. 점으로 된 "i"를 철자하고 "t"를 넘어 섰습니다. POC가 끝나기 전에 사용자가 읽을 수 있도록 서명하십시오. 일반적으로 스크린 샷이 많은 단어는 잘 작동합니다.

사용자가 UML 및 데이터 흐름 차트를 가져올 수있는 경우가 아니면 고객이 보거나 표시 한 내용에 사용하지 마십시오. 고객이 서명하고 "what if"를 충족시키기 위해 백엔드를 regig해야만한다면 모든 것을 사임해야합니다.

마지막 사항은 고객이 자신의 요구 사항에 대해 자신의 말로 이야기하고 그들이 얻는 바를 자세히 설명 할 수 있도록하는 것입니다. 이를 수행하는 한 가지 방법은 중간 관리자가 상위 관리자에게 판매하는 것입니다.

마지막 순간에 변경된 사항을 원할 경우 비용을 시간과 비용으로 설명하고 필요한 경우 고객에게 물어보십시오. 이렇게하면 사람들이 사소한 변화를 일으키는 것을 막고 종종 변화를 원하는 이유를 생각하게 만듭니다.

요구 사항은 고객이 원하는 것을 원하는대로 얻는 것입니다.

편집 - 스크린 샷을 일찍 표시하는 시점까지는 고객에게 시간 척도와 모든 정보를 알려주는 좋은 PM이 필요한 경우가 있습니다. PM이 적절한시기와 기대를 설정하는 데 도움이된다면 고객은 흥분하지 않을 것입니다. POC와 스크린 샷의 좋은 점은 사람들이 자신이 좋아할 수있는 것의 이미지를 얻고 종종 마음 속에서 그렇게 할 수 있다는 것입니다.

스크린 샷을 피하려면 와이어 프레임 모양을 사용하거나 화이트 보드와 20 분의 그림을 사용하십시오. 사진을 찍기 전에 화이트 보드를 사진으로 저장하는 것을 잊지 마십시오.

화이트 보드 (및 오래된 OHP)는 요구 사항 수집에 도움이 될 수 있습니다. 그리기 개념의 선명한 스타일을 개발하면 워크샵에서 시간을 절약 할 수 있습니다.

Answer 7

나는 도메인과 그 의미와 관계의 용어를 사용하여 간단한 어휘를 만드는 데 좋은 경험을 가졌으며 그 다음에 그것을 통해 모든 사람들이 모든 것에 동의하는지 확인했습니다.

어휘를 쓰고 토론하면 "나중에 알아낼 것"이라고 생각하기보다는 생각하게됩니다.

물론 기능 요구 사항 사양 및 가능한 프로토 타입과 같은 다른 방법과 함께 사용해야합니다.