[소개원실] Requirements and Specification

Credit: Many Slides from UCB CS169

지라에서 사용하던 것들의 정확한 의미를 알게 되어서 좀 더 재밌게 공부할 수 있었다.

Requirements and Specification

Requirements Engineering

• 소프트웨어 시스템을 만드는데 가장 중요한 부분 중 하나: 무엇을 만들 것인가
  • 잘못된 프로세스가 있으면 바로잡기.
  • 나중에 고치려하면 더욱 많은 비용이 든다
• 반드시 software process에 적합해야 함
  • 향후 plan과 document를 위해 requirements/specs을 아주 상세히 만들어야함.
  • 일부 user story들은 여러 번 반복해서 수정하고, 개선시킴(iterative process)

Determining Stateholders and Needs

• 반드시 stakeholders를 결정할 것.(타겟 고객)
  • 어떤 사람이 이 소프트웨어로 혜택을 받을 것인가?
    • who's client and who's user
• 그들의 니즈를 파악
• 서로 다른 니즈, pov를 잘 조정할 것.

사용할 수 있는 방법들

• 인터뷰
• 유저 스토리
• Strawmen
  • 디자인 mocks and sketchs
• Prototyping(프로토 타이핑)
• Pretotyping(프리토 타이핑)

Interviewing

• 단순 질의 응답(명확한 방법)
• 또 다른 방법(less obvious)
  • Master-apprentice relationship
  • 사람들에게 해야할 일을 가르치고
  • 실제 하는 행동을 관찰
• 모든 인터뷰에서 디테일을 얻어낼 것.
  • report, log, email 등을 진행 과정에서 받기
  • 이게 실제 나타나는 현상을 설명할 근거가 된다.

Talking의 단점

• 인터뷰는 유용하다. 하지만 유저가
  • 자신이 원하는 바를 말로 표현하지 못할 수 있음.
  • 실제 Computer science 기술로 구현이 가능한지, 불가능한지에 대한 지식이 충분하지 않다.
  • 즉, 요구사항이 비현실적일 수 있음.

User Stories

• 소프트웨어의 사용 용도를 묘사
• 각 유저스토리는 acceptance test를 가짐.
  • Concrete instance(s) of story
  • Will tell you when the customer thinks story is done.

Style #1

• 기능
• 시나리오
• Acceptance tests ( 하나 이상의 acceptance tests를 적어야함. with concrete values for the parameters)
• 에시
  • 기능: 글 삭제
  • 시나리오: 글 삭제 버튼 클릭 -> 경고 모달 pop-up -> 확인 버튼 누르기(Y/N) -> 삭제 후 게시글 목록으로 이동..
  • Acceptance tests 적기

Style #2

• Featurename
• Actor(s)
  • 스토리에서 행동하는 대상
• Preconditions(in what system state is this user story applicable)
  • 시작 조건
• Triggers(what initiates the story)
  • 스토리 동작하는 조건
• Scenario(s)
  • 구체적인 시나리오
• Postconditions(what is the system state after the story is done)
  • 스토리 끝난 다음의 sys state
• Exceptions
• Acceptance tests(list one or more acceptance tests with concrete values for the parameters, and concrete assertions that you will make to verify the postconditions).

Style #3: Connextra Format

예시
기능: 영화 순위에 새로운 영화 추가하기
영화 팬으로서(who)
나는 영화 순위 서비스에 새로운 영화를 추가하고 싶다.(what)
그렇게 함으로써, 나는 다른 영화 팬들과 영화를 공유할 수 있다.(why)

Strawmen

• Sketch the product for the user/client
  • 스토리보드
  • 순서도
  • HTML mock-ups
  • 중요한 이벤트/인터페이스/액션 등을 그리기
• 코드 작성없이 아이디어를 전달하는 것!

요약 (Requirements 관련)

• 유저와 고객의 니즈를 파악하라.
  • 꼭 그들이 말하는 것이 아니어도 됌
• 인터뷰, 유저 스토리, Strawmen, etc. 이용할 것.

Specs(Specifications)

Specifications

• 제품의 기능을 묘사
  • 정밀하게
  • 모든 상황을 커버해야함
• finite한 것에서 infinite로 이동하면서 묘사
  • finite examples -> infinite set of possible cases

Different Views of Spec

• 개발자
  • 구현이 가능할 정도로 스펙이 명확해야한다.
  • 모호하면 안됌
  • self-consistent
• 유저/고객
  • 이해 가능해야 함.
  • 기술적인 용어가 아닌 일상 용어.
• Legal(법적으로)
  • spec은 계약 조항이 될 수 있다.
  • Should include acceptance criteria
    • 어떤 테스트(x,y,z)를 통과하면, accepted와 같은 기준.

Problems with Informal Specs

• Informal specs: written in natural language.
• Informal specs은 다음과 같은 심각한 문제가 생길 수 있음
  • Omissions
  • Ambiguities
  • Contradictions
• These problems will be faithfully implemented in the software unless found in the spec.
  • Spec 명확히 하지 않으면, 오류가 있는 코드가 구현 됌.

Informal Specifications 예시

• '이번 달 매출이 목표 매출보다 적을 경우에, 이번 달 목표 매출액과 실제 매출액의 차이가 지난 달의 차이보다 절반보다 작지 않거나 이번달 목표 매출액과 실제 매출액의 차이가 5% 이상이면, 리포트가 출력된다.' 와 같이 모호한 표현
• Problem
  • 매출액이 정확히 어떤 값인지 정의가 안 되어있음. 주문 받은 금액인지, 주문 받고 결제까지 완료된 금액인지?
  • 목표 매출액이 어떤 단위인지 모호하다. 이번달? 이번 분기? 등.
  • unless A or B로 원문에는 표현되어 있었는데, 이것은 if !(A || B) 혹은 if(!A || B) 두 가지 의미로 해석할 여지가 있음.
  • 즉, 언어 자체에서 오는 중의성, 모호함 등이 문제가 된다.
  • 5%라는 것이 목표 매출액 or 실제 매출액 둘 중에 어떤 것의 5%인가

Comments on Informal Spec

• 이러한 서술 방식은 학문 적으로나 'how to'(특정 분야에 대한 tutorial 같은 것)의 저자들도 선호하지 않음.
• 그러함에도, 많이 사용되고 있음

왜 Informal Specs를 사람들이 사용하는가?

• 사람들에게 익숙한 방식이다(자연어).
  • 고객들이 formal spec은 읽지 않음
  • 대다수의 프로그래머들도 마찬가지로 읽지 않음.
  • Or most managers
  • A least-common denominator effect takes hold
• Truly formal specs are very time-consuming
  • And hard to understand
  • And overkill for most prj.

Formal Spec Exampl (TLA+)

• TLA+

Semi-Formal Specs

• Best Current practice is "semi-formal" specs
  • 일상 용어보다 더욱 정확하게 표현할 수 있음
• 보통 boxes-and-arrows notation 사용.

Semi-formal example

• UML Use Case
• UML Class Diagram - Design Phase

SMART User Stories

Creating User Stories

• 어떤 것이 좋은 유저스토리인가?
  • 적절한 사이즈? 어렵진 않은가? Is worthwhile?

SMART stories

• Specific
• Measurable
• Achievable (ideally, implement in 1 iteration)
• Relevant ("the 5 why' s")
• Timeboxed (know when to give up)

Specific & Measureable

• 각각의 시나리오는 테스트 가능해야 함(good input <-> expected result가 존재해야 함)
• Anti-example(반대되는 예시): "UI는 사용자 친화적이어야 한다"
• Example: Given/When/Then
  1. Given Some Specific starting condition(s),
  2. When I do X,
  3. Then one or more Specific Thing should happen

Achievable

• Complete in 1 iteration
• If can't deliver feature in 1 iteration, deliver subset of stories
  • Always aim for working code @ end of iteration
• if <1 story per iteration, need to improve point estimation per story

Relevant: "business value"

• Discover business value, or kill the story (비즈니스적으로 가치 있는 스토리만을 살리기)
  • Protect, Increase Revenue (프로젝트 효율 up)
  • 비용 낭비 최소화
  • 브랜드 가치 올림
  • 프로덕트를 더욱 remarkable하게 만들어줌.
  • 소비자에게 더욱 큰 가치를 제공.5 whys to Find Relevance5가지의 why를 하나의 스토리에서 생각해볼 것.

Behavior-Driven Design and User Stories

SW 프로젝트가 실패하는 이유들

• 소비자가 원하는 것을 만들지 않는다
• Or projects들이 너무 늦음
• 예산 초과
• 유지 보수 및 발전시키기 어려운 경우
• 위의 모든 이유들
• 애자일 방법론은 실패를 막기 위해 어떻게 할까?

Agile Lifecycle Review

• Work closely, continuously with stakeholders(이해관계자) to develop requirements, tests
  • 유저들, 고객들, 개발자들, 유지보수 개발자들, operators, PM(prj manager)..
• Maintain working prototype while deploying new features every iteration(sprint)
  • 1~2주 마다.
• Check with stakeholders on what’s next, to validate building right thing (vs. verify)

Behavior-Driven Design (BDD)

• BDD는 실제 개발 전, 개발 중에 비효율적인 의사소통을 줄이기 위해 앱의 behavior에 대한 질문을 함.
• Requirements written down as user stories
  • Lightweight descriptions of how app used
• BDD는 앱의 behavior에 집중함.
  • TDD(Test Driven Design) tests implementation

User Stories

• 일상 용어로 1~3 문장.
  • 3"(인치) x 5" 인덱스 카드에 들어가도록
  • Written by/whth customer(고객/ 이용자만을 생각)
• "Connextra" format:
  • Feature name
  • As stakeholders, so that achive some goals, I want to do some task.
  • 위의 3단계가 꼭 있어야 함.
• 유저 스토리는 acceptance test의 형태로 작성되어야 한다.(코드 구현 이전에)

왜 3x5 카드에 들어갈 정도의 분량이어야 하나?

• Nonthreatening: 모든 이해관계자가 브레인 스토밍에 참여 가능
• 재배열하기 쉬움: 우선순위 변경 쉬워짐
• 실제 개발 중 바꾸기 쉽다: 개발 중에 생각이 바뀌는 경우 많음

하나의 행동을 묘사하는 방법이 사람마다 다름

Product Backlog

• 실제 시스템에선 수백개의 유저스토리가 존재.
• Backlog(미처 처리하지 못하고 쌓여 있는 일): User Stories not yet completed
• 더욱 가치있는 아이템의 우선순위를 조정한다.
• 릴리즈 일정에 맞춰서 다시 Organize하기

Related Issue

• Spike
  • 특정 기술이나 문제점에 대해 짧게 조사하는 것.(ex: spike on recommendation algorithm)
• After spike done, code must be thrown away
  • 구현 방법 등에 대해 알아내었으니, 실제 코드를 작성하면 된다.

Lo-Fi UI Sketches and Storyboards

Building Successful UI

• SaaS app은 유저와 자주 마주하게 됨
  • 유저 스토리는 유저 인터페이스가 필요.
• How get customer to participate in UI design so is happy when complete?
  • Avoid WISBNWIW(Whay-I-Said-But-Not-What-I-Want) UI
  • UI version of 3x5 cards?
• 프로토타입 제작 없이 어떻게 interaction을 보여줄 수 있을까?

SaaS UI 디자인

• UI Sketches: 손으로 그리기 or "Lo-Fi UI"

스토리보드

• user action에 따라 UI가 어떻게 변하는가 보여줘야함
• Human-Computer-Interaction
• UI Sketch간의 interaction을 표현(어떤 버튼을 누르면 어떤 화면으로 가는지와 같은 정보)

Lo-Fi to HTML

• UI 스케치보다 더 지루한 작업.
• 다음 단계: CSS

Cucumber: A BDD Tool

• 유저 스토리를 테스트 코드로 바꾸는 과정을 자동화 하자는 아이디어.
• natural language to test code
• 고객 친화적인 유저스토리로 테스트 실행.
  • Acceptance: 유저 만족도 향상
  • Integration: 모듈간의 interface가 consistent assumption, communicate correctly 하도록 ensure함.
• 고객과 개발자 둘의 입장을 절충해서 만족시킴.

이하 생략.