UI 모형에서 실제 요구 사항으로 클라이언트를 어떻게 이동합니까?

응용 프로그램의 시각적 상태를 25 개 모의 화면으로 표시한다고 가정 해보십시오. 이것은 우리가 완성 된 응용 프로그램으로 원래 이해 관계자 또는 고객에게이를 개발하고 전달할 수 있다고 확신하기에 충분할 것으로 기대합니다. 당연히 UI를 생각해내는 데 사용되었던 많은 질문을 이해 당사자에게 다시 묻는다.

그러나 나는 이것이 충분하지 않다는 것을 여러 번 발견했습니다. 응용 프로그램을 개발하는 과정에서 인터페이스를 복제하고 결국 고객이 처음 보았던 것처럼 행복하지 않다는 사실로 인해 요구 사항이 흐려집니다. UI를 만들기 위해 모든 정보를 요청했을 때

나는 무엇을 요구해야하는지 잘 모르겠습니다. 구체적으로 노력하고 요구 사항과 전반적인 목표에 대한 이해를 요구했지만, 무엇을 요구해야하는지 모르겠습니다. 방금 시작하면 UI로 연결되는 모든 정보를 다시 해싱하는 데 많은 시간이 낭비되고이 단계에서 고객이 원래 잃어버린 여러 가지 중요한 이유가 사라집니다.

UI 모형을 기반으로 요구 사항을 잠글 수 없다는 점을 사람들이 이해하도록하려면 어떻게해야합니까?

최종 사용자를위한 응용 프로그램 개발 작업을 올바르게 실행하기 위해 무엇을 시작하는 것이 이상적입니까?

필요한 다른 것들은 다음과 같습니다.

• 사용 사례 또는 워크 플로 설명 : 화면의 모양을 알고 있기 때문에 입력이 어떻게 처리되는지 알고 있습니까? 모든 경우에 화면 간 전환 방법을 알고 있습니까? 여기에도 오류 처리를 포함시킬 수 있습니다.

• 높은 수준의 시스템 설명 : 뭔가는 설명 어떤 이 25 개 화면가 있는지 전체 시스템, 그리고 그들이 할 수 있습니다.

• 데이터 모델 :이 화면에서 데이터 모델을 유추 할 수 있습니까? 사용해야하는 데이터 모델이 있습니까? 아니면 업무를 완수하기 위해 자유롭게 디자인 할 수 있습니까?

• 기술 요구 사항 : 라이센스 때문에 또는 통합 이유로 사용해야 하는 특정 기술이 있습니까?

• 성능 요구 사항 : 검색 화면이있는 경우 검색 할 수있는 내용과 응답 속도는 어느 정도입니까? 다른 유형의 행동에 대한 반응은 어떻습니까? 이들 중 일부는 비동기식이어야합니까 (사용자가 작업을 제출 한 후 나중에 다시옵니다)?

• 보안 요구 사항 : 응용 프로그램은 잠재적으로 민감한 / 개인 데이터를 저장합니까? 그렇다면 보안을 유지하기 위해 어떤 종류의 데이터와 무엇을해야합니까? 신용 카드 결제를위한 PCI 준수와 같은 일정 수준의 준수를 충족해야합니까?

또한 도움이 필요한 특별한 비즈니스 도메인 지식이 있습니까? 보험, 은행업, 의료 건강 기록 등과 같은 일부 산업에는 모든 종류의 복잡한 비즈니스 논리가 있습니다. 이러한 프로젝트는 해당 도메인을 알고있는 비즈니스 분석가의 도움없이 시도해서는 안됩니다. 그러나 일반 위젯의 쇼핑 카트 / 정보 사이트 인 경우 이러한 팀 구성원이 필요하지 않을 수 있습니다.

사람들이 UI 모의로 작업 프로그램을 만들기에 충분하지 않다는 것을 이해하도록하는 방법 :

나는 이것을 유추로 다룰 것입니다. 나는 약간의 차 견과이기 때문에 그 길을 가고 있습니다.

"내가 차에 대해 아는 바없는 척. 당신은 나에게 페라리 사진 몇 장을 건네 주겠지. 외부와 차 안에서 몇 명 (운전석에서 가져 와서 차의 컨트롤을 볼 수있다.) 페라리를 만들기 위해 그림처럼 보이고 모든 컨트롤을 가지고있는 것으로 돌아 왔습니다. 불행히도, 그 컨트롤은 (자동차에 대해 아무것도 모르기 때문에) 어떤 것에도 연결되어 있지 않습니다. 자동차가 무엇을해야하는지조차 모르기 때문에 추측조차 할 수 없습니다.

"페라리는 무엇을 하는가?" "이를 통해 한 지점에서 다른 지점으로 빠르게 이동할 수 있습니다." "그래.이 서클은 무엇을 하는가?" "아, 그것은 스티어링 휠입니다.이 휠을 돌리면 차량 바깥쪽에있는 휠의 방향을 바꿀 수 있습니다. 이것은 자동차의 이동 방향을 바꿀 것입니다." "좋아,이 페달은 어때?" "이것은 가스 페달입니다. 엔진이 더 빨라지고 자동차가 더 빨라집니다." ... 몇 분 후 ... "좋아요, 어떤 엔진이 필요한가요? 조사를 해봤는데 골프 카트 엔진과 스포츠카 엔진을 찾았습니다. 어느 것을 사용해야합니까?" ... 등 ... "

그런 다음 유추를 설명 할 수 있습니다. 개발자들에게 화면의 모의를 건네주는 것은 화면이 아닌 모양 만 알려줍니다. 개발자는 프로그램이 해결하는 문제 또는 사용 방법을 알아야합니다 (예 : 자동차의 기능을 알면 자동차 설계가 쉬워지고 수행해야 할 사항에 대한 교육적인 추측이 가능함). 그들은 어떤 종류의 물건 (예 : 골프 카트 엔진 대 스포츠카 엔진)과 다른 비 UI 요구 사항 (자동차가 빨리 가야 함)을 알아야합니다.

내가 요청할 것 :

일반 / 고수준 문제 설명

사용 사례 / 사용자 사례

성능 요건

필요한 기술 / 플랫폼 (Windows, Linux, Web)

FrustratedWithForms가 그의 답변에 가지고있는 모든 것

개발 노력의 80 %에 영향을 미치는 것은 프린지 사용 사례의 20 %를 향합니다. 스크린 샷은 사용 사례에 대해 알려주지 않으므로 활성 개발의 80 %가 어두워집니다.

클라이언트가 프로젝트 요구 사항에 더 관여하는 것이 얼마나 중요한지 더 많은 정보를 얻고 의사 소통을 시도하는 것이 좋지만, 그렇지 않은 경우 프로젝트를 실패로 설정합니다. 그건 네 잘못이 아니야

클라이언트가 소프트웨어 개발 프로세스에 충분히 관여하지 않기 때문에 대부분의 소프트웨어 프로젝트가 실패합니다. 이것은 새로운 문제가 아니며 소프트웨어 프로젝트가 실패하는 이유에 대한 미스터리가 아니지만 이러한 상황으로 인해 업계에서 계속해서 계속되고 있습니다.

당신은 벽을 통해 정보의 물방울을 던져 버릴 수 없으며 소프트웨어 패키지의 형태로 모든 희망과 꿈을 되 찾을 것으로 기대합니다. 소프트웨어 개발은 ​​이런 식으로 작동하지 않습니다. 애자일이든 워터 폴 상점이든 프로젝트의 성공 또는 실패에는 확실한 고객 지향이 필요합니다.

사람들이 묻는 것을 잊어 버린 것 중 하나는 입력 후 데이터가 무엇입니까? 보고서가 필요하십니까? 포장 명세서를 생성하고 운송 등을 위해 창고로 보내야합니다. 관리 결정 및보고를 위해 데이터가 사용되는 경우 데이터베이스 설계가 변경 될 수 있습니다. 또한 보고서의 복잡성에 따라 개발 시간이 크게 늘어날 수 있습니다.

또한 가능한 각 결정에 대한 경로가 있는지 확인해야합니다. 따라서 관리 승인이 필요한 항목이 있으면 승인 된 경우 수행 한 작업뿐만 아니라 승인되지 않은 경우 수행하는 작업이 수행됩니다. X 시간 동안 승인 또는 비 승인되지 않은 경우 어떻게됩니까? 제품을 선택했는데 재고가 없으면 주문은 어떻게됩니까? 그런 종류의 질문들.

또한 각 필드에 어떤 데이터를 입력해야하는지에 대한 특정 제한이 있는지 알아야합니다. 필요한 값이 있습니까? 어디서 구할 수 있습니까? 그것들은 어떻게 업데이트됩니까? 오류를 처리하는 방법을 알아야합니다. 데이터베이스에 감사가 필요한지 또는 히스토리 관점에서 데이터를 다시 작성할 수 있어야 하는지를 알아야합니다.

내가 겪고있는 또 다른 것은 데이터가 나중에 유지 관리되는 방식을 고려하지 않고 응용 프로그램이 릴리스에 도달하도록 설계 될 수 있다는 것입니다. 필요한 값 목록을 업데이트 할 수 있도록 관리자 페이지가 필요합니까? 다른 시스템으로 데이터를주고 받아야합니다. 초기 데이터를 데이터베이스에 어떻게 가져 옵니까?

개인적으로 클라이언트와의 반나절 회의를 통해 UI 디자인과 목표를 살펴보고 모든 것이 정렬되도록해야합니다.

간단하게 시작하십시오. 귀하가 제공 한 정보를 바탕 으로 그 화면들 중 어느 것도 아무것도하지 않을 것임을 이해하도록하십시오 . 사용 사례, 잘못된 입력 동작 등에 대한 세부 사항이 없습니다. 그냥 작동하지 않습니다. 포인트를 잃을 수 없기 때문에 세부 사항을 설명하는 것보다 무딘 일반화를 설명하는 것이 더 쉽습니다. 화면 모형이 충분하지 않은 이유에 대해 더 복잡한 근거를 제시하려고하면 문제를 인정하는 대신 정의를 떨쳐 버릴 수 있습니다. 백엔드 개발자가 영어를 구사하지 못했거나 화면에 표시되는 언어가 무엇인지 상상해보십시오. 그런 다음 전혀 모르는 개발자에게이 상황이 얼마나 다른지 묻습니다.그들의 비즈니스 프로세스. 그런 다음 지식이 있지만 자신의 비즈니스 논리를 결정하는 것이 적절하지 않다고 믿는 정당한보다 현실적인 예를 세우십시오 .

소프트웨어를 개발하지 않은 사람들은 소프트웨어 개발자가 알아야 할 사항을 모릅니다. 요구 사항 사양 및 사용 사례를 자체적으로 생성 할 것으로 기대할 수는 없습니다. 알아야 할 정보를 얻으려면 요구 사항 추출 기술 을 적용 해야합니다. 클라이언트 (및 다양한 역할의 사용자 샘플)와 협력하여 필요하거나 원하는 것을 결정하십시오. 이에 대한 일반적인 기술은 인터뷰 및 / 또는 사용자 관찰, 사용 사례 및 사용자 사례 식별, 프로토 타입 제작입니다.

모호하거나 불완전하거나 이해하기 어려운 요구 사항이 있으므로이 경우 반복 및 증분 개발 기술을 적용하는 것이 좋습니다. 수명주기 계획을 해결하기 위해 나선형 모델과 함께 다양한 민첩한 방법론을 살펴보십시오.

이 소프트웨어의 개발을 주도하는 비즈니스 목표를 얻는 것으로 시작하십시오. 클라이언트와 사용자를 인터뷰하고 가능하면 직장에서 관찰하십시오. 그들이 해결하려는 문제를 확인하십시오. 현재 사용중인 도구와 도구를 사용하여 현재 작업 방식을 개선 할 수 있는지 확인하십시오. 이 기회를 이용하여 도메인과 언어를 배우십시오. 소프트웨어 개발자와 클라이언트 / 사용자가 모두 같은 언어를 사용하는 경우 (그리고 클라이언트 / 사용자가 소프트웨어 용어로 말하는 것을 기대하지 않는 경우) 의사 소통이 훨씬 쉬워집니다.

목표가 무엇인지 이해 한 후에는 보유하고있는 UI 디자인 모형을 사용하여 다양한 화면이 어떻게 결합되는지에 따라 사용 사례와 사용자 사례를 "역 엔지니어링"할 수 있습니다. 사용자 스토리 형식은 기술이 아닌 독자를 처리하는 데 효과적 일 것입니다. 형식은 As a <user type>, I want to <action> so that <reason>개발자와 클라이언트 / 사용자가 동일한 언어를 사용하도록하는 측면에서 효과적입니다. 사용자 스토리를 시작할 수 있다면 개발에 프로토 타이핑 방식을 채택 할 것입니다.

저는 프로토 타입을 사용하여 이것에 접근 할 것이라고 생각합니다. 진화 적 프로토 타이핑 또는 버리기 프로토 타이핑 관점 에서 이것에 접근 할 수 있지만, 나는 먼저 진화 적 프로토 타이핑 접근법을 고려할 것입니다. 가장 편안하고 검증 된 사용자 스토리로 시작하여 구현하십시오. 구현할 때 고객으로부터 피드백을 받고 새로운 사용자 사례를 개발하고 사용 사례를 파악하고 오해를 해결하십시오.

또한 이것을 "아래에 기능이있는 사용자 인터페이스 구현"으로 생각하지 마십시오. 대신 얇은 세로 조각으로 생각하십시오. 모든 사용자 인터페이스를 한 번에 구현하지 말고 기능에 대해 걱정하십시오. 대신, 사용자 인터페이스 모형을 사용하여 기능 및 기타 요구 사항을 식별 한 후 UI에서 비즈니스 로직 및 데이터 스토리지까지 수직 분할을 구현하십시오. 모든 수직 슬라이스에 대해 이것을 반복하십시오. 또한 요구 사항과 사용성 원칙에 따라 UI를 개선하기위한 제안을 자유롭게해야합니다.

Karl Wiegers ( 소프트웨어 요구 사항 및 소프트웨어 요구 사항 에 대한 추가 정보)의 두 권의 책을 읽는 것이 좋습니다 . 이것들이이 분야의 요구 사항 엔지니어링 및 모범 사례에 도움이 될 것이라고 생각합니다.

글쎄, 이것은 당혹스럽게도 명백한 시작 참고 자료이지만 Wikipedia 는 귀하와 사용자가 처음 시작할 수있는 장소 일 수 있습니다. 이 물건에 대한 항목이 있다는 사실은 이것이 당신이 고통이 아니라 실제 문제임을 확신시키는 데 도움이 될 수 있습니다.

더 구체적으로, 모형을 검토 한 후에도 응용 프로그램의 기능에 대해 당황스럽게 생각하십니까? 그렇다면, 그것을 인정하고, 각 양식이 어떤 데이터를 표시해야하는지, 또는 어디에서 왔는지, 다른 화면이나 외부 데이터로부터 어떤 데이터인지 모릅니다.

어떤 아이디어 가 있다면 , 어떻게 해야할지 모르는 일의 예를 생각해보십시오 ( "템플릿 목록을 선택하여 하나의 글로벌 목록이되거나 사용자가 다른 것입니까?" 사용자가 아닌 두 사람이 한 번에 편집하도록해야합니까? 다른 사람이 편집하고 있다면 UI에 무엇을 표시해야합니까? 그 화면이 있습니까? 변경 사항이 템플릿을 사용하여 만든 내용으로 전파되어야합니까? ").

현재의 지식 수준으로 남은 개발주기 동안 약 90 초마다 질문에 답변해야하며, 답변을 얻을 때까지 계속 일할 수 없을 것이라는 점을 분명히하십시오. 어떤 종류의 프로세스를 갖는 것이 왜 모든 과정을 더 쉽게 만들 수 있는지 명확하게하는 것이 목표입니다. 또한 QA에는 귀하가하는 것과 동일한 정보가 필요하므로 모든 정보를 쉽게 기록 할 수 있으므로 모든 사람이 이용할 수 있으며 아무도 잊지 않습니다.

작성하는 일부 코드가 한 번에 두 개 이상의 화면에 영향을 준다는 점을 언급하면 ​​도움이 될 수 있으므로 가능한 한 많은 답변을 얻을 경우 해당 코드를보다 쉽게 ​​작성하고 나중에 변경할 필요가 없습니다.

당신이 경우 여전히 요구 사항을 얻을 수 없다 그리고 당신이 정말로, 진행하는 방법을 알고 좀 더 자세한 정보 (즉, 요구 사항)가 필요 때마다 이메일을 보내하지 않습니다 당신은 당신이 있음을 명확하게 정보, 상태없이 작업을 계속할 수없는 경우 불행히도 작성해야하는 코드는 질문에 대한 답변에 따라 매우 다르기 때문에 작업을 계속할 수 없습니다. 불평하지 말고, 프로그램을 어떻게해야할지 알기 전까지는 프로그램을 작성할 수 없다는 것을 매우 전문적으로 알려주십시오.

응용 프로그램의 각 필드에 대한 한계 및 범위를 알아야합니다. 예를 들어, 필드가 전화 번호 인 경우 +1을 처리 할 것으로 예상합니까? 어떤 필드가 필요합니까? 사용자가 phone # 필드에 "abc"를 입력하면 응용 프로그램이 무엇을하기를 원합니까? 모든 사용자가 진행해야하는 순서대로 25 개의 화면이 모두 있습니까?

그렇지 않으면 모든 것을 텍스트 필드로 작성하면 끝납니다! 리드 풍선처럼 진행 될까요?