Requirements documents, perhaps called solution documents are more appropriate.
Baidu casually searched "requirements documents", and there were about hundreds of thousands of results. Presumably we have all seen many such articles and downloaded many templates. In many cases, I still don't know the point, and I have a headache when I think of writing documents.
This article does not focus on what it is written, and then gives you a template, and it will not talk about the structure of the document.
Clear thinking is the only way to be efficient. This article focuses on the thinking process behind the writing. Now, let me share some of my thoughts.
introduction
Before talking about requirements documents, let's first understand the word "requirements". In many scenarios, we will use this term. Adjust the font color, it is also called demand by the designer, and the word demand feels a bit generalized.
When the product manager is doing demand analysis. The definition of this requirement refers to: who wants to do what under what circumstances, to achieve what results? Simply put, what does a character want or accomplish? Demand is the desire of the demander, and it is only related to the demander itself without a solution. It is the job of the product manager to propose a solution.
If someone says, I want to add a button, the correct way for the product manager is to figure out what the user’s starting point is? Why add? Is there a better solution? Instead of adding the button right away.
In traditional software requirements analysis theory, requirements can be divided into three levels:
Business requirements indicate the high-level goals of an organization or customer. Business needs usually come from project investors, customers who purchase products, actual user managers, marketing departments or product planning departments. Business requirements describe why the organization wants to develop a system, that is, what the organization hopes to achieve. Use a vision and scope document to record business requirements. This document is sometimes referred to as a project charter or market requirement document.
User requirements describe the goals of users, or tasks that users require that the system must be able to complete. Use cases, scenario descriptions, and event-response tables are all effective ways to express user needs. In other words, user requirements describe what users can do with the system.
Functional requirements specify the software functions that developers must implement in the product, and users use these functions to complete tasks and meet business needs. Functional requirements are sometimes called behavīoral requirements because it is customary to describe them as "should": "The system should send an email to notify the user that the reservation has been accepted." The functional requirement description is what the developer needs to achieve.
We are doing needs analysis, and we are also proceeding in accordance with this idea.
The first step, what does the company want to do?
Defining the problem correctly is half of successfully solving the problem.
At the macro level, you need to have a good understanding of the strengths and weaknesses of the organization; you need to be familiar with the composition and characteristics of users; and you need to be sure of market trends.
Under the above background conditions, providing a solution is actually like creating a miniature ecology under the big ecology.
Suppose we are operating an orchard and the goal is to grow delicious fruits.
Deconstruct this small ecology first. What are the elements? For example, fruit trees are needed, fertile soil is needed, someone needs to take care of them, and so on.
Furthermore, which elements of the ecology are variables? What variables can we adjust?
What are some essential laws followed in this process? For example, photosynthesis, such as the relationship between temperature changes and sweetness, and so on.
Finally, what indicators are needed to evaluate the operating status of this orchard?
In fact, some of the above are like business requirements analysis documents, looking at the problem from a macro perspective, and finding ways to build an ecosystem that can function well.
After the above is completed, we will zoom in on the perspective and put this small ecology into the entire large ecology to examine: What impact will it have on the entire original system? What else did you not think of?
The second step, what can each role do?
Next we enter the user demand analysis.
In short, put yourself into each specific role in this ecology and think about what needs to be done. Note that this role does not necessarily refer to a person, but can also refer to a system. From entering this ecology to leaving this ecology, what does this role have to accomplish?
After finishing this step, output the use case diagram and a detailed description of each use case.
If necessary, use cases can be classified according to value orientation, such as efficiency and benefit. Use the KANO model to analyze it again, so that you will basically have a thorough understanding of the requirements.
Use cases describe the process and results of interaction with the system from the perspective of using roles, focusing on the level that users can perceive.
What is the measure of the completion of each use case? You have to think clearly, because we are designing for a group of users.
In the third step, how does the user complete the process?
If you know what you can do, then come down and deconstruct everything you need to do. At this stage, just output the flowchart.
The flow chart is centered on the process, with a global perspective, focusing on how things are done.
There may be many roles involved in one thing, and they can be completed together. In order to obtain a result for each flow chart, each branch must be considered, that is, it must be a closed loop.
After sorting out the use cases and flowcharts. It is recommended that you list the data entities involved in each use case. What is the state transition of the data? This is also very important, usually the output state transition diagram.
The fourth step, what is the user's page interaction like?
Here I say a point:
use case is a description of user needs, flowcharts serve the use cases, and prototypes serve the process.
Writing a document is a process from abstract to concrete. The work before the prototype is the abstract part, which can exist without a specific implementation method and page.
Before drawing, some abstract things have to be done.
Think about the user contacts first. Do you want to be an APP yourself, or do you want to be an official account? Or a small program? If it is a formed product, there is basically nothing to think about.
Then make a page structure diagram, which is equivalent to an article directory. After sorting out, it will be clear which pages each module needs. Each page can basically correspond to the nodes of the flowchart, and you can check yourself in this way.
To make a page, you must also have a big picture. What role does the page play in the overall process? For example, for product details, this page is responsible for sales conversion. What information does the user care about at this step? What is his decision-making basis? All of these require a very subtle understanding of users in order to improve conversions on the basis of meeting user needs.
If it is necessary to explain the data display rules or interactive effect description on each page, directly mark the description on the page. For example, does the time display year, month, day or X days ago? The display-related rules of the page should not be mixed with the previous user flow chart. The page only focuses on the microscopic presentation.
Note that each page must correspond to the data state transition diagram, and consider the presentation of each element in various states.
It is recommended to use Axure's motherboard to do the page. After all the pages are completed, they are matched with the relevant use case description and flowchart, tiled on one page, and interactive jump instructions are made.
At this point, the document is basically almost the same, and there may be other parts in the actual work, such as non-functional requirements, performance requirements, and so on.
to sum up
The requirements document is the description of the solution, and the thinking process is from the macro to the micro, from the abstract to the concrete, similar to the way of thinking in philosophical reductionism.
Before the abstract work is completed, don't do the concrete work of the page.
Explain again:
Use case is a description of user needs, flow chart serves for use case, and prototype serves for process.
My idea is to focus on the use case.
Hope the above is useful to everyone. In addition, it is recommended that you learn about UML, including some of its very useful diagrams, which is of great help to clarify your thinking.