一个产品新人问我需求分析的工作方式，作为一名IT从业人员，“需求分析”我倒是经常听说，不过说到需求分析的方式，一时却几无头绪。隐约记得软件工程教科书上讲到需求分析是软件生命周期的第一个阶段，但从业数载，未见将需求分析按照教条方式进行的。既然被问起，只好将平日一些需求方面的工作做一番总结，一则解答新人的问题，二则梳理一下日常工作于已不无裨益。 ————————————分隔线以下是聊天内容———————————— he: 头儿让我负责咱们网页产品的需求分析，她说你是咱们这边负责技术类的需求分析的，所以我想问问你那边关于需求分析的主要工作方式，看咱们有没有交叉点 he: 工作方式还有主要的需求分析点 me: 这个，等我想想梳理一下，再和你沟通吧 he: 好的 me: … me: 我这边收到的需求主要来源于产品，技术需求分析，其实就是把产品需求转化成能够由程序实现的技术方案。需求分析并没有固定的套路（特别是对于我们这样的创业型团队），通常是根据自己的经验积累、思维分析，把不确定的、模糊的需求明晰化，转化成可执行的方案的过程，说下我个人的一点体会：主要是需求的收集、处理和验收。 需求收集：一般产品会把需求（方案、策略）通过邮件发过来，小的需求也可能通过口头或RTX说明，当然还有禅道，现在几乎没怎么用了。所以我会把邮件、RTX消息、口头交流得到一些需求信息收集并记录下来，视情况而做处理。 需求处理：这是根据经验通过分析，把需求映射为技术实现方案的过程。需求中可能带有不确定性和尚不清楚的地方，我会找产品相关人进行沟通确认，要实现某个需求可能存在某些技术难点，要及早识别并进行技术评估和权衡。这一步是真正需要进行分析的，难以言说，很大程度上是通过你的经验和思维来进行，需要平时多多总结、积累经验。 ——————————————————————————————————– 经过这一步把需求转化成可实现的技术方案，我们就可以进行技术开发了。当然在开发过程中也可能会遇到一些未曾预见的问题，或者产品方面可能提出某些需求变更，所以平时工作中，技术和产品经常会就一些问题反复确认，某些需求会经过多次迭代。 ——————————————————————————————————– 需求验收：需求转化成技术方案，开发完成之后，我们会提交给产品相关人测试，发上线/测试申请，通常需求提出人会进行测试，对实现的功能进行验收，测试通过后上线。 产品需求分析，我想也应该包含需求收集、需求转化等。你那边的需求收集可能会从用户反馈、搜索日志、其它部门（如市场营销部门、与垂直频道合作）等渠道，得到需求。经过产品评估分析，将其转化成网页产品的功能特性。这就变成了技术需求，到了我这边，呵呵，我们可以多交流。当然，最主要还是要和你们产品组同事多沟通，积累经验。 上面只是我想到一些东西，所谓“法无定法，式无常式”，前面说了，需求分析没有固定的套路，我也不是专职做需求分析的，只是实际承担一些职责。大体上需要平时多多总结思考，在工作中积累经验，经验丰富了，自然可以游刃有余 ^_^ he: …
正在浏览 开发 里的文章
正则表达式的先行断言和后行断言一共有4种形式： (?=pattern) 零宽正向先行断言(zero-width positive lookahead assertion) (?!pattern) 零宽负向先行断言(zero-width negative lookahead assertion) (?<=pattern) 零宽正向后行断言(zero-width positive lookbehind assertion) (?<!pattern) 零宽负向后行断言(zero-width negative lookbehind assertion) 这里面的pattern是一个正则表达式。 如同^代表开头，$代表结尾，\b代表单词边界一样，先行断言和后行断言也有类似的作用，它们只匹配某些位置，在匹配过程中，不占用字符，所以被称为“零宽”。所谓位置，是指字符串中(每行)第一个字符的左边、最后一个字符的右边以及相邻字符的中间（假设文字方向是头左尾右）。 下面分别举例来说明这4种断言的含义。 (?=pattern) 正向先行断言 代表字符串中的一个位置，紧接该位置之后的字符序列能够匹配pattern。 例如对”a regular expression”这个字符串，要想匹配regular中的re，但不能匹配expression中的re，可以用”re(?=gular)”，该表达式限定了re右边的位置，这个位置之后是gular，但并不消耗gular这些字符，将表达式改为”re(?=gular).”，将会匹配reg，元字符.匹配了g，括号这一砣匹配了e和g之间的位置。 (?!pattern) 负向先行断言 代表字符串中的一个位置，紧接该位置之后的字符序列不能匹配pattern。 例如对”regex represents regular expression”这个字符串，要想匹配除regex和regular之外的re，可以用”re(?!g)”，该表达式限定了re右边的位置，这个位置后面不是字符g。负向和正向的区别，就在于该位置之后的字符能否匹配括号中的表达式。 (?<=pattern) 正向后行断言 代表字符串中的一个位置，紧接该位置之前的字符序列能够匹配pattern。 例如对”regex represents regular expression”这个字符串，有4个单词，要想匹配单词内部的re，但不匹配单词开头的re，可以用”(?<=\w)re”，单词内部的re，在re前面应该是一个单词字符。之所以叫后行断言，是因为正则表达式引擎在匹配字符串和表达式时，是从前向后逐个扫描字符串中的字符，并判断是否与表达式符合，当在表达式中遇到该断言时，正则表达式引擎需要往字符串前端检测已扫描过的字符，相对于扫描方向是向后的。 (?<!pattern) 负向后行断言 代表字符串中的一个位置，紧接该位置之前的字符序列不能匹配pattern。 例如对”regex represents regular expression”这个字符串，要想匹配单词开头的re，可以用”(?<!\w)re”。单词开头的re，在本例中，也就是指不在单词内部的re，即re前面不是单词字符。当然也可以用”\bre”来匹配。 对于这4个断言的理解，可以从两个方面入手： 1.关于先行(lookahead)和后行(lookbehind)：正则表达式引擎在执行字符串和表达式匹配时，会从头到尾（从前到后）连续扫描字符串中的字符，设想有一个扫描指针指向字符边界处并随匹配过程移动。先行断言，是当扫描指针位于某处时，引擎会尝试匹配指针还未扫过的字符，先于指针到达该字符，故称为先行。后行断言，引擎会尝试匹配指针已扫过的字符，后于指针到达该字符，故称为后行。 2.关于正向(positive)和负向(negative)：正向就表示匹配括号中的表达式，负向表示不匹配。 对这4个断言形式的记忆： [...]
很多桌面应用程序都具有多标签页功能，以便同时进行多个会话或处理多个任务，这包括所有主流的浏览器，流行的编辑器和开发环境等。在gnome-terminal中，可以通过Ctrl-Shift-T打开多个标签页，要在多个标签页间切换，可以使用Ctrl-PageUP/PageDown切换到上一个/下一个标签。由于习惯了在Firefox和eclipse中使用Ctrl-Tab组合键切换标签，对gnome-terminal这种需要左右手配合的切换方式稍感不便，尝试在它的Keyboard Shortcuts中更改下/上一个标签页的快捷键，惊奇地发现根本无法设置Ctrl-Tab组合键。google了一把，发现有同样遭遇的人还真不少，不过很遗憾，这个问题却没有合适的解决方法。 有个哥们试图hack，没有成功。早在2003年这个问题就被报告给了GNOME，而且不断有人旧事重提，可见这个问题是多么普遍，官方的回答是 Tab键是GTK的保留键，基于GTK的应用程序不能使用它作为快捷键。这不是BUG。 这个回答貌似不能令人满意。 根据gnome-terminal开发者的说法： Tab, Shift-Tab, Ctrl-Tab and Shift-Control-Tab are reserved in all gtk+ applications, for focus movement 但是有人指出，同样基于GTK+的Pidgin能够使用Ctrl-Tab切换标签，并且翻出了一段Pidgin的源码。 GNOME开发者解释Pidgin并不是GNOME程序，他们与GNOME不一致。并进一步说明在GNOME项目所有这样的问题都未被处理。 原来这个问题不是一天两天了，作为一个用户，我想狂骂gnome-terminal的开发团队。从2003年至今，陆续有人提出这个Bug（或者说需求），但至今都没有得到解决。站在开发者的角度，我也能够理解他们的处境，毕竟这个问题的源头看似在GTK，要解决还得从GTK入手。也许并非gnome-terminal团队无力搞定或不想解决这个问题，在GNOME大家庭里面，可能很多应用程序都依赖GTK，与GTK和GNOME保持一致性或许比较重要，如果要解决这个问题，恐怕需要协调多个团队。作为开发者，也许他们面临很多比这更加严重的Bug，这仅仅是部分用户使用习惯的问题，能不做则不做，这种权衡似乎也是人之常情。无论如何，既然有这么多用户需要，还是希望在不久之后，gnome-terminal团队能够注意并解决这个问题，以方便用户定制自己喜欢的快捷键。
订阅
更多阅读器 >>
最新评论