Section 3. 요구사항 정의 단계


목차

 

SECTION 3 요구사항 정의 단계

THE REQUIREMENTS DEFINITION PHASE

3.0

개요

OVERVIEW

 

요구사항 정의 단계의 목적은 소프트웨어 제품에 대한 기술적인 요구의 명확하고, 완성되고, 일관성 있으며 검증 가능한 사양을 생성하는 것이다.

 

The purpose of the requirements definition phase is to produce a clear, complete, consistent, and testable specification of the technical requirements for the software product.

 

요구사항 정의는 소프트웨어 개발 라이프 사이클을 시작한다. 이 단계에서 요구사항 정의 팀은 소프트웨어가 수행하고 충족해야 각 기준해야 하는 각 기능의 완전하고 상세한 사양에 시스템 요구사항의 넓은 문을 확장하는 반복적인 프로세스를 사용한다. 독립 소프트웨어 개발자가 제대로 필요한 시스템을 구축 할 수 있도록 시스템과 운영 개념과 함께 완성된 요구사항 및 사양은 충분히 상세하게 소프트웨어 제품에 대해 설명한다.

 

Requirements definition initiates the software development life cycle. During this phase, the requirements definition team uses an iterative process to expand a broad statement of the system requirements into a complete and detailed specification of each function that the software must perform and each criterion that it must meet. The finished requirements and specifications, combined with the system and operations concept, describe the software product in sufficient detail so that independent software developers can build the required system correctly.

 

시작점은 보통 프로젝트 또는 문제점을 설명하는 고객으로부터 상위 요구의 집합이다. 임무 지원 시스템의 경우, 이러한 요구사항은 이러한 시스템의 계측 요구사항 문서 (SIRD, system instrumentation requirements document) 및 시스템 운영 요구사항 문서 (SORD, system operations requirements document)와 같은 프로젝트 문서에서 추출된다. 내부적인 도구를 위해서, 높은 수준의 요구사항은 종종 단순히 도구가 제공하는 기능의 목록이다.

 

The starting point is usually a set of high-level requirements from the customer that describe the project or problem. For mission support systems, these requirements are extracted from project documentation such as the system instrumentation requirements document (SIRD) and the system operations requirements document (SORD). For internal tools, high-level requirements are often simply a list of the capabilities that the tool is to provide.

 

어느 경우, 요구사항 정의 팀은 이전의 임무 또는 시스템의 유사성에 ​​대한 높은 수준의 요구를 검사하는 재사용 할 수 있는 기존의 소프트웨어를 식별하고, 예비 시스템 아키텍처를 개발함으로써 시스템의 전체적인 개념을 공식화한다. 팀은 그 시스템이 작동하는 방법을 보여주는 시나리오를 정의하고, 시스템 및 운영 개념 문서를 게시하고, 시스템의 개념을 검토 (SCR)를 실시한다. (그림 3-1 참조).

 

In either case, the requirements definition team formulates an overall concept for the system by examining the high-level requirements for similarities to previous missions or systems, identifying existing software that can be reused, and developing a preliminary system architecture. The team then defines scenarios showing how the system will be operated, publishes the system and operations concept document, and conducts a system concept review (SCR). (See Figure 3-1.)

 

SCR에 따라, 팀은 상위 요구에서 시스템과 시스템 및 동작 개념에 대한 상세한 요건을 유도한다. 구조화 또는 객체 지향 분석을 사용하여, 팀은 각각 상세한 필요 조건을 만족하기 위해 필요한 소프트웨어 기능 및 알고리즘을 명세 한다.

 

Following the SCR, the team derives detailed requirements for the system from the high- level requirements and the system and operations concept. Using structured or object-oriented analysis, the team specifies the software functions and algorithms needed to satisfy each detailed requirement

 

명세가 완료되면, 요구사항 정의의 팀은 세 부분의 요구사항 및 사양 문서를 게시한다. (1) 세부적인 요구사항, (2) 기능적 명세 또는 객체 지향적 명세 및 (3) 필요한 수학적 배경 정보. 이 단계의 끝에서, 팀은 이 제품의 완성도와 품질을 입증하기 위한 시스템 요구사항 검토 (SRR)를 실시한다. (그림 3-2 참조).

 

When the specifications are complete, the requirements definition team publishes the requirements and specifications document in three parts: (1) the detailed requirements, (2) the functional or object-oriented specifications, and (3) any necessary mathematical background information. At the end of the phase, the team conducts a system requirements review (SRR) to demonstrate the completeness and quality of these products. (See Figure 3-2.)

3.1

Figure 3-1.   Generating the System and Operations Concept

 3.2

Figure 3-2.  Developing Requirements and Specifications

 

핵심 활동들

KEY ACTIVITIES

The key technical and managerial activities of the requirements definition phase are itemized below.

 

Tailoring notes

도구나 프로토타이핑을 개발하는 작은 프로젝트에서 요구사항 정의 및 분석은 종종 하나의 단계로 결합된다. 이러한 프로젝트에서 개발자는 일반적으로 모든 요구사항 정의 활동을 수행한다.

On small projects that are developing tools or prototypes, requirements definition and analysis are often combined into a single phase. On such projects, developers generally perform all requirements definition activities.

 

요구사항정의 팀의 활동들

Activities of the Requirements Definition Team

 

  • 시스템 개념 개발한다. 시스템에 대한 모든 높은 수준의 요구사항을 수집하고 항목별로. 시스템이 이러한 높은 수준의 요구사항을 만족하기 위해 수행해야 하는 기본적인 기능을 설명한다. 이러한 시스템의 수명 (사용 타임 라인), 성능, 보안, 안정성, 안전성, 데이터 볼륨 등을 문제를 다룬다.이러한 기능적인 설명으로부터, 소프트웨어 프로그램 및 모든 중요한 인터페이스를 식별하는 이상적이고 높은 수준의 시스템 아키텍처를 생성한다. 소프트웨어, 하드웨어, 또는 사람에게 각각 높은 수준의 요구사항을 할당한다. 모든 주요 데이터 인터페이스의 형태 (파일, 디스플레이, 출력)을 명세한다.

 

  • Develop a system concept. Collect and itemize all high-level requirements for the system. Describe the basic functions that the system must perform to satisfy these high-level requirements. Address issues such as system lifetime (usage timelines), performance, security, reliability, safety, and data volume.From this functional description, generate an ideal, high-level system architecture identifying software programs and all major interfaces. Allocate each high-level requirement to software, hardware, or a person. Specify the form (file, display, printout) of all major data interfaces.

 

  • 재사용 제안을 준비한다. 재사용을 위한 후보자를 식별하기 위해 요구사항 및 사양, 시스템 설명, 사용자 가이드 및 관련, 기존 시스템의 소스 코드를 검토한다. 항공 역학 임무 지원 시스템의 경우, 이 유사한 우주선에 대한 지원 시스템을 검토하는 것을 포함한다. 유력한 후보를 선택하고 해당 비용 및 신뢰성 혜택을 예상한다. 소프트웨어를 재사용하고 장단점을 분석하는 데 필요한 어떤 타협을 확인한다. 재사용 가능한 소프트웨어를 설명하기 위해 하이 레벨 아키텍처를 조정한다. 시스템 및 동작 개념 문서에 포함될 것 재사용 계획안의 모든 재사용 분석 결과를 기록한다.

 

  • Prepare the reuse proposal. Review the requirements and specifications, system descriptions, user’s guides, and source code of related, existing systems to identify candidates for reuse. For flight dynamics mission support systems, this involves reviewing support systems for similar spacecraft. Select strong candidates and estimate the corresponding cost and reliability benefits. Determine what compromises are necessary to reuse software and analyze the tradeoffs.Adjust the high-level architecture to account for reusable software. Record the results of all reuse analysis in a reuse proposal that will be included in the system and operations concept document.

 

  • 운영 개념 개발한다. 이것은 분명히 시스템이 환경에서 동작해야 하는 방법을 정의한다. 운영 작업의 주요 모드에 대한 시나리오 (예를 들면, 정상 대 긴급) 등이 있다. 이 과정에서 최종 사용자를 포함해야 한다. SCR을 실시한다.

 

  • Develop an operations concept. This clearly defines how the system must operate within its environment. Include operational scenarios for all major modes of operation (e.g., emergency versus normal). Be sure to include the end-user in this process. Conduct an SCR.

 

  • 자세한 요구사항을 정의한다. 상위 요구와 시스템 개념 및 아키텍처에 기초하여, 서브 시스템 수준까지 모든 소프트웨어 요건을 정의한다. 시스템은 (많은 서브 시스템으로) 큰 또는 다른 시스템과 인터페이스 하는 경우, 명시적으로 모두 외부 인터페이스를 정의하면 시스템 성능과 신뢰성 요구사항을 결정한다. 특정한 판정 기준을 (특정 응답 시간을 만족 예) 요건에 적용할 수 있다면, 요구사항과 시험 조건을 명세 한다. 승인 테스트 시스템에 필요한 모든 중간 제품을 확인한다.

 

  • Define the detailed requirements. Based on the high-level requirements and the system concept and architecture, define all software requirements down to the subsystem level. If the system is large (with many subsystems) or if it will interface with other systems, explicitly define all external interfacesDetermine system performance and reliability requirements. If certain acceptance criteria apply to a requirement (e.g., meeting a particular response time), specify the test criteria with the requirement. Identify all intermediate products needed to acceptance test the system.

 

  • 요구사항에서 시스템의 기능 사양을 파생시킨다. 요건을 충족하기 위해 필요한 주 입력 및 출력 데이터를 식별한다. 소프트웨어가 반드시 수행해야 하는 낮은 수준의 기능 및 알고리즘을 유도하기 위한 구조적 및 객체 지향적 분석을 사용한다. 모든 보고서 및 디스플레이를 정의하고 사용자가 어떤 데이터를 수정할 수 있어야 하는지를 표시한다.디자인 중립적이고 언어 중립적 사양을 유지한다; 즉, 소프트웨어를 어떻게 할 것인지에 집중하려고 하지 말고 소프트웨어가 수행하기 위해 필요한 것이 무엇인지에 집중한다. 각각의 낮은 수준의 기능 혹은 데이터 사양과 그것이 충족시키고자 했던 요구사항을 매핑하기 위한 추적 테이블을 생성한다.모든 요구사항 및 사양이 철저하게 피어 리뷰가 되었는지 확인한다. 주요 기능들 사이의 인터페이스 문제를 감시하고 여러 서브 시스템에서 중복되는 사양 인터페이스 문제에 대한 감시를 수행한다. 지정된 알고리즘 간의 호환성 및 표기상의 일치성, 그리고 정확도 수준을 보장한다.소프트웨어 개발을 시작하기 위한 기초로서 필요한 수학적 배경 정보를 포함하는 요구 사양 문서를 준비한다.

 

  • Derive the functional specifications for the system from the requirements. Identify the primary input and output data needed to satisfy the requirements. Use structured or object-oriented analysis to derive the low-level functions and algorithms the software must perform. Define all reports and displays and indicate which data the user must be able to modify.Keep the specifications design-neutral and language-neutral; i.e., concentrate on what the software needs to do, rather than how it will do it. Create a traceability matrix to map each low-level function or data specification to the requirements it fulfills.Ensure that all requirements and specifications are given a thorough peer review. Watch for interface problems among major functions and for specifications that are duplicated in multiple subsystems. Ensure compatibility and consistency in notation and level of accuracy among the specified algorithmsPrepare the requirements and specifications document, including any necessary mathematical background information, as a basis for beginning software development.

 

  • SRR 실시하고, 요구사항 및 사양에 승인된 변경 사항을 적용한다. 시스템의 베이스 라인으로 문서를 형상 관리하에 둔다.

 

  • Conduct the SRR and incorporate approved changes into the requirements and specifications. Place the document under configuration management as the system baseline.

 

 

관리팀의 활동들

Activities of the Management Team

 

The management activities performed during this phase pave the way for all future phases of the project’s life cycle. Specifically, managers must accomplish the following:

 

  • 단계에 대한 계획을 개발한다. (시스템 사양이 정의가 완료된 후 전체 개발 노력의 세부 계획은 요구사항 분석 단계로 연기된다.) 기술적인 작업을 수행할 팀의 인력 수급방안을 언급하고 그 팀과 인터페이스 할 단체와 개인 접근 방법, 이정표 및 일정, 위험 관리, 품질 보증을 언급한다. 실시할 리뷰와 형식의 수준을 나열한다.

 

  • Develop a plan for the phase. (Detailed planning of the entire development effort is deferred to the requirements analysis phase, after system specifications have been defined.) Address the staffing of the teams that will perform the technical work, the groups and individuals that will interface with the teams, the technical approach, milestones and schedules, risk management, and quality assurance. List the reviews to be conducted and their level of formality.

 

  • 요구사항 정의 팀의 직원을 채용하고 훈련시킨다. 팀이 기술과 작업에 대한 경험이 필요한 조합이 있는지 확인한다. 임무 지원 시스템의 경우, 팀은 임무 분석, 자세와 궤도 결정에 강한 배경을 가진 분석가와의 작업을 포함해야 한다. 재사용 작업 그룹은 주요 소프트웨어 개발자뿐만 아니라 경험 분석을 포함해야 한다. 직원들이 절차, 방법, 그리고 자신의 목표를 달성하는 데 필요한 도구에 대해 직원들의 필요한 교육이 있는지 확인한다.

 

  • Staff and train the requirements definition team. Ensure that the team contains the necessary mix of skills and experience for the task. For mission support systems, the team should include analysts with strong backgrounds in mission analysis, attitude and orbit determination, and operations. The reuse working group must include key software developers as well as experienced analysts. Ensure that staff members have the necessary training in the procedures, methods, and tools needed to accomplish their goals.

 

  • 모든문제의 가시성및해결을 보장하기 위해 고객과 상호 작용한다. 일반 상태의 회의를 수행하고 팀 구성원, 관리자, 고객 및 프로젝트의 측면에 작업을 다른 그룹들 사이의 통신을 보장한다.

 

  • Interact with the customer to assure visibility and resolution of all issues. Conduct regular status meetings and ensure communications among team members, managers, customers, and other groups working on aspects of the project.

 

  • 진행 상황 제품을 평가한다. 시스템 및 운영 개념과 요구사항 및 사양을 검토한다. 진행 조치를 수집하고 일정과 비용에 대한 준수를 모니터링 한다.

 

  • Evaluate progress and products. Review the system and operations concept and the requirements and specifications. Collect progress measures and monitor adherence to schedules and cost.

 

  • 주요 리뷰를 제어한다. 핵심 인력들이 공식 및 비공식 리뷰에 모두 참석했는지 확인한다. SCR 및 SRR에 참여한다.

 

  • Control major reviews. Ensure that key personnel are present at reviews, both formal and informal. Participate in the SCR and SRR.

 

방법 및 도구

METHODS AND TOOLS

 

The methods and tools used during the requirements definition phase are

 

  • Structured or object-oriented analysis
  • Walk-throughs
  • Prototyping

 

Each is discussed below.

 

 

분석 방법론

Analysis Methodologies

 

구조적 분석과 객체 지향 분석은 요구사항 정의에 있는 텍스트 문장의 의미를 이해하고 명확하게 하기 위해 사용되는 기술이다. 요구사항 정의 팀은 상위 레벨 요건 시스템 상세 사양을 도출하는 분석 기법을 사용한다. 프로젝트를 위해 선택된 분석 방법론은 문제의 유형 시스템이 언급하는 문제의 타입에 적당해야 한다.

 

Structured analysis and object-oriented analysis are techniques used to understand and articulate the implications of the textual statements found in the requirements definition. The requirements definition team uses analysis techniques to derive the detailed specifications for the system from the higher-level requirements. The analysis methodology selected for the project should be appropriate to the type of problem the system addresses.

 

기능 분해는 현재 구조 분석의 가장 일반적으로 사용되는 방법이다. 기능 분해는 프로세스에 초점을 맞추고, 이들 각각은 입력에 대한 출력 변환의 집합을 나타낸다. 이 방법을 사용하여, 분석자는 주요 시스템 기능을 연속적으로 더욱 심화된 수준의 프로세스로 분리하고 이들 프로세스들간의 데이터 플로우를 정의한다. 구조 분석과 관련된 저자는 E. Yourdon, L.Constantine 및 T. DeMarco(참고 자료 13, 14)가 있다. S. Mellor와 P. Ward는 이벤트 응답 분석 (참조 15) 에 대해 이 방법을 실시간으로 확장 세트를 발표했다.

 

13. E. Yourdon and L. L. Constantine, Structured Design, Yourdon Press: NY, 1978

14. T. DeMarco, Structured Analysis and System Specification, Yourdon, Inc.: NY, 1978

15. P. Ward and S. Mellor, Structured Development for Real-Time Systems, Prentice-Hall:Englewood Cliffs, NJ, 1985

 

Functional decomposition is currently the most commonly used method of structured analysis. Functional decomposition focuses on processes, each of which represents a set of transformations of input to output. Using this method, the analyst separates the primary system function into successively more detailed levels of processes and defines the data flows between these processes. Authors associated with structured analysis include E. Yourdon, L.Constantine, and T. DeMarco (References 13 and 14). S. Mellor and P. Ward have published a set of real-time extensions to this method for event-response analysis (Reference 15).

 

객체 지향 분석은 프로세스의 방향으로 데이터 공학의 영역에서의 기술을 결합한다. 이 방법은 객체 (또는 엔티티)와 실제 세계의 ​​문제 도메인과 상호 관계의 속성을 정의한다. 객체의 개념은 엔티티의 영구적인 관점에서 집중하는 수단으로 제공한다. – 구조적 분석의 그것과는 다른 강조. 객체 지향 접근법은 재사용을 위해 설계된 소프트웨어에 적합한데 그 이유는 특정 객체는 다른 task를 위한 시스템에 적합하도록 하기 위해 쉽게 추출가능하고 교체 가능할 수 있기 때문이다. 객체 지향 접근 방식의 상세는 참고 문헌 11, 16, 및 17에서 확인할 수 있다.

 

11. G. Booch, Object-Oriented Design (with Applications), Benjamin/Cummings: Redwood City, CA, 1991

16. P. Coad and E. Yourdon, Object-Oriented Analysis, Yourdon Press: NY, 1991

17. Software Engineering Laboratory, SEL-86-002, General Object-Oriented Software Development, E. Seidewitz and M. Stark, August 1986

 

Object-oriented analysis combines techniques from the realm of data engineering with a process orientation. This method defines the objects (or entities) and attributes of the real-world problem domain and their interrelationships. The concept of an object provides a means of focusing on the persistent aspect of entities — an emphasis different from that of structured analysis. An object-oriented approach is appropriate for software designed for reuse because specific objects can be readily extracted and replaced to adapt the system for other tasks (e.g., a different spacecraft). Details of the object-oriented approach may be found in References 11, 16, and 17.

 

구조적 분석에서 만약 기능들이 높은 수준의 기능의 실행 단계에 있다면 기능들은 같이 그룹화된다. 객체 지향적 분석에서 기능들이 동일한 데이터 추상화 위에서 동작한다면 기능들은 같이 그룹화된다. 이런 차이로 인해 기능적 사양으로부터 객체 지향적 설계로의 진행은 데이터 플로우 다이어그램을 다시 작성하는 필요가 있을 수 있다. 이것은 요구사항 정의 단계 동안 객체 지향적 관점을 가정함으로 회피될 수 있는 상당한 노력이다.

 

In structured analysis, functions are grouped together if they are steps in the execution of a higher-level function. In object-oriented analysis, functions are grouped together if they operate on the same data abstraction. Because of this difference, proceeding from functional specifications to an object-oriented design may necessitate recasting the data flow diagrams. This is a significant amount of effort that can be avoided by assuming an object-oriented viewpoint during the requirements definition phase.

 

CASE 도구의 다이어그램 능력은 선택된 분석 방법의 응용을 용이하게 한다. 그 도구는 필요한 데이터 플로우 및 온라인 객체 다이어그램을 생성하고 유지하는 수단을 제공한다. 그들은 일반적으로 데이터, 프로세스 및 개체의 정의를 저장하고 검색하기 위한 중앙 저장소를 포함한다. 고급 도구들은 사양 자체가 요구사항에서 설계 엘리먼트에 쉽게 추적할 수 있도록 저장소에 유지되도록 할 수 있다.

 

The diagramming capabilities of CASE tools facilitate application of the chosen analysis methodology. The tools provide a means of producing and maintaining the necessary data flow and object-diagrams online. They usually include a centralized repository for storing and retrieving definitions of data, processes, and entities. Advanced tools may allow the specifications themselves to be maintained in the repository, making it easier to trace the requirements to design elements.

 

선택된 도구는 사양 및 다른 문서에 직접적으로 통합될 수 있는 형태로 다이어그램을 인쇄할 수 있는 능력이 있어야 한다. 현재 비행 역학 환경에서 사용되는 CASE 도구의 예로는 그림을 통한 시스템 아키텍트와 소프트웨어를 포함한다.

 

Selected tools should be capable of printing the diagrams in a form that can be directly integrated into specifications and other documents. Examples of CASE tools currently used in the flight dynamics environment include System Architect and Software Through Pictures.

 

워크스루

Walk-throughs

 

수명주기의 모든 단계에서, 피어 리뷰는 생성되는 제품의 품질과 일관성을 보장한다. SEL은 SRR 및 CDR 등과 같은 형식적 검토를 추가하여 두 가지 타입의 피어 리뷰를 권장한다. – 워크스루 및 검사.

 

In all phases of the life cycle, peer review ensures the quality and consistency of the products being generated. The SEL recommends two types of peer review — walk-throughs and inspections — in addition to formal reviews such as the SRR and CDR.

 

워크스루는 주로 이해를 돕기 위해서 주로 수행된다. 그러므로 참가자들은 토론에서 자료를 분석하고 질문하도록 장려 받는다. 검토 자료는 회의 전에 참가자들에게 배포된다. 회의 동안, 워크스루 리더는 간단하게 제품에 대한 튜토리얼 개요를 제공하고 검토자가 단계별로 검토하도록 한다. 참가자 간의 질문과 답변의 비공식적인 분위기와 자유로운 교환 학습 과정을 촉진한다.

 

Walk-throughs are primarily conducted as an aid to understanding, so participants are encouraged to analyze and question the material under discussion. Review materials are distributed to participants prior to the meeting. During the meeting, the walk-through leader gives a brief, tutorial overview of the product, then walks the reviewers through the materials step-by-step. An informal atmosphere and a free interchange of questions and answers among participants fosters the learning process.

 

반면에, 검사는 가능한 한 빨리 오류를 발견하고 고품질의 제품을 위한 목적으로 수행된다. 검사 팀은 기술적 능력과 프로젝트에 사용되는 어플리케이션, 언어, 표준에 익숙한 작은 피어 그룹이다. 검토되어야 하는 제품(예를 들면, 요구사항, 설계 다이어그램, 또는 소스코드)은 몇 일 회의 전에 검사 팀에 주어진다. 검사자들은 이런 제품을 밀접하게 검사하고 표준으로부터 어떤 에러나 편차를 기록하고 어떤 문제를 항목별로 나열하고 토론하기 위해 준비된 검토 회의에 온다.

 

Inspections, on the other hand, are designed to uncover errors as early as possible and to ensure a high-quality product. The inspection team is a small group of peers who are technically competent and familiar with the application, language, and standards used on the project. The products to be reviewed (e.g., requirements, design diagrams, or source code) are given to the inspection team several days before the meeting. Inspectors examine these materials closely, noting all errors or deviations from standards, and they come to the review meeting prepared to itemize and discuss any problems.

 

워크스루 및 검사 모두에서, 지정된 팀 구성원은 제기 된 문제, 할당 된 작업 항목 및 완료 일정을 포함하여 검토 세션의 상세한 것을 기록한다. 제기된 이런 항목들의 마감은 다음 회의에서 해결된다.

 

In both walk-throughs and inspections, a designated team member records the minutes of the review session, including issues raised, action items assigned, and completion schedules. Closure of these items is addressed in subsequent meetings.

 

요구사항 정의 단계에서 요구사항 및 사양의 워크스루는 요구사항이 형성 단계에 있는 동안 핵심적인 이해 당사자가 입력을 제공할 수 있도록 하기 위해 실시된다. 참가자들은 개발 팀에서 요구사항 정의 팀의 구성원, 개발하는 소프트웨어와 인터페이스 할 시스템의 대표 및 어플리케이션 전문가가 있다.

 

In the requirements definition phase, walk-throughs of the requirements and specifications are conducted to ensure that key interested parties provide input while requirements are in a formative stage. Participants include the members of the requirements definition team, representatives of systems that will interface with the software to be developed, and application specialists from the development team.

 

 

프로토타이핑

Prototyping

 

요구사항 정의 단계에서, MathCAD가 명세서에 포함되어야 하는 수학적 알고리즘을 시험하기 위해 해결하는 것을 돕기 위해서 프로토타이핑이 필요할 수 있다. 성능 요구사항에 대한 플랫폼 특정 성능 모델이나 측정 / 모니터링 도구가 사용될 수 있다.

 

During the requirements definition phase, prototyping may be needed to help resolve MathCAD to test the mathematical algorithms that will be included in the specifications. For performance requirements, platform-specific performance models or measurement/monitoring tools may be used.

 

측정

MEASURES

 

객관적인 측정

Objective Measures

 

세 가지 진행 대책 요구사항 정의 단계에서 추적:

 

  • 직원의 시간 – 프로젝트 직원 즉, 누적 된 노력의 시간
  • 요구사항의 총 개수 대비 완료된 요구사항의 개수
  • 예측된 요구사항의 총 개수 대 정의된 요구사항의 총 개수

 

데이터가 수집되고 분석되는 이러한 데이터의 종류 및 수집 빈도 소스를 표 3-1에 나타낸다.

 

Three progress measures are tracked during the requirements definition phase:

 

  • Staff hours — e., the cumulative effort hours of the project staff
  • Number of requirements with completed specifications versus the total number of requirements
  • Number of requirements defined versus the total number of estimated requirements

 

The sources of these data and the frequency with which the data are collected and analyzed are shown in Table 3-1.

 

Table 3-1.   Objective Measures Collected During the Requirements Definition Phase

3.1t

평가 기준

Evaluation Criteria

 

노력은 유사한 성격의 과거 프로젝트에서 과거 데이터를 기반으로 예측에 대해 계측되어야 한다. 각 주요 활동에 대해 개별적으로 직원의 시간을 모니터링 한다. 일정이 충족되고 있지만, 시간이 예상보다 낮은 경우, 그 팀이 문제와 문제를 제기하는 데 필요한 세부 사항의 수준에서 작동하지 않을 수 있다.

 

Effort should be gauged against estimates based on historical data from past projects of a similar nature. Monitor staff hours separately for each major activity. If schedules are being met but hours are lower than expected, the team may not be working at the level of detail necessary to raise problems and issues.

 

SCR 다음 진행 상황을 판단하기 위해, 어떤 사양에 대한 요구사항의 수를 추적하는 것은 요구사항의 총 수의 백분율로 기록될 수 있다. (“전체 요구사항”은 식별될 필요가 있는 사람들을 포함할 수 있지만 세부 사항은 아직 미정이다.)

 

To judge progress following the SCR, track the number of requirements for which specifications have been written as a percentage of the total number of requirements. (“Total requirements” includes those for which a need has been identified, but for which details are still TBD.)

 

프로젝트의 예측된 총합에 대해 정의된 요구사항의 수를 추적함으로써 요구사항의 성장을 모니터링 한다. 만약 요구사항 안전성이 이슈이면 요구사항에 대한 변경 사항의 수를 추적할 것을 고려하라. 과도한 성장이나 사양 변경은 더 큰 관리 제어에 대한 필요성이나 자세한 시스템 운영 개념의 부족을 가리킨다.

 

Monitor requirements growth by tracking the number of requirements that have been defined against an estimated total for the project. If requirements stability is an issue, consider tracking the number of changes made to requirements as well. Excessive growth or change to specifications point to a need for greater management control or to the lack of a detailed system operations concept.

 

제품

PRODUCTS

 

요구사항 정의 단계의 주요 제품은 시스템 및 운영 개념 (SOC) 문서 및 요구사항 및 사양 문서이다. 이러한 제품의 내용과 형식은 다음 단락에서 설명된다.

 

The key products of the requirements definition phase are the system and operations concept (SOC) document and the requirements and specifications document. The content and form of these products are addressed in the following paragraphs.

 

 

시스템 및 운영 개념 문서

System and Operations Concept Document

 

SOC 문서는 높은 수준의 요구사항을 나열하는 전체 시스템 아키텍처 및 운영 환경을 정의하고 시스템이 환경에서 작동하는 방법에 대해 설명한다. 이 문서는 개발자가 소프트웨어 구조와 사용자 인터페이스를 만들 수 있는 기반을 제공한다. 문서에 권장되는 형식은 그림 3-3에 나와 있다.

 

The SOC document lists the high-level requirements, defines the overall system architecture and its operational environment, and describes how the system will operate within this environment. The document provides a base from which developers can create the software structure and user interface. The format recommended for the document is shown in Figure 3-3.

 

SOC는 일반적으로 발행 후 업데이트되지 않는다. 요구사항 분석 단계에서 개발자는 문서에 포함된 재사용 제안을 수정하고 요구사항 분석 보고서의 결과를 재사용하는 계획을 게시할 수 있다. 이와 유사하게, 개발자는 운영 시나리오를 수정하고 요구사항 분석, 예비 설계 및 상세 설계 보고서에 포함한다. SOC의 이들과 다른 부분이 수정된 이후의 개발 제품에 포함되어 있기 때문에, 초기에 필요하거나 SOC 자체를 유지하지 않을 수 있다.

 

The SOC is not usually updated after publication. During the requirements analysis phase, developers refine the reuse proposal contained in the document and publish the resulting reuse plan in the requirements analysis report. Similarly, developers refine the operational scenarios and include them in the requirements analysis, preliminary design, and detailed design reports. Because these and other pieces of the SOC are reworked and included in subsequent development products, it may not be necessary to baseline or maintain the SOC itself.

 

 

요구사항 및 명세 문서

Requirements and Specifications Document

 

이 문서는 요구사항 정의 단계의 주요 제품으로 요구사항 정의의 팀에 의해 생성된다. 그것은 종종 여러 볼륨에 게시된다: 1 권 2 권은 기능 사양을 포함, 요구사항을 정의하고, 볼륨 3은 수학 사양을 제공한다. 이 문서는 이전 SRR에 분산 검토 승인 검토 항목을 통합하고 베이스 라인에 다음 업데이트된다.

 

This document is produced by the requirements definition team as the key product of the requirements definition phase. It is often published in multiple volumes: volume 1 defines the requirements, volume 2 contains the functional specifications, and volume 3 provides mathematical specifications. The document is distributed prior to the SRR, updated following the review to incorporate approved review items, and then baselined.

 

요구사항 및 사양 문서는 낮은 수준, 파생된 요구사항의 모든 완성된 목록을 포함하여 소프트웨어 시스템이 인수 시험 할에 대한 기준을 제공한다. 각 프로세스의 출력에 입력을 변형하기 위해 필요한 입력 데이터, 출력 데이터, 및 프로세싱을 식별 기능이나 개체 사양, 세부 설계 및 시스템 테스트를 위한 기초를 제공한다. 문서는 또한 지정된 알고리즘을 평가하고 정확하게 시스템을 설계 할 필요가 수학적 배경 정보를 포함한다.

 

The requirements and specifications document contains a complete list of all requirements —including low-level, derived requirements — and provides the criteria against which the software system will be acceptance tested. The functional or object specifications, which identify the input data, output data, and processing required to transform input to output for each process, provide the basis for detailed design and system testing. The document also includes the mathematical background information necessary to evaluate specified algorithms and to design the system correctly.

 

요구사항 및 사양 문서의 권장 개요는 그림 3-4에 제시되어있다.

 

The recommended outline for the requirements and specifications document is presented in Figure 3-4.

 

SYSTEM AND OPERATIONS CONCEPT DOCUMENT

 

This document provides a top-down view of the system from the user’s perspective by describing the behavior of the system in terms of operational methods and scenarios. Analysts should provide the document to the development team by the end of the requirements definition phase. The suggested contents are as follows:

 

1.    Introduction

a.  Purpose and background of the system

b.  Document organization

 

2.    System overview

a.  Overall system concept

b.  System overview with high-level diagrams showing external interfaces and data flow

c.  Discussion and diagrams showing an ideal, high-level architecture for the system

 

3.    Reuse proposal

a.  Summary of domain and reuse analysis performed

b.  Description of potential candidates for reuse — architectural components, designs, operational processes, and test approaches — and associated trade-offs

c.  Discussion and diagrams of the proposed high-level architecture, as adjusted to incorporate reusable elements

 

4.    Operational environment — description and high-level diagrams of the environment in which the system will be operated

a.  Overview of operating scenarios

b.  Description and high-level diagrams of the system configuration (hardware and software)

c.  Description of the responsibilities of the operations personnel

 

5.    Operational modes

a.  Discussion of the system’s modes of operation (e.g., critical versus normal and launch/early mission versus on-orbit operations)

b.  Volume and frequency of data to be processed in each mode

c.  Order, frequency, and type (e.g., batch or interactive) of operations in each mode

 

6.    Operational description of each major function or object in the system

a.  Description and high-level diagrams of each major operational scenario showing all input, output, and critical control sequences

b.  Description of the input data, including the format and limitations of the input.  Sample screens (i.e., displays, menus, popup windows) depicting the state of the function before receiving the input data should also be included.

c.  Process — high-level description of how this function will work

d.  Description of the output data, including the format and limitations of the output.

Samples (i.e., displays, reports, screens, plots) showing the results after processing the input should also be included.

e.  Description of status and prompt messages needed during processing, including guidelines for user responses to any critical messages

 

7.    Requirements traceability matrix mapping each operational scenario to requirements

 

Figure 3-3.   SOC Document Contents


 

 

REQUIREMENTS AND SPECIFICATIONS DOCUMENT

 

This document, which contains a complete description of the requirements for the software system, is the primary product of the requirements definition phase. In the flight dynamics environment, it is usually published in three volumes: volume 1 lists the requirements, volume 2 contains the functional specifications, and volume 3 provides the mathematical specifications.

 

1.    Introduction

a.   Purpose and background of the project

b.   Document organization

 

2.    System  overview

a.   Overall system concept

b.   Expected operational environment (hardware, peripherals, etc.)

c.   High-level diagrams of the system showing the external interfaces and data flows

d.   Overview of high-level requirements

 

3.    Requirements  — functional, operational (interface, resource, performance, reliability, safety,    security), and data requirements

a.   Numbered list of high-level requirements with their respective derived requirements (derived requirements are not explicitly called out in source documents such as the SIRD or SORD, but represent constraints, Iimitations, or implications that must be satisfied to achieve the explicitly stated requirements)

b.   For each requirement:

(1)      Requirement number and name

(2)       Description of the requirement

(3)      Reference source for the requirement, distinguishing derived from explicit requirements

(4)       Interfaces to other major functions or external entities

(5)       Performance specifications — frequency, response time, accuracy, etc.

 

4.    Specifications

a.   Discussion and diagrams showing the functional or object hierarchy of the system

b.   Description and data flow/object diagrams of the basic processes in each major subsystem

c.   Description of general conventions used (mathematical symbols, units of measure, etc.)

d.   Description of each basic function/object, e.g.:

(1)      Function  number and name

(2)       Input

(3)       Process — detailed description of what the function should do

(4)       Output

(5)       Identification of candidate reusable software

(6)       Acceptance criteria for verifying satisfaction of related requirements

(7)      Data dictionary — indicating name of item, definition, structural composition of the item, item range, item type

 

5.    Mapping of specifications to requirements — also distinguishes project-unique requirements from standard requirements for the project type (AGSS, dynamics simulator, etc.)

 

6.    Mathematical specifications — formulas and algorithm descriptions to be used in implementing the computational functions of the system

a.   Overview of each major algorithm

b.   Detailed formulas for each major algorithm

 

Figure 3-4.   Requirements and Specifications Document Contents

 

 

 

검토

REVIEWS

 

시스템의 개념을 검토 및 시스템 요구사항 검토: 두 가지 핵심 리뷰는 요구사항 정의 단계에서 실시하고 있다. 목적, 참석자, 일정, 콘텐츠 및 후기의 형식은 다음 하위 절에서 설명한다.

 

Two key reviews are conducted during the requirements definition phase: the system concept review and the system requirements review. The purpose, participants, scheduling, content, and format of these reviews are discussed in the subsections that follow.

 

 

시스템 개념 검토

System Concept Review

 

SCR은 사용자, 고객 담당자 및 기타 이해 관계자에게 자세한 요구사항을 작성하기 전에 제안된 시스템 아키텍처 및 운영 개념을 검토하고 영향을 미칠 수 있는 기회를 제공한다. 시스템 및 운영 개념이 정의 된 후에는 요구사항 정의 단계가 수행된다. 비행 역학 환경에서 전체 SCR은 대형, 임무 지원 시스템에 대해 수행된다. 복잡한 외부 인터페이스가 없는 작은 개발 노력, SCR 재료는 비공식적으로 표시된다. SCR 형식은 그림 3-5에 제시되어있다.

 

The SCR gives users, customer representatives, and other interested parties an opportunity to examine and influence the proposed system architecture and operations concept before detailed requirements are written. It is held during the requirements definition phase after system and operations concepts have been defined. In the flight dynamics environment, a full SCR is conducted for large, mission support systems. For smaller development efforts without complex external interfaces, SCR material is presented informally. The SCR format is given in Figure 3-5

 

SCR FORMAT

 

Presenters — requirements definition team

 

Participants

•        Customer representatives

•        User representatives

•        Representatives of systems and groups that will interface with the system to be developed

•        Senior development team representatives (application specialists)

•        Quality assurance (QA) representatives

•        System capacity/performance analysts

 

Schedule — after the system and operations document is complete and before requirements definition begins

 

Agenda — summary of high-level requirements (e.g., from SIRD and SORD) and presentation of system and operations concepts; interactive participation and discussion should be encouraged.

 

Materials Distribution

•        The system and operations concept document is distributed 1 to 2 weeks before the SCR.

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

 

Figure 3-5.  SCR Format

 

SCR하드카피 자료

SCR Hardcopy Material

 

검토에 사용하기 위해 분산 된 하드 카피 자료는 프리젠테이션 viewgraphs에 해당한다. SCR의 하드 카피 자료의 내용에 대한 제안 개요는 그림 3-6에 제시되어있다.

 

The hardcopy materials distributed for use at the review should correspond to the presentation viewgraphs. A suggested outline for the contents of SCR hardcopy material is presented in Figure 3-6.

 

HARDCOPY  MATERIAL  FOR  THE  SCR

1.         Agenda — outline of review material

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

3.         High-level requirements

a.  Derivation of high-level requirements — identification of input (such as the SIRD and SORD) from project office, support organization, and system engineering organization

b.  Summary of high-level requirements

 

4.         System concept

a.  Assumptions

b.  Overall system concept

c.  List of major system capabilities

 

5.         Reuse considerations

a.  Existing systems reviewed for possible reuse

b.  Reuse trade-offs analyzed

c.  Proposed reuse candidates

 

6.         High-level system architecture

a.  Description and high-level diagrams of the proposed system architecture (hardware and software), including external interfaces and data flow

b.  Diagrams showing the high-level functions of the system — their hierarchy and interaction

 

7.         System environment

a.  Computers and peripherals

b.  Communications

c.  Operating system Iimitations and other constraints

 

8.         Operations concept

a.  Assumptions

b.  Organizations that provide system and support input and receive system output

c.  System modes of operation (e.g., critical versus normal and launch versus on-orbit operations)

d.  Order, frequency, and type (e.g., batch or interactive) of operations in each mode

e.  Discussion and high-level diagrams of major operational scenarios

f.   Performance implications

 

9.         Issues, TBD items, and problems — outstanding issues and TBDs and a course of action to  handle them

 

Figure 3-6.   SCR Hardcopy Material Contents

 

시스템 요구사항 검토(SRR)

System Requirements Review (SRR)

 

요구 사양 문서가 분배 될 때, 요구사항 정의 팀은 요구를 제시하고 피드백을 구하고 주목할 만한 문제 해결을 용이하게 하기 위해 SRR을 수행한다. SRR 형식, 일정, 참가자들은 그림 3-7에 제시되어 있다.

 

When the requirements and specifications document is distributed, the requirements definition team conducts an SRR to present the requirements, obtain feedback, and facilitate resolution of outstanding issues. The SRR format, schedule, and participants are given in Figure 3-7.

 

SRR FORMAT

 

Presenters — requirements definition team

 

Participants

•        Customer representatives

•        User representatives

•        Configuration Control Board (CCB)

•        Senior development team representatives

•        System capacity/performance analysts

•        Quality assurance representatives

 

Schedule — after requirements definition is complete and before the requirements analysis phase begins

 

Agenda — selective presentation of system requirements, highlighting operations concepts and critical issues (e.g., TBD requirements)

 

Materials Distribution

•        The requirements and specifications document is distributed 1 to 2 weeks before SRR.

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

 

Figure 3-7.  SRR Format

 

SRR 하드카피 자료

SRR Hardcopy Material

 

검토를 위해 하드 카피 자료의 대부분은 요구사항 및 사양 문서에서 추출할 수 있다. SRR의 하드 카피 자료의 개요 및 제안 내용은 그림 3-8에 제시되어 있다.

 

Much of the hardcopy material for the review can be extracted from the requirements and specifications document. An outline and suggested contents of the SRR hardcopy material are presented in Figure 3-8.

 

Tailoring Notes

 

For very large or complex projects, hold a preliminary SRR to obtain interim feedback from users and customers. The format of the PSRR is the same as the SRR. Hardcopy material contains preliminary results and is adjusted to reflect work accomplished to date.

 

Definition

 

The Configuration Control Board (CCB) is a NASA/GSFC committee that reviews, controls, and approves FDD systems, internal interfaces, and system changes. Among its duties are the approval of system baseline reviews (e.g., SRR, PDR) and baseline documents (e.g., requirements and specifications, detailed design document).

 

HARDCOPY  MATERIAL  FOR  THE  SRR

 

1.         Agenda — outline of review material

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

3.         Requirements summary — review of top-level (basic) requirements developed to form the specifications

a.  Background of requirements — overview of project characteristics and major events

b.  Derivation of requirements — identification of input from project office, support organization, and system engineering organization used to formulate the requirements:

e.g., the SIRD, SORD, memoranda of information (MOIs), and memoranda of understanding  (MOUs)

c.  Relationship of requirements to Ievel of support provided — typical support, critical support, and special or contingency support

d.  Organizations that provide system and support input and receive system output

e.  Data availability — frequency, volume, and format

f.   Facilities — target computing hardware and environment characteristics

g.  Requirements for computer storage, failure/recovery, operator interaction, diagnostic output, security, reliability, and safety

h.  Requirements for support and test software — data simulators, test programs, and utilities

i.    Overview of the requirements and specifications document — its evolution, including draft dates and reviews and outline of contents

 

4.         lnterface requirements  — summary of human, special-purpose hardware, and automated system interfaces, including references to interface agreement documents (IADs) and interface control documents (ICDs)

5.         Performance requirements — system processing speed, system response time, system failure recovery time, and output data availability

6.         Environmental considerations — special computing capabilities, e.g., graphics, operating system Iimitations, computer facility operating procedures and policies, support software limitations, database constraints, and resource limitations

7.         Derived system requirements — Iist of those requirements not explicitly called out in the SIRD, SORD, MOIs, and MOUs, but representing constraints, Iimitations, or implications that must be satisfied to achieve the explicitly stated requirements

 

8.         Operations concepts

a.  High-level diagrams of operating scenarios showing intended system behavior from the user’s viewpoint

b.  Sample input screens and menus; sample output displays, reports, and plots; critical control sequences

 

9.         Requirements management approach

a.  Description of controlled documents, including scheduled updates

b.  Specifications/requirements  change-control  procedures

c.  System  enhancement/maintenance  procedures

 

10.        Personnel organization and interfaces

11.        Milestones and suggested development schedule Issues, TBD items, and problems — a characterization of all outstanding requirements issues and TBDs, an assessment of their risks (including the effect on progress), and a course of action to manage them, including required effort, schedule, and cost

Figure 3-8.  SRR Hardcopy Material Contents

 

탈출 기준

EXIT CRITERIA

 

SRR에 따라, 요구사항 정의의 팀은 모든 RID를 분석 요구사항의 변경이 필요할지 여부를 결정하고, 그에 따라 요구사항 및 사양 문서를 수정한다. 업데이트 된 문서는 승인을 위해 구성 제어 보드 (CCB)로 전송된다. 요구사항 기준선 – 일단 승인, 통제된 문서가 된다.

 

Following the SRR, the requirements definition team analyzes all RIDs, determines whether requirements changes are necessary, and revises the requirements and specifications document accordingly. The updated document is sent to the configuration control board (CCB) for approval. Once approved, it becomes a controlled document — the requirements baseline.

 

요구사항 및 사양 분석을 위해 개발 팀에 제공 할 준비가 되어 있는지 여부를 확인하려면 다음과 같은 질문을 사용한다:

 

  • 사용 가능한 정보에 대해 요구사항이 모두 존재하는가? TBD 요구사항이 최소화 되었는가?
  • 외부 인터페이스가 적절하게 정의되어 있는가?
  • 표기, 용어 및 기능 수준에 부합하는 사양하고, 알고리즘이 적합한가?
  • 요구사항을 테스트 할 수 있는가?
  • 핵심적인 종료 기준이 충족 되었는가? 즉, 문서가 배포 된 요구사항 및 사양은, SRR이 성공적으로 완료되어 있으며, 모든 SRR RID(review item disposition form)는 답변이 되었는가?

 

이 질문에 대한 대답이 “예”이면, 요구사항 정의 단계가 완료된다.

 

Use the following questions to determine whether the requirements and specifications are ready to be given to the development team for analysis:

 

  • Do specifications exist for all requirements for which information is available? Have TBD requirements been minimized?
  • Have external interfaces been adequately defined?
  • Are the specifications consistent in notation, terminology, and level of functionality, and are the algorithms compatible?
  • Are the requirements testable?
  • Have key exit criteria been met? That is, has the requirements and specifications document been distributed, has the SRR been successfully completed, and have all SRR RIDs been answered?

 

When the answer to these questions is “yes,” the requirements definition phase is complete.

 

형식적 검토 동안 및 후에, 검토 아이템 처리 양식(RID)은 문서화된 답변이나 향후 액션을 위해 요구되는 이슈로 식별하기 위해 참석자에게 전달된다. 관리자는 모든 RID가 기록되고 답변되었으며 결과적인 행동 아이템이 할당되고 완료되었는지를 확인할 책임이 있다.

During and following formal reviews, review item disposition forms (RIDs) are submitted by participants to identify issues requiring a written response or further action. Managers are responsible for ensuring that all RIDs are logged and answered and resulting action items are assigned and completed.

 

 

 

 

관련 링크

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

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

challenges of software projects

IEEE 830-1998 Recommended Practice for Software Requirement Specification

좋은 요구사항의 특성

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

SECTION 4. 요구사항 분석 단계

Advertisements

5 thoughts on “Section 3. 요구사항 정의 단계”

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