02 "Software Requirements Analysis Tutorial"

As a complement to functional requirements, the software Requirements specification should also include non-functional requirements, which describe the behavior of the system and the actions performed by the user. It includes standards, specifications and contracts that the product must comply with, details of the external interface, performance requirements, constraints and quality attributes of the design or implementation. The so-called constraint refers to the developer in the software product design and construction of the choice of restrictions. Quality attributes are a variety of angles to describe the characteristics of the product, thus reflecting the product function, multi-angle description of the product for users and developers are extremely important.

Requirements do not include design details, implementation details, project planning information, or test information. The requirement is not related to these, it is concerned with fully explaining what you want to develop. The project also has other needs, such as developing environmental requirements or releasing products and porting to supporting environments. While these requirements are critical to the success of the project, they are not discussed in this book.

The most difficult part of developing a software system is precisely explaining what is being developed. The most difficult conceptual task is to write detailed technical requirements, including all user-oriented interfaces for machines and other software systems. At the same time, this is the part of the system that will eventually cause great damage if done wrong, and it is extremely difficult to modify it later.

A project team that does not attach importance to the demand process will reap the consequences. The defects in demand engineering will bring great risk to the success of the project, and the "success" here means that the product can be completed in a reasonable price, in time and in the function and quality to meet the user's expectation. Some requirements risks are discussed below. The 5th chapter describes how to apply software risk management to prevent risks associated with the emergence of demand-related risks and inappropriate demand processes.

(1) The number of users involved will result in unacceptable products.

(2) The expansion of user demand will lead to excessive cost and reduce the quality of products.

(3) Ambiguous requirements may lead to wasted time and rework.

(4) Users add some unnecessary features and developers "superfluous (gold-plating)" Pursuit.

(5) Overly streamlined requirements are explained to omit certain critical needs.

(6) Ignoring a certain part of the user class needs will lead to the dissatisfaction of many customers.

(7) The imperfect requirement indicates that the project planning and tracking cannot be carried out accurately.

Customers often do not understand why it takes so much effort to collect requirements and ensure quality, and developers may not value user engagement. The reason: one is not as interested in writing code as working with users, and secondly because they feel that they understand the needs of the user. In some cases, it is difficult to have direct contact with the user who actually uses the product, and the customer is not quite aware of the user's real needs. However, a representative user should be allowed to participate directly in the development team early in the project and go through the whole development process together.

In the development of the continuous replenishment of demand, the project becomes larger and larger than its planning and budget scope. The plan is not always close to the actual situation of the size and complexity of the project requirements, risk, development and production rate and demand changes, which makes the problem more difficult to solve. In fact, the root of the problem is the user's need for change and the developer's changes to the new requirements.

To control the expanding scope of changes, it is important to start with a clear description of the project view, scope, objectives, constraints, and success criteria, and use this as a frame of reference for evaluating requirements changes and new features. The description includes a change control process for each change impact factor analysis, which will also help all stakeholders understand the reasonableness of business decisions, why certain changes are made, and tradeoffs in time, resources, or characteristics that are consumed accordingly.

Continuous changes in product development will make its overall structure increasingly chaotic, patch code also makes the entire program difficult to understand and maintain. Inserting patch code also makes the module violate strong cohesion, loose coupling design principles, especially if the project configuration management work is not perfect, recall changes and delete features will also cause problems. If you can differentiate these features from the changes as early as possible, you can develop a more robust structure and adapt better to it, so that the design phase requirements change does not directly lead to patch code, but also helps to control the degradation of quality caused by the change.

Ambiguity is the most frightening problem in the requirements specification. One implication of this is that many readers have a different understanding of the requirements statement, and the other means that an individual reader can interpret a requirement description in more than one way. Ambiguous requirements can create different expectations for different stakeholders, which can cause developers to waste time on the wrong issues and make them inconsistent with what developers expect. One system tester once told me that her test team was often wrong about the requirements and had to rewrite many test cases and redo many tests.

02 Software Requirements Analysis Tutorial