Requirement Analysis: unify technical and business languages

In the field of software development, more and more people are talking about requirements. Like in other fields, the demand here comes from the user's "needs". The difference is that the most difficult part of developing a software system is to accurately describe what to develop, which is the requirement of a software project.

Why do we need so much attention? The reason is that we cannot effectively obtain the demand, and we cannot accurately express the demand. The demand changes have a great impact on the cost and cycle of the entire project ". Therefore, to make the project successful, you must first analyze the requirements.

What is demand?

To understand the nature of requirements, we must first clarify who is responsible for the requirements? Are users or developers? Of course, the user is God, and all the work we do is responsible for them, but the customer's wish is not all demand. Only from the business requirements, consider the actual development situation, on this basis, the development commitment can be called a requirement.

In 1997, the IEEE software engineering standard vocabulary defined the software requirements:

◆ Conditions or capabilities required by the user to solve the problem or achieve the goal.
◆ The system or system components shall meet the conditions or capabilities required in the contract, standard, specification or other formal provision documents.
◆ A document describing the conditions or capabilities described in 1 or 2 above.

Note that in this definition, the terms "conditions or capabilities" and "contracts and specifications" are generally used as users' needs, this includes the issues to be solved, the goals to be achieved, and the conditions required to achieve these goals. The expressions are generally in the form of documents.

Although demand work is increasingly mentioned, many people do not have enough understanding of the demand in project development work. As small as several hundred thousand yuan, as large as hundreds of millions of software projects, their needs are more or less different types of problems, for a wide range of reasons: the importance, technical, personnel organization, communication, and mechanism of developers indicate that developing software requirements is a systematic task rather than a simple technical task.

Demand Development and Management

What is a good demand? People who have renovated the House should know that the designer will give a design drawing or start construction only when the customer is satisfied. Development of software is the same as house decoration. A good requirement is the effect of delivery before development. To achieve this, we need to analyze and describe Services, functions, and systems.

The requirement analysis process consists of requirement development and requirement management. Requirement development refers to a series of activities that generate requirements from situation collection, analysis and evaluation to document writing and verification. They are divided into four stages: obtaining, analyzing, formulating specifications and verifying. These four stages do not necessarily follow a linear sequence. They are independent and repeated. Requirement management is an activity that controls and maintains requirements agreements during software project development. It includes change control, version control, requirement tracking, and status tracking.

From the perspective of workflow, the requirement analysis process starts from the user's desire to obtain the requirement, analyze the requirement, and form the specification document. After iterative verification, the requirement changes are generated to form a new specification document, and conduct version control; repeat the iterative verification process until both parties confirm to form a requirement document for establishing a development commitment.

How to analyze requirements?

Demand analysis puts forward higher requirements for analysts. It requires not only the analysts to have rich demand analysis experience and good professional quality, analysts are also required to have good learning, PR, language, and organizational skills. In actual work, analysts should face different personnel from different units and departments. They may have different cultures, relationships, and management levels. In the face of such a complicated environment, how can we do a good job of demand analysis? Here, we will introduce some related methods from two aspects: requirement development and requirement management.

First, there are many methods available for demand development. Different development methods have different analysis methods:

◆ Draw Association diagram: Draw a system Association diagram is a simple model used to define the boundaries and interfaces between the system and external entities of the system.

◆ Feasibility analysis: analyzes the feasibility of implementation of each requirement with the cost and performance requirements allowed, and puts forward the risks related to implementation of the requirement, including conflicts with other requirements, reliance on external factors and technical barriers.

◆ Demand priority: determine the priority level for using instances, product features, or individual requirements. Determine the features or requirements of the product version based on the priority.

◆ System prototype: when the user's own needs are not very clear, we can establish a system prototype, the user can better understand the problem to be solved by evaluating the prototype.

◆ Graphic analysis model: drawing a graphic analysis model is an important means to describe the specifications of software requirements. It helps analysts to clarify data, business models, workflows, and relationships between them, and identify requirements for omissions, redundancy, and inconsistency. Such a model includes a data flow diagram, an object relation diagram, a State Transformation Diagram, a dialog box diagram, an object class diagram, and an interaction diagram.

The purpose of requirement management is to control and maintain requirements and ensure the consistency of the project development process. Requirements management methods include:

◆ Determine the demand change control process. Make a selection, analysis, and decision-making process for demand changes. All demand changes must follow this process.

◆ Analyze the impact of demand changes. Evaluate each requirement change to determine its impact on the project plan and other requirements, clarify the tasks related to the change and assess the workload required to complete these tasks. These analyses will help the demand change control department make better decisions.

◆ Create the document of the requirement baseline version and requirement control version. Determine the demand benchmark. This is the consensus of all parties on the demand. Subsequent demand changes follow the change control process. The requirement specifications for each version must be described independently to avoid confusion between the draft and the benchmark or between the old and new versions.

◆ Maintain the historical records of demand changes. Write the requirement change information into a document, record the change date, reason, owner, version number, and other content, and notify the personnel involved in the project development in a timely manner.

◆ Track the status of each requirement. You can save the status attributes of each requirement (such as recommended, approved, implemented, or verified) in the database, in this way, you can obtain the number of requests for each status class at any time.

Requirement Analysis: unified technology and business language

Demand Analysis is inseparable from two groups: business personnel and technical personnel. The two speak different languages: Business and Technology. The goal of requirement analysis is to make the two speak a language in the software project and "bundle" the two to the most fit. The more likely the project is to succeed.

Note: The above content comes from the Internet and I am not liable for any joint liability.

Article transferred from: http://developer.51cto.com/art/200804/67754.htm