External Interface Requirements

         External Interface Requirements (외부 인터페이스 요구사항)

 

여기에는 System Interface, User Interface, Hardware/Software Interface, Communication Interface, 기타 인터페이스가 포함되어야 하고 시스템 자체는 그룹화해서 표현해야 한다. 이것은 회사마다 양식이 다른데 꼭 SRS 포멧에 맞출 필요가 없다. 해당 문서를 첨부하고 첨부한 문서에 번호를 붙여(SRS-시스템이름-001) 따로 문서를 만들었다고 기입하면 된다. 그것이 power pointer 일 수도 있고 word 문서일 수도 있겠다. 모바일인 경우 User Interface는 simpli나 zeplin 일수도 있다. 기업간의 경우 주소로 대체해도 되겠으나 FDA 승인의 경우 printable 한 문서 형태여야 한다는 것이 주의점이다. 이것도 시대가 바뀌면 계속 바뀌겠지. User Case로 그린 후 첨부할 때는 동그라미(사용 사례, Use Case) 들이 사각형(시스템)안에 들어가도록 배치하고 <<시스템>> 혹은 <<하위시스템>>으로 명시한 후 아래 이름을 적어주면 된다.

 

졸라맨, 동그라미, 사각형, 화살표만 있는데 나름 규칙이 있으니 우선 따르고 본인이 고객을 상대하면서 변화되는 것을 반영하면 되겠다. 식약처든 FDA던 결국 요구사항에 대한 acceptance test에 대한 논의는 모두 이해 관계자들이 하게 되니까 너무 형식에 구애 받을 필요는 없다. 그러나 형식이 있는 이유는 혹시라도 생각하지 못했던 것에 대한 확인이니 되도록이면 따르는게 좋다.

 

 

 

 

If the product is independent and totally self-contained, it should be so stated here.  If the SRS defines a product that is a component of a larger system, as frequently occurs, then this subsection relates the requirements of the larger system to functionality of the software and identifies interfaces between that system and the software. 

 

A block diagram showing the major components of the larger system, interconnections, and external interfaces can be helpful.  This is not a design or architecture picture.  It is more to provide context, especially if your system will interact with external actors.  The system you are building should be shown as a black box.  Let the design document present the internals.

 

This contains a detailed description of all inputs into and outputs from the software system.

 

It contains both content and format as follows:

 

·          Name of item

·          Description of purpose

·          Source of input or destination of output

·          Valid range, accuracy and/or tolerance

·          Units of measure

·          Timing

·          Relationships to other inputs/outputs

·          Screen formats/organization

·          Window formats/organization

·          Data formats

·          Command formats

·          End messages

 

If the external interfaces are complicated , you may write a separate ‘Interface Requirement Specification’ document for all or any of the following interfaces.

 

외부에서 들어온 홈페이지 제작 건을 수락하기 전에 고려해야 할 중요한 사항들이 몇 가지 있습니다. 여기 주요한 포인트를 설명합니다:

1. **자원 평가**:
   - 현재 내부 로드맵에 따른 팀의 자원(인력, 시간 등)을 평가해야 합니다. 개발자 2명이 내부 프로젝트를 어떻게 관리하고 있는지, 여유 시간이 어느 정도인지 확인하세요.
   - 외주 업체의 능력과 신뢰도를 평가합니다. 이전 작업의 품질, 일정 준수, 소통 능력 등을 고려해서 결정을 내리세요.

2. **프로젝트 스코프와 요구사항**:
   - 홈페이지 제작 프로젝트의 전체 범위와 요구사항을 명확히 정의하세요. 이는 범위 변경이나 추가 요구사항을 최소화하여 문제를 줄이는 데 도움이 됩니다.
   - 기술적인 요구사항(예: 백엔드 기술, 프론트엔드 프레임워크 등)과 비즈니스 요구사항(예: 마감일, 예산 등)을 명확히 파악합니다.

3. **예산 및 비용 평가**:
   - 프로젝트의 예산을 평가하고, 외주 업체와의 계약 조건(예: 비용, 결제 일정 등)을 명확히 합니다.
   - 추가적인 비용(예: 유지보수, 추가 기능 개발 등)을 고려한 예산 계정이 필요한지 검토합니다.

4. **타임라인 및 일정 관리**:
   - 내부 로드맵과 외부 프로젝트의 일정을 조율하여 충돌을 최소화합니다. 내부 프로젝트의 마감일이 외부 프로젝트로 인해 지연되지 않도록 신경 써야 합니다.
   - 외주 업체와 명확한 일정(마일스톤, 주요 전달물 등)을 설정하여 프로젝트 관리의 투명성을 높입니다.

5. **위험 관리**:
   - 프로젝트 진행 중 발생할 수 있는 위험 요소(예: 일정 지연, 품질 문제 등)를 식별하고 경감 계획을 마련합니다.
   - 외주 업체와 명확한 책임 구분과 계약서에 이를 반영하여 향후 발생할 수 있는 법적 문제를 예방합니다.

6. **커뮤니케이션 계획**:
   - 내부 팀과 외주 업체 간의 효과적인 커뮤니케이션 채널과 주기(예: 주간 회의, 상태 보고 등)를 설정합니다.
   - 주요 의사결정 포인트와 승인 절차를 명확히 하여 협업을 원활하게 합니다.

7. **품질 관리**:
   - 외주 업체가 제공하는 코드 및 디자인의 품질을 평가할 방법(예: 코드 리뷰, 테스트 계획 등)을 마련합니다.
   - 외주 제공물의 품질이 회사의 기준에 부합하는지 확인하는 테스트 계획을 수립합니다.

8. **계약 및 법적 고려사항**:
   - 외주 업체와의 계약 조건을 명확히 합니다. 계약 내용에는 지급 조건, 기한, 품질 기준, 요건 변경 절차 등을 포함합니다.
   - 데이터 보안 및 개인 정보 보호에 대한 법적 요구사항(예: 개인정보보호법 등)을 준수합니다.

9. **장기적인 유지보수 계획**:
   - 프로젝트 완료 후에 발생할 유지보수 작업에 대한 계획을 마련합니다.
   - 유지보수 계약을 외주 업체와 체결할지, 내부 팀이 담당할지 결정합니다.

이러한 요소들을 면밀히 검토함으로써, 외부 홈페이지 제작 건을 수락할 때 발생할 수 있는 리스크를 줄이고 성공적인 프로젝트 수행을 위해 준비할 수 있습니다.