사양 작성에 대한 몇 가지 질문이 있으며 다음과 같습니다.
소프트웨어 사양을 작성할 때 "사용자 요구 사항 정의"주제에서 "기능"및 "제약 사항"만 지정해야합니까?
"사용자 인터페이스"가 "기능"또는 "제약"에 해당됩니까?
소프트웨어가 깨질 수있는 주요 핵심 영역 (요구 사항)은 무엇입니까 (예 : UI)?
답변:
내가 수집의 큰 팬이 아니다 동안 모든 앞까지 상세 요구 사항을 (그들이 아닌 사소한 프로젝트의 과정을 통해 너무 많은 변경 될 수 있습니다로) 당신은 요구 사항 문서를 작성하는 경우,의 Volere 요구 사항 명세 템플릿은 훌륭한 가이드 .
일부 프로젝트에서는 과도 할 수 있지만이 요구 사항에 해당 항목이 필요하지 않은 목록을 정신적으로 확인하는 경우에도 고려해야 할 사항에 대한 훌륭한 점검 목록을 제공합니다.
템플릿에 대한 자세한 정보 링크는 다음과 같습니다.
http://www.volere.co.uk/template.htm
템플릿 자체 (및 실제로는 템플릿보다 약간 비싸고 전체 템플릿 텍스트를 포함하는 요구 사항 프로세스 마스터 링 책 )에는 각 섹션에서 수행해야 할 사항에 대한 다양한 섹션 내에 많은 정보, 예제 및 조언이 포함되어 있습니다.
위의 링크에서 인용 한 섹션의 요약은 다음과 같습니다.
프로젝트의 목적
이해 관계자
강제 제약
명명 규칙 및 정의
관련 사실 및 가정
작업의 범위
비즈니스 데이터 모델 및 데이터 사전
제품의 범위
기능 및 데이터 요구 사항
룩앤필 요구 사항
사용성 및 인류 요구 사항
성능 요건
운영 및 환경 요구 사항
유지 관리 및 지원 요구 사항
보안 요구 사항
문화 및 정치 요구 사항
법적 요구 사항
미결 문제
상용 솔루션
새로운 문제
작업
신제품으로의 마이그레이션
위험
소송 비용
사용자 설명서 및 교육
대기실
솔루션에 대한 아이디어
소프트웨어에서 Joel을 읽는 것이 좋습니다. 특정 질문에 대한 답변인지 확실하지 않지만 기능 사양 작성의 의미에 대한 훌륭한 개요를 제공합니다 .
스펙의 가장 중요한 기능은 프로그램 을 설계하는 것 입니다. 직접 코드를 작성하고 자신의 이익을 위해서만 사양을 작성하더라도 프로그램 작성 방법 (세부 사항을 자세히 설명)을 작성하면 실제로 프로그램을 설계 해야합니다.
... 인간의 언어로 제품을 디자인 할 때 몇 가지 가능성에 대해 생각하고 디자인을 수정하고 개선하는 데 몇 분 밖에 걸리지 않습니다. 워드 프로세서에서 단락을 삭제할 때 기분이 좋지 않습니다. 그러나 프로그래밍 언어로 제품을 디자인 할 때 반복적 인 디자인을 수행 하는 데 몇 주가 걸립니다 . 더 나쁜 것은, 코드를 작성하는 데 2 주를 소비 한 프로그래머는 아무리 잘못해도 해당 코드에 첨부 될 것입니다 ...
... 사양을 작성할 때 프로그램이 한 번만 작동하는 방식 만 전달 하면 됩니다. 팀의 모든 사람이 사양을 읽을 수 있습니다. QA 직원은 프로그램이 어떻게 작동하는지 알고 테스트 할 대상을 알 수 있도록 읽습니다. 마케팅 담당자는이 정보를 사용하여 아직 생성되지 않은 제품에 대한 웹 사이트에 모호한 증기 백서를 작성합니다. 비즈니스 개발 사람들은 제품이 대머리와 사마귀와 물건을 어떻게 치료할 것인지에 대한 이상한 환상을 돌리기 위해 그것을 잘못 읽었지만 투자자를 얻습니다. 개발자는 어떤 코드를 작성해야하는지 읽습니다. 고객은 개발자가 지불하고자하는 제품을 개발하고 있는지 확인하기 위해이 내용을 읽습니다. 기술 작가는 그것을 읽고 좋은 매뉴얼을 작성합니다 ...
사양이없는 경우이 모든 통신 은 반드시 수행되어야 하지만, 이 기능은 ad hoc 이므로 발생합니다 . 품질 보증 사람들은 다짜고짜 프로그램과 주위 바보, 뭔가의 외모가 홀수, 그들이 가서 프로그래머를 중단하면 다시 한번 그들에게 물어 다른 것은이 일에 생각하는 방법에 대한 바보 같은 질문을 ...
자세한 사양이 없으면 일정을 세우는 것이 불가능합니다 ... 너무 많은 프로그래밍 조직에서 디자인 논쟁이있을 때마다, 정치적 이유 때문에 아무도 결정을 내릴 수 없습니다. 따라서 프로그래머는 논쟁의 여지가없는 것들에 대해서만 작업합니다. 시간이 지남에 따라 모든 어려운 결정은 끝까지 밀려납니다. 사양을 작성하는 것은 사양이 없으면 크고 작은 자극적 인 디자인 결정을 내리는 좋은 방법입니다. ..
소프트웨어 사양을 작성할 때 "사용자 요구 사항 정의"주제에서 "기능"및 "제약 사항"만 지정해야합니까?
요구 사항은 두 가지의 조합입니다 ...
"사용자 인터페이스"가 "기능"또는 "제약"에 해당됩니까?
마지막 질문에서 확인한대로 "사용자 인터페이스"가 요구 사항 범주가 될 것입니다.
소프트웨어가 깨질 수있는 주요 핵심 영역 (요구 사항)은 무엇입니까 (예 : UI)?
소프트웨어에 따라 다릅니다. 시스템의 일부를 기준으로 요구 사항을 그룹화하거나 유스 케이스 또는 기능이 충족되는 비즈니스 요구 사항을 기반으로 요구 사항을 그룹화 할 수 있습니다.
물론이 모든 것은 소프트웨어 시스템에 대한 명확하고 명확한 테스트 가능한 설명을 결정하는 실제 목표에 부수적 인 것입니다.
요구 사항의 주요 요구 사항은 테스트 가능하다는 것입니다. 요구 사항을 테스트하는 방법을 알 수 없으면 작성자가 의도 한 방식으로 구현되지 않을 가능성이 있습니다.
필자는 기능 및 제약 조건으로 만 제한되는 요구 사항 문서를 보지 못했지만 이와 같은 구조를 갖는 데는 가치가 있습니다. 필자는 요구 사항을 "소프트웨어가 수행해야하는 작업"으로 분류하고 소프트웨어를 따라야합니다. "
사용자 인터페이스에는 두 범주 모두에 대한 요구 사항이 있다고 생각합니다.
제약 사항 :
기능 :
Start키를 누르면 소프트웨어가 WOPR에 대한 TCP / IP 연결을 설정해야합니다 "