精华内容
下载资源
问答
  • 分享一篇在公众号看到的关于从需求分析到原型文档的极佳文章,转自:龙港码头 前言: 此篇文章是关于墨刀 「解X」 设计比赛活动的需求分析。内容包括:需求、设计目标定义、设计方向、解决方案(头脑风暴)、以及...

    分享一篇在公众号看到的关于从需求分析到原型文档的极佳文章,转自:龙港码头

    前言:

    此篇文章是关于墨刀 「解X」 设计比赛活动的需求分析。内容包括:需求、设计目标定义、设计方向、解决方案(头脑风暴)、以及设计概念展示。

    活动地址 https://modao.cc/posts/10983

    Redesign 对象 「倍洽」

    倍洽,是一款企业即时通讯产品。除 IM 基础能力外,其核心功能是将包括邮件、项目管理工具,市场运营工具、开发工具的信息聚合到倍洽,实现在聊天窗口查收所有信息并完成响应。倍洽分为 PC 端和 APP 端,本期待解决难题是:倍洽 APP 端 IM 功能体验优化。

    倍洽产品定位
    1、产品特点(定位):
    面向工作场景的智能消息处理中心。

    面向科技IT产品开发团队 或 轻资产互联网、媒体团队。比较适合远程工作者

    2、用户画像
    主要年龄段:18-35

    主要行业:IT/互联网、教育培训、文化/娱乐/传媒、金融

    主要职业特征:中小型企业为主要用户群体;产品/研发/设计同学居多;

    一、 用户需求调研

    *根据题目给出、网络资料、个人体验、官方用户支持群聊天记录,及调查访谈朋友使用同类型产品(钉钉)后搜集的反馈。

    一般IM应用在 一般工作时,存在的问题。(这里并不针对倍洽一款产品)

    • 大量消息处在 异步与同步之间,频繁查看 会占用过多的专心工作时间。
    • 单条消息的信息密度过小,巨量消息处于同步与异步之间,注意力需要频繁投入,致使工作进程被打断,进而影响工作效率。
    • 与自己相关的消息难定位。
    • 待处理入口过多,造成选择困难。没有轻松的选择次序提示。
      在这里插入图片描述
    • 消息异步,沟通不畅。不知道对方是否已读、什么时候会回复。
    • 讨论不停,如同开会,但发言不受控制,交叉情况严重。
    • 大部分工作是在私下独自完成的,而不是讨论出来的。
    • 暂离聊天平台,没有明确给到其他人状态和紧急联系途径。
    • 因工作原因 一直在线,严重占用个人时间,模糊工作与生活。
    • 聊天消息,随时无法随时添加到个人任务 Inbox(设置待办或稍后阅读)
    • - 跨部门找人合作、不知道如何找到相关问题的负责人。

    *Slack 使用问题 延伸阅读:https://ux.useronboard.com/slack-i-m-breaking-up-with-you-54600ace03ea

    二、用户需求分析和问题定义:

    1、定义问题:

    • 工作时对 IM应用的需求
    • 非工作时间 对工作IM应用的需求

    需要处理的重要信息才通知我

    2、用户体验地图

    使用工具:storyboardthat&sketch

    模版地址:https://pan.baidu.com/s/1DREdJW1mobByDkbyjfOfow

    3、头脑风暴 框架

    三、解决方案洞察:

    1、头脑风暴:
    ?地址:https://realtimeboard.com/app/board/o9J_kyDSUOo=/



    使用工具:realtimeboard

    自定义的标签系统可以实现各类的信息分类,超越原文的限制,而单纯搜索关键词必须基于原文。此外,自定义的标签可以包含一定创造性,分类时主观成分越多,就越无法被关键词搜索替代。

    四、设计概念:

    1、功能架构调整

    原应用产品功能架构:

    原应用系统关于聊天消息的某些常用功能层级略深。

    优化后产品功能架构:

    主要将上面提到的需要优化的功能加进去了,同时提升了一些关于聊天消息相关功能 的信息层级。

    1、设计概念故事板:






    2、概念稿:

    墨刀查看详细介绍,地址:https://pro.modao.cc/app/tyoBM7BHapai7Xy2aZ9QrNu1TPpXRU2

    消息页面 与 群聊页面

    通知页面 与 1v1对话 页面

    关注的消息 与 订阅消息

    补充:

    很高兴能够获得主办方鼓励,最后的原型确实比较粗糙,主要头脑风暴涉及功能过多,没有做好筛选。参加比赛目的主要是作为一个练手项目,将自己之前在 知群设计课程中掌握的方法都应用上,实现一套工作流。

    以上方案只进行到概念 阶段,并未涉及到功能点的交互设计。

    从比赛角度看,这份方案实际上并没有很好地提出一个完整的方案。非常感谢主办方「倍洽」的鼓励奖 。后面我会继续填上原型中的部分功能原型 自己挖的坑。

    并尝试根据官方的反馈 调整后,继续分享一下 用户故事 => 功能流程设计 => 原型设计 的思考和经验,以及整个过程 中涉及到的方法和工具的简单介绍。

    如果你感兴趣的话可以关注公众号或 加我微信 sun584103329 交流,你可以在【查看原文】https://www.notion.so/yuspace/X-9571e7fb66354084b436412c1c8cedf0看到后续的内容更新 (公众号用不习惯,似情况更新…)

    展开全文
  • 评审需求文档原型

    千次阅读 2018-04-14 16:09:43
    1. 你们的项目组使用源代码管理工具了么? 应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。2. 你们的项目组使用缺陷管理系统了么? 应该用。ClearQuest太复杂,我的推荐是...
    1. 你们的项目组使用源代码管理工具了么?
      应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。

    2. 你们的项目组使用缺陷管理系统了么?
      应该用。ClearQuest太复杂,我的推荐是BugZilla。

    3. 你们的测试组还在用Word写测试用例么?
      不要用Word写测试用例(Test Case)。应该用一个专门的系统,可以是Test Manager,也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。

    4. 你们的项目组有没有建立一个门户网站?
      要有一个门户网站,用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现,15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。

    5. 你们的项目组用了你能买到最好的工具么?
      应该用尽量好的工具来工作。比如,应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费,所以说是“你能买到最好的”。

    6. 你们的程序员工作在安静的环境里么?
      需要安静环境。这点极端重要,而且要保证每个人的空间大于一定面积。

    7. 你们的员工每个人都有一部电话么?
      需要每人一部电话。而且电话最好是带留言功能的。当然,上这么一套带留言电话系统开销不小。不过至少每人一部电话要有,千万别搞得经常有人站起来喊:“某某某电话”。《人件》里面就强烈谴责这种做法。

    8. 你们每个人都知道出了问题应该找谁么?
     应该知道。任何一个Feature至少都应该有一个Owner,当然,Owner可以继续Dispatch给其他人。

    9. 你遇到过有人说“我以为…”么?
     要消灭“我以为”。Never assume anything。

    10. 你们的项目组中所有的人都坐在一起么?
      需要。我反对Virtual Team,也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起,好处多得不得了。

    11. 你们的进度表是否反映最新开发进展情况?
      应该反映。但是,应该用Baseline的方法来管理进度表:维护一份稳定的Schedule,再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。

    12. 你们的工作量是先由每个人自己估算的么?
      应该让每个人自己估算。要从下而上估算工作量,而不是从上往下分派。除非有其他原因,比如政治任务工期固定等。

    13. 你们的开发人员从项目一开始就加班么?
      不要这样。不要一开始就搞疲劳战。从项目一开始就加班,只能说明项目进度不合理。当然,一些对日软件外包必须天天加班,那属于剥削的范畴。

    14. 你们的项目计划中Buffer Time是加在每个小任务后面的么?
      不要。Buffer Time加在每个小任务后面,很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。

    15. 值得再多花一些时间,从95%做到100%好值得,非常值得。
      尤其当项目后期人困马乏的时候,要坚持。这会给产品带来质的区别。

    16. 登记新缺陷时,是否写清了重现步骤?
      要。这属于Dev和Test之间的沟通手段。面对面沟通需要,详细填写Repro Steps也需要。

    17. 写新代码前会把已知缺陷解决么?
      要。每个人的缺陷不能超过10个或15个,否则必须先解决老的bug才能继续写新代码。

    18. 你们对缺陷的轻重缓急有事先的约定么?
      必须有定义。Severity要分1、2、3,约定好:蓝屏和Data Lost算Sev 1,Function Error算Sev 2,界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。

    19. 你们对意见不一的缺陷有三国会议么?
       必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。

    20. 所有的缺陷都是由登记的人最后关闭的么?
      Bug应该由Opener关闭。Dev不能私自关闭Bug。

    21. 你们的程序员厌恶修改老的代码么?
      厌恶是正常的。解决方法是组织Code Review,单独留出时间来。XP也是一个方法。

    22. 你们项目组有Team Morale Activity么?
      每个月都要搞一次,吃饭、唱歌、Outing、打球、开卡丁车等等,一定要有。不要剩这些钱。

    23. 你们项目组有自己的Logo么?
      要有自己的Logo。至少应该有自己的Codename。

    24. 你们的员工有印有公司Logo的T-Shirt么?
      要有。能增强归属感。当然,T-Shirt要做的好看一些,最好用80支的棉来做。别没穿几次就破破烂烂的。

    25. 总经理至少每月参加次项目组会议要的。
      要让team member觉得高层关注这个项目。

    26. 你们是给每个Dev开一个分支么?
      反对。Branch的管理以及Merge的工作量太大,而且容易出错。

    27. 有人长期不Check-In代码么?
      不可以。对大部分项目来说,最多两三天就应该Check-In。

    28. 在Check-In代码时都填写注释了么?
      要写的,至少一两句话,比如“解决了Bug No.225”。如果往高处拔,这也算做“配置审计”的一部分。

    29. 有没有设定每天Check-In的最后期限?
      要的,要明确Check-In Deadline。否则会Build Break。

    30. 你们能把所有源码一下子编译成安装文件吗?
      要的。这是每日编译(Daily Build)的基础。而且必须要能够做成自动的。

    31. 你们的项目组做每日编译么?
    当然要做。有三样东西是软件项目/产品开发必备的:1. bug management; 2. source control; 3. daily build。

    32. 你们公司有没有积累一个项目风险列表?
      要。Risk Inventory。否则,下个项目开始的时候,又只能拍脑袋分析Risk了。

    33. 设计越简单越好越简单越好。
      设计时候多一句话,将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。

    34. 尽量利用现有的产品、技术、代码千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子,有这两个作为基础,可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML,而不是自己去Parse一个文本文件;尽量用RegExp,而不是自己从头操作字符串,等等等等。这就是“软件复用”的体现。

    35. 你们会隔一段时间就停下来夯实代码么?
      要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw,“夯”这个字念“hang”,第一声。

    36. 你们的项目组每个人都写Daily Report么?
      要写。五分钟就够了,写10句话左右,告诉自己小组的人今天我干了什么。一则为了沟通,二则鞭策自己(要是游手好闲一天,自己都会不好意思写的)。

    37. 你们的项目经理会发出Weekly Report么?
       要。也是为了沟通。内容包括目前进度,可能的风险,质量状况,各种工作的进展等。

    38. 你们项目组是否至少每周全体开会一次?
       要。一定要开会。程序员讨厌开会,但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。

    39. 你们项目组的会议、讨论都有记录么?
      会前发meeting request和agenda,会中有人负责主持和记录,会后有人负责发meeting minutes,这都是effective meeting的要点。而且,每个会议都要形成agreements和action items。

    40. 其他部门知道你们项目组在干什么么?
      要发一些Newsflash给整个大组织。Show your team’s value。否则,当你坐在电梯里面,其他部门的人问:“你们在干嘛”,你回答“ABC项目”的时候,别人全然不知,那种感觉不太好。

    41. 通过Email进行所有正式沟通
      Email的好处是免得抵赖。但也要避免矫枉过正,最好的方法是先用电话和当面说,然后Email来确认。

    42. 为项目组建立多个Mailing Group
      如果在AD+Exchange里面,就建Distribution List。比如,我会建ABC Project Core Team,ABC Project Dev Team,ABC Project All Testers,ABC Project Extended Team等等。这样发起Email来方便,而且能让该收到email的人都收到、不该收到不被骚扰。

    43. 每个人都知道哪里可以找到全部的文档么?
      应该每个人都知道。这叫做知识管理(Knowledge Management)。最方便的就是把文档放在一个集中的File Share,更好的方法是用Sharepoint。

    44. 你做决定、做变化时,告诉大家原因了么?
      要告诉大家原因。Empower team member的手段之一是提供足够的information,这是MSF一开篇的几个原则之一。的确如此,tell me why是人之常情,tell me why了才能有understanding。中国人做事喜欢搞限制,限制信息,似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力,不在于是不是能access information/data,而在于是不是掌握资源。

    45. Stay agile and expect change 要这样。
      需求一定会变的,已经写好的代码一定会被要求修改的。做好心理准备,对change不要抗拒,而是expect change。

    46. 你们有没有专职的软件测试人员?
      要有专职测试。如果人手不够,可以peer test,交换了测试。千万别自己测试自己的。

    47. 你们的测试有一份总的计划来规定做什么和怎么做么?
       这就是Test Plan。要不要做性能测试?要不要做Usability测试?什么时候开始测试性能?测试通过的标准是什么?用什么手段,自动的还是手动的?这些问题需要用Test Plan来回答。

    48. 你是先写Test Case然后再测试的么?
      应该如此。应该先设计再编程、先test case再测试。当然,事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发,我不喜欢,因为不习惯,太麻烦,至于别人推荐,那试试看也无妨。

    49. 你是否会为各种输入组合创建测试用例?
      不要,不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚,你是否有时间去运行那么多test case。

    50. 你们的程序员能看到测试用例么?
      要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的:提高质量。

    51. 你们是否随便抓一些人来做易用性测试?
      要这么做。自己看自己写的程序界面,怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了,不方便的永久了也就习惯了。

    52. 你对自动测试的期望正确么?
      别期望太高。依我看,除了性能测试以外,还是暂时先忘掉“自动测试”吧,忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说,只能“矫枉必须过正”了。

    53. 你们的性能测试是等所有功能都开发完才做的么?
      不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正,早死早升天。

    54. 你注意到测试中的杀虫剂效应了么?
      虫子有抗药性,Bug也有。发现的新Bug越来越少是正常的。这时候,最好大家交换一下测试的area,或者用用看其他工具和手法,就又会发现一些新bug了。

    55. 你们项目组中有人能说出产品的当前整体质量情况么?
      要有。当老板问起这个产品目前质量如何,Test Lead/Manager应该负责回答。

    56. 你们有单元测试么?
      单元测试要有的。不过没有单元测试也不是不可以,我做过没有单元测试的项目,也做成功了——可能是侥幸,可能是大家都是熟手的关系。还是那句话,软件工程是非常实践、非常工程、非常灵活的一套方法,某些方法在某些情况下会比另一些方法好,反之亦然。

    57. 你们的程序员是写完代码就扔过墙的么?
      大忌。写好一块程序以后,即便不做单元测试,也应该自己先跑一跑。虽然有了专门的测试人员,做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法,程序太烂的话,测试有权踢回去。

    58. 你们的程序中所有的函数都有输入检查么?
      不要。虽然说做输入检查是write secure code的要点,但不要做太多的输入检查,有些内部函数之间的参数传递就不必检查输入了,省点功夫。同样的道理,未必要给所有的函数都写注释。写一部分主要的就够了。

    59. 产品有统一的错误处理机制和报错界面么?
      要有。最好能有统一的error message,然后每个error message都带一个error number。这样,用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因,就像SQL Server的错误那样。同样,ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。

    60. 你们有统一的代码书写规范么?
      要有。Code Convention很多,搞一份来发给大家就可以了。当然,要是有FxCop这种工具来检查代码就更好了。

    61. 你们的每个人都了解项目的商业意义么?
      要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者,或者时不时的告诉team member,这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱,这样就有动力了。平凡的事情也是可以有个崇高的目标的。

    62. 产品各部分的界面和操作习惯一致么?
      要这样。要让用户觉得整个程序好像是一个人写出来的那样。

    63. 有可以作为宣传亮点的Cool Feature么?
      要。这是增强团队凝聚力、信心的。而且,“一俊遮百丑”,有亮点就可以掩盖一些问题。这样,对于客户来说,会感觉产品从质量角度来说还是acceptable的。或者说,cool feature或者说亮点可以作为质量问题的一个事后弥补措施。

    64. 尽可能缩短产品的启动时间要这样。
       软件启动时间(Start-Up time)是客户对性能好坏的第一印象。

    65. 不要过于注重内在品质而忽视了第一眼的外在印象程序员容易犯这个错误:太看重性能、稳定性、存储效率,但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾,协调这些是PM的工作。

    66. 你们根据详细产品功能说明书做开发么?
      要这样。要有设计才能开发,这是必须的。设计文档,应该说清楚这个产品会怎么运行,应该采取一些讲故事的方法。设计的时候千万别钻细节,别钻到数据库、代码等具体实现里面去,那些是后面的事情,一步步来不能着急。

    67. 开始开发和测试之前每个人都仔细审阅功能设计么?
      要做。Function Spec review是用来统一思想的。而且,review过以后形成了一致意见,将来再也没有人可以说“你看,当初我就是反对这么设计的,现在吃苦头了吧”

    68. 所有人都始终想着The Whole Image么?
      要这样。项目里面每个人虽然都只是在制造一片叶子,但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领,反对过分的把软件制造看成流水线、车间。参见第61条。

    69. Dev工作的划分是单纯纵向或横向的么?
      不能单纯的根据功能模块分,或者单纯根据表现层、中间层、数据库层分。我推荐这么做:首先根据功能模块分,然后每个“层”都有一个Owner来Review所有人的设计和代码,保证consistency。

    70. 你们的程序员写程序设计说明文档么?
      要。不过我听说微软的程序员1999年以前也不写。所以说,写不写也不是绝对的,偷懒有时候也是可以的。参见第56条。

    71. 你在招人面试时让他写一段程序么?
      要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等,既不偏向过于考算法,也不偏向过于考特定的API。

    72. 你们有没有技术交流讲座?
      要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得,这笔花钱送到外面去培训划算。

    73. 你们的程序员都能专注于一件事情么?
      要让程序员专注一件事。例如说,一个部门有两个项目和10个人,一种方法是让10个人同时参加两个项目,每个项目上每个人都花50%时间;另一种方法是5个人去项目A,5个人去项目B,每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂,但很多领导实践起来就把属下当成可以任意拆分的资源了。

    74. 你们的程序员会夸大完成某项工作所需要的时间么?
      会的,这是常见的,尤其会在项目后期夸大做某个change所需要的时间,以次来抵制change。解决的方法是坐下来慢慢磨,磨掉程序员的逆反心理,一起分析,并把估算时间的颗粒度变小。

    75. 尽量不要用Virtual Heads 最好不要用Virtual Heads。
      Virtual heads意味着resource is not secure,shared resource会降低resource的工作效率,容易增加出错的机会,会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人,要强过两个只能投入50%时间和精力的人。我是吃过亏的:7个part time的tester,发现的Bug和干的活,加起来还不如两个full-time的。参见第73条。73条是针对程序员的,75条是针对Resource Manager的。
    展开全文
  • 原型设计工具

    2018-09-27 17:33:16
    Axure RP是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。作为专业的原型设计工具,它能快速、高效的创建原型,...
  • 工具网址:https://rm2pt.mydreamy.net/ 写在前面:用到这个东西呢是老师布置...不过话说回来,通过需求模型能直接生成原型代码,这个工具还是很有意义的。虽然有一些逻辑错误,以及一些部分与我们课程所学有出入.....

    工具网址:https://rm2pt.mydreamy.net/

    写在前面:用到这个东西呢是老师布置的作业,在会议上看到的工具,就让我们直接去用。这东西真他妈神了,除了两个介绍视频,连他妈说明文档都没有,我佛了。作者的github这两天被我们疯狂骚扰,dbqdbqdbq。不过话说回来,通过需求模型能直接生成原型代码,这个工具还是很有意义的。虽然有一些逻辑错误,以及一些部分与我们课程所学有出入...

    废话不多讲,开始介绍。这东西其实是基于eclipse来写的,整个工具界面以及项目布局都是一样的,包括生成的代码也是java。

    工具就长的这个样子。基本的项目导入和运行我就不说了啊,官方网站里都有。那我们来看一下需求模型这一块。这个东西写好代码呢可以直接生成需求模型的图,之后对图进行改动也会自动在代码里改动。那么我们对照代码(remodel文件)和图片来看一下需求模型。对照的这个例子是官方的ATM系统例子。

    首先是概念类图,也就是我们常说的领域模型。

    对应代码里面是每个实体,实体里面定义了属性、约束以及与其他实体的联系。

    本人比较懒,就不把全部实体的代码贴上来了,各位可以对照图片体会一下。

    然后是用例图。这个对照代码,还是挺好观察的。

    顺便说一句,图片自己修改,可以通过旁边的素材板。

    下面看看顺序图。这个代码,他妈的我都不想说话...

    这根本不是在写代码,这是在写诗。

    那么这个工具的需求模型有一个独特的地方,叫做服务图,服务图会对操作进行定义。

    可以看到,每个服务定义了操作和临时属性。

    那么还有操作契约,没有生成可视化效果,但是在代码中有所体现。它直接关系到原型生成后的运行逻辑。

    可以看到代码中,definition定义了需要进行操作的实体,precondition和postcondition应该就不用我多解释了。

    最后原型运行出来就是这个样子(原型的运行方法也在官方网站中)

    接下来我自己尝试写了一下12306的需求模型,不过生成原型之后运行不正确(谁叫这玩意连说明文档都咩有!)。下面说一下我踩到的坑。

    1、这个东西你要是想自己在本地创建一个项目的话多半是跑不通(也可能是我创建项目的姿势不对)。因为在每个跑的通的样例中都有一个MainTest.java文件

    就是这货。然而在编译remodel文件生成代码的时候不会生成这玩意...

    2、自己写完remodel文件之后,想看到图还是挺麻烦的一个过程...

    需要在remodel所在的文件夹中新建一个arid文件(New->Other)

    之后选这个representations file

    选中第二项,next

    选到对应的remodel文件,finish,完事你就能看图了。

    3、这个工具中,编写代码的时候,就算是不同用例,方法也不能重名,否则就会报错。

    4、实体中的属性开头必须是大写字母,否则也会报错

    5、未完待续,因为我自己的例子还没跑通......

    总的来说,这个工具的出发点是好的,但是充斥着太多小问题,而且没!有!说!明!文!档!(怨念)后面我也不知道该说什么了,给大家拜个早年吧。反正一段时间之内我是不会碰这玩意了...

     

    展开全文
  • Axure8 原型工具

    2019-02-19 11:09:31
    Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • 原型工具AxureRP8

    2018-03-30 15:49:41
    AxureRP原型画图工具,用于界面网页设计,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。作为专业的原型设计工具,...
  • Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • 本期生态伙伴「xiaopiu原型」作为首批入驻飞书的专业设计工具,与飞书深度集成。结合飞书,将产品设计环节无缝嵌入用户整体的工作信息流,让产品方案的交付和沟通更加自然和高效,为企业提供一站式产品原型设计解决...

    本期生态伙伴「xiaopiu原型」作为首批入驻飞书的专业设计工具,与飞书深度集成。结合飞书,将产品设计环节无缝嵌入用户整体的工作信息流,让产品方案的交付和沟通更加自然和高效,为企业提供一站式产品原型设计解决方案。

    • 产品原型设计需求标准难统一?
    • 跨团队多人协作编辑费时费力?
    • 产品原型交付不断延期?

    ……

    飞书+「xiaopiu」原型

    从原型到文档一站搞定

    当企业内部运行通畅时,企业才能够将更多的精力专注在自己的业务目标上,在有意义有价值的事上全力以赴,完成自己的使命。未来企业的发展,除了自上而下的流程管控之外,更需要自下而上的效率提升,从根本上实现降本增效的目标。

    飞书团队与xiaopiu团队在合作中产生共鸣、碰撞出新的想法,通过提升每位员工的效率,来帮助企业实现高效的沟通、流畅的协作和敏捷的管理。快来飞书「应用目录」获取「xiaopiu」应用,畅享受更优质的产品原型设计与协作体验!

    👉欢迎下载飞书,立即免费体验>

    👉了解更多产品信息,请访问飞书官网>

    展开全文
  • UE原型设计工具

    2014-07-26 22:31:27
    Axure是Windows上最出色的原型设计软件,亦是web产品前期设计的首选,原因是:够简单、上手快,能帮助网站需求设计者,快捷而简便的创建 基于目录组织的原型文档、功能说明、交互界面以及带注释的wireframe网页,并...
  • Axure RP是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。作为专业的原型设计工具,它能快速、高效的创建原型,...
  • 原型设计工具Axure

    2017-06-16 15:34:49
      Axure RP是一个专业的快速原型设计工具,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。 1.2、Axure使用...
  • Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • 软件需求文档

    2012-04-05 12:26:44
    本项目为 Phone Me 联系人管理软件。在基本的设计实现基础上, 将丌断对已有的设计进行进一步...第 3 阶 段在设计文档需求分析的指导下,完成 Phone Me 原型系统的开发, 幵完成整个开发流程的测试报告(第 4 阶段)。
  • Axure RP一个专业的快速原型设计工具

    千次阅读 2014-10-25 22:25:46
    Axure RP--是一个非常专业的快速原型设计的一个工具,客户提出需求,然后根据需求定义和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。Axure RP--作为专门的 原型...
  • Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • 快速原型设计工具 Axure RP 8安装记录

    千次阅读 2016-06-01 21:36:37
    Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • 画手机原型工具推荐

    千次阅读 2017-04-10 15:02:01
    是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。作为专业的原型设计工具,它能快速、高效的创建原型,同时支持...
  • Axure RP 原型设计工具

    2014-02-26 17:30:55
    Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • 是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。作为专业的原型设计工具,它能快速、高效的创建原型,同时支持...
  • Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • 专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。作为专业的原型设计工具,它能快速、高效的创建原型,同时支持多人协作...
  • axurerp(原型工具).rar

    2019-07-02 12:07:32
    Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • 产品经理必备的原型设计工具汇总

    万次阅读 2017-01-03 08:59:53
    Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 568
精华内容 227
关键字:

原型需求文档工具