What is software requirements

For most people, to build a millions of-dollar house, he will discuss the details with the builders, who understand that changes after completion will cause damage and change the details. However, when it comes to software development, people become "careless". 40% to 60% of the problems in software projects are "Bane" (Leffingwell 1997) that are buried in the requirements analysis phase. But many organizations still use some irregular approach to basic project functionality, which results in a gap (expectation of difference)-a huge expectation difference between developers and the software they want.

In software engineering, all stakeholders (stakeholder) (the term is very interesting, the original meaning is the gambling custodian.) I've seen a lot of translations, translators and translators, but I think his main point is that people who have a close interest in the project are interested in the requirements analysis phase. These stakeholders include customers, users, business or demand analysts (who collect customer requirements and write documents, and who are responsible for communicating with the development organization), developers, testers, user documentation authors, project managers, and customer managers. If this part of the work is handled well, can develop a very good product, at the same time will make the customer satisfied, the developer also feel satisfied, enrich. Poor handling can lead to misunderstandings, setbacks, obstacles, and threats to potential quality and business value. Because requirements analysis lays the foundation for Software Engineering and project management, it is best for all stakeholders to adopt an effective requirements analysis process. Definition of software Requirements

The requirements defined in the IEEE Software Engineering Standard Glossary (1997) are:

(1) The user to solve the problem or achieve the goal of the necessary conditions or competencies (Capability).

(2) System or system components to meet the contract, standards, specifications or other formal requirements of the document required to have the conditions or power.

(3) A document description that reflects the conditions or competencies described above (1) or (2).

Level of demand

The following definitions are a description of the common terms in the requirements engineering field.

Software requirements include three different tiers-business needs, user needs, and functional requirements-and non-functional requirements. Business requirements (business requirement) reflect the organization's or customer's high-level goals for the system and product, which are described in the Project view and scope documentation. The user requirements Requirement document describes the tasks that a user must complete to use the product, as described in the usage case document or scenario script (scenario) description. Functional requirements (functional requirement) define the software features that a developer must implement to enable the user to complete their tasks to meet business requirements. The so-called feature (feature) is a collection of logically related functional requirements that provide users with the ability to handle and meet business needs. The relationship between the components of the software requirements is shown in the figure.

As a supplement, the software Requirements specification should also include non-functional requirements that describe the behavior and actions that the system presents to the user. It includes standards, specifications, and contracts that the product must comply with, details of the external interface, performance requirements, constraints on design or implementation, and quality attributes. Constraints are restrictions on the design and construction of software products for developers. The quality attribute is to describe the characteristics of the product through various angles, thus reflecting the function of the product. Multi-angle description of the product is extremely important to both users and developers. It is noteworthy that the requirements do not include design details, implementation details, project plan information, or test information. Demand has nothing to do with it, it focuses on what you really want to develop.

Frederick Brooks fully illustrates the important role that the requirements process plays in software projects in his 1987 classic article "No Silver bullet:essence and accidents Ofsoftware Engineering":

The most difficult part of developing a software system is to accurately describe what is being developed. The most difficult conceptual task is to write detailed technical requirements, including all user-oriented, machine-oriented, and other software systems interfaces. At the same time, it is also extremely difficult to make changes to the system when it is wrong and will eventually cause great damage to the systems.

Why, because in most software systems, the end user may not be aware of what his needs are, this is true. If your users tell you that this is the case, don't trust him and keep digging until you're exhausted.

It's a little weird, but it's a lesson, and no one in my project is going to call me when the software is nearing completion, I think I have to change some places. In those days, I even got a phone-tone phobia.

Demand risk

Here's a list of some of the most risky things to do with requirements analysis, and if you find that some of your practices are similar, give yourself some time to think about how these practices can have a fatal effect on your software.

1. Not enough users to participate

Customers often do not understand why it takes so much effort to gather requirements and ensure the quality of requirements, and developers may also not attach importance to user participation. The reason: First, because it is better to work with users than to write code interesting, and second, because developers feel that they already understand the needs of users. In some cases, it is difficult to get in touch with the users who actually use the product, and the customer is less aware of their real needs. However, a representative user should be allowed to participate directly in the development team early in the project and experience the whole development process together. The most important thing is that the user must pay attention to his software, must let him understand: if failed, he is the biggest loss (of course, your loss is not small, but at this time you must let him pay attention to this work). If the user does not pay attention, find a way to solve, otherwise you do not have to continue.

2. Increasing demand for users

In the development of continuous replenishment of demand, the project becomes bigger and larger than its plan and budget scope. This makes the problem more difficult to solve. In fact, the problem is rooted in changes in user needs and developers ' changes to new requirements. To minimize the scope of the change in requirements, the project view, scope, objectives, constraints, and success criteria must be clearly stated at the outset as a reference framework for evaluating requirements changes and new features. The description includes a change control process that changes the impact factor analysis of each change, and helps all stakeholders understand the rationality of the business decision, that is, why some changes are made, the time, resources, or characteristics of the compromise.

Continuous changes in product development can make their overall structure increasingly disorganized, and patch code makes the whole process difficult to understand and maintain. Inserting patch code causes the module to violate the design principles of strong cohesion and loose coupling, especially if the project configuration management is not complete, the recovery of change and deletion features can cause problems. If you distinguish between these potentially changing features as early as possible, you can develop a more robust structure and adapt to it better. This design-time requirements change does not directly lead to patch code, but also helps reduce the quality of the changes caused by the decline.

The worst of all is that users feel sorry for themselves if they don't add any more functionality. I have seen a data warehouse of the first phase of the project, in the design phase does not have a good definition of scope, when I asked the project manager this question, he thought that has been said, the contract is also written clearly, and did not pay attention to. But in the end, the user's proposed changes are far beyond the scope of the project time has been extended by one times. The entire team was exhausted, but he was constantly receiving complaints that the project had failed.

3. Ambiguous needs

Ambiguity is the most dreaded problem in the specification of requirements (Lawrence 1996). One layer of meaning is that many readers have different interpretations of requirements, and another meaning is that individual readers can interpret a requirement description in more than one way.

Ambiguous requirements can lead to different expectations for different stakeholders, which can cause developers to waste time on error issues and make the testers and developers expect them to be inconsistent. A system tester once told me that her test team often misunderstood the requirements so that she had to rewrite many test cases and do many tests.

The inevitable consequence of ambiguous demand is rework-redo something you think you've done well. Rework consumes 40% of the total cost of development, and 70%~85% is caused by requirements errors (Leffingwell 1997). Imagine what it would be like if you could reduce the rework by half? You can develop products faster, develop more and better products in the same time, and even go home and rest occasionally.

One way to deal with ambiguous needs is to organize teams that are responsible for examining requirements from different angles. Simply browsing through the requirements document does not solve the ambiguity problem. If different reviewers give explanations of requirements from different angles, but each reviewer really understands the requirements document so that ambiguity will not be discovered until the end of the project, then the discovery will make the correction costly.