2014-02-20 1 views
6

SRS 문서와 두 회사 (한개는 소프트웨어 프로젝트를 공급하고 다른 하나는 고객)와 공식 계약을 맺은 관계에 대해 항상 궁금해했습니다.SRS 문서와 소프트웨어 개발 계약서 체결 (b2b)

최초 계약서 서명 이전이나 이후에 SRS 문서를 작성해야합니까? B2B 관계에있는 두 파트너가 계약으로 사용할 수있는 공식 문서로 서 있습니까?

+4

이 질문은 비즈니스 관행에 관한 것이므로 도움말 센터에서 정의한대로 프로그래밍하지 않기 때문에이 질문을 주제로 끝내기로합니다. – TylerH

답변

0

SRS와 계약 간의 관계는 임의적이며 계약 당사자들이 계약을 체결하고자하는 협력 방식에 따라 다릅니다. 주요 모드는 다음과 같습니다.

  • 폭포 : 계약서는 구현해야하는 완전히 완성 된 SRS를 나타냅니다. 변화는 값 비싸고 복잡합니다.
  • 민첩 시간 & 물질 없음 SRS는 정면, 몇 사용자 사례 첫번째 반복을 채우지하는
  • 민첩 정가 : @Matthias로서
0

두 밝혔다 이전의 혼합물, SRS의 관계 문서 및 계약은 공동 작업 모드에 따라 다릅니다.

SRS 문서는 계약 전에 고객이 요구 한대로 개발되도록 functional and non-functional requirements and implementation goals must be clear으로 작성해야합니다. SRS를 클라이언트의 사인 오프 및 승인을 요구하는 산출물 문서이기 때문에

SRS는 문서는 an official document and can be used for legal settlements입니다.

0

소프트웨어 요구 사양은 ‘must have’ 문서 중 하나이며 업무 및 기술 팀에도 똑같이 중요합니다.

SRS는 솔루션 아키텍처를 포함한 모든 고급 또는 저수준 기술 사양을 준비하기위한 technical team의 기초 문서 역할을합니다. 나는이 문제가 아니기 때문에 기술적 측면에서 더 많은 것을 추가하지 않을 것이다.

이제 비즈니스와 특히 계약에 관해서, SRS는 두 비즈니스 간의 안전한 교신으로 통신하고 작동합니다. 여기에는 완전한 소프트웨어 및 서비스 제공 업체가 제공하는 것에 대해 소비자가 기대할 수있는 내용이 나와 있습니다. 즉, 양 당사자는 대화하고 협상 할 근거를 얻습니다.

이상적으로 SRS를 준비 할 때 product scope, business function, area of coverage, future directio과 같은 점을 포함하고 목록이 계속 올라갑니다. 그리고이 문서는 나중에 제품 소유자와 최종 사용자를 포함한 이해 관계자가 ‘signed’에게 알려줍니다. 이 agreement gives both parties a structured understanding of their responsibilities.

따라서 나에게는 SRS 초안이없는 프로젝트를 시작할 가능성이 적습니다.

마지막으로 저는 소프트웨어 개발 프로세스를 배우고 싶었습니다. 아시다시피, 우리는 소프트웨어 개발의 삶을 단순화하기 위해 따라야 할 소수의 개발 프로세스를 가지고 있습니다.예 : Waterfall, VModel, RUP, URUP, Agile are some of them.

다음과 같은 특정 프로세스와 관계없이 다음을 제공 할 수 있습니다.

  1. 즐거운 여행 끝에 소프트웨어 개발 및 그것은 관리입니다.
  2. 에는 변화하는 비즈니스 요구를 조정하고 채택 할 수있는 능력이 있습니다.

고객의 마음이 바뀌면 어떻게됩니까?

고객은 change을 개발 과정에서 염두에 두어야합니다. 이러한 변화는 다른 과정에서 다르게 처리됩니다. waterfall의 경우, 변경 요구 사항 또는 추가 요구 사항은 변경 요구 사항 관리 프로세스를 거쳐야합니다. 이렇게하면 시간과 비용을 의사 소통하고 수량화하는 데 도움이됩니다. agile의 경우, 우리는 사용자 스토리에 영향력, 비용 등을 추가/업데이트/우선 순위 지정해야합니다.

허용 된 답변 중 하나는 기민성에서 ‘no upfront SRS’입니다. 나는 그것이 ‘no complete SRS upfront’로 reworded 선호합니다. 즉, 비즈니스 성격 상 완벽한 SRS를 얻지 못할 가능성이 적습니다. 그러나 이것이 SRS가 없다는 것을 의미하지는 않습니다.

결론적으로 SRS는 외부 고객을 상대 할 때 반드시 있어야하는 문서 여야합니다. 따라서 조직에서 어떤 프로세스를 따르는지는 중요하지 않습니다.