• documentation
• product manual
• understand and grasp the overall function
• understand and master the detailed functional description
- Examples (Use Case)
- Functional Description
——————————————————————————————————
• Global Function
- Since then we have to express a more detailed description of each class of each sub-class features, so here it is imperative that can not go inside into subclasses
The overall thing is clear
• Despite a global function, but it can also be classified description, for example:
– UI
- interactive
- and many more...
• E.g:
- Unified user interaction Description:
- This client user trigger operation, the user interface should be loaded first, loading position while data is used in the interface mentioned Wheels
It illustrates user data.
- this time the client display, it is recommended to use user-friendly prompts, for example: 20 minutes ago, the day before, three days ago, more than seven days, the
Display specific time, such as: at 17:55 on March 30, more than a year, the show for 12 years at 17:55 on March 30
• Detailed description of the functional requirements
• overall explanation is completed, we will begin the various sectors demand a detailed description of the requirements
- according to the actual needs, you can be expressed in accordance with the order you get used to express the common order of presentation are:
• Follow the logic functions to express (more abstract, like R & D)
• According to the product structure to express (logical expression channels, pages, modules, elements, relatively more suitable product managers, product managers like)
- Which particular, look at the team and understanding of the requirements
• Example: logical product to express demand
• UML> use case documents> Case Diagram and state diagrams with
• UML debut (in fact, PRD document writing product manager involved to a very limited knowledge of UML)
- Chinese name: the Unified Modeling Language
- English name: Unified Modeling Language
- Definition: an object-oriented modeling language, it is the use of a unified, standardized labeling and custom implementations of object-oriented software systems and modeling
• UML diagram types common explanation
- use case diagram - the expression
- State diagram
- timing diagram
- Structural map
- Wait....
♦ What is the use case diagram?
• Examples
- Method is a description of embodiments with functional requirements of the system
• Use Case Diagram
- use case diagrams express the relationship between system participants and external systems, it is a schematic diagram of a participant with the composition of Example
- with the constituent elements of the embodiment of FIG.
• participants (who may be, or may be another system, it can be something else, is relative)
• Examples
• Association lines
• Box
Example:
• Use Case Description
Interface Element Description
• special comment: you can see this table, just a basic format, with cases concerning the industry does not become a constant and specialized in
We apply for something, everything in the default habits of your team and achieve your goals as the basis to write use cases
• The product's overall use case diagram
• function blocks Requirement 1
- functional blocks only function 11
• function blocks sub-function 1 1 1 illustrates the elements (described by)
• functional module element 1 functions described 1 2 (described use)
- sub-functions of the functional blocks 12
• functional blocks of elements of sub-function 2 1 1 illustrates (described use)
• function blocks sub-function element 1 2 2 described (described use)
• Function blocks 2 requirements (use case documents)
- functional blocks of the sub-function 2 1
• subfunction functional blocks 2 1 1 illustrates the elements (described by)
• 2 function module functions described elements 1, 1 (use described)
- functional blocks of the sub-function 2 1
• subfunction functional blocks 2 1 1 illustrates the elements (described by)
• 2 function module functions described elements 1, 1 (use described)
• MECE principle
- MECE, is Mutaually Exclusive Colletively Exhaustive, Chinese means "independent of each other, completely
Exhausted. "That is a major issue for, can do not overlap, do not miss the classification, and can thereby have
Efficient method to grasp the core of the problem, and to solve the problem.
• MECE just a way of thinking, when the PRD document written after the delivery of research and development, in fact, how much there is still not taken into account
位或者需求调整的情况，所以：
– 撰写PRD文档前一定要保证思考到位了，产品结构本身短期内不会有重大改动
– 需求分类与表述方式要参考NECE原则
– 这样即便是在交付后，出现调整或需要优化的地方，也不会出现重构的情况
• 重构需求，重新调整产品结构等，对已经处在开发过程中的团队来说是灾难性的
– 需求撰写，更多的是考验耐心，思路，经验，但产品架构的确定等更是考验一个产品经理
对产品的规划与把握能力
– 不要害怕，不要迷信
• 正确
– 确保文档中的表述与产品经理的思路是对应且正确的
• 无歧义
– 文档的表述方便阅读理解，不会产生歧义
• 完备
– MECE原则尽量保证对产品功能需求表述的系统完整
• 一致
– 文档中用词用语一致，对于同一事物的表述应该一样，避免混用同义词
• 具有优先级
– 产品的功能性需求是有先后主次的，对于一次性规划叫多功能的PRD ，应该注明功能性
需求的先后主次
• 可验证
– 对于功能的描述，是可以进行测试的，而不是不发测试，无法定性的东西。例如：效率高，
交互完美等词语，都是无法验证的
• 可修改
– PRD 文档利于后期的修改与升级
• 可追踪
– 每个功能性需求的来源应该是清楚明白的