사양의 모호성을 어떻게 해결합니까?

https://stackoverflow.com/questions/626737

06-07-2019
|

문제

애플리케이션 사양 내 모호성을 해결하는 방법에 대한 조언이 필요합니다.간단한 예로,

사용자가 여러 번 인증에 실패하면 IT에 알림을 보냅니다.

위의 예에서는 "a number of times"이 몇 번인지 명확하지 않습니다.명확하지 않으며 단순히 1000회와 같은 무작위 제한을 설정할 수 없습니다.

어떤 사양에서든 불분명한 부분을 어떻게 해결하시겠습니까?(제가 언급한 것 뿐만이 아닙니다)

그리고 또 어떤 종류의 주제 이런 경우에는 Google에서 검색해야 하나요? 아니면 책을 검색해야 하나요?소프트웨어 공학?민첩한 개발?어디서부터 시작해야할지 모르겠습니다.

도움이 되는 노하우와 팁을 알려주시면 감사하겠습니다.

해결책

공식적인 방식으로 요구 사항을 추적하는 경우 가정을 만들어 파생 요구 사항으로 문서화 할 수 있습니다.

예시:

사용자 요구 사항 :

REQ 1 : 여러 번 사용자가 인증하지 못하면 알림을 보냅니다.

파생 요구 사항 :

Req 1.1 3 번의 시도 후 사용자가 인증하지 못하면 시스템은 계정을 중단하고 IT 지원 데스크에 이메일을 보냅니다.

REQ 1.1.1 계정 서스펜션 이메일은 다음을 지정합니다.

사용자의 계정 이름.
인증 시도가 이루어진 컴퓨터의 IP 주소.

고객을 사용할 수없는 경우 고객 또는 이해 관계자를 보관하고 파생 요구 사항을 검토 및 승인하십시오.

자세한 내용은 Google "요구 사항 관리"또는 "요구 사항 엔지니어링" 국방 산업 부문은입니다 짐을 실은 예제와 템플릿, 아마도 너무 많을 것입니다;)

일부는 북마크를 사용했습니다.

다른 팁

정확한 질문으로 고객에게 응답하십시오. 가능한 경우 최선의 선택입니다. 그렇지 않은 경우 최종 사용자 (클라이언트)가 구성 할 수 있도록하십시오.

(바람직하게는 순서대로)와 의사 소통합니다.

비즈니스 분석가
클라이언트 (개인) 최종 제품에 대한 지불)
최종 사용자

그것을 빌드하거나 프로토 타입으로 한 다음 사양을 쓴 사람들에게 보여줍니다.

모호성은 실제 일에 대해 이야기함으로써 사물이 어떻게 작동하는지 말하는 종이 대신에 문의하면 훨씬 쉽게 청소하기가 훨씬 쉽습니다.

당신은 이것을 지나치게 생각하고 있습니다.

'횟수'값은 웹에 쉽게 넣을 수 있습니다.
가정 된 적절한 값으로 설정하십시오. (틀린 것에 대해 걱정하지 마십시오)
가정과 함께 관리자에게 이메일을 보내고 가정이 잘못된 경우 어떻게 변경할 수 있는지 이메일을 보내십시오.

다른 모든 앱 알림이 이메일 (비현실적이지 않음) 인 경우 사양의 알림 부분을 가정 할 수 있습니다. 그렇지 않으면 무엇이든하기 전에 물어보십시오.

나는 물론 설명을 요구하는 것에 반대하지 않습니다. 그러나 나는 가정을 만들 수 있는지 발견했다 단점이 거의 없거나 전혀 없습니다, 그렇게하는 것이 가장 좋습니다. 결국 그들은 문제를 해결하기 위해 당신을 고용했습니다. ;-)

그리고 이상하게도 충분히; 아마도 대부분의 가정이 어쨌든 정확할 것임을 알게 될 것입니다.

그 예에서, 나는 클라이언트로 돌아가서 "횟수"를 구성 할 수 있는지 물어볼 것입니다. 또한 다음과 같은 질문으로 이어질 수도 있습니다.

1) 누가 구성된 횟수를 유지할 것인가. 2) 이러한 설정을보고 변경하려면 UI가 필요합니다.

보다 민첩한 개발 프로세스를 채택하는 것도 도움이 될 것입니다. 예를 들어, 로그인 할 수있는 세 가지 기회를 허용하는 예를 보여 주면 기능이 입증되고 숫자를 알려 주도록 자극 할 수 있습니다.

요구 사항을 명확히하는 것의 중요성은 질문에 대한 답변이 프로젝트의 시간, 복잡성 및 비용에 영향을 미칠 곳이 변경됩니다.

누가 이용 가능한가에 따라 모호함을 처리할 수 있는 몇 가지 다른 경로가 있습니다.

1) 프로젝트 관리자/비즈니스 분석가 -> 사양 관련 문제를 신속하게 해결하는 데 도움이 될 수 있는 프로젝트에 가장 가까운 사람일 가능성이 높습니다.여기에는 다른 사람에게 물어보고 나중에 다시 연락하는 것이 포함될 수 있지만 이는 허용될 수 있습니다.

2) 전문 분석가/담당자 -> 예를 들어, 보안 관련 사항이 있는 부분을 언급하는 경우 이에 대해 시행할 정책이 있을 수 있고 토론에 참여해야 하는 보안 담당자가 있는지 여부입니다.또 다른 예는 경우에 따라 유용할 수 있는 하드웨어 관점에서 아키텍처를 살펴보기 위해 네트워크 분석가를 두는 것입니다.

3) 제품 소유자 -> 애플리케이션 정의를 담당하는 사람입니다.이 사람은 기술적인 사람이 아니므로 구체적으로 설명하고 권장 사항을 제시하는 것이 "알다시피, 그런 건 생각하지 못했어요..."라는 응답을 받는 경우 유용할 수 있습니다.

4) 그룹장/팀장 -> 모두 실패하면 상사에게 가서 설명을 요청한다.

"요구사항 수집" 또는 "요구사항 분석"은 "소프트웨어 개발 수명 주기" 또는 "시스템 개발 수명 주기"의 이 부분에 대한 일반적인 용어로, 검색할 수 있는 몇 가지 용어를 더 추가하고 많은 기사를 찾을 수 있습니다.

가장 좋은 방법은 다양한 옵션이 사용자에게 어떤 영향을 미치는지 설명하는 간단한 대체 사용자 스토리 (사용 사례)를 작성하고 고객에게 지원 해야하는 것을 선택하도록 요청하는 것입니다.

종종 사양의 모호성은 고객의 마음에 모호함을 반영합니다. 그들은 단순히 그것을 아직 스스로 파악하지 못했기 때문에이 접근법은 두 사람 모두에게 도움이됩니다. (서면 노트 사용 - 기술이 없음 - 용어로 사물을 설명합니다.)

사양이 정확하지 않다면 아마도 중요하지 않습니까? 다른 일이 작동하는 것이 중요하지 않습니까? 전화를 걸어 그것 1000이 되십시오. 하드 코딩되지 않은지 확인하십시오. 좋은 아이디어는 일부 구성 파일에 넣는 것입니다 (사용자는 일반적으로 귀하보다 아이디어가 훨씬 적기 때문에 최종 사용자 인터페이스에 노출되지는 않습니다).

상호 운용성의 문제라면 다른 사람들은 무엇을합니까? ~이다 그것 Windows에서 200 개? 200. 이제 창과 사양과 일치합니다. 나쁘지 않습니다 :-)

당신이 당신의 전화가 나쁘고 그것 1500 명이어야했는데, 최소한 소프트웨어를 다시 설치하지 않고 사용자에게 수정하는 방법을 알려줄 수 있습니다.

기업 기업에서는 이것이 일반적인 기업 정책을 따른다는 것을 의미합니다.

실제로 사양을 직접 작성할 때, 나는 이러한 일반적인 사양을 귀찮게하지 않고, 정책을 참조하고 특정 비즈니스 요구 사항의 핵심으로 바로 이동한다고 말합니다.

이를 위해 포커스 그룹을 만들거나 고객/적절한 이해 관계자와 의사 소통 할 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow