用户需求

ISDM定义 ISDM不仅只是—种如何开发信息系统的方法／过程模型。ISDM是—套整体方法，包含： —个通过分析方法、工具和技术操作的分析框架。描述系统开发中分析问题与解决问题的行为特征。主要指，面向过程、面向数据、面向对象。 支持分析框架的过程模型(process-model , 指开发活动的次序和持续时间）。描述系统开发随时间变化而呈现的阶段特征和项目管理与组织上的特征。有些类似SDLC, 如，瀑布模型、原型法、螺旋模型、敏捷软件开发等。 从技术上来讲， mis开发是系统阶段特征和行为特征的结合。因此， ISDM可视为包含开发信息系统用到的所有方法、操作和过程的框架。 完整的ISDM包含SDLC与开发方法、开发技术、开发工具及环境三层。 • SDLC ：ISDM开发方法的过程模型可能混用多种SDLC 以适用不同项目需求。 • 开发方法：主要指面向过程、面向数据、面向对象。是—个通过分析方法、工具和开发技术操作的分析框架。 • 开发技术：中间件、可视化、软件复用等 • 开发环境和工具： CASE 、SDE 、SEE 、IPSE等 ISDM 中的这四项内容彼此相互联系、相互支持、相互制约。 • 开发环境／工具位于最底层，说明其他层面均需要开发环境／工具的支持 • 开发技术是组成开发方法的基本成分，例如，结构化开发方法是由结构化分析技术、结构化设计技术、结构化程序设计技术组成

需求：根据用户的需求，查找一个文件用户输入的内容并把它打印出来 def find(file,aim): with open(file,encoding='utf-8') as g: for i in g: if aim in i: yield i l = find('log','姐姐') for i in l: print(i.strip()) View Code 通过定义了一个生成器，在调用是传入传输，就可以实现这个需求。 来源： https://www.cnblogs.com/zly9527/p/11392074.html

需求分析二 1.1编制目的 希望通过此文档来初步介绍这一微信小程序，并借此使得用户能够更加了解其大概功能和使用方法。 1.2适用范围 此文档只适用于基于微信小程序的食堂订餐送餐等功能的介绍与使用。适用于使用本程序的食堂工作人员和点餐的学生等。 1.3前提与约束 这项软件开发的时长为一个月，无具体经费限制。要求是使用Java、软件工程及数据库访问技术等知识进行开发。 系统概述 2.1用户特点 此小程序的用户类型主要分为两类，主要是食堂工作人员和学生。面对学生大数量的点餐送餐，软件需要及时更新发布数据，对于数据的快速响应和准确性有很大的要求。 2.2运行环境 手机客户端（安卓、iOS都行），使用者通过微信进入小程序页面进行操作，需要用户开通地理位置的权限等。 2.3设计和执行约束 软件使用可以在微信小程序中找到并使用，且必须符合微信小程序使用的相关规定，必须配备身份认证系统等。 外部需求接口 3.1用户界面 用户进入需要登录并且进行身份认证，需要配备其他帮助选项或者错误信息显示等。 3.2软件接口 由微信小程序提供各种软件接口，如数据库、操作系统等应用程序编程接口。 3.3通信接口 与本程序所使用的的通信功能相关的如电子邮件、Web浏览器、网络通信标准或协议等。 功能需求 4.1用户分类 一类为食堂的工作人员

基于微信小程序的食堂订餐送餐系统的需求分析 文档说明 1.1编制目的 希望通过此文档来初步介绍这一微信小程序，并借此使得用户能够更加了解其大概功能和使用方法。 1.2适用范围 此文档只适用于基于微信小程序的食堂订餐送餐等功能的介绍与使用。 1.3前提与约束 我们假设使用我们这一产品的用户已经了解到现在线上点餐等基本功能。 系统概述 2.1用户特点 此小程序的用户类型主要分为两类，主要是食堂工作人员和学生。面对学生大数量的点餐送餐，软件需要及时更新发布数据，对于数据的快速响应和准确性有很大的要求。 2.2运行环境 手机客户端（安卓、 iOS都行），使用者的网络必须保持良好，需要用户开通地理位置的权限等。 2.3设计和执行约束 软件使用可以在微信小程序中找到并使用，且必须符合微信小程序使用的相关规定，必须配备身份认证系统等。 外部需求接口 3.1用户界面 用户进入需要登录并且进行身份认证，需要配备其他帮助选项或者错误信息显示等。 3.2软件接口 3.3通信接口 功能需求 用户分为两类，一类为食堂的工作人员，食堂需要在此小程序上登录注册账户并将其菜品样式价格等上传到网上并及时更新其状态；另外一类便是使用该小程序点餐的学生，学生同样也是可以使用学号登录线上点餐。 今天我们小组就“饱了么”小程序的需求分析做了一个大概的叙述和分析

以前有看过敏捷开发相关的内容，被说不懂敏捷开发被人带着做敏捷开发，到后来我自己结合瀑布流与敏捷开发建立出一套比较能提高项目效率的“伪敏捷”模式。 一、敏捷开发是什么 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。——来源百度百科 其实从上面的描述里面，敏捷开发的核心理念是“以用户需求进化”、“迭代、循序渐进”、“持续可用”，相比起瀑布式开发，敏捷开发更加强调团队合作、快速响应、持续产出。两种模式各有优缺，其实现在很少纯粹的敏捷，也很少纯粹的瀑布式开发，更多是将两者结合。 二、我的“伪敏捷开发” 纯粹的敏捷开发，是基于用户需求，然后团队分析团队建模，快速开发，快速上线。但是这种做法非常考验团队及对工作的把控，因为大部分公司一个产品都不是纯粹的产品，除了负责某个产品线外，还需要很大量的其他工作，而且团队素质能力也未必很高。所以纯粹的敏捷开发比较少见到。 大部分的公司团队都是用瀑布式，我做了一堆需求，然后批量一个团队开发，批量上线，每次上线都是生死大关一样，通宵是常态化的情况。我一开始也是这种做法，但是后来发现太累了，将需求拆解得更细

任高军 008 于谦　 015 2012/12/15 首次提交作业 2012/12/16 根据老师指出的缺陷和错误进行修改（添加相关链接地址，重新查找一遍学术搜索的移动端应用产品） 作业题目博文地址： http://www.cnblogs.com/xinz/archive/2012/03/26/2417699.html 第一部分 我们用IE9和Chrome浏览器对系统介绍中的每一个功能进行了测试，仅发现一个较为影响使用的功能缺陷。 以co-author graph为例（其他如co-auther path和citation graph等也有该问题），当作者较多并且合作关系复杂时，图片叠在一起，无法看到之间的关系，如下图： http://academic.research.microsoft.com/VisualExplorer#28553 很自然的，用户会希望将图放大，也确实，右下角有缩放功能，但是放大后： 要知道用户并不是希望看到更大的图片，所以这一缩放功能的开发者未能明确该功能设计的需求依据。 修改建议：图片大小保持不变，调整两作者之间的距离。其实该系统的call for paper模块就有类似的实现： http://academic.research.microsoft.com/CFP#latest=180 第二部分 通过对开发流程描述 http://www.cnblogs

一、瀑布模型 1.1 什么是瀑布模型 1970年温斯顿.罗伊斯提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型 瀑布模型将 软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动 ，并且规定了它们 自上而下、相互衔接 的固定次序，如同瀑布流水，逐级下落 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动 从本质来讲，它是一个软件开发架构 ，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生 循环反馈 ，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来 对于经常变化的项目而言，瀑布模型毫无价值 1.2 特点 1、阶段间具有顺序性和依赖性 该阶段具有两重含义 必须等前一阶段的工作完成后，才能开始后一阶段的工作 前一阶段的输出文档就是后一阶段的输入文档，因此只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果 2、推迟实现的观点 对于规模较大的软件项目来说，往往编码开始的越早，最终完成开发所需时间越长

最近在整理部门内部的培训材料，希望通过培训和在项目中的实践来提升整个团队的分析和设计能力，同时也是自己所了解的一点知识的总结。 谈到软件开发，一个项目的成败，关键因素是人的因素，人就是一切，或者说几乎是一切。对于项目的成功来所，项目人员的素质、人员的组织和管理是比其它工具或技术方法更重要。团队质量直接决定项目的成功和失败，团队的沟通能力，协作能力尤为重要，一个高效的团队一定是沟通能力很强的团队，我们所从事的软件项目，其实不是在研发新技术，而是利用别人的研究成果而已，只是成果的应用，说白了没有什么“纯”技术含量，这里纯加了引号，如今是个知识爆炸的时代，互联网高度发达，你需要什么信息，只要有时间，一般都能找到相关内容。所以说软件项目的开展，更侧重于社会性，而不是科学性。软件开发本身是一个复杂性活动，著名的“没有银弹”中介绍过，复杂性是软件开发的根本属性，短期内不会有任何的工具或方法会使软件生产率有数量级的提升。它是一个复杂的纯思维的活动，这个世界同时又成千上万个软件项目在开展，但是没有任何两个是完全一样的。相同的功能，可以有上百个实现，一个功能，可能用一个类实现，也可能5个、10个类，但是为什么是5个类，而不是3个，没有定型的优劣之分。只有掌握了合适的方法，总结前人的经验成果，研究较好的或经典设计，并在项目中实践应用，才能逐步提升自己的能力水平。 我们以往的项目中存在的问题

什么是功能，什么是软件，什么是产品，期初，我的理解产品和软件是一个东西，都由功能构成。经历一段时间工作和学习后，发现这个想法不对。 功能组合在一起是软件，软件本质是完成特定功能或流程的集合体，外形没有要求，注重功能实现，它可以简单，也可以复杂，可以个人开发，也可以公司，本质是某种需求的实现，不牵涉商业。 产品也是需求的集合体，它一般外形优美，功能庞大而复杂，以用户为导向，通过某种方式获得并留住用户，实现资本积累，主要公司提供。 软件以需求为导向，产品以营利和用户为导向，所以我认为软件和产品是两个东西。 程序员第一步，做的东西功能，完成能力积累，开始做软件，这是一次升级，从点连成线，再进一步是产品，根据人文环境，定义需求，制造的商品。 以上个人愚见。 来源： oschina 链接： https://my.oschina.net/wangzonghui/blog/3132707