실용적인 소프트웨어 요구사항

칼 위거스 지음 | 정보문화사 펴냄

실용적인 소프트웨어 요구사항 (까다로운 문제와 핵심적인 조언, More About Software Requirements)

이 책을 읽은 사람

나의 별점

읽고싶어요
13,000원 10% 11,700원

책장에 담기

게시물 작성

문장 남기기

분량

보통인 책

출간일

2006.6.12

페이지

228쪽

#소프트웨어 #아키텍트 #조언 #직역

상세 정보

솔직히 전문적인 조언과 실용적인 충고는 실제 프로젝트 경험에 근거를 두며, 이 책은 산업 전문가들에 의한 많은 거친 질문들에 답하고 있다. 고객과 같이 일하고 평가하는 전략으로부터 요구사항 문서화의 너트와 볼트에 이르기까지 이 핵심적인 안내서는 개발자, 분석가 그리고 관리자에게 사실상 모든 소프트웨어 개발 프로젝트에 적용하는 일반적인 진리를 제공한다.

  • 더 나은 요구사항 사례들에 대한 투자를 위해 비즈니스 케이스를 만들어라.
  • 세 가지 특정한 기술을 사용하여 평가하라.
  • 의미 있는 비즈니스 및 사용자 요구사항을 유도하기 위해 조사하라.
  • 프로젝트 범위를 명확하게 문서화하라.
  • 효과적으로 유스케이스, 시나리오 그리고 사용자 스토리를 구현하라.
  • 검사와 동료 검토를 개선하라.
  • 요구사항 작성에서 모호함을 피하라.

  • 상세 정보 더보기

    이 책을 언급한 게시물1

    jejeong9031님의 프로필 이미지

    jejeong9031

    @a6nte2nqqjqt

    아주 유용하게 읽었다.
    두리뭉실하니 애매하던 부분들, 잘몰랐던 부분들을 이해하는데 도움이 되었고 동저자의 다른책들도 탐날만큼 내용이 아주 알차다*-*♥♥
    내가 딱 원했던 요구사항에 대한 실무적인 조언들이 많이 있어서 흥미진진했다♪

    단지,,,번역이 좀,,,,,개정판이 나올 계획은 없는걸까,,,TㅡT

    SW쪽에 종사해본 사람이 한 작업이 아닌건지 영어문장이 영어식으로 번역되어있다.. 의역이 아니라 직역...OTL
    번역기를 돌린것 마냥 직역이라 원문을 추측할 수 있을정도ㅋㅋ
    그러다보니 단어도 그렇고 문장도 이상한 것들이 있었다..

    고수준 설계. 정말 고수준의 설계를 말하는줄 알았으나 이 단어가 여러곳에서 나와 계속 읽다보니 문장이 이상하다.
    왠걸. 상위 레벨의 설계를 고수준 설계로 직역한 것 같다.
    아마 원문은 high level design이 아닐까 추측,,,
    sw쪽에서는 `상위/하위레벨`이란 말을 쓰는게 아니었던가....-ㅅ-??
    한국어로는 상당히 다른 의미로 받아들여지는데. 고수준설계는 수준높은 설계고 상위레벨설계는 추상적인 설계랄까 스케치정도의 설계라는 의미라고 생각하는데 좀 당황했다;


    책임. 요것도 반복적으로 나와서 읽다보니 문장을 아무리 읽어도 책임이 우리가 쓰는 의미의 그 책임이 아닌거다.
    원문은 responsibility였겠지? 근데 문맥상 의미는 내 일이니 니 일이니 할때의 그 `일`.
    이걸 책임이라고 해버리니 영 이상한거다. 분명히 한글 문장인데 이해가 안돼ㅠㅡㅠ

    ˝그는 책임이 그가 아니라, 분석가의 책임이라고 생각했다˝
    이 문장을 몇번이나 읽었는지 모르겠다.
    앞뒤 문장을 한참이나 맞춰보고서야 앞뒤 문장도 번역이 이상했다는걸 이해; 마치 나는 오답을 정답으로 끼워맞추려고 용쓰고 있었던거다-_-a
    ˝그는 그 일이 그가 아니라 분석가가 했어야하는 일이라고 생각했다˝가 의역했을 때 문장이라고 생각한다.

    번역미스 중에 내가 커버할 수 없는 부분들은 어찌해야하나요..
    원문사서 내가 번역해보겠어! 할정도로 절박?열정적이 되어야겠지..OTL

    ˝아키텍트로부터 몇몇 추가적인 입력을 분석가의 작업으로 안내하는 것은 향후 명세서가 요구사항 개발과 소프트웨어 설계 사이의 틈을 적절히 메워준다는 것을 보증하는 것이다.˝
    니 일을 내가했다고 생각한다라는 상황뒤에 나온 말이다.
    아키텍트가 분석가가 한 작업(요구사항 도출)에 요구사항을 몇개 더 추가하는 것은 명세서가 요구사항 개발과 설계사이의 틈을 메꿔준다는 증거라고? 이렇게 이해하면 되는건가..????

    결국 아키텍트 입장에서 생각하길 ˝분석가가 할일을 내가했잖아˝인데, 그게아니라 분석가가 도출한 요구사항은 (분석가가 아키텍트의 시야를 다 포용하지 못하므로)아키텍트가 보기에 부족할 수 있다. 때문에 아키텍트가 생각한 니 일(분석가의 일)은 아키텍트의 일이 맞는거다ㅡ 라는 의미인건가.

    그럼 요구사항 명세서는 요구사항 분석가가 초안쓰고 아키텍트가 보완하는 작업이었던건가!?!
    오오 이렇게 리뷰쓰면서 쓰고지우고 하다보니 이해되는것 같은ㅋㅋ
    이해못한 문장이 한두개가 아닌데.. 에라이..

    에고고 직역문장 덕택에 본의아니게 원문 단어는 뭘까를 추측해가며, 그게 실패하면 일단 넘어가고,
    또 단어 위치바꿔도 보고 한국어를 막 끼워맞추다보니 짜증도 났지만
    그래도! 소프트웨어 요구사항만을 주제로한 책의 번역본은 몇권 없는데다가 정말 도움되는 포인트들이 많았기에 감사하게 보았다ㅎㅎㅎㅎ

    초판인쇄 2006년이라고 되어있던데 10주년 기념으로 번역문장을 좀 교정한 개정판이 나오길 바래본다 ㅠㅡㅠㅎㅎ

    실용적인 소프트웨어 요구사항

    칼 위거스 지음
    정보문화사 펴냄

    읽었어요
    2016년 11월 11일
    0
    집으로 대여
    지금 첫 대여라면 배송비가 무료!

    상세정보

    솔직히 전문적인 조언과 실용적인 충고는 실제 프로젝트 경험에 근거를 두며, 이 책은 산업 전문가들에 의한 많은 거친 질문들에 답하고 있다. 고객과 같이 일하고 평가하는 전략으로부터 요구사항 문서화의 너트와 볼트에 이르기까지 이 핵심적인 안내서는 개발자, 분석가 그리고 관리자에게 사실상 모든 소프트웨어 개발 프로젝트에 적용하는 일반적인 진리를 제공한다.

  • 더 나은 요구사항 사례들에 대한 투자를 위해 비즈니스 케이스를 만들어라.
  • 세 가지 특정한 기술을 사용하여 평가하라.
  • 의미 있는 비즈니스 및 사용자 요구사항을 유도하기 위해 조사하라.
  • 프로젝트 범위를 명확하게 문서화하라.
  • 효과적으로 유스케이스, 시나리오 그리고 사용자 스토리를 구현하라.
  • 검사와 동료 검토를 개선하라.
  • 요구사항 작성에서 모호함을 피하라.

  • 무제한 대여 혜택 받기

    현재 25만명이 게시글을
    작성하고 있어요

    나와 비슷한 취향의 회원들이 작성한
    FLYBOOK의 더 많은 게시물을 확인해보세요.

    지금 바로 시작하기

    플라이북 앱에서
    10% 할인받고 구매해 보세요!

    지금 구매하러 가기

    FLYBOOK 게시물이 더 궁금하다면?

    게시물 더보기
    웹으로 보기