프로젝트 요구 사항을 수집하는 가장 좋은 방법은 무엇입니까?

Question

시스템 엔지니어링 또는 제품 요구 사항을 수집하는 방법은 무엇입니까? 예를 들어 자동차를 만들고 싶다면 요구 사항을 어떻게 수집해야합니까? 친절하게 안내 해줍니다.

Answer 1

이것은 실제로 정말로 큰 질문입니다. 내가 제기 할 답은 "그것이 달려있다"이다. 요구 사항을 수집하는 것은 매우 어려운 일입니다. 요구 사항을 수집하는 가장 좋은 방법은 프로젝트 방법론에 따라 다릅니다. 먼저 반복 접근법이나 폭포 접근법을 사용할 것입니까? 또한 프로젝트 이해 관계자 (예 : 프로젝트 관리자, 개발자, 비즈니스 분석가, 고객, 프로젝트 스폰서 ...)를 결정해야합니다. 그러면 프로젝트 이해 관계자가 원하는 것을 이야기해야합니다.

비즈니스 분석가가 원하는 바를 모두 말하면 고객이 원하는 것을 설명하는 데 도움이됩니다. 분석가는 요구 사항을 파헤쳐 야합니다. 많은 경우 고객은 개발자가 이해할 수있는 방식으로 시스템을 설명하는 방법이나 실제로 원하는 것을 알지 못합니다.

이 단계의 첫 번째 단계는 프로젝트 범위를 설명하는 것입니다. 좋은 범위가 식별되면 어떤 요구 사항이 범위에 있는지 또는 범위를 벗어나는지를 결정할 수 있습니다. 그 후 요구 사항을 식별하는 가장 좋은 방법은 문제를 논의하고 문제를 해결하려는 것입니다. 요구 사항 단계에서 솔루션을 작성하지 말고 최종 제품이 수행해야 할 작업에 대해 설명하십시오.

Becareful은 너무 적은 시간을 들여 요구 사항을 수집하지 않습니다. 나중에 프로젝트 라이프 사이클에서 변경하는 사항이 많을수록 변경 작업을 수행하는 것이 더 비쌉니다. 또한 요구 사항을 완성하는 데 너무 많은 시간을 투자하지 마십시오. 그렇지 않으면 "분석 마비"에 빠지게됩니다. 이 점들은 단지 표면을 긁는 것임을 명심하십시오. 칼 E. Wiegers에 의해

칼 E. Wiegers에 의한 소프트웨어 요구 사항 소개

더

이은을

소프트웨어 요구 사항 2 판 : 여기이 정보의 일부를 읽고 몇 가지 괜찮은 책입니다 괜찮은 책 들이며 그들은 여러 시청자를위한 SRS 준비에서부터 "요구 사항 추출"에 이르기까지 모든 주제에 관해 이야기합니다."

Answer 2

시스템 분석이라고합니다 - 당신은 가서 제품의 사용자가 될 것입니다.

Answer 3

나는 아마도 준비로 시작할 것입니다. Gathering Requirements 그러면 체크 아웃 Joel On Software과 37Signals입니다. 요구 사항 문서 작성과 관련하여 적절한 정보가 있습니다. Joel on Software 사이트는 example입니다.

Answer 4

클라이언트에서 얻은 요구 사항을 기록하려면 SRS document을 사용하십시오.

Answer 5

1. 사람들과 이야기하십시오 - 특히 프로젝트 이해 관계자와 사용자.
2. 질문하기 그들 중 많은 것들.
3. 토론 및 결론을 문서화하십시오.
4. 결론을 검증하기 위해 프로토 타입을 사용하십시오.

Answer 6

는 일반적으로 당신이 한 번에 여러 개의 마스터를 제공하는 것을 기억하는 것이 도움이된다 :

1. 최종 사용자
2. 관리
3. 귀하의 디자인 환경과는

을 부과 어떤 제한

가장 좋은 점은 위의 모든 항목과 함께 시간을 보내는 것입니다.

tance : 저는 최근에 패키지 배달 회사를 위해 처음부터 시스템을 프로그래밍하기 위해 고용되었습니다. 최종 사용자 (드라이버 - 간단하고 신속하게) 관리 (모든 사람이 언제, 어떻게했는지 알고 싶음)를 기쁘게해야했습니다. 제한적인 환경에서 작업하는 것 (모바일 스캐너)

나는 관리와 많은 시간을 보낸 다음, 돌아 서서 운전사와 함께 배달에 나갔다. 그 이후에야 나는 정말로 그 일을 처리 할 수있었습니다.

기억해야 할 중요한 점은 처럼 클라이언트가 매일 직면하는 문제를 실제로 해결하는 솔루션을 생각해내는 것이 아닙니다. 당신이 이것을 할 방법은 그들이 일을하는 동안 그들과 약간의 양질의 시간을 보내는 것입니다.

마지막 포인트를 문명화 할 가치가 있습니다. 일을하는 동안 일을 처리하는 중입니다 ... 단지 물어 보면 불완전한 답변을 얻게 될 것입니다. 대부분의 사람들은 자신의 직업에 대해 더 이상 생각조차하지 않는 많은 일을합니다. 단지 습관이되었습니다. 처음 업무 경험 없이는 새로운 시스템에 포함 시켜서 포함시키기 란 어려운 일입니다.

방법 대신 도구를 요청하는 경우 사과드립니다. 고객과 특히 미래의 사용자와 키 - 사용자

와

Answer 7

• 일반 토론은 공식 요구 사항 목록을 작성하고 승인을 위해 그것을 제시 각 대화 후 회담
• 동안 작은 메모를. 나중에 동의 한 모든 문서에 대해 논쟁하기가 어려울 것입니다.
• 고객이 "필요 이상"요구 사항을 이행하기위한 대략적인 비용과 시간을 대략 알고 있는지 확인하십시오. 고객이 그 유형의 차이점을 이해하고 있는지 확인하십시오.
• 모든 문서를 최신 및 최종 요구 사항 분석에 통합하십시오 (또는 현재 반복 또는 기타 요구 사항 분석을 위해). 당신이 사용하고있는 민첩한 프로그래밍 사이클 ...)
• 이 요구 사항은 소프트웨어 수명주기에 따라 변화 할 것을 기억 때문에 모임이 있지만, 관리하고 다른
• KISS를 구현하는 한 가지입니다 -
• 이 민첩 선언문을 읽어 가능한 한 간단하게 - 소프트웨어를 작업하는 유일한 측정입니다 소프트웨어 프로젝트의 성공을 위해
• 미래 시스템이 상주 할 환경을 연구하십시오. 회사가 투자 한 돈을 쓰레기통에 던지기를 원하지 않기 때문에 레거시 또는 주변 시스템의 기술적 제약이 점점 더 커지고 있습니다. 현대인의 마음 속에 20 년이 넘은 코드가 쓰레기 일지라도 수십 년 동안 ...