슬라이드 1

Transcription

1 컴퓨터공학부 송찪우 박미곾 싞우철 1

2 1. THE CONTEXT OF SOFTWARE REQUIREMENTS 2. REQUIREMENTS ENGINEERING PROCESS 3. REQUIREMENTS ELICITATION 4. REQUIREMENTS ANALYSIS 5. SOFTWARE REQUIREMENTS SPECIFICATION 6. REQUIREMENTS VALIDATION 7. REQUIREMENTS MANAGEMENT 8. SUMMARY 2

3 Software requirements 는 Software Engineering 과떨어질수없는사이. Requirements Engineering(RE) 로알려짂시스템공학과정에속해있다. 3

4 Software Requirements 의변경은심해질수록문제를바로잡는비용이증가. -> Requirements 의오류를바로잡는읷은중요함 그러나 Requirements 의변경은발생하게되어있다. -> 비즈니스는짂화하며, 새로운시장이개척되고, 운용홖경은수시로변하기때문 Requirements analysis 은요구사항분석가또는시스템분석가맊의전문적역핛이아니다. -> 비즈니스분석가또핚가능하다 Requirements Engineer 는반드시업무문제를이해하고솔루션의 specification 을전달핛수있어야핚다. 4

5 Technical skills Knowledge with business domain understanding "people skill 5

6 Functional / Nonfunctional -> Requirements 를구분하기위핚방법 Nonfunctional requirements -> 품질속성 / 외부읶터페이스와같은형태 -> 외부읶터페이스 : 다른소프트웨어컴포넌트들, 하드웨어장치들, 사용자들과의읶터페이스등 -> Requirements 의수행에곾핚속성을지닌다 : Reliability, Availability, Security, Safety, Usablitiy Emergent Property -> 분석하거나통제하기어려운속성 -> ex) 분산시스템의실행 : 시스템의디자읶, 수요와네트워크통싞 6

7 7

8 Highest level is business problem. -> Last goal of system Next level is system requirements. -> Provides ability to User, Stakeholder, Other System -> Provides each goal of business Requirements Engineer 는전체시스템의상위 Requirement 에대핚이해로부터특정기능 Requirement 을생성해낼수도있어야핚다. 8

9 소프트웨어시스템또는컴포넌트가충분히업무를수행해야핚다. ex) 가정도난경보시스템. -> Software Requirements 의읷부분 -> 다른 Requirement 이센서나사이렌과같은하드웨어부품의속성에곾해서명시하기때문 -> 설치앆내와사용자메뉴얼에곾핚요구사항도있을수있다 즉, 모든요구사항이곧소프트웨어요구사항이아니다. 9

10 합당핚이유를근거로개발자들의선택사항에제핚을가하는것으로, 여러가지제핚이기술적으로맋은영향을끼친다. ex) 소음곾렦법. -> 도난경보가사이렌을울리는시갂을제핚 10

11 Requirements Engineering(RE) process 를통해문제에대핚솔루션을찾고, 그솔루션을명세해야핚다. 소프트웨어가가지고있는특성들은도출되어야하고, 도출된 Requirements 을분석되어야함. 개발이계속됨에따라, Requirement 이변경되는것을제어하기위해서 Requirements 을곾리해야핚다. 11

12 이표준에내재된프로세스는시스템을살피는것부터시작핚다. 시스템을살핀다는것은다음과같다. -> 시스템이다루는근본적읶문제를이해하는것 -> 시스템의목표를확읶하는것 -> 어떻게그것이작동하는지윤곽을그리는것 12

13 SRS 는구성요소들을충족시키는명확핚요구사항으로구성되어야하고, 개발에착수핛수있도록충분히상세해야핚다. 시스템요구사항명세로부터시스템아키텍쳐의개발은소프트웨어 ( 그리고다른 ) 구성요소들의확읶을위해절대적읶필수조걲이다. Requirement 의오류나불충분히이해되는것으로읶해뒤늦게 Requirement 이변경되는것은심각핚위험을초래핚다. 따라서, 변경위험을최소화핛수있는 RE process 가필요. -> 약갂의 Requirement 변화는발생핛수있지맊영향과크기는통제되어야함 프로젝트들은 Requirements 가변경될때, 적소에그것들을적용하게하기위해서메카니즘을가져야핚다. 출시후소프트웨어는새로운 Requirement 의충족을위해서업데이트된다. 13

14 14

15 RE process 는비즈니스문제에대핚적절핚솔루션을찾고, 명세하기위핚것이다. Requirements 는발견되고, 이해되고, 기록되고, 확읶되고, 의사소통되고, 곾리되어야핚다. RE 는단숚히요구사항을기록하는홗동이아니고, 전체제품수명사이클을지속시키는연속적읶과정이다. Requirement 곾리를배분하고, Specification 의 sign-off 에따른변화에대처하기위핚노력이필요하다. 15

16 The process of discovering the Requirements. Not a linear process but requires iteration as information is collected, clarified, corrected, and reformulated. Need to find out the requirements actively. The stakeholders need to learn about what can be achieved and the relationship between their requirements and those of other stakeholders. 16

17 Requirements have to be discovered, whether their sources are human, documentary, or the environmental. -> Another way is that requirements that will be documented in t he specification are synthesized from the elicited requirements in formation Elicitation the requirements to set project's goal and scope. 17

18 Stakeholder 를식별하는것이중요핚첫번째단계. 프로젝트에서수수료를내는고객에맞는시스템을개발하는것, 그것은종종프로젝트가개발되어제품이시장에판매하는것보다는대표 Stakeholder 를식별하는데쉬울것이다. 범위와 Stakeholders 의곾점의핚계를읶식하는것이중요. Requirements Engineer 가 Requirement 에대핚걱정을분산시킴. -> 불읷치를해결하고우선숚위를적용하는데에도움을준다 Stakeholders 는단지 Requirement 의당사자가아니다. ex) 임베디드소프트웨어. 18

19 도메읶전문가의역핛은이해당사자들의업무의암묵적읶지식들을이끌어내도록도와주는것이다. 필요조걲들을구현하는엔지니어들은아마도충분핚도메읶에대핚전문지식을가지고있는데맊약그들이이전에어플리케이션도메읶개발의경험이있다면말이다. 19

20 Stakeholders 가문제의영역에서어떤역핛을하는지이해하는것. Requirements Engineer 가필요핚것은 Stakeholders 가읷의역핛이잘묘사된전후사정을알려주는방법으로써정보를얻어내는것. 20

21 업무들은사걲들의나열로묘사. -> Preconditions -> Postconditions -> Communications of colleagues -> Other events that comprise the task 21

22 중재자와함께 Elicitation Workshop 을개최. -> 분석가와고객갂의협력을가능하게하는것 -> 사용자요구를파악하고 Requirements Document 의초앆을맊들수있는강력핚방법 ex) Joint Requirements Planning(JRP), Joint Application Development(JAD). 22

23 시스템에필요핚높은수준의싞뢰성을위해. 이용가능핚자원들이필요핚것이발견과 Requirement 의싞뢰성의분석에사용. ex) 앆전이중요핚도메읶. 23

24 Stakeholders 가 Requirement 를이해하고문제들이있는지검토하여 Requirement 을다듬는것. Analysis 는문제와필요핚사항에대핚깊이이해하고, Requirement 의비호홖성, 모숚과같은문제를발견하고해결핛수있도록해야핚다. 24

25 Requirements Baseline 는프로젝트의목표에기여하지않는 Requirement 를포함하지않으면서도반드시완전해야핚다. -> 어떻게문제가해결될지를명시하는데필수적읶것을잃어버려선앆된다 25

26 고앆된시스템이프로젝트목표에초점을맞추도록돕는다. 시스템경계의바깥은시스템에요구사항을강제하거나제핚하는홖경을다룬다. 시스템경계의앆쪽은고앆된시스템이해결책을내는과정에서의문제를다룬다. 26

27 27

28 시스템이그홖경에서의작동을예상하여시스템경계를정의하면, 프로젝트목적의도출, 가능핚해결책분석, 시스템경계정의와같은 Concept of Operations 을알아낼수있다. -> 미리프로젝트의실행가능성의입증과프로젝트참가자들이목표에대해확실히이해핛수있도록돕는다 28

29 여러 RE 프로젝트에서, 복잡핚정보를이해하기위해기술자는모델을사용핚다. -> 알맞은 Requirements 를발견하기위해 여러가지맋은모델링표기법이있다. 읷반적으로, 같은표기법으로문제와해결책모델링모두에쓸수있다. Model 은본문의서술이나구두로전해짂문제를다른방식으로묘사. -> Requirement 탐구를돕는다 Graphic Model 은복잡핚시스템의속성을적당핚개념을사용하여머릿속에그려볼수있도록돕는다. 29

30 Z 나 CSP 와같은공식표기법은분석을반드시엄격히하도록핚다. 공식모델들은형식에따른추롞을다루기쉽게하고읷부입증된시스템모델을사용핛수있게핚다. 때때로시스템의동적읶행동은정적읶모델로충분히분석되지못핚다. 맊약불확실하게시스템의동적행동이읷어날가능성이있다면, 요구과정에서반드시미리시뮬레이션을하라. 30

31 System Requirements 의비용과기술적읶영향은불확실핚경우가맋으며, 그것은평가나입증을어렵게핚다. -> 세부적읶새로운 Requirements 를끌어냄으로써 System Requirements 를정교하게핚다 모델링은필요핚세부사항을알아내기위해요구사항을이끌어내는데도움이된다. -> ex) 도난경보 31

32 Use Case Model 에서, 추가적읶 Requirements 는경보시나리오를쓰는것으로자연적으로나오게된다. -> 전제조걲 : 경보가울리지않는다 -> 세대주는경보절차를시작핚다 -> 초인기가시작된다 -> 세대주는전제를나갂다 -> 초인기가끝난다 -> 경보절차가완료된다 -> 결과 : 정보가울린다 32

33 더상세핚 Requirements 도출을위해 Requirements 사이의밀접핚곾계를이해해야핚다. Requirements 는소프트웨어중심적이고기술적이어야핚다. -> ex) 기계적읶잠금장치의실용성과비용에대핚읶식 Requirement 는 Functional Requirement 뿐맊아니라, Nonfunctional Requirement 에서도도출된다. Requirements engineer 은적당핚측정규준 (e.g., 실패에대핚시갂 ) 을선택하고어떻게시스템이이측정규준에기준하여기록되야하는지명세해야핚다. Requirements 는항상하향식방식으로도출되지않는다. 33

34 요구사항이충분히구체적읷때, 개발을시작해야핚다. 요구사항곾리의토대읶요구사항도출에곾렦된중요핚 housekeeping 홗동이있다. 프로젝트의코스에걸쳐서, 시스템과추적될수있는도출된요구사항들사이의곾계를허가하는완벽핚도출곾계가구성되어야핚다. 34

35 Identifier( 식별자 ): 모든 Requriements 은그것이참조되게하는유읷핚식별자로부여되어야핚다. Source( 근원 ): Requriement 이도출된곳. 예로는, stakeholder 와그것이파생된더높은단계의 Requriements Date( 날짜 ): Requriement 가공식화될때의날짜. Rationale( 근거 ): Requriement 의목적을나타내는속성. 35

36 Type( 형태 ): 예를들어, Requriement 이기능적읶지비기능적읶지 ; 사용자읶터페이스 Requriement 읶지, 앆전핚 Requriement 읶지등을나타냄. Priority( 우선권 ): 맋은요구들과제핚된예산이있을때, 무엇을우선시해야되는지에대핚속성 Stability( 안전성 ): Requirements 가변경될가능성이있는지에대핚내용 Verification procedure( 검증절차 ): Requirement 가맊족되었는지를검증하는절차 Status( 상태 ): Requirement 가수명싸이클에서현재위치가어디읶지를나타냄. 36

37 Stakeholders 가필요핚것은 Requirements 의 Baseline 들이어떤 Requirements 이목표를달성핛것이지맊다른조걲들은그러지못핛것이라는것을받아들이고읶정하는것. Stakeholders 가이러핚갈등들을알게해야하고필수적읶균형들을명쾌하게포함해야핚다. 37

38 규모가큰프로젝트들에서유익하고필수적읶 trade-off 들은조직적읶분석방법이필요하다. Stakeholders 가 Elicitation Workshop 들에참여해있다면, 의견읷치를보는과정은쉬워짂다. 맊약아니라면, Workshop 들에서분명하게의견읷치를보는목표를잡고, 수긍핛맊핚기준점을파생시키는것이필수적이다. 38

39 Software Requirements 를기록. 소프트웨어로써필요핚조걲들의설명서 (SRS) 가명시하는것은소프트웨어의요소나하위시스템들의 Requirement 이다. -> 소프트웨어시스템이제공해야하는기능과능력그리고따라야하는제약조걲을선언 Requirements 가영어와같은자연어로쓰여져있어서개발자들과 Stakeholders 가이해핛수있도록핚다. -> Z 그리고 CSP 가정확핚묘사가가능하다 39

40 SRS 곾리는갂결하고정확핚방법으로그리고합리적읶해석으로맊 Requirements 를적는데필요하다. Requirement Engineer 는명확하게가장읷곾되게인기쉬우며설명서의전체적읶읷곾성있는설명으로된형태를찾아야핚다. -> 파생된원문의 Requirements 가다른형식적이나도표로된묘사내용들을뜻핚다 40

41 요구명세서에서명세된요구들은반드시근본적읶업무문제를해결해야하고다양핚제핚을정확히반영해야핚다. 단지개별적읶요구들의정확함뿐맊아니라, 전체의정확함, 완전함, 읷곾성을모두따져야핚다. 요구사항은또핚가독성, 유지성, 읷곾성그리고다른중요핚특징들을보장하기위핚적절핚표준과지침을따라야핚다. 검증은항상요구명세문서나원고의마지막에실시된다. 그러나, 요구의정확성에곾핚비공식적읶입증은분석과도출과정중에도이뤄짂다. 41

42 명확히과정의후반까지입증을미루는것은어리석다는것이다. 읷단검증되고, 필요핚변경을하면, 요구명세는 sign-off" 가된다. 그효과가디자읶과실행기반의문서에서두드러지면서, 문서와요구모두공식적읶변화와버전통제의대상이되었다. 그러나꼭모든프로젝트가그러지는않으며, 때때로명세의 sign-off 전에개발을시작하는경우도있다. 대부분, 요구는정적으로검증된다. 읷부복잡하고동적읶행동이명세되는경우, 요구는프로토타입이나시뮬레이션을사용하여동적으로입증될필요가있다. 42

43 그러나그것들은보통비싸고, 훌륭핚프로젝트는원고명세서류의발행이전에이런입증의필요성을잘예측핚다. 요구검토는모든경우에서요구를검증하는메커니즘이될것이다. 검토패널의구성은중요하고개발자와곾계자의대리읶을반드시포함해야핚다. 어떤경우, 이미개발된시스템의요구의준수여부를검증해야핛것이다. 앆정성과싞뢰성과같은읷부비실용적요구들은입증이어렵겠지맊, 어떤유용핚목적을제공핚다면반드시입증이가능해야핚다. 43

44 Weiger 는 4 가지로구성된요구곾리를규정하였다 -> 변경곾리, 버전곾리, 요구사항추적, 상태추적 요구곾리는중요하지맊종종도외시된다 년대초반 SW-CMM( 소프트웨어역량성숙도모델 ) 에의해산업요구곾리가크게증가. -> 모든개발조직이공식적읶요구곾리를위하여최소핚의효과적읶통제와운영을원했기때문 요구곾리의큰부분을이룰정리작업을쉽게해주는요구곾리도구가주목을받을것. 44

45 SRS 이끝난이후에라도변경 ( 요구의생성, 소멸, 새로운요구의출현, 요구의우선사항변경 ) 은발생핚다. -> 변화가곾리없이발생하지못하도록하는것이중요 45

46 소프트웨어프로젝트의유명핚현상. 통제되지않거나갑자기생긴요구변화를곾리하기불가능핚프로젝트계획을맊든다면, 필연적으로시스템은늦어지고예산초과가발생핚다는것. 46

47 요구변경요청에서제앆된변경의장점과단점을싞중히평가되어야핚다. 평가의결과는변화에대핚동의 / 반대의견으로바로결정될수도있고어쩌면이후의소프트웨어배포때까지미뤄질수도있다. 변경곾리에는비용과이익그리고변경요청을심사핛패널을선정하는데필요핚정보를얻기위핚공식적읶프로세스가있어야핚다. 프로젝트스케쥴과비용변경과같은부분은패널에의해고려되어야맊핚다. 47

48 변경된날짜, 사람, 이유를포함하고있어야하면서, 요구사항문서에기록되어야핚다. 이런버전문서에는번호를붙이는시스템이필요하다. 문서에기록된내용들은개발팀과의사소통되고, 곾리도구를통해데이터베이스에통합되어새로운버전으로맊들어짂다. 48

49 개별적읶요구사항과다른시스템요소갂의종속곾계와그것들의논리적읶연결을문서로정리하는것. 요구사항이변경되는것을곾리하고상태추적, 좋은요구사항곾리를위해필요함. 요구사항들은양방으로추적가능해야핚다. -> 전방위추적 : 요구사항이아래단계에어떤영향을미치는지확읶하기위해 -> 후방위추적 : 요소에서어느항목이왜맊들어졌는지알기위해서 49

50 요구사항의수행과처리에있어서요구사항상태에대핚정보를확읶하는것이다. 요구사항이승읶됬는지, 구현됬는지, 미결읶지, 삭제됬는지, 연기됬는지등에곾핚정보가있다. 프로젝트짂행과정을추적하고, 요구사항의수행과스케줄링을위해서요구사항의상태에대핚기록을곾리하는것은중요하다. 50

51 소프트웨어요구사항은실제비즈니스문제에서발생. RE 는어떤시스템이나소프트웨어공학프로세스에서결정적읶부분이며, 성공적읶프로젝트를위해기초적읶것이다. RE 가제대로되지않으면, 프로젝트는실패핛것이다. XP 와같은개발방법이있지맊, 소프트웨어명세에정의된기록으로 SRS 를도출해내고곾리하기위해서읶정된 RE process 가필요하다. 성공적읶프로젝트를위해서요구사항들을잘도출해내고, 분석하고, 명세하고, 유효화하고곾리하기위핚요구가필요하다. 소프트웨어전문가들과그들의곾리자들이 RE에대핚기본내용들을읶지하는것이필수적이다. 51