First draw the key points:
Functional requirements are to turn specific user requirements into functional requirements of the software. For example, a customer wants to send a photo of a traffic accident to an insurance company through an app. This is user demand.
Then the functional requirement is to have the function of submitting accident photos and uploading on-site photos under this module.
Functional requirements are the result of demand analysis based on business needs and user needs. To meet business needs and user needs, a set of product feature lists are proposed. Functional requirements constitute a complete product abstract model, which is used by the product design team to design and product products. The basis for product development by the R&D team.
Requirements document 2.0: Three reasons to answer why I use excel to write requirements documents
Demonstration example of product requirement document template:
Nursing assistant app product requirement document
PAGES requirement list
product requirement document 丨 cloud home V1.0 version requirement document
Axure requirement document application: mobile phone traffic monitoring product function design
applet product requirement document prd (detailed case explanation)
Requirements, functions, interaction description
Many people always miss some details when writing function descriptions and interactive descriptions, and the logic is not rigorous. Explaining from the following dimensions will allow you to consider more comprehensively:
Fields, field descriptions, data sources,
pre-conditions, sorting mechanism, refresh mechanism
State flow (a page may have multiple states, need to be explained)
interactive operation (normal operation, abnormal operation)
Below, the author will take a page as an example:
Requirements, functions, interaction description
Features
Function refers to what it can do. To describe this part clearly, you also need to start from the three aspects of process, conditions, and elements. First of all, we must explain clearly how this function is implemented; secondly, we must describe clearly what are the restrictions in the process of implementing this function. For example, some video resources in the video website can only be viewed by member users; and finally, the detailed function is required. For example, if a user wants to delete a video uploaded by himself, he needs to add a confirmation message box, which buttons on the message box, what their functions are, and how to describe the text, all need to be explained.
How to write a requirement document that programmers love to read?
Requirements document writing and qualified delivery principles
The requirements document is actually very complete
This is the conversation between our software supervisor and me two days ago
目标：
一个月时间：最多一个半月
表格形式，所有功能列出来
使用者的程度了解功能是什么，做成什么样的，需求文档
开发者的角度，后台有数据接口，列清楚，变成设计文档
所有代码啃过来，之后怎么实现
问测试看一下所有bug，根据bug看怎么解决的，为什么会出现，不要求整理文档，
功能是什么。做成什么样。
功能应该实现的逻辑。
什么样这个功能算是ok了
要成为验收软件合格不合格的依据。
传到后台的数据
开发目标
7.17
At first glance, I was asked to write a requirements document, so Baidu found a lot of information
I wrote a login and showed it to the supervisor.
Guess what he would say.
He said I didn’t understand it,
but I also searched for professional ones. They taught me to write like that.
Black question mark face? ?
Explained to me again, from the user's point of view,
maybe I should write a requirement specification and talk about the product function from the customer's point of view
"Software Requirements Specification" is abbreviated as SRS. SRS is generally not made by the enterprise (delegator), but is obtained by the developer (delegator) based on the non-standard text or oral materials of the enterprise. SRS is not only to clarify requirements, but also to coordinate the first standard document for the unified goals of all parties (enterprise users, architects, developers, testers, and deployers). Once the project is relatively large and spans multiple organizations and multiple departments, this document is very important, saving a lot of communication troubles. https://www.jianshu.com/p/f9bcf52f4321
Theoretically speaking, Requirement Specification is divided into user requirement specification and product requirement specification. The user requirement specification is the system business requirement described from the user's perspective, and is used to sign and confirm the business requirement with the user; the product requirement specification is the system business requirement described from the developer's perspective, and guides the developer to complete the design and development Technical documentation.
Reference this
to write about
I asked ui about the requirements document written from the user's point of view. He told me how to write PRD for this product called prd document
? PRD document entry example-everyone is a product manager APP requirements document:
Who is our product requirements document written for? What do these people in different roles care about?
Actual users of the product: These are the users who practiced our product after it was launched. They focused on the prototype. Through the page prototype rather than the text description, let them perceive what this product is, know the various functional blocks, and the operation process, so that they can give us suggestions.
Interaction designer: Focus on page presentation and operation logic, let them understand the product function and logic, and optimize the product visually and interactively.
Front end: prototype page, function, interaction logic, operation logic, related to the final presentation effect of the product.
Back-end: business logic, technical logic, followed by prototype.
Test: page details, function details, and corresponding solutions in various situations.
Leader/colleagues in other departments: Product target background, product iteration history, product final effect. This kind of users are more concerned about why we make this product? What did we make of this product?
I find that sometimes I really spend a long time on understanding others and finding information, resulting in inefficiency
7.22 I
wrote the demand form for a week, and found that I still didn’t understand what I was going to write. I
posted a part of
it and I took this to ask the supervisor again.
Earlier, you said that the user understands what the function is, and what is it made?
Is it a scene description or a process?
He gave me an example, you go to buy glasses, what is this demand
I said: good-looking, thin
Then he said, do you have reading glasses to meet your needs?
Brother Song next to him said that the demand is the degree, and he suddenly realized
Is to describe the function point in one sentence
This time I really understand
Look at the difference between business requirements, user requirements, and functional requirements explained by others.
Know: What do business requirements, user requirements, and functional requirements mean? What's the difference?
User needs refer to the needs
of a certain type of user to use the software. For example, as a user, you use Taobao to find things, buy goods, and pay, what kind of needs do you have. As a seller, how do you use Taobao to collect, ship, and manage orders. This is one use case or user story. So when writing a user story, the first sentence at the beginning is As a xxx. This is all from a personal perspective.
Business requirements After
finishing the requirements from different perspectives, you need to look at the requirements from a higher level and a more holistic perspective. It is necessary to connect these requirements in series. Especially to sort out the overall process. From a personal point of view, the overall process cannot be seen. But to sort out the business, especially the data flow. It needs this sort of overall perspective. We know what the use case/user story is in. Especially sometimes, the needs of different users may conflict. Through this kind of overall business requirements combing, you can find potential conflicts and balance requirements.
Functional requirements
is to turn specific user requirements into functional requirements of the software. For example, a customer wants to send a photo of a traffic accident to an insurance company through an app. This is user demand. Then the functional requirement is to have the function of submitting accident photos and uploading on-site photos under this module. If it is more specific, it is the interface interaction diagram. Now when Internet companies mention product management and demand design, it is basically UX. Demand is too fragmented.
Author: a touch of sadness
link: https: //www.zhihu.com/question/24191618/answer/88163277
Business needs need to be understood from two levels. On the one hand, it is the concept of the 2B domain, which refers to the business departments (such as sales department, financial department, etc.) in the process of 2B software implementation based on various business transactions in the daily operation process. Solution requirements; on the other hand, it is an overview of high-level requirements based on the company’s business needs and core user needs from the perspective of the enterprise.
User needs User needs need to be understood from two levels. One is the essential needs of the user, which is what we usually call the user’s need, such as: the user is "hungry and wants to eat", to solve the problem of being hungry is the user The other is the solution that the user wants, that is, what we usually call the user’s want, such as: the user is "hungry and wants to eat", and eating is the user's need.
Functional requirements Functional requirements are the result of demand analysis based on business needs and user needs. A set of product feature lists are proposed to meet business needs and user needs. Functional requirements constitute a complete product abstract model, which is designed by the product design team. The basis for product development with the product development team.
Link: https://www.zhihu.com/question/24191618/answer/173896639
A business requirement can be understood as the idea is just an idea, but this idea is based on the company's internal,
for example, a reading software, the
boss proposes a reader to be able to turn pages when reading, this is a business requirement, the
product manager according to the boss proposed this The requirement is proposed to turn the page through voice control, which is a user requirement; the
product manager puts it forward and then hand it over to the development, and the development realizes the voice control page turning by calling the voice recognition system, which is the functional requirement; the
business requirement is the most straightforward, and the user needs to propose a plan. Functional requirements achieve results.
Author: Unlimited
link: https: //www.zhihu.com/question/24191618/answer/523691459
Learned a new term: demand boundary
PRD (Product Requirement Document), as the name suggests, is a document that elaborates product requirements, and its core is to clearly describe the requirements.
First of all, first understand the reader of PRD, the user.
The intended readers of PRD include: product, development, testing personnel and the corresponding responsible persons and user representatives. Product, development, and test personnel will learn about the background and detailed requirements of this demand, as well as the future optimization direction of each demand point or the value to users. The user representative can use the document to understand whether the content described in the PRD is the requirement in their own expectations, whether they meet and whether they have covered their expectations. Therefore, PRD is also an important basis for product managers to confirm development tasks with related roles. After all roles approve the content in the PRD, this PRD will serve as the basis for subsequent development, testing, and requirements verification.
Functional Requirements
Functional requirements are generally composed of functional details and main process descriptions. Function details are the description and planning of all product functions. Function details include the following:
Brief description: Introduce the purpose of this function, including its source or background, and what problems it can solve.
Scenario description, under which circumstances the product will be used by users, is the user scenario simulation. This is also a prerequisite for product managers to tell "good" stories.
Business rules: each product has corresponding business rules during development. These rules are clearly described so that developers and testers can intuitively understand the rules without ambiguity. Business rules must be complete, accurate, and easy to understand. If the description of business rules involves page interaction or page modification, it is recommended to give a sketch of the page or a screenshot of the page to illustrate the content to be modified on the diagram. In addition, it is also recommended to explain the content format, length, and correlation between the input box and the drop-down box on the page, and the conditions for when it is visible, invisible, grayed out or lit are given in the document. It is convenient for readers to understand business rules.
Interface prototype: As mentioned earlier, when it comes to page interaction, product managers need to design page prototypes. Prototyping usually requires product managers and UI designers to complete together. The recommended approach is that the product manager can design a page frame to explain clearly to the interaction designer the fields and features to be presented on the page and the scenes to be used on the page. After that, the interactive and visual designers complete the prototype design of the product.
User description: Make a description of the product user, which can be integrated into the brief description.
Precondition: the precondition for the realization of the requirement. For example, when uploading a photo, an image file needs to be stored.
Post-condition: the subsequent processing caused by the operation.
Main process: It makes sense to put the mainstream at the end. Combined with the above, make the main process description, and explain the direction of each functional process (this is very important).
I have seen many PRDs. The document has neither preconditions nor postconditions. It only explains the main process. However, when describing the main process, it does not describe the various trends of each functional process in the main process. Only A main trend, people feel that prd has become an operating manual. In fact, the introduction of branches is very important, and all kinds of questions raised in development and testing are related to the unclear definition of branches. A qualified PRD must not only describe the main process, but also elaborate on the various problems that arise in the branch process and give solutions. The characteristic of PRD must be a clear and comprehensive description of the requirements and the handling of various abnormal situations, rather than waiting for problems to be found in the development and testing stages before giving answers (although PRD cannot cover all possibilities 100%, but maximize thinking All business issues are principles that must be followed when compiling PRD). In addition, words such as "possible", "or" cannot appear in the methods given when describing functional requirements, and they must be clear and the only description. If there are other schemes, it is recommended to write "optional scheme". In the early stage of product construction, alternative schemes can provide more options for function realization. When the scheme is determined, you can indicate which scheme is used this time in the document .
Recommend a method: "use case". In an object-oriented software design model, a use case is an expounded content, and a use case is an explanation of a functional usage scenario. The use case introduces the pre-conditions and post-conditions of each function in an orderly manner, and the introduction of the main process, which helps the roles of development and testing to quickly understand product functions.
Product analysis report: Wanzi long text, dismantling the national application WeChat http://www.woshipm.com/evaluating/487857.html?utm_source=wechat_session&utm_medium=social&utm_oi=631585448561086464