How to verify that the written requirements statement is an appropriate requirement?(작성된 요구사항 명세서가 적절한 요구사항인지를 확인하는 방법?)


  1. Are reviewers easy to understand? If you do not know what you mean, it is necessary to supplement it.

  2. Can testers be tested on a requirement basis? Can I draw a picture of the test environment or test method? Do you think you can take the test?

  3. Is the scope defined in the requirements described in terms of the interface of the requirements? Not surprisingly, it is surprisingly useful and it is good to judge whether the requirements are appropriate with this standard. Of course, if you have not defined a scope or interface, then from that …

  4. Can you design a detail from requirements? It would be fine if you could describe the details from the designer’s point of view, but what does that mean? You need to review it once again to see if it needs to be modified.

related link

개발 프로세스의 불명확한 이해로 인해 발생되는 엉망진창 개발 사례

Project가 실패하는 이유(Why projects fail?)

challenges of software projects

SECTION 3 요구사항 정의 단계

IEEE 830-1998 Recommended Practice for Software Requirement Specification

좋은 요구사항의 특성

요구사항.. 어떻게 작성해야 좋을까?

제목: 작성된 요구사항 명세서가 적절한 요구사항인지를 확인하는 방법?

  1. 검토자가 이해하기 쉬운가? 무슨 말인지 모른다면 보완이 필요한 일이다.

  2. Tester가 요구사항 기반으로 시험을 할 수 있는가? 시험 환경이나 시험 방법에 대한 그림을 그릴 수 있는가? 시험을 할 수 있을 것 같은가?

  3. 요구사항에서 정의한 scope에서 요구사항의 interface를 기준으로 기술되었는가? 당연한 말 같지만, 의외로 유용하며, 이 기준으로 요구사항이 적절한지의 여부를 판단하기 좋다. 물론 scope이나 interface를 정의하지 않았다면, 일단 그것부터..

  4. 요구사항으로부터 detail한 설계를 할 수 있을까? 설계자의 관점에서 구체적인 내용을 기술할 수 있다면 괜찮겠지만, 그게 무슨 의미인가? 한다면 다시 한번 해당 항목의 수정이 필요하지는 않은지 검토해야 할 필요가 있다.

관련 링크

개발 프로세스의 불명확한 이해로 인해 발생되는 엉망진창 개발 사례

Project가 실패하는 이유(Why projects fail?)

challenges of software projects

SECTION 3 요구사항 정의 단계

IEEE 830-1998 Recommended Practice for Software Requirement Specification

좋은 요구사항의 특성

요구사항.. 어떻게 작성해야 좋을까?

Advertisements

Engineering effort및 일정을 최소화하기 위한 프로젝트 관리


비용 및 일정을 줄이는 것은 고객의 니즈와 당신의 조직에게 아주 효과적인 방법이다.

이 전략을 적용하기 위한 지표들로는 다음과 같은 것들이 있을 수 있다.

  • engineering months by product/component/activity
  • engineering months by defects/enhancements
  • defect and enhancement request counts
  • counts of remaining critical and serious defects
  • calendar time by phase and activity
  • code stability(% of code changed)
  • size(NCSS, tasks, objects, components)
중요 특징들 엔지니어링 노력 및 스케줄의 최소화
중요 비즈니스 요인 신제품 개발에 대한 경쟁력 압력 및 비용 제어
가장 중요한 시점 여러 경쟁사들이 제품을 만든다면 당신들은 이윤이 나는 제품을 더 팔아야 한다.
특징적 요소들 인도 날짜 및 노력에 집중함
가장 시각적 메트릭 날짜, 엔지니어링 노력, 결함
전략을 이끌어나가기 위한 그룹 회사 관리 부서
고객과 직접적 접촉을 해야 하는 그룹 마케팅/공장 고객 지원
너무 제한적 집중으로 인한 잠재적 문제점 결함 백로그는 관리가 안될 수 있다; 고객과 개발자들이 혼란스러울 수 있다.

노력과 시간을 줄이기 위한 방법?

  • 대부분의 시간을 소비하는 활동들을 개선한다.
  • 자주 defect가 발생하는 영역에 집중한다.
  • 대부분의 effort를 하는 defect에 집중한다.

어디서 비용이 많이 발생하는가?
– 알고 싶으면 tracking이 필요하다. 프로젝트 모니터링은 프로세스 개선을 위한 첫걸음이다.

개발 단계에 따른 엔지니어링 노력의 비율

Firmware
(31 projects)
Systems
(48 projects)
Applications
(53 projects)
Requirements 15% 14% 22%
Design 21% 19% 16%
Implementation 39% 30% 34%
Test 25% 37% 28%

위의 표는 엔지니어링 effort를 개선하기 위한 목적 외에도 여러가지 목적을 위해 사용될 수 있을 것 같다.  저 표를 보고 “어? 우리는 저렇게 일 안하는데? 라고 하는 조직이 많을 텐데, 그렇다고 하면 그 둘 간의 gap으로 인하여 어떤 차이가 있는지를 분석해보는 것도 해당 조직의 생산성을 높일 수 있는 방법이 될 수 있을 것으로 보인다.

또한 위의 표로부터 project의 기간 산정을 하는데 매우 유용한 reference가 될  수도 있다는 점이다. 비례식을 적용하여 requirement를 완성하는데 5달이 걸렸다면 대충 requirement의 개발 시간 비율을 20%로 가정하면, 25개월, 즉 2년 1개월이 프로젝트를 수행하는데 필요한 시간이라는 것을 알 수도 있을 것이다.

비용을 줄일 수 있는 새로운 방법을 학습하기

엔지니어들은 잘 알고 있을 수도 있겠지만, 신기술을 도입하면 마치 비용이 줄어드는 환상을 갖는 비전문가이면서 높은 자리에 있는 분들을 생각하게 되는 섹션이다. in the long run, 아마도 그렇게 될 수 있을 것으로 생각한다. 근데, 고위직에 있는 분들이 모두 그런 투자가 장기적 투자를 필요로 한다는 사실은 잘 모르고 있는 듯 하다. (현실과 이상의 gap은 항상 거리가 있다.)

개발 및 시험 스케줄을 줄이기 위한 추적

위의 표에서 보면 코딩 및 시험이 개발 일정의 60%를 차지한다는 것을 알 수 있으므로, 해당 활동에 대한 detail을 추적하여 분석한다.

  • 클래스의 갯수를 추적
  • operation(or method)의 갯수를 추적
  • non-comment source statements(NCSS)를 추적
  • number of defects per hours of testing time
  • amount of test execution time between defects
  • past average times to find and fix defects

고객 만족을 최대화하기 위한 프로젝트 관리


고객만족을 최대화하기 위한 목적을 가진 프로젝트 관리는 고객의 니즈에 대한 이해가 필요하다. 그리고 그런 이해가 제품에 막대한 영향을 미치게 된다.

중요 특징들 고객만족 극대화
중요 비즈니스 요인 마켓 쉐어를 잡으려는 시도
가장 중요한 시점 시장에 초기 진입할 때
특징적 요소들 고객 의사소통, 빠른 대응
가장 시각적 메트릭 조사, 인터뷰 데이터, 제품 메트릭, 결함
전략을 이끌어나가기 위한 그룹 초기에는 개발 팀, 나중에는 고객 대응팀
고객과 직접적 접촉을 해야 하는 그룹 개발 팀
너무 제한적 집중으로 인한 잠재적 문제점 제품 개발의 프로세스가 개선되지 않을 수 있다.

주요 지표

  • product metrics
  • survey data
  • counts of unresolved critical and serious defects
  • calendar time by phase and activity(emphasis on times customers experience problems)
  • defect and enhancement request counts
  • break/fix ratio

Customer needs에 대해 구조화하기

1) FURPS+ model을 이용하는 방법. ISO9126의 품질속성 관점과 유사한 것 같다. 각 관점에서 고객이 원하는 내용을 유도한다.

functionality feature set
capabilities
generality
security
usability human factors
aesthetics
consistency
documentation
reliability frequency/severity of failure
recoverability
predictability
accuracy
mean time to failure
performance speed
efficiency
resource consumption
thruput
response time
supportability testability
extensibility
adaptability
maintainability
compatibility
configurability
serviceability
installability
localizability

2) QFD(Quality function deployment) 방법 사용하기

FURPS+모델로부터 고객의 요구사항을 도출하고, 현재 시스템이 가지고 있는 점수를 기술하고, 앞으로 나아가야 할 방향(Engineering effort)을 제시

상당히 유용한 접근법인 것 같다. 꼭 프로젝트 모니터링에서만 사용될 필요가 있는 것은 아닌 것 같고, 여러가지 용도로 활용가능한 방법론인 듯 싶음

QFD

3) Surveys and interviews

고객의 요구를 이끌어내기 위해서 그리고 편향되지 않은 결과를 얻어내기 위해서는 질문이 중요하다. 특정 속성에 대한 질문이 의도적으로 많아서 그 질문만 하여 답을 얻어내게 되면, 그 자료로부터의 해석이 마치 그 속성이 강조된 것으로 오해될 수 있다. (고객은 유도당한 꼴이 됨)

이런 문제를 해결하기 위해서는 관련 참조 문헌을 통해 균형적 시각을 유지해야 할 필요가 있다. 아직 읽어보진 않았지만, 고객의 요구사항을 도출하기 위해서 읽어두면 좋을 내용이라고 생각한다. (추후 읽어보고 요구사항 분석과정을 위한 권장도서 목록에 포함할지의 여부를 결정할 것임)

일부 가이드라인(from HP group)

  • survey의 목적, 어떤 질문을 답해야 하는지, 어떻게 데이터를 분석할 것인지, 어떻게 결과를 표현할 것인지를 정의한다. 샘플 결론을 명시하거나 그래프로 표현한다.
  • survey를 배포하여 설문을 하기 전에 survey를 테스트하고 데이터 분석 방법을 적용한다.
  • 정량적이거나 y/n로 응답받을 수 있는 질문을 한다.
  • 설문지는 짧게
  • 부가적인 material을 주어서 섞이지 않도록 한다.
  • 회수하기 쉬운 형태가 되도록 한다.

참고문헌

Asking question: A practical guide to questionnaire design

QFD가 궁금하다면?