Section 4. 요구사항 분석 단계


목차

 

SECTION 4 요구사항 분석 단계

THE REQUIREMENTS ANALYSIS PHASE

4.0

 

 

개요

OVERVIEW

 

요구사항 분석 단계의 목적은 요구사항 및 사양이 가능하고 완전하며 일관성이 있는지 확인하고 그들이 개발 팀에 의해 이해되는 것이다.

 

The purpose of the requirements analysis phase is to ensure that the requirements and specifications are feasible, complete, and consistent, and that they are understood by the development team.

 

TAILORING NOTE

대형 프로젝트에서 요구사항 분석은 PSRR에서 시작된다. 개발 팀의 주요 구성원은 검토 자료를 조사 검토 자체에 참여하고, 잠시 후 요구사항을 분류하기 시작한다.

On large projects, requirements analysis begins at the PSRR. Key members of the development team examine the review materials, participate in the review itself, and begin classifying requirements shortly thereafter.

 

일반적인 개발 팀은 다음과 같이 구성된다.

  • 프로젝트 리소스를 관리하고, 진행 상황을 모니터링하며, 기술 컨설턴트 역할을 하는 하는 프로젝트 관리자
  • 기술 방향 및 일일 감독을 제공하는 프로젝트 (또는 작업) 지도자,
  • 기술적인 작업을 수행하는 프로그래머와 어플리케이션 전문가
  • 품질 보증 담당자
  • 프로젝트 사서 (방법 및 도구를 참조)

A typical development team comprises

  • the project manager, who manages project resources, monitors progress, and serves as a technical consultant
  • the project (or task) leader, who provides technical direction and daily supervision
  • the programmers and application specialists who perform the technical work
  • a quality assurance representative
  • a project librarian (see METHODS & TOOLS)

 

요구사항 정의 팀은 요구사항 및 사양을 완료하고 SRR을 보유하고 후에 요구사항 분석이 시작된다. 요구사항 분석 시, 개발 팀의 구성원은 주의 깊게 요구사항 및 사양 문서를 연구한다. 그들은 누락, 모순, TBDs 및 설명 또는 증폭을 필요 사양을 밝히기 위해서 문서의 각 문을 항목별로 정리하고 분류한다. 개발 팀은 (예를 들어, 구조화 된 또는 분석 객체 지향) 프로젝트에 적합한 분석 방법론을 사용하여, 내용의 다음 단계로 요구사항 정의 단계에서 수행 된 분석을 한다. 분석이 완료되면, 팀은 SSR에 그 결과(findings)를 제시한다.

 

Requirements analysis begins after the requirements definition team completes the requirements and specifications and holds the SRR. During requirements analysis, members of the development team carefully study the requirements and specifications document. They itemize and categorize each statement in the document to uncover omissions, contradictions, TBDs, and specifications that need clarification or amplification. The development team takes the analysis that was performed in the requirements definition phase to the next level of detail, using the appropriate analysis methodology for the project (e.g., structured or object-oriented analysis). When analysis is complete, the team presents its findings at an SSR.

 

개발 팀은 전체 단계에서 요구사항 정의 팀과 긴밀하게 작업한다. 요구사항 정의 팀은 워크스루에 참여하는 질문에 대한 답변, 요구사항의 문제를 해결하고, SSR에 참석한다. 한편, 프로젝트 관리자는 소프트웨어 시스템을 개발할 때 및 개발 노력을 관리할 때에 사용되는 접근 방법을 계획하고, 현 단계 동안 생성된 산출물을 검토한다.

 

The development team works closely with the requirements definition team during the entire phase. The requirements     definition team participates in walk-throughs, answers questions, resolves requirements issues, and attends the SSR. Meanwhile, the project manager plans the approaches to be used in developing the software system and in managing the development effort, obtains and trains the necessary staff, and reviews the products produced during the phase.

 

그림 4-1은 요구 분석 프로세스의 상위 레벨의 데이터 흐름도이다.

 

Figure 4-1 is a high-level data flow diagram of the requirements analysis process.

4.1

Figure   4-1.      Analyzing Requirements

 

핵심 활동들

KEY ACTIVITIES

 

요구사항 분석 단계에서, 활동들은 주로 요구사항 정의팀, 개발 팀, 소프트웨어 개발 관리자 사이에 주로 나누어진다. 각각의 요구사항 분석 단계에서 수행하는 주요 활동은 다음 절에서 세분화된다. 그림 4-2은 이러한 활동은 일반적으로 계획되는 방법을 보여주는 샘플 타임 라인이다.

 

In the requirements analysis phase, activities are divided primarily among the requirements definition team, the development team, and software development managers. The key activities that each performs during the requirements analysis phase are itemized in the following subsections. Figure 4-2 is a sample timeline showing how these activities are typically scheduled.

 

 

요구사항 정의 팀의 활동들

Activities of the Requirements Definition Team

 

  • 사양에 있어서의 모호함, 불일치, TBDs를 해결한다. 개발 팀을 위한 요구사항 및 사양의 초기 워크스루를 실시하고 나중에 워크스루에 참여한다. 개발자의 모든 질문들에 응답한다.개발 팀에 의해 제기된 요구사항 문제를 해결한다. 요구사항 및 사양 문서에 승인된 수정 사항을 통합한다.

 

  • SSR에 참여 한다.

 

  • Resolve ambiguities, discrepancies, and TBDs in the specifications. Conduct the initial walk-throughs of the requirements and specifications for the development team and participate in later walk-throughs. Respond to all developer questions.Resolve the requirements issues raised by the development team. Incorporate approved modifications into the requirements and specifications document.

 

  • Participate in the SSR.

 

 

개발 팀의 활동들

Activities of the Development Team

 

  • 요구사항을 분석하고 분류한다. 각각의 요구사항 및 사양을 워크스루하고 명확화하기 위해 요구사항 정의 팀과 만난다.요구사항 및 명세 문서에서의 과 누락 사양, 충돌 모호하거나, 불가능을 확인한다. 필수의 분류를 명세하기 위한 검토가 필요하며, 요구사항 문서의 각 항목에 분류, 단순 정보(information only) 또는 TBD를 필요로 한다.

 

  • Analyze and classify requirements. Meet with the requirements definition team to walk through and clarify each requirement and specification. Identify requirements and specifications that are missing, conflicting, ambiguous, or infeasible. Assign a classification of mandatory, requires review, and needs clarification, information only, or TBD to each item in the requirements and specifications document.

 

사양을 검증하기 위해 구조적 분석 또는 객체 지향 분석을 사용한다. 요구사항 및 사양의 고 수준의 다이어그램을 확장하여 낮은 수준의 상세하게 확장하고 누락된 부분을 채워 넣어서 모든 명세가 같은 수준에서 표현되도록 한다. 사용자의 상호 작용 및 주요 데이터를 저장 (예를 들어, 고도의 기록 파일)이 완벽하게 명세되어 있는지 확인한다.

 

Use structured or object-oriented analysis to verify the specifications. Expand the high-level diagrams in the requirements and specifications document to a lower level of detail, and supply missing diagrams so that all specifications are represented at the same level. Ensure that user interactions and major data stores (e.g., attitude history files) are completely specified.

 

이용 가능한 자원의 관점에서 컴퓨터 용량 및 성능 요구사항의 타당성을 확인한다. 기존 시스템들에 지정된 기능 / 알고리즘을 비교하여 초기 성능 예측을 설정한다. SOC에 설명된 운영 시나리오에 대한 전반적인 성능 (CPU, I / O 등)을 모델로 추정치를 사용한다. 이런 결과에 고려하도록 하기 위해 SOC 시나리오를 조정한다.

 

Determine the feasibility of computer capacity and performance requirements in view of available resources. Establish initial performance estimates by comparing specified functions/algorithms with those of existing systems. Use the estimates to model overall performance (CPU,         I/O, etc.) for the operational scenarios described in the SOC. Adjust the SOC scenarios to take these results into account.

 

요구사항 정의 팀과 워크스루를 통해 요구사항의 분류 및 분석을 수행한다.

Walk through the results of classification and analysis with the requirements definition team.

 

  • 현실적인 계획으로 재사용 제안을 개정(refine)한다. 기존 소프트웨어의 현재 작동 기능과 요구사항 기준선에 대한 변경의 관점에서 SOC의 소프트웨어 재사용 제안을 분석한다.
  • 기술적 위험 영역을 식별한다. 이러한 위험을 최소화하기 위해 프로토타이핑을 하거나 다른 적절한 기술을 계획하고 수행한다.
  • SSR전에 요구사항 분석 보고서를 준비하고 배포한다.
  • SSR을 실시하고 모든 RID를 해결한다.

 

  • Refine the reuse proposal into a realistic plan. Analyze the software reuse proposal in the SOC in light of the existing software’s current operational capabilities and any changes to the requirements baseline.
  • Identify areas of technical risk. Plan and conduct prototyping efforts or other appropriate techniques to minimize these risks.
  • Prepare the requirements analysis report and distribute it before the SSR.
  • Conduct the SSR and resolve all RIDs.

 

워크스루, 요구사항 분류, 분석 방법에 대한 자세한 정보는 아래 방법 및 도구를 참조한다.

See METHODS AND TOOLS below for more information about walk-throughs, requirements classifications, and analysis methodologies.

 

The contents of the requirements analysis report and the software development/ management plan are covered under PRODUCTS below. The SSR is discussed separately at the end of this section.

 

프로젝트의 크기, 비용 및 일정을 추정 지침에 대한 관리자의 소프트웨어 개발을 위한 핸드북 및 소프트웨어 비용 추정에 대한 접근을 (참고 자료 각각 12, 18)를 참조하십시오.

12. Software Engineering Laboratory, SEL-84-101, Manager’s Handbook for Software

Development (Revision 1), L. Landis, F. McGarry, S. Waligora, et al., November 1990

18. —,SEL-83-001, An Approach to Software Cost Estimation, F. E. McGarry, G. Page,

D. N. Card, et al., February 1984

See the Manager’s Handbook for Software Development and the Approach to Software Cost Estimation (References 12 and 18, respectively) for guidance in estimating project size, costs, and schedule.

 

 

관리팀의 활동들

Activities of the Management Team

 

  • 소프트웨어 개발 / 관리 계획 (SDMP)을 준비한다. 적절한 크기, 비용 및 일정 데이터뿐만 아니라 지난 프로젝트로부터 얻은 교훈(lesson-learned)에 대한 과거 프로젝트 및 관련 기록을 검토한다. 어떤 리소스가 필요한지를 결정하고, 인력 프로파일을 개발하고, 프로젝트 비용을 추정한다. 프로젝트 위험을 식별하고 이를 최소화 할 계획을 세운다. 프로젝트에 사용되는 기술과 관리 방법을 문서화한다.

 

  • Prepare the software development/management plan (SDMP). Review the histories of related, past projects for applicable size, cost, and schedule data as well as lessons learned. Determine what resources are needed, develop a staffing profile, and estimate project costs. Identify project risks and plan to minimize them. Document the technical and management approaches that will be used on the project.

 

  • 직원 및 개발 팀을 훈련한다. 가능한 한 빨리 다음의 SRR (또는 대형 프로젝트에, PSRR)와 같은 프로젝트에 직원을 데려온다. 개발 팀 구성원, 관리자 및 요구사항 정의팀 사이의 의사소통을 확인한다.또한, 요구사항 정의팀이 SRR을 대응하기에 충분한 직원을 보유하여 TBD 및 변화하는 요구사항이 즉시 주어지고 철저한 분석을 할 수 있도록 한다.

 

  • Staff and train the development team. Bring staff onto the project as soon as possible following SRR (or, on large projects, PSRR). Ensure communications among development team members, managers, and the requirements definition team.Also make certain that the requirements definition team is adequately staffed following SRR, so that TBD and changing requirements can be given prompt and thorough analysis.

 

  • 요구사항의 문제 해결을 용이하게 하기 위해 분석가 및 고객과 상호 작용한다. 제안된 요구사항 변경의 타당성을 평가하기 위해 비용과 일정에 미치는 영향을 추정하기 위해 팀 리더와 함께 작업한다.

 

  • Interact with analysts and customers to facilitate resolution of requirements issues. Work with team leaders to assess the feasibility of proposed requirements changes and to estimate their impact on costs and schedules.

 

  • 요구사항 분석 과정의 산출물을 검토한다. 요구사항 분류, 데이터 흐름 또는 객체 지향 다이어그램, 데이터 사전(data dictionary), 요구사항 분석 보고서 및 SSR 하드 카피 자료를 검토한다. SSR을 위한 일정을 예약하고 해당 그룹의 참여를 보장한다.

 

  • Review the products of the requirements analysis process. Look at requirements classifications, data-flow or object-oriented diagrams, the data dictionary, the requirements analysis report, and the SSR hardcopy materials. Schedule the SSR and ensure participation from the appropriate groups.

 

  • 예비 설계 단계로의 순차적인 전환을 계획한다. 개발 팀 멤버에게 예비 설계에 적용할 수 있는 소프트웨어 개발 계획의 일부를 전달한다. (예를 들어, 설계 기준 및 형상 관리 절차) 그리고 설계 동안 사용할 특별한 소프트웨어 엔지니어링 접근법들을 엔지니어들에게 교육시킨다. 핵심 멤버가 SSR을 위해 준비하는 동안 개발 팀의 나머지는 사전 예비 활동을 시작한다.

 

  • Plan an orderly transition to the preliminary design phase. Convey to the development team members the parts of the software development plan that apply to preliminary design (e.g., design standards and configuration management procedures) and instruct them in the specific software engineering approach to use during design. While the key team members are preparing for SSR, have the remainder of the development team begin preliminary design activities.

4.2

Figure 4-2:     Timeline of Key Activities in the Requirements Analysis Phase

 

방법 및 도구들

METHODS AND TOOLS

 

다음과 같은 방법, 기술 및 도구는 요구사항 분석 단계의 활동을 지원하는 데 사용된다:

 

The following methods, techniques, and tools are used to support the activities of the requirements analysis phase:

 

  • 요구사항 워크스루
  • 요구사항 분류
  • 요구사항 양식
  • 구조화 되고 객체 지향 요구사항 분석
  • CASE 도구
  • 프로토타이핑
  • 프로젝트 라이브러리

 

  • Requirements walk-throughs
  • Requirements classifications
  • Requirements forms
  • Structured and object-oriented requirements analysis
  • CASE tools
  • Prototyping
  • The project library

 

각각은 아래에서 논의된다.

Each is discussed below.

 

 

요구사항 워크스루

Requirements Walk-Throughs

 

요구사항 분석 단계의 시작 부분에서, 개발자는 요구사항 및 사양을 충족하는 요구사항 정의 팀의 분석자와 비공식적으로 만난다. 이러한 초기 워크스루 동안, 분석자는 각각의 사양을 논의하고 왜 어떤 알고리즘이 다른 것들을 제외하고 선택하였는지에 대해서 설명하며 개발자에게 질문하고 문제를 제기할 수 있는 기회를 제공한다.

 

At the beginning of the requirements analysis phase, developers meet informally with analysts of the requirements definition team to go through the requirements and specifications.  During these initial walk-throughs, analysts discuss each of the specifications, explain why certain algorithms were selected over others, and give developers the opportunity to raise questions and issues.

 

개발자가 요구사항 및 명세를 분석하고 분류한 후, 그들은 요구사항 정의팀에 대한 자신의 결과의 워크스루를 수행한다. 하나의 워크스루는 시스템에서 각각의 주요 기능 혹은 목적에 대해서 개최되어야 한다. 향후 이러한 워크스루 동안 양쪽의 팀은 문제가 있는 명세 목록을 검토하고 요구사항 문서에서 변경되어야 할 필요가 있는 부분을 논의한다.

 

After developers have analyzed and classified the requirements and specifications, they conduct walk-throughs of their results for the requirements definition team. One walk-through should be held for each major function or object in the system. During these later walk-throughs, both teams review all problematic specification items and discuss any needed changes to the requirements and specifications document.

 

모든 문제 영역과 결정이 문서화되어 있는지를 확인하기 위해, 개발 팀의 한 멤버는 워크스루 회의의 상세한 내용을 기록해야 한다. 개발자는 요구사항 정의팀에 의한 요청 확인, 추가 분석, 또는 다른 작업을 위해 질의 응답 양식을 작성할 필요가 있다.

 

To ensure that all problem areas and decisions are documented, one member of the development team should record the minutes of the walk-through meeting. Developers will need the minutes to fill out requirements question-and-answer forms for any issues that require confirmation, further analysis, or other action by the requirements definition team.

 

 

요구사항 분류

Requirements Classification

 

개발 팀은 요구사항 및 사양 문서를 잘 알고 있을 때, 그들은 요구사항 및 사양 문서의 각 통로 (문장이나 단락을) 가지고 필수 중 하나로 분류한다: 필수사항, 검토가 필요함, 분류가 필요함, 정보 전달 목적(information only), 또는 TBD

 

When the development team is thoroughly familiar with the requirements and specifications document, they take each passage (sentence or paragraph) in the requirements and specifications document and classify it as either mandatory, requires review, needs clarification, information only, or TBD.

 

  • 항목이 SIRD 또는 SORD와 같이 프로젝트 수준의 요구사항 문서로 정의되어 있거나 항목이 프로젝트 수준의 요구사항 분석에서 파생된 경우 해당 아이템은 필수이다. 필수 항목이 사양에서 제거되는 경우, 시스템은 프로젝트 레벨 요건을 충족하지 못할 것이다.

 

  • An item is mandatory if it is explicitly defined in project-level requirements documents such as the SIRD or SORD, or if it has been derived from analysis of the project-level requirements. If mandatory items are removed from the specifications, the system will fail to meet project-level requirements.

 

  • (프로젝트 수준의 요구사항 및 운영 개념을 기반으로 한) 특정 ​​요구사항 또는 사양에 대한 명백한 요구가 없다면, 아이템은 검토를 요구한다. (요구사항 정의팀에 의해 추가 분석되어야 함)가 필요하다. 해당 항목은 CDR전에 (사양 변경에 의해) 사양에서 제거되거나 필수 카테고리로 이동해야 한다.

 

  • If (on the basis of project-level requirements and the system and operations concept) there is no apparent need for a particular requirement or specification, then that item requires review (i.e., further analysis by the requirements definition team). The item must be deleted from the specification (by means of a specification modification) or moved into the mandatory category before CDR.

 

  • 아이템이 모호하고타당하지않은것으로보이거나요구사항의하나이상과충돌할때, 해당아이템은분류가필요하다.

 

  • An item needs clarification when it is ambiguous, appears infeasible, or contradicts one or more of the other requirements or specifications.

 

항목이 요구사항이나 사양이 없는 경우 아이템은 information only로 표기된다. 이러한 항목은 배경 정보, 소프트웨어 개발자를 위한 도움이 되는 힌트 등을 제공할 수 있다.

 

An item is labelled as information only if it contains no requirement or specification per se. Such an item may provide background information, helpful hints for the software developer, etc

 

  • 만약 (1) 이거나 (2)인 경우, 요구사항이나 사양 항목은 TBD이다.

(1): 항목이 “프로세스가 현재 시점에서 TBD와 같은 문장을 포함한다.”

(2): 항목과 관련된 정보가 없거나 정의되지 않았다.

 

  • A requirement or specification item is TBD if (1) the item contains a statement such as “the process is TBD at this time,” or (2) information associated with the item is missing or undefined.

 

요구사항 및 사양은 데이터베이스에 사용할 수 있는 경우, 분류를 입력하고 온라인 데이터베이스에 논평을 지원. 그렇지 않으면, 각각의 요구사항이나 사양 항목을 요약 요약 목록을 작성하고, 분류를 할당할 목록을 사용한다.

 

If the requirements and specifications are available in a database, enter the classifications and supporting commentary into the database online.  Otherwise, summarize each requirement or specification item, create a list of the summaries, and use the lists to assign classifications.

 

요구사항 양식

Requirements Forms

 

요구사항 분석 및 후속 단계에서, 질의 응답 형태의 통신에 사용 기록 요구사항의 문제 사항에 있다. 사양 변경은 요구사항의 변경을 문서화하는 데 사용된다.

 

During the requirements analysis and subsequent phases, question- and-answer forms are used to communicate and record requirements issues and clarifications. Specification modifications are used to document requirements changes.

 

개발 팀은 요구사항 정의의 팀에 제출 질문을 추적하고 요구사항에 대한 자신의 가정을 확인하기 위해 질의 응답 형태를 ​​사용한다. 요구사항 정의 팀의 관리자는 개발자가 자신의 팀의 응답 인원 및 기한을 지정 양식을 사용한다. 양식에 제출된 질문에 대한 답변은 서면으로 해야 한다.

 

The development team uses question-and-answer forms to track questions submitted to the requirements definition team and to verify their assumptions about requirements. Managers of the requirements definition team use the forms to assign personnel and due dates for their team’s response to developers. Responses to questions submitted on the forms must be in writing.

 

질문과 대답의 형태는 요구사항 또는 사양을 변경할 권한을 부여하는 데 사용할 수 없다. 제출된 질문이나 문제의 분석은 요구사항의 변경이 필요하다는 것을 알 수 있는 경우, 요구사항 정의 팀의 구성원은 사양 변경 초안을 작성한다. 제안된 사양 변경은 요구사항 정의 및 개발 팀 모두의 관리자에 의해 CCB의 승인을 받아야 한다. 요구사항 정의의 팀은 요구사항 및 사양 문서에 승인 된 모든 규격의 수정을 포함한다.

 

The question-and-answer form cannot be used to authorize changes to requirements or specifications. If analysis of the submitted question or issue reveals that a requirements change is needed, members of the requirements definition team draft a specification modification. Proposed specification modifications must be approved by the managers of both the requirements definition and the development teams and by the CCB. The requirements definition team incorporates all approved specification modifications into the requirements and specifications document.

 

 

분석 방법 및 CASE 도구들

Analysis Methods and CASE Tools

 

요구사항 분석에 적용 할 수 있는 방법과 도구는 섹션 3의 요구사항 정의 단계에서 정의된 것과 동일하다. 개발 팀은 일반적으로 요구사항 정의 팀에 의해 사용된 방법과 동일한 방법을 사용하는데 이는 명세에서 제공되는 상세한 수준으로 분석을 수행하기 위해서이다. 이것은 개발 팀이 이전 분석을 검증하고 문서에 존재할 수 있는 갭을 채울 수 있도록 한다. 만약 CASE 도구가 요구사항 정의단계에서 데이터 플로우나 객체 지향 다이어그램을 생성하기 위해서 사용된다면, 그것은 요구사항 분석 단계에서 동일한 도구의 사용을 하는 것이 중요하다. 개발자가 다시 입력하거나 다른 도구에 대한 다이어그램으로 다시 작성해야 하는 경우 생산성 및 통신 지원 등의 CASE 도구의 가치는 크게 감소한다.

 

The methods and tools applicable for requirements analysis are the same as those recommended for the requirements definition phase in Section 3. The development team will generally use the same method as was used by the requirements definition team to take the analysis down to a level of detail below that provided in the specifications. This allows the development team to verify the previous analysis and to fill in any gaps that may exist in the document. If CASE tools were used in the requirements definition phase to generate data flow or object diagrams, it is important to use the same tools in the requirements analysis phase. The value of a CASE tool as a productivity and communication aid is greatly reduced if developers must re-enter or reformat the diagrams for a different tool.

 

요구사항 정의팀이 분석을 위해 기능 분해를 사용하고 개발 팀이 객체 지향 설계를 생성할 필요가 있는 경우라면, 부가적인 분석 단계가 필요하다. 개발 팀은 낮은 수준으로 명세의 상세화된 다이어그램을 그려야 하고, 그 다음 그 다이어그램이 상위 수준의 요구사항을 백업할 수 있도록 사용한다. 이것은 개발 팀이 새롭고, 객체지향적인 관점으로 시스템을 바라보고 시스템을 필요에 따라 재구성할 수 있도록 한다.

 

If the requirements definition team has used functional decomposition for their analysis and the development team needs to generate an object-oriented design, then extra analysis steps are required. The development team must diagram the details of the specification at a low level, then use the diagrams to abstract back up to higher-level requirements. This allows the team to take a fresh, object-oriented look at the system architecture and to restructure it as needed.

 

 

프로토타이핑

Prototyping

 

요구사항 분석 단계에서 프로토타이핑의 활동은 일반적으로 위험을 줄이기 위해 실시하고 있다. 익숙하지 않은 기술 (예를 들어, 하드웨어 또는 새로운 개발 언어 기능) 프로젝트에 사용될 경우, 프로토타이핑은 변경 사항에 적은 비용으로 할 때 개발 팀은 초기 수명주기 기술의 가능성을 평가할 수 있다. 시스템의 성능이나 신뢰성이 주요, 해결되지 않은 문제의 경우, 팀은 중요한 작업이나 알고리즘을 프로토타이핑 할 수 있다.

 

During the requirements analysis phase, prototyping activities are usually conducted to reduce risk. If unfamiliar technology (e.g., hardware or new development language features) will be employed on the project, prototyping allows the development team to assess the feasibility of the technology early in the life cycle when changes are less costly to effect. If system performance or reliability is a major, unresolved issue, the team can prototype critical operations or algorithms.

 

사용자인터페이스에 대한 요구사항이 프로토타이핑 되어야 하는 프로젝트에서 인터페이스는 시스템 성공에 중요하며 사용자들은 그들의 필요를 잘 모르기 때문에 도구는 개발자들로 하여금 스크린과 윈도우를 빨리 셋업할 수 있도록 한다. 그와 같은 도구로 개발자들은 사용자들로 하여금 과도한 프로그래밍 없이 시스템을 보고 느낄 수 있도록 하여 조기에 피드백을 제공할 수 있도록 한다. 도구는 메뉴를 생성할 수 있어야 하고 여러 개의 스크린을 생성할 수 있어야 하며 입력에 따른 반응을 해야 한다. 성공적으로 SEL에서 사용 된 하나의 도구는 댄 브리 클린의 데모 프로그램이다.

 

On projects where the requirements for the user interface must be prototyped — either because the interface is critical to system success or because users are uncertain of their needs — a tool that allows the developer to set up screens and windows rapidly is often essential. With such a tool, the developer can give the user the “look and feel” of a system without extensive programming and can obtain early feedback. The tool should be able to generate menus, multiple screens, and windows and respond to input. One such tool that has been successfully used in the SEL is Dan Bricklin’s Demo Program.

 

어떤 프로토타이핑 활동이 수행되는 것이 필요하다는 것을 보장하기 위해서 주의 깊게 실시되어야 하고 명확한 목표를 가지고 있어야 하며 표준 개발 절차를 우회하는 수단으로 사용되지 않아야 한다. 프로토타이핑 노력을 계획하는 방법에 대한 자세한 지침은 4 장에서 제품을 참조하라.

 

Caution must be exercised to ensure that any prototyping activity that is conducted is necessary, has a defined goal, and is not being used as a means to circumvent standard development procedures. See PRODUCTS in Section 4 for additional guidance on how to plan a prototyping effort.

 

 

프로젝트 라이브러리

Project Library

 

각각의 소프트웨어 개발 프로젝트에서, 하나의 팀 구성원은 사서의 역할이 할당된다. 프로젝트 기간 동안, (때로는 소프트웨어 형상 관리자라고도 함) 사서는 모든 프로젝트 정보의 저장소인 프로젝트 라이브러리를 유지한다. 사서도 구성 소프트웨어 라이브러리를 관리하고 프로젝트 활동을 지원하는 다양한 소프트웨어 도구를 운영하고 있다.

 

In each software development project, one team member is assigned the role of librarian. During a project, the librarian (sometimes called the software configuration manager) maintains the project library, which is a repository of all project information. The librarian also maintains configured software libraries and operates various software tools in support of project activities.

 

사서는 요구사항 분석 단계에서 프로젝트 라이브러리를 설정한다. 일반적으로, 프로젝트 라이브러리는 결정의 기록 또는 정보를 통신하기 위한 목적으로 개발 팀에 의해 사용되거나 생산 서면 자료를 포함한다. 그것은 요구사항 및 사양 문서, 요구사항을 질문과 대답 양식, 승인된 사양 수정, 요구사항 분석 요약 보고서 등을 포함한다. 이러한 소프트웨어 개발 / 관리 계획 등 필요한 관리 정보도 포함되어 있다.

 

The librarian establishes the project library during the requirements analysis phase. In general, the project library contains any written material used or produced by the development team for the purpose of recording decisions or communicating information. It includes such items as the requirements and specifications document, requirements question-and-answer forms, approved specification modifications, and the requirements analysis summary report. Necessary management information, such as the software development/management plan, is also included.

 

측정

MEASURES

 

다음 단락에서는 매니저가 요구 분석 단계 중에 개발 프로세스를 평가하는 데 사용할 수 있는 방법 및 평가 기준을 설명한다.

 

The following paragraphs describe the measures and evaluation criteria that managers can use to assess the development process during the requirements analysis phase.

 

목표 지표들

Objective Measures

 

요구사항 분석의 진행과 품질은 여러 가지 객관적인 측정을 검사하여 모니터링 한다:

 

  • 직원 시간 – 직원의 실제 노력, 혹은 총 합으로서의 누적 시간, 혹은 활동당 직원의 노력
  • 요구사항 질문 및 답변 – 제출한 질문지, 답변지의 개수 대비 답변된 수
  • TBD 요구사항 – 요구사항의 총 개수 대비 TBD로 분류 요구사항의 개수
  • 요구사항 변경 – 사양 변경이 승인 된 것에 대한 요구사항의 총 누적 수
  • 시스템 크기, 재사용, 노력, 일정의 추정 – 시스템에서 코드 라인의 총 예상 시간; 새 코드의 예측되는 길이, 재사용된 코드의 길이, 시스템을 개발하기 위해 필요한 예상되는 직원의 시간, 라이프사이클의 각 단계와 끝에서 예상되는 기간

 

The progress and quality of requirements analysis are monitored by examining several objective measures:

 

  • Staff hours — actual, cumulative hours of staff effort, as a total and per activity
  • Requirements questions and answers — the number of question- and-answer forms submitted versus the number answered
  • TBD requirements — the number of requirements classified as TBD versus the total number of requirements
  • Requirements changes — the total cumulative number of requirements for which specification modifications have been approved
  • Estimates of system size, reuse, effort, and schedule — the total estimated number of lines of code in the system; the estimated number of new, modified, and reused (verbatim) lines of code; the total estimated staff hours needed to develop the system; and estimated dates for the start and end of each phase of the life cycle.

 

이러한 방법 각각에 대해, 표 4-1는 누가 데이터를 제공하고 어떤 데이터가 수집되고 분석되는지에 대한 빈도, 그리고 데이터 수집이 요구사항 정의 단계 혹은 초기단계에서 계속되는지의 여부를 나타낸다.

 

For each of these measures, Table 4-1 shows who provides the data, the frequency with which the data are collected and analyzed, and whether data collection is continued from the requirements definition phase or newly initiated.

 

SEL은 요구사항의 분석 단계에서 통계를 수집하기 위해 3개의 하드 카피 형태를 사용한다. 인사 자료 양식은 매주 노력의 시간을 기록하는 개발 팀에 의해 사용된다. 이 프로젝트는 형태가 매달 크기와 노력이 개발 상태 양식이 요구사항 변경의 수를 기록하는 데 사용된다 추정 기록하고, 요구사항의 질문에 대 답의 수에 관리자에 의해 사용되는 추정하고 있다. SEL 데이터 수집 양식 및 절차에 대한 자세한 내용은 참조 19를 참조하십시오.

 

19. —,SEL-92-002, Data Collection Procedures for the Software Engineering Laboratory

(SEL) Database, G. Heller, J. Valett, M.Wild, March 1992

 

The SEL uses 3 hardcopy forms to collect metrics during the requirement s analysis phase. The Personnel Resources Form is used by the development team to record weekly effort hours. The Project Estimates Form is used by managers to record their monthly size and effort estimates The Development Status Form is used to record the number of requirements changes, and number of requirements questions vs. answers. See Reference 19 for detailed information about SEL data collection forms and procedures.

 

Table    4-1.       Objective Measures Collected   During the Requirements

4.1t

평가 범주

Evaluation Criteria

 

직원 시간은 보통 SDMP (그림 4-5)에 대한 소프트웨어 개발 관리자에 의해 생성된다 추정 직원의 노력의 프로필에 대해 그래프로 그려진다. 실제 인력 대비 계획의 초기 비교는 계획의 실행 가능성을 평가하는 데 사용된다.

 

Staff hours are usually graphed against a profile of estimated staff effort that is generated by the software development manager for the SDMP (Figure 4-5). This early comparison of planned versus actual staffing is used to evaluate the viability of the plan.

 

비행 역학 환경에서 예상보다 낮은 시간은 심각한 위험 신호이다 – 일정이 충족되는 경우에도 – 그들이 개발 팀이 일손 표시하기 때문이다. 너무 적은 수의 개발자가 요구사항 분석을 수행 할 경우, 팀은 요구사항 문제를 표면에 필요한 이해의 깊이를 얻을 수 없습니다. 그들은 훨씬 더 비용이 많이 드는 조정하는 경우 이러한 문제는 나중에 라이프 사이클에 표시된다.

 

In the flight dynamics environment, hours that are lower than expected are a serious danger signal — even if schedules are being met — because they indicate the development team is understaffed. If too few developers perform requirements analysis, the team will not gain the depth of understanding necessary to surface requirements problems. These problems will show up later in the life cycle when they are far more costly to rectify.

 

제출된 질문의 수와 수신된 응답 또는 요구사항의 변화에 많은 수의 수 사이의 성장 격차는 명확성, 정확성, 또는 요구사항 및 사양 문서에 제시된 요구사항의 완전성에 문제가 있을 수 있다. 유사한 과거의 프로젝트에서의 데이터는 이러한 숫자의 상대적인 크기의 의미를 평가하기 위해 사용되어야 한다.

 

A growing gap between the number of questions submitted and the number of responses received or a large number of requirements changes may indicate problems with the clarity, correctness, or completeness of the requirements as presented in the requirements and specifications document. Data from similar past projects should be used to assess the meaning of the relative sizes of these numbers.

 

미해결 TBD 요구 프로젝트 뒷부분 심각한 설계 변경을 필요로 할 수 있기 때문에, TBD 요구의 수는 이 단계에서 검사 될 수 있는 가장 중요한 척도이다. 분류 및 심각도에 따라 TBD 요구사항을 추적할 수 있다. 외부 인터페이스에 관한 TBD 요건들은 시스템 입력을 포함할 경우 특히 제일 중요하다. 내부 알고리즘에 영향을 미치는 TBDs은 일반적으로 그렇게 심각하지 않습니다.

 

Because unresolved TBD requirements can necessitate severe design changes later in the project, the number of TBD requirements is the most important measure to be examined during this phase. Categorize and track TBD requirements according to their severity. TBD requirements concerning external interfaces are the most critical, especially if they involve system input. TBDs affecting internal algorithms are generally not so serious.

 

하나 이상의 서브 시스템 또는 데이터 처리 알고리즘을 지원하기 위해 필요한 높은 수준의 데이터 구조의 기능 설계에 영향을 미칠 수 있다면 TBD 요구는 심각한 것으로 간주된다. 모든 심각한 TBD 요구사항이 해결 될 때까지 예비 디자인은 더 이상 진행하지 않는 것이 좋습니다. 그것은 하나 이상의 구성 요소를 포함하는 서브 시스템의 부분에 영향을 미치는 경우 TBD 요건은 명목상이라고(nominal) 여겨진다. 명목상의 TBD 요구사항의 많은 하나의 기능 영역에 존재하지 않는 예비 설계를 진행할 수 있다. 부수적 TBD 요구사항은 하나의 단위만 내부에 영향을 미치는 하나이다. 부수적인 TBD 요구사항은 상세 설계의 마지막에서 해결되어야 한다.

 

A TBD requirement is considered severe if it could affect the functional design of one or more subsystems or of the high-level data structures needed to support the data processing algorithms. Preliminary design should not proceed until all severe TBD requirements have been resolved. A TBD requirement is considered nominal if it affects a portion of a subsystem involving more than one component. Preliminary design can proceed unless large numbers of nominal TBD requirements exist in one functional area. An incidental TBD requirement is one that affects only the internals of one unit. Incidental TBD requirements should be resolved by the end of detailed design.

 

각 TBD 요구사항은 시스템 크기, 필요한 노력, 비용 및 일정에 미치는 영향을 추정한다. 종종 TBD 요구사항을 해결하는 데 필요한 정보는 나중에까지 사용할 수 있으며, 디자인은 고정 기한을 충족하기 위해 시작해야 한다. 이러한 추정치는 개발 일정의 불확실성을 결정하는 데 도움이 된다.

 

For each TBD requirement, estimate the effect on system size, required effort, cost, and schedule. Often the information necessary to resolve a TBD requirement is not available until later, and design must begin to meet fixed deadlines. These estimates will help determine the uncertainty of the development schedule.

 

MORE MEASURES

요구사항 분석 단계 중에 진행 과정상의 이러한 추가 조치를 추적을 고려한다.

• 총 요구사항에 대 분류 요구사항의 수

• 총 예상 다이어그램 대 완료 요구사항 다이어그램의 수

 

Consider tracking these additional measures of progress during the requirements analysis phase:

• number of requirements classified vs. total requirements

• number of requirements diagrams completed vs. estimated total diagrams

4.3

Figure 4-3.           Effort Data Example — ERBS AGSS

 

시스템의 크기의 성장에 대한 예측은 프로젝트의 안정성의 또 다른 중요한 지표이다. 시스템의 최종 크기를 추정하는 것은 비용, 일정 및 인력 수준 (참조 12, 제 3 항)를 결정하기 위한 절차의 첫 번째 단계이다. 응용 프로그램 환경 내에서 지난 프로젝트의 정보로 현재의 요구사항을 비교하여 초기 견적을 확인한다. 수명주기 전반에 걸쳐 매달 예상치를 그래프를 그려서 업데이트 한다.

 

12. Software Engineering Laboratory, SEL-84-101, Manager’s Handbook for Software Development (Revision 1), L. Landis, F. McGarry, S. Waligora, et al., November 1990

 

The growth of system size estimates is another key indicator of project stability. Estimating the final size of the system is the first step in the procedure for determining costs, schedules, and staffing levels (Section 3 of Reference 12). Make the initial estimate by comparing current requirements with information from past projects within the application environment. Update and plot the estimate each month throughout the life cycle.

 

프로젝트가 성숙하면, 추정의 변화의 정도가 안정된다. 요구사항의 성장이 예상 범위를 넘어서 시스템의 크기 추정치를 밀어 경우, 엄격한 변경 관리 절차를 구현하거나 추가 자금 및 개정된 프로젝트 계획을 얻을 필요가 있다. 크기 추정치를 평가하는 추가적인 지침은 참조 (12)의 제 6 절을 참고하라.

 

As the project matures, the degree of change in the estimates should stabilize. If requirements growth pushes the system size estimate beyond expected limits, it may be necessary to implement stricter change control procedures or to obtain additional funding and revise project plans. See Section 6 of Reference 12 for additional guidance in evaluating size estimates.

 

 

제품

PRODUCTS

 

다음과 같은 주요 제품은 이 단계에서 생성된다:

• 요구사항 분석 보고서
• 소프트웨어 개발 / 관리 계획
• 업데이트 요구사항 및 사양 문서
• 프로토타이핑 계획 (필요에 따라)

이 제품은 다음 단락에서 언급된다.

 

The following key products are produced during this phase:

 

  • The requirements analysis report
  • The software development/management plan
  • Updated requirements and specifications document
  • Prototyping plans (as needed)

 

These products are addressed in the paragraphs that follow.

 

 

요구사항 분석 보고서

The Requirements Analysis Report

 

요구사항 분석 보고서는 예비 설계를 시작하기 위한 기반을 구축하고, 따라서, 요구사항 분석 단계의 핵심 제품이다. 이 보고서는 다음을 포함한다:

 

The requirements analysis report establishes a basis for beginning preliminary design and is, therefore, a key product of the requirements analysis phase. This report includes the following:

 

  • 업데이트 된 재사용 플랜 (본래의 재사용 제안은 요구사항 정의 단계에 개발되었으며 시스템 및 운영 개념 문서에 기록된다. 그 문서는 승인된 요구사항 변경 및 재사용할 수 있는 소프트웨어의 현재 능력의 분석 결과를 반영하기 위해 조정된다.)
  • 운영시나리오에 대한 업데이트 (프로토타이핑 결과, 성능분석, 요구사항 변경및기능적재할당의관점에서)
  • 사양을 분석하고 완성하기 위해 생성되는 DFD나 객체 지향 다이어그램
  • 요구사항분석결과, 강조및문제점들, TBD요구사항들, 시스템제약, 개발가정들의요약
  • TBD요구사항이나 다른 요인들로부터 발생하는 비용 및 스케줄 위험뿐만 아니라 프로젝트의 기술적 위험의 분석

 

  • The updated reuse plan (The original reuse proposal was developed during the requirements definition phase and recorded in the systems and operations concept document. It is adjusted to reflect approved requirements changes and the results of analysis of the reusable software’s current capabilities.)
  • Updates to operational scenarios (in view of prototyping results, performance analyses, requirements changes, and functional reallocations)
  • The DFDs or object-oriented diagrams generated to analyze and complete the specifications
  • A summary of the results of requirements analysis, highlighting problematic and TBD requirements, system constraints, and development assumptions
  • An analysis of the technical risks of the project, as well as cost and schedule risks resulting from TBD requirements or other factors

 

그림 4-4은 요구사항 분석 보고서의 형식과 내용을 제시한다.

Figure 4-4 presents the format and contents of the requirements analysis report.

 

소프트웨어 개발/관리 계획

The Software Development/Management Plan

 

소프트웨어 개발 관리 계획(SDMP)은 프로젝트에 사용되는 특정 기술 및 관리 방법의 상세한 해설을 제공한다. SDMP에서 개발 팀 매니저는 현재 프로젝트에 맞게 권장되는 방법을 조정하는 지에 대해서 논의하고 실제 진행 데이터와 비교를 위한 기준으로 자원 및 일정 견적을 제공한다.

 

The SDMP provides a detailed exposition of the specific technical and management approaches to be used on the project. In the SDMP, the development team manager discusses how the recommended approach will be tailored for the current project and provides the resource and schedule estimates that will serve as a baseline for comparisons with actual progress data.

 

REQUIREMENTS ANALYSIS REPORT

This report is prepared by the development team at the conclusion of the requirements analysis phase. It summarizes the results of requirements analysis and establishes a basis for beginning preliminary design. The suggested contents are as follows:

1.        Introduction — purpose and background of the project, overall system concepts, and document overview

2.        Reuse proposal — key reuse candidates and overall architectural concept for the system

3.        Operations overview — updates to system and operations concepts resulting from work performed during the requirements analysis phase

a.    Updated operations scenarios

b.    Operational modes, including volume and frequency of data to be processed in each mode, order, and type of operations, etc.

c.    Updated descriptions of input, output, and messages

4.        Specification analysis

a.    Summary of classifications (mandatory, requires review, information only, needs clarification, or TBD) assigned to requirements and specifications

b.    Problematic specifications — identification and discussion of conflicting, ambiguous, infeasible, untestable, and TBD requirements and specifications

c.    Unresolved requirements/operations issues, including the dates by which resolutions are needed

d.    Analysis of mathematical algorithms

5.        System constraints

a.    Hardware availability — execution, storage, peripherals

b.    Operating system limitations

c.    Support software limitations

6.        Performance estimates and models

7.        Development assumptions

8.        Risks, to both costs and schedules.  (These should include risks related to TBD or changing requirements, as well as technical risks.)

9.        Prototyping efforts needed to resolve technical risks, including the goals and completion criteria for each prototyping effort

10.     Data flow or object-oriented diagrams — results of all structured or object-oriented analysis of the requirements performed during the requirements analysis phase

11.     Data dictionary — for the updated processes, data flows, and objects shown in the diagrams

Figure 4-4. Requirements Analysis Report Contents

 

관리자는 요구사항 분석 단계에서 SDMP을 준비하고 개발 라이프 사이클 전반에 걸쳐 최신으로 유지한다. 이 계획은 중요하기 때문에 소프트웨어 개발에 대한 관리자의 수첩 (참고 12)에 자세히 설명되어 있다.

 

The manager prepares the SDMP during the requirements analysis phase and keeps it up to date throughout the development life cycle. Because of the primary importance of this plan, it is described in detail in the Manager’s Handbook for Software Development (Reference 12).

 

SDMP은 소프트웨어 개발 접근법을 포함한다; 위험과 위험 완화에 대한 설명; 시스템의 크기의 초기 추정; 및 일정, 인력, 자원, 프로젝트의 비용을 추정하고 있다. 그림 4-5은 SDMP의 내용을 간략하게 설명한다.

 

The SDMP includes a software development approach; a description of risks and risk mitigation; an initial estimate of the system’s size; and estimates of the schedule, staffing, resources, and cost of the project. Figure 4-5 outlines the contents of the SDMP.

 

SOFTWARE DEVELOPMENT/MANAGEMENT PLAN

In some sections of the plan, material (shown in italics) is to be regularly added during the life of the project. Other sections should be revised and reissued if circumstances require significant changes in approach.

1.      INTRODUCTION

1.1          Purpose — brief statement of the project’s purpose.

1.2          Background — brief description that shows where the software products produced by the project fit into the overall system.

1.3          Organization and Responsibilities

1.3.1   Project Personnel — explanation and diagram of how the development team will organize activities and personnel to carry out the project: types and numbers of personnel assigned, reporting relationships, and team members’ authorities and responsibilities (see Reference 12 for guidelines on team composition).

1.3.2   Interfacing Groups — list of interfacing groups, points of contact, and group responsibilities.

2.      STATEMENT OF PROBLEM — brief elaboration of the key requirements, the steps numbered) to be taken to accomplish the project, and the relation (if any) to other projects.

3.      TECHNICAL APPROACH

3.1               Reuse Strategy — high-level description of the current plan for reusing software from existing systems.

3.2               Assumptions and Constraints — that govern the manner in which the work will be performed.

3.3               Anticipated and Unresolved Problems — that may affect the work and the expected effect on each phase.

3.4               Development Environment — development computer and programming languages.

3.5               Activities, Tools, and Products — for each phase, a matrix showing (a) the major activities to be performed, (b) the development methodologies and tools to be applied, and (c) the products of the phase. Includes discussion of any unique approaches or activities.

3.6               Build Strategy — which portions of the system will be implemented in which builds and the rationale for this. Determined during the preliminary design phase. Updated at the end of detailed design and after each build.

4.        MANAGEMENT APPROACH

4.1          Assumptions and Constraints — that affect the management approach, including project priorities.

4.2          Resource Requirements — tabular lists of estimated levels of resources required, including estimates of system size (new and reused SLOC), staff effort (managerial, programmer, and support) by phase, training requirements, and computer resources. Includes estimation methods or rationale used. Updated estimates are added at the end of each phase.

4.3          Milestones and Schedules — list of work to be done, who will do it, and when it will be completed. Includes development life cycle (phase start and finish dates); build/release dates; delivery dates of required external interfaces; schedule for integration of externally developed software and hardware; list of data, information, documents, software, hardware, and support to be supplied by external sources and delivery dates; list of data, information, documents, software, and support to be delivered to the customer and delivery dates; and schedule for reviews (internal and external).  Updated schedules are added at the end of each phase.

4.4          Measures — a table showing, by phase, which measures will be collected to capture project data for historical analysis and which will be used by management to monitor progress and product quality (see Reference 12). If standard measures will be collected, references to the relevant standards and procedures will suffice. Describes any measures or data collection methods unique to the project.

4.5          Risk Management — statements of each technical and managerial risk or concern and how it is to be mitigated. Updated at the end of each phase to incorporate any new concerns.

5.       PRODUCT ASSURANCE

5.1          Assumptions and Constraints — that affect the type and degree of quality control and configuration management to be used.

5.2          Quality Assurance — table of the methods and standards that will be used to ensure the quality of the development process and products (by phase). Where these do not deviate from published methods and standards, the table should reference the appropriate documentation.  Methods of ensuring or promoting quality that are innovative or unique to the project are described explicitly. Identifies the person(s) responsible for quality assurance on the project, and defines his/her functions and products by phase.

5.3          Configuration Management — table showing products controlled, as well as tools and procedures used to ensure the integrity of the system configuration   (when is the system under control, how are changes requested, who makes the changes, etc.). Unique procedures are discussed in detail. If standard configuration management practices are to be applied, references to the appropriate documents are sufficient. Identifies the person responsible for configuration management and describes this role. Updated before the beginning of each new phase with detailed configuration management procedures for the phase, including naming conventions, directory designations, reuse libraries, etc.

6.       APPENDIX:  PROTOTYPING PLANS — collected plans for each prototyping effort to be conducted on the project.

7.       PLAN UPDATE HISTORY — lead sheets from each update of the SDMP, indicating which sections were updated and when the update was made.

Figure 4-5. SDMP Contents

 

업데이트 된 요구사항 및 명세

Updated Requirements and Specifications

 

이 단계에서, 요구사항 정의 팀 승인 사양 변경에 기초하여 요구 사양 문서에 업데이트를 준비한다. 추가 사양 변경은 SSR 또는 RID 프로세스에서 논의의 결과로 승인될 수 있다. 그들은 소프트웨어 디자인을 생성하는 대로 개발자가 사용할 수 있도록 요구사항 정의의 팀은 업데이트 된 요구사항 및 사양 문서가 곧 SSR 후 게시되어 있는지 확인해야 한다.

 

During this phase, the requirements definition team prepares updates to the requirements and specifications document on the basis of approved specification modifications. Additional specification modifications may be approved as a result of discussion at the SSR or the RID process. The requirements definition team must ensure that the updated requirements and specifications document is republished shortly after the SSR, so that it will be available to the developers as they generate the software design.

 

 

프로토타이핑 계획

Prototyping Plans

 

프로토타이핑 노력을 관리하는 특별한 경계가 필요하다. 진행을 예측하고 측정하는 것이 어렵다. 기준이 프로토타이핑을 평가하고 완료를 판단하기 위한 설정되지 않은 경우 프로토타이핑의 노력은 무한정 계속될 수 있다. 각 프로토타이핑의 활동에 대한 계획을 작성하는 것은, 아무리 간단해도 제어를 구축하는 데에 매우 중요하다.

 

Managing a prototype effort requires special vigilance. Progress is often difficult to predict and measure. A prototyping effort may continue indefinitely if no criteria are established for evaluating the prototype and judging completion. Writing a plan for each prototyping activity, no matter how brief, is vital to establishing control.

 

계획의 길이 및 준비 시간은 프로토타이핑 노력의 크기 및 범위에 비례한다. 한 페이지의 계획은 작은 프로토타이핑 노력에 필요한 모든 것을 할 수 있다. 간단한 계획은 별도로 게시 할 수 있지만, 대신 SDMP (그림 4-5)에 통합할 필요는 없다.

 

The length of the plan and the time to prepare it should be proportional to the size and scope of the prototyping effort. A one- page plan may be all that is required for small prototyping efforts. A brief plan need not be published separately but may, instead, be incorporated into the SDMP (Figure 4-5).

 

다음 항목은 계획에 포함되어야 한다:

  • 프로토타이핑의목표-목적과 사용
  • 행해질일과생성되는 제품의정책
  • 완료기준
  • 평가방법– 누가 프로토타이핑을평가하고 어떻게 그것을 평가할것인가
  • 기술방식
  • 필요한자원 -노력과크기추정, 가능직원의통역서비스,하드웨어, 소프트웨어등
  • 일정

 

The following items should be included in the plan:

  • Objective of the prototype — its purpose and use
  • Statement of the work to be done and the products to be generated
  • Completion criteria
  • Assessment methods — who will evaluate the prototype and how it will be evaluated
  • Technical approach
  • Resources required — effort and size estimates, staff, hardware, software,
  • Schedule

 

SDMP는 자세한 프로토타이핑 계획의 요약을 포함해야 한다. 각각의 요약은, 일반적인 방법을 설명하는 프로토타이핑 할 항목을 논의하고, 노력의 추정을 포함하며, 일정을 제공하고, 일정에 대한 이론적 근거를 설명해야 한다.

 

The SDMP should contain summaries of the detailed prototyping plans. Each summary should describe the general approach, discuss the items to be prototyped, include effort estimates, provide a schedule, and discuss the rationale for the schedule.

 

소프트웨어 사양 검토

SOFTWARE SPECIFICATION REVIEW

 

요구사항 분석의 결론에서, 개발 팀은 SSR을 보유하고 있다. 이 프로젝트 관리 및 시스템의 최종 사용자에 대해 실시하는 고수준의 리뷰이다. SSR 형식, 일정, 참가자는 그림 4-6에서 세분화 된다.

 

At the conclusion of requirements analysis, the development team holds an SSR. This is a high-level review conducted for project management and the end users of the system. The SSR format, schedule, and participants are itemized in Figure 4-6.

 

SSR FORMAT

Presenters — software development team

Participants

•       Requirements definition team

•       Customer interfaces for both the requirements definition and software development teams

•       User representatives

•       Representatives of interfacing systems

•       Quality assurance representatives for both teams

•       System capacity/performance analysts

•       CCB

Schedule — after requirements analysis is complete and before the preliminary design phase is begun

Agenda — selective presentation of the results of requirements analysis, directed primarily toward project management and the users of the system

Materials Distribution

•       The requirements analysis report and software development/ management plan are distributed 1 to 2 weeks before SSR.

•       Hardcopy material is distributed a minimum of 3 days before SSR.

Figure 4-6.  SSR Format

 

SSR 하드카피 자료

SSR Hardcopy Material

 

검토를 위해 하드 카피 자료는 요구사항 분석 보고서에 있는 동일한 정보의 일부가 포함된다. 프레젠테이션에 포함 할 가장 적절한 정보를 선택하는 유연성이 있음을 유의하십시오. 그림 4-7에서 제안된 내용은 가이드라인으로 구성되어있다.

The hardcopy materials for the review will contain some of the same information found in the requirements analysis report. Keep in mind that there is some flexibility in selecting the most appropriate information to include in the presentation. The contents suggested in Figure 4-7 are intended as a guideline.

 

HARDCOPY  MATERIAL  FOR  THE  SSR

1.      Agenda — outline of review material

2.      Introduction — background of the project and purpose of system

3.      Analysis overview — analysis approach, degree of innovation required in analysis, special studies, and results

4.      Revisions since SRR — changes to system and operations concepts, requirements, and specifications effected following the SRR

5.      Reusable software summary

a.   Key reuse candidates — identification of existing software components that satisfy specific system specifications exactly or that will satisfy the specifications after modification

b.   Overall architectural concept for the system

c.   Matrix of requirements to be fulfilled by reused components

6.      Requirements classification summary

a.   List of requirements and specifications with their assigned classifications (mandatory, requires review, needs clarification, information only, or TBD)

b.   Problematic specifications — identification and discussion of conflicting, ambiguous, infeasible, and untestable requirements and specifications

c.   Unresolved requirements/operations issues, including the dates by which resolutions to TBDs are needed (NOTE:  This is a key element of the SSR.)

7.      Functional or object-oriented specifications

a.   Object diagrams or high-level data flow diagrams showing input, transforming processes, and output

b.   Data set definitions for external interfaces to the system

8.      Performance model — key estimates and results of modeling system performance

9.      Development  considerations

a.   System constraints — hardware availability, operating system limitations, and support software limitations

b.   Utility, support, and test programs — Iist of auxiliary software required to support development (e.g., data simulators, special test programs, software tools, etc.)

c.   Testing  requirements

d.   Development  assumptions

10.       Risks, both to costs and schedules — includes how risks are identified, their potential impact, and how they will be managed. Covers risks related to TBD or changing requirements as well as technical risks

11.       Summary of planned prototyping efforts needed to resolve technical risks, including the goals and schedule for each effort and a summary of any prototyping conducted to date

12.       Key contacts — leaders of technical teams, application specialists, and other key project members

13.       Milestones and schedules — includes size estimates, development life cycle (phase start and finish dates), schedule for reviews (internal and external), build/release requirements, delivery dates of required external interfaces, schedule for integration of externally developed software and hardware

Figure 4-7.  SSR Hardcopy Material

 

IEEE 830-1998 Recommended Practice for Software Requirement Specification

좋은 요구사항의 특성

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

SECTION 4. 요구사항 분석 단계

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

Advertisements

4 thoughts on “Section 4. 요구사항 분석 단계”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s