Elaborate on sustainable demand analysis and Software Design

When discussing the functional requirements of content management, we often consider various scenarios of a specific function, such as functionality, ease of use, complex processing scenarios, and Exception Handling scenarios, these are undoubtedly very valuable. A system can do its best. From the customer's point of view, this is also the function.
At the same time, we also discussed a lot of software design content, taking into account a lot of flexibility and scalability content, while the design and functions are closely linked, the design usually affects the specific display of functions.
What are the actual difficulties we encounter? The two aspects we discussed above mainly involve two issues:
1) there are too many functions. Sometimes, the more you think about it, the more important you should choose the appropriate function set;
2) there is also the flexibility and scalability of the Design. A good design usually requires more implementation time, and the project time does not seem to be allowed.
Before explaining these two problems, I would like to explain a little bit about the classification of software quality.
I recently read a book (scrum and XP from the trenches). The quality of software is divided into internal quality and external quality ), external Quality refers to quality that can be seen from the customer's perspective, such as software functions, ease of use, performance, etc. Internal Quality refers to quality from the programmer's perspective, for example, code robustness, scalability, and maintainability. The internal quality of software with good external quality is not necessarily good; however, the external quality of software with poor internal quality is generally difficult. It is hard to imagine that a system with poor design and poor code quality can provide good functionality, performance, and ease of use. Internal Quality is like the cornerstone of external quality. the maintainability and scalability of Code directly affects the improvement and improvement of system functions.
External quality and internal quality are easier to address both functional and design issues.
Let's look back at the two problems we have encountered. The first is the function selection problem.
In our agile team's discussion, the more people talk about a user story, the more intense they will be. They have come up with many functional points, which brings a lot of trouble, for example, the scope of implementation seems to be too large, and the workload suddenly becomes very heavy. As there is a lot of pressure, then we sometimes can't help but follow the project time point, find some "Shortcuts", and then you may gradually lose or do less good functions, and even turn to the functions that meet the project's time points, although not as good as you think, at this time, everyone may feel a little lost.
What can we do? We can analyze the features we have sorted out a little and we will find that the situation may not be as bad as we think. I think there are four principles that can help us make choices:
<! -- [If! Supportlists] --> 1) <! -- [Endif] --> function priority
<! -- [If! Supportlists] --> 2) <! -- [Endif] --> 80/20 rule
<! -- [If! Supportlists] --> 3) <! -- [Endif] --> integrity
<! -- [If! Supportlists] --> 4) <! -- [Endif] --> sustainability
1) Priority
First, we can select function points by priority. This is obvious. Important functions must be done first. Secondary functions can be put first. In particular, the most basic functions, such as the functions required by the customer, cannot be used without this function. For example, for content management, if the content is created, modified, or deleted, none of these functions are available, then the system cannot run normally.
2) Rule 80/20
The 80/20 rule is to first select the features most needed for daily use by customers, such as the basic process of content processing and exceptions in content synchronization, however, there are relatively few possibilities in practice. Another example is the ease-of-use of the content creation process, which is frequently used by users. Therefore, how to optimize the user experience of content creation has a high priority, however, the cost may not be very high.
3) Integrity
Special attention should be paid to the functional integrity. For example, if the content exception process is not implemented because of the project time, it does not mean that the exception is not handled at all, it is still necessary to ensure integrity, even simple implementation (for example, logging for manual query), but this simple implementation is the minimum cost, it can be replaced quickly in the future.
4) Sustainability
The implementation and selection of functional points should also consider the sustainability issue, that is, the functional points can be constantly superimposed to improve, rather than being re-implemented after being overturned, this is very different. For example, the content creation function is currently not implemented for exception handling. This is no problem. However, if you want to implement Exception Handling next time, we need to overwrite the Functional Descriptions of the process created in the current content, and this sustainability will be problematic, because this means that all previous functions will be overturned, it is likely that the previous implementations are all in vain. This is the imsustainability of the functional design. The functional design must be sustainable. If this is the case, the system functions will become stronger and stronger.
Therefore, we can improve the functions of each user story. This is good. The rest is just how to choose between them. The so-called trade-offs are just a staged discard and choice. Therefore, during the discussion, we should not be afraid or confused by the enhancement of functions and the expansion of the scope. record them as a good weapon for gradually improving the system, as long as we use the above principles, we will be able to do better.
Let's talk about the design issues.
In the head first object-oriented design book, good design is defined as flexible design. The art of Agile Software Development defines good design as "a good software design minimizes the time required to create, modify and maintain the software while achieving acceptable runtime performance. "Is the maintainability of the software. Therefore, the functions highlighted by agile design are basically all focused on Improving Software maintainability and scalability. Only the software has good maintainability and scalability, so that the software can be well superimposed, so that the software has a strong vitality.
What are our actual problems? In fact, it is still very simple, that is, the conflict between a good design and the project time. A good design requires time to consider and implement it (although not absolute, sometimes a good design will save more work ).
For the first question, the project time conflict, this can return to the internal quality and external quality problems discussed earlier, the previous questions about the function (external quality, we have already discussed the trade-off method. Can we choose Internal Quality (Design? In the book "scrum and XP from the trenches", the author thinks:
Internal quality, however, is not up for discussion. It is the team's responsibility to maintain the system's quality under all circumstances and this is simply not negotiable. Ever.
I share the same opinion on this.
However, our problems still exist. How can we balance conflicts with project time? I would like to consider two principles:
<! -- [If! Supportlists] --> 1) <! -- [Endif] --> good enough (first right)
<! -- [If! Supportlists] --> 2) <! -- [Endif] --> phased implementation/Sustainability
1) Good enough (first right & good enough)
The so-called first right & good enough is to let us see if our design is clear enough to structure our system, rather than being too complex, leading to insufficient project time, A good design doesn't usually take more time to implement. It is usually only over design that makes us feel powerless. So when we find that the implementation time caused by the design is too long, we need to check whether we think it is too complicated?
On the other hand, we do not advocate over design to avoid needless complexity, but we still need good enough & first right, that is, within the scope of the expected needs, our design is better, the difference between good design and poor design is often seen only when code is maintained and functions are added. It takes a little time to complete some exquisite design, not only technology, it is also an embodiment of artistic beauty, which can only be realized in the future.
Note that there is no conflict between refactoring and first right. Only when the right is more than the wrong at a time, refactor the wrong place gradually to make the system better. Otherwise, the system quality will remain in the initial stage.
2) Implementation/sustainability in stages
A good design is often flexible and can be implemented in stages. Many basic design principles, such as interface-oriented programming, are a good principle supporting "implementation in stages. When we define a clear interface level, the specific implementation of the interface can be controlled according to the project time point. When the project time is relatively tight, you can do some quick implementation, and then refactoring In the next stage, if the objects are interface dependencies rather than class dependencies, the refactoring in the next stage also has a very small impact on the existing functions of the system, which is also the core value of IOC.
For example, the flexible design of a ticket file format. If there are several formats for a ticket, the design may take several stages:
The first stage is to be easy to maintain at the class level. After a single parent class is defined through the template design mode, the single-format subclass implements the parent class template method in different words, for example, formatcdr (format statement record). In this case, when an external function writes a statement, you only need to instantiate the corresponding object and call the interface of the parent class to write the corresponding statement. When there is a new statement format, you only need to generate a new subclass and implement the corresponding method. We can see that this design is a good enough design.
The second stage is to improve the maintainability of the class to the maintainability of the Configuration. For example, you can use an XML method to configure the ticket format, so that the maintainability of the system is not compiled at runtime. At this time, a new subclass is generated based on the original one. During formatcdr, This subclass reads the configuration from the xml configuration file and generates formatted data, the system still supports many default CDR formats. For some CDR formats that cannot be configured, you can still implement them through subclass inheritance.
The third stage is to make a good GUI to configure and manage the xml configuration file of the ticket.
Therefore, a good design can be gradually superimposed and improved, and the core IOC of spring is born for the design model. These technologies and ideas are well applied, is to make our design have better vitality and continuity, while also balancing some time points in the project.
Conclusion: In any case, the demand analysis and design of software is an art. We need to accumulate and improve it in the process of continuous development. We need to do our best and make every effort, all are worthwhile.