LOGO Software Requirements 200412358 최상현
Contents www.themegallery.com 1 THE CONTEXT OF SOFTWARE REQUIREMENTS 2 REQUIREMENTS ENGINEERING PROCESS 3 REQUIREMENTS ELICITATION 4 REQUIREMENTS ANALYSIS
Contents www.themegallery.com 5 SOFTWARE REQUIREMENTS SPECIFICATION 6 REQUIREMENTS VALIDATION 7 REQUIREMENTS MANAGEMENT
www.themegallery.com 1. THE CONTEXT OF SOFTWARE REQUIRMENTS 소프트웨어요구사항항상사업문제 (business problem) 로부터나옴예 ) 여권신청절차, 자동차안전시스템개발 이러한문제를해결할수있는방안들이통합된기술이소프트웨어 고객이요구한것을소프트웨어로옮기는작업은매우복잡하고비용이많이듦 EX) 오류수정비용 설계와구현방법에따라비용이달라짐 따라서, 요구사항공학절차를거침으로써에러발생을최소한으로줄여비용을줄일수있음
www.themegallery.com 1. THE CONTEXT OF SOFTWARE REQUIRMENTS 1.1 Requirements and Constraints 요구사항 (Requirements) 정의요구사항은시스템에의해서사업문제를해결하기위한자산또는능력 분류 - 기능적요구사항 ( Functional Requirement ) : 소프트웨어가수행해야하는기능 - 비기능적요구사항 ( Nonfunctional Requirement ) : 시스템의특징을묘사
www.themegallery.com 1. THE CONTEXT OF SOFTWARE REQUIRMENTS 1.1 Requirements and Constraints 요구사항 (Requirements) Emergent properties - 요구사항과대조적 ex) 분산시스템의성능
www.themegallery.com 1. THE CONTEXT OF SOFTWARE REQUIRMENTS 1.1 Requirements and Constraints 제약사항 (Constraints) 사업문제를해결하기위한방법의범위를제한 예 1) 소음법률로인한도난경보사이렌울리는소리의길이제한예 2) 메모리, 프로세스속도, 대역폭 ( 기술적인부분 ) 특정분야의문제 (problem domain) 예 ) 기차제어시스템에서의전자기파
www.themegallery.com 2. REQUIREMENTS ENGINEERING PROCESS 요구사항공학프로세스 (Requirements Engineering Process) 는문제해결방안의시스템속성을명세서 (specification ) 로변환시켜야함 분석을통해나온요구사항들은개발자와유저간의소통을위해문서화해야함. IEEE( 전기전자기술자협회 ) 에서발표한 3 개지표준 - IEEE Std 1362~1998 Guide for Information Technology - system Definition - Concept of Operation (ConOps) Document [IEEE 98a] - IEEE Std 1233-19981998 Guide for Developing System Requirements Specifications [IEEE 98b] - IEEE Std 830-1998 Recommended Practice for Software Requirements Specifications [IEEE 98c]
www.themegallery.com 2. REQUIREMENTS ENGINEERING PROCESS 프로젝트같이복잡한것은요구사항변경때문에개발과정에서문제가늦게발생할수있음 요구사항공학은이러한요구사항변경으로인한예기치못한위험을최소화하는과정 즉, 비즈니스문제를해결하기위해요구사항을발견하고, 이해하고, 기록하고, 검사하고, 소통하고, 관리
3. REQUIREMENTS ELICITATION www.themegallery.com 요구사항추출은요구사항을발견하는과정 요구사항추출을통해프로젝트의규모를명확히할수있음 요구사항을추출하기위해선먼저요구사항이발생하는근원에대한정보수집이필요함 그정보로부터요구사항을종합하여추출함 수집, 수정, 올바른건지아닌지, 재공급을반복적으로수행
3. REQUIREMENTS ELICITATION www.themegallery.com 3.1 Requirements Source 큰시스템에서는많고다양한투자자들 (stakeholders ) 이있는데이들이요구사항의첫번째근원 (source) 투자자를확인하는것이중요한첫걸음 해당분야전문가는요구사항도출에중요한역할을함.
3. REQUIREMENTS ELICITATION www.themegallery.com 3.2 Elicitation Techniques 다양한투자자들이있으면요구사항이일치가안될때있는데이때투자자의배경정보를앎으로써해결할수있음 sociotechnical 시스템에서사용자 (user) 의이야기나시나리오는가치있는도구 시나리오는요구사항엔지니어에게의문에대한대답을제공
www.themegallery.com 4. REQUIREMENTS ANALYSIS 요구사항분석은문제를이해하고열거된요구사항들중최선의해결책을통합하는것 분석활동은요구사항의기준선을산출하는일 엔지니어와투자자는요구사항기준선을맞추기위해무엇을포함할지무엇을빼야할지, 일치하지않은부분을협상해야함 요구사항의기준선은필요하지만이기준선이모든요구사항을포함하고목표달성에기여하는것은아님 하지만문제를어떻게해결할것인가를명확히하기위해필요함
www.themegallery.com 4. REQUIREMENTS ANALYSIS 4.1 The System Boundary System Boundary 는 proposed p system 의모든문제의해결방안을제공하고환경에서어떻게시스템이작동하는지도포함됨
www.themegallery.com 4. REQUIREMENTS ANALYSIS 4.2 Requirements Modeling 엔지니어는요구사항에대한적절한해결책을찾기위해문제를모델로구성 모델은요구사항에대해개발자와 proposed system 사이의사소통에도움을줌 모델링예 : UML
www.themegallery.com 4. REQUIREMENTS ANALYSIS 4.3 Derived Requirements 요구사항을추출하는과정 분석과정에서새롭게추출된기록으로부터요구사항을유도 4.4 Requirements Attributes 요구사항을편리하게관리하기위한것 종류 : Identifier, Source, Date, Rationale, Type, Priority, Stability Verification Procedure, Status 4.5 Requirement Trade-offs 요구사항에필요한것은포함시키고불필요한것은빼는작업
www.themegallery.com 5. SOFTWARE REQUIREMENTS SPECIFICATION 소프트웨어요구사항의문서 ( SRS : 소프트웨어요구사항명세서 ) 알기쉽고일관되게작성해야하고전체가긴밀하게연결되어야함 시스템모델과연결된요구사항뿐만아니라전후관계, 제약사항, 협약 ( 약조 ), 가설과같은정보를제공
6. REQUIREMENTS VALIDATION www.themegallery.com 요구사항은사업문제를해결하기위해필요한것이무엇인지정확히반영되어야함. 검증 (Validation) 은항상요구사항명세서에적용되며이것이최종도안 한번검증되면그명세서는변경가능 즉, 검증된문서가형식과버전을변경해야만할때다시설계또는실행의기초가됨. 예외 ) 투자자의동의가필요할경우, 프로세스요구사항변동없을경우 요구수용했는가에대해입증해야함. 요구사항에대한가능한해결방안을계획하는데너무과도하게어려운것이입증된다면요구사항이잘못임 요구사항이유용해야만적법함
7. REQUIREMENTS MANAGEMENT www.themegallery.com 요구사항관리 (management) 는 4 가지업무를포함 -change control - version control - requirements tracing - status tracking 요구사항이유일할때 4 가지업무가능 요구사항관리는중요한업무이나등한시되기도함 1990 년대초 SW-CMM(Capability Maturity Model for Software) 에의해부각
7. REQUIREMENTS MANAGEMENT www.themegallery.com 7.1 Change Control 개발단계에서요구사항은언제라도변화 (change) 이발생할수있음 허락되지않은변화는문제를야기시킴예 ) 예산초과, 기한초과 변경의평가기준 : 비용, 이로움, 평가위원단 (assessment panel) 에서변화요청확인 평가위원단은변화가프로젝트에기간과비용에어떤영향을끼칠지고려해야함 진보적인변화는항상우선순위를정하고개발계획을변화에따라조절해야함
7. REQUIREMENTS MANAGEMENT www.themegallery.com 7.2 Version Control 요구사항의변화는저장되어야하는데 Version Control 에서는이변화를자세한부분까지포함 변화할때마다새로운요구사항명세서가나옴 문서버전을위해번호를붙이는작업이본질적인일 7.3 Requirements Tracing Change Control 과 Status Tracking을하기위해서는요구사항을반드시추적해야함 개념적으로 Requirements Tracing 은그래프형태는 acyclic 그래프임 7.4 Status Tracking 프로세싱과요구사항의실행에대한정보를유지하는것
LOGO www.themegallery.com