Flow vs agile

Old topic: Process vs agility.

The company has certain requirements on the project process and must produce the required flow documents. Although it does not force the output of the previous flow document to be the next flow document, parallel processing is allowed. However, there are still some dependencies.

One problem currently encountered is that the flow must generate the software develop plan before it can go to the development stage. However, the company and its users bite very tight during work hours. It's really embarrassing. In fact, according to process control, it is really necessary to plan more accurately to start development. However, from the agile point of view, the sooner the project is started, the better, not because the plan is more accurate, but the plan time is changing. Agility emphasizes output and value, and makes available "things" for users as soon as possible. Currently, you can only evaluate and communicate with users to facilitate early entry into iteration.

For the first time, contact the company's product external special documentation. It feels a bit like the user story in agility, but it is more documented and standardized than the user story. However, I think it can all be understood as the user requirement. Here I will do a review. In the early stage, I did not communicate well with the customer when I did the PES document, but I wrote PES based on my own understanding. This is very bad. In the future, I will communicate with the customer to better determine what the user needs are. At present, I am trying to use the user story method to communicate with the user to understand the requirements, and then gradually add it to PES.

Note that business analysis is not much done in the early stage of the project, so it is necessary to add the business objectives here, and then the important business processes. Through business processes, we can understand user scenarios and user stories to better guide users to explore valuable story.

 

Here we introduce a concept: three layers of software requirements

1. Business Needs

Describes the high-level objectives of an organization or a customer. Generally, the problem definition itself is a business requirement. Business needs are system goals. They must be business-oriented, measurable, reasonable, and feasible. Such requirements usually come from high-level personnel, such as project investors, customers who purchase products, managers of actual users, marketing departments, or product planning departments. The business requirements generally describe why to develop a system (why) And what goals the organization wants to achieve. Generally, vision and scope documents are used to record business requirements. This document is also called a project profile or market requirement document. The organization vision is an organization's expectation for the goals to be achieved by the software system to be used. For example, "We hope that the company's customer satisfaction will reach more than 80% after the implementation of CRM" is an organizational vision. These high-level requirements are few (2-5 ).

2. User Requirements

User requirements refer to the tasks that a user must complete and how to fulfill the requirements when using a product. Generally, user interviews and surveys are conducted based on the problem definition to sort out user scenarios, this allows you to establish user-defined requirements. User requirements must reflect the business value that the software system will bring to the user, or the tasks that the user requires the system to complete. That is to say, the user requirements describe what the user can do with the system (What). The requirements at this level are very important. Use Cases, user stories, and features are all effective ways to express user needs. The focus at the user requirement level is on how to collect user requirements, that is, to determine the role and role use cases. Requirement analysis is very difficult, because many requirements are implicit and difficult to obtain, it is more difficult to ensure that the demand is complete, and the demand is variable.

3. Functional Requirements

System analysts describe the software functions implemented by developers in the product. You can use these functions to complete tasks and meet business needs. Functional requirements are the subject of requirements. They describe how developers design specific solutions to achieve these needs (How), The number is usually an order of magnitude higher than the user demand. These requirements are documented in the Software Requirement Specification Description. SRS fully describes the expected features of the software system. SRS is generally used as a document. In fact, SRS can also be a database or spreadsheet containing requirement information, or stored in Business Requirement Management Engineers.
But for small projects, it may even be a stacked of index cards. SRS is required for development, testing, quality assurance, project management, and other related project functions.