2025. 시나공 정처기 실기 1-006 요구 사항 개발 프로세스

https://youtu.be/qbayfp0ztHM?si=JhbgBlsvuUjH5p3z

 

 

 

요구사항을 개발하는 프로세스로 위의 네가지임.

개발대상에 대한 요구 사항을 도출하고 분석, 명세성에 정리한 다음 확인

개발프로세스가 비즈니스 목적에 적합한지가 타당성 조사임.

 

요구사항 도출은 중간중간 프로그램 작성 중에도 고객이 요구할 수 있음 -> 그렇게 지속적으로 반복되는 것

 

브레인 스토밍: 희희 아무말이나 하다보면 걸림

프로토타이핑: 프로토타입을 가지고 그리는 건데, 일종의 에스키스나 스케치 수준

유스케이스: 사용자의 요구사항을 기능단위로 표현한 것. ~가 있으면 좋겠어용. ~도 있으면 좋겠어용

쉽게 이야기하면 타당성 확보하는 거임.

요구사항 도출할 때 여러 방법이 있음. 그 요구사항들을 특정 기준으로 분리하는데, 기능이니 비기능이니로 분류함. 

거기서 매긴 우선순위가 생긴 요구사항을 단순화하고 이걸 관계나 종속성을 분석하는 걸 모델링이라고 함. 이걸 표기할 때 UML을 사용하는데 뒤에서 배움.

 

 

이건 정말 말도 안돼요! 개발할 수 없어요!

했을 때 사용자가 이해못할 수도 있음. 이걸 중재하는데 DFD,DD를 만들어서 이용함

뒤에서 배움

분석한걸 문서화하는 단계임.

개발 승인을 위해 문서화하는 것임.

 

소단위 명세서 = 모듈 명세서

작성한 명세서를 바탕으로 그 명세서가 정확한지 완전하게 작성 되었는지를 검토함.

명세서는 이해관계자들 싹다 모여서 함.

 

형상: 특정 작업의 결과물을 통칭해서 부르는 말. 

-> 특정 작업의 결과물: 소프트웨어를 개발하는 각 단곙에서 만들어지는 문서, 데이터, 프로그램 등

형상관리는 소프트웨어 개발 과정에서 만들어 지는 형상을 관리하는 일련의 활동을 형상관리라고 함.

요구사항 확인부터 수행함. 

 

결과물을 정리하고 관리한다는 뜻임. 

 

요구 사항을 이해하는 게 매우 중요함.

요구한 것과 다르면 프로그램을 구매하지 않을 것임.

 

요구공학에 요구사항개발이 들어감. 

고객이 ~해달라, ~ 만들어달라 할건데, 이걸 사용자와 설계자가 모두 알아 볼 수 있게 하는게 요구사항 명세기법임. 

 

정형: 수학처럼 공식화, 특정 규칙, 룰이 있음.

비정형: 룰 없음. 내 맘대로 작성