SRSExample-webapp (1).doc

IoT 디바이스를 만든다고 하면 사실 S/W 부분보다 H/W 성능이 조건이 더 중요할 것이다. 또, RESTAPI도 많이 이용되므로 서버 성능도 함께 고려해야 한다.

얼마나 많은 트렉젝션(소켓통신, 패킷단위, DB CRUD, ...)을 감당할 수 있는지 해당 부분에 대한 포괄적인 사용 기준을 정해서 일반 사용자는 이러이러한 만큼 쓸 것이다. 그런 사용자를 얼마만큼 포용할 수 있는가 등... 

성능 조건은 스스로를 옥죄는 항목이 될 수도 있기 때문에 최대한 루즈하게 적어야 한다. 그러나 사람 목숨과 관련된 부분이라면 루즈한 성능 조건 정의가 되려 설득력을 잃을 수도 있기 때문에 성능 요구사항은 정말 각 실무자들이 최대한 협업해서 적어야 하는 항목일 수 밖에 없다. 기업간의 하청에도 늘 꼬투리를 잡거나 잡힐 수 있는 부분이니 이 부분 관련해서 우선 대화를 많이 해야 한다. 술자리도 좋다.

If there are performance requirements for the product under various circumstances, state them here and explain their rationale, to help the developers understand the intent and make suitable design choices.

Specify the timing relationships for real time systems.

Make such requirements as specific as possible. You may need to state performance requirements for individual functional requirements or features here or “Functional Requirements” section.

Specify both the static and the dynamic numerical requirements placed on the software or on human interaction with the software, as a whole. 

Static numerical requirements may include:

      (a)  The number of terminals to be supported

      (b)  The number of simultaneous users to be supported

      (c)  Amount and type of information to be handled

Static numerical requirements are sometimes identified under a separate section entitled capacity.

Dynamic numerical requirements may include, for example, the numbers of transactions and tasks and the amount of data to be processed within certain time periods for both normal and peak workload conditions.

All of these requirements should be stated in measurable terms.

For example,

95% of the transactions shall be processed in less than 1 second

rather than,

An operator shall not have to wait for the transaction to complete.

(Note: Numerical limits applied to one specific function are normally specified as part of the processing subparagraph description of that function.)

   Throughput (작업처리량) , Concurrent Session (동시 세션), Response Time (대응시간),  Performance Dependency (성능 종속 관계), Other Performance 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.

난 UML을 그릴 때 visio 나 visual studio 2015 enterprise 버전을 이용한다. Xcode에는 없는 기능이다.

https://channel9.msdn.com/Series/Visual-Studio-2012-Premium-and-Ultimate-Overview-KOR/Visual-Studio-Ultimate-2012-Improving-architecture-through-modeling-KOR

이런 동영상이 있긴 하지만 사실 UML은 많이 보고 또 많이 그려보는 수 밖에 답이 없다. 그리고 USE CASE의 모든 규칙을 지킬 필요도 없다.

USECASE는 requirements analysis 단계에서 작성하는 것이고 그것은 고객과의 의사 소통을 돕기 위해 만드는 것이지 내가 아는 지식을 자랑하려고 하는 것은 아니기 때문이다. 그리고 대부분의 고객은 돈이 많은 정도와 알고 있는 IT 지식이 반비례 하는 경우가 많다. 내가 하청을 받을 때는 몰랐는데 직접 고객을 만나 대응하는 경우 우 수백억의 자산가들은 IT에 대해서 전혀 모른다. 

보통은 use case를 그리지도 않고 구두로 설명하거나 해당 기술을 설명할 때 기껏 써봐야 sequence diagram, 개발자를 데리고 나온 경우 class diagram 정도였다. 그 중에서 나이 드신 분들도 좋아하는 것은 졸라맨(Actor)이 있는 use case 이다. 졸라맨과 벤다이어그램 하나면 시스템 전체를 설명할 수 있으니 정말 좋다.

그리고 같은 시스템이라도 다양한 관점에서 표현하고 구두로 설명하다보면 고객은 이해를 하고 IT 문외한인 자신도 이해하는 쉽고 자세한 설명을 할 수 있는 사람을 고수로 본다. 돈이 많은 데에는 이유가 있고, 대부분의 IT 기업 사장들이 그러하듯, 돈만 많고 IT는 전혀 몰라... 하는 식으로 접근하면 제대로 된 일을 따기란 불가능 하다고 생각하면 된다. 예전엔 먹혔지만 요즈음엔 다들 영악해서 일을 따더라도 헐값에 처리하거나 갑자기 다른 업체로 넘어가기도 한다.

쉽게 표현해 보자.

이런 경우 use case는 requirements 단계에서 작성하는 것이 아니게 된다.

어려운 용어는 SDS 단계에서 고려하는 것이 맞다. 그리고 졸라맨(Actor)이 "어라? 저게 뭐지 하면 안된다.

다시 그리면 다음과 같다. Visual Studio 2015 Enterprise 버전에서 그렸다.

액터에 이름을 따로 붙이지 않더라도 그냥 사람으로 생각이 될 것이고(그림부터가 사람)

사람 1과 2가 상호 작용을 할 수 있는데 사람 1, 2는 대부분 같은 기능을 공유한다.

사람1의 경우 메세지를 공유할 수 있지만 사람2는 메세지를 공유 할 수 없다는 것도 알 수 있다.

똑같은 기능이라도 여러번 그릴 수 있다. 목적은 내가 잘 그리느냐 못 그리느냐는 것이 아니라 사용자의 IT 지식 수준을 맞추고 이해시키는 것이 주된 목적이다.

그래서 요구사항 정의 단계에서 가장 먼저 선행되는 것은 용어의 정의, 용어의 명확화, 커뮤니케이션 할 때 빈번하게 나올 법한 

최소 개체에 대한 학습과 same page에 있기 위한 훈련이다.

사실 개발 전단계의 워크샵이 이런 것을 논의하기 위해 가는 것인데 뭐, ... 대부분 술먹고 놀자하고 끝나버린다.