How to analyze software requirements

Requirements are defined from the user perspective (external behavior of the system) and from the developer perspective (some internal features.
The key issue is that you must write the requirement documents. I once witnessed a change of all developers in the middle of a project, and the customer was forced to sit with the new demand analyst. System analysts said: "We want to talk to you about your needs ." The customer's first response was: "I have told your predecessor all my requirements, and now all I want is to compile a system for me ". In fact, the requirements are not compiled into documents, so new analysts have to start from scratch. Therefore, if you only have a bunch of emails, meeting records, or fragmented conversations, you are sure that you understand your needs, and you are completely deceiving yourself.
Another requirement is defined as "a description of what the user needs and can trigger the development of a program or system ". Some demand analysis experts have extended this concept: "from outside the system, we can find that the system meets the user's characteristics, functions, and attributes ". These definitions emphasize what products are, rather than how they are designed and constructed. The following definition is further transferred from the user to the system features:
The requirement is to specify what specifications must be implemented. It describes the behaviors, features, or attributes of the system and is a constraint on the system during development.
From the definitions of these different forms, it is not difficult to find that there is no clear and unambiguous "demand" term. The true "demand" is actually in people's minds, this person mainly refers to customers, but generally users cannot describe their own needs, the system analysts only need to sort out the relevant requirements based on the user's own language description before further checking with the customer. System analysts and customers need to ensure that all project risk owners reach consensus on the terms that describe the requirements.
Requirements in any document form (for example, the requirement specification to be described below) are only one model and one description.

2. Requirement Analysis task

The most difficult part of developing a software system is to accurately describe what to develop. The most difficult conceptual task is to compile detailed technical requirements, including all interfaces for users, machines, and other software systems. At the same time, this is also part of the system that will eventually cause great damage if you do something wrong, and it is extremely difficult to modify it later.
At present, the complexity of domestic products, an enterprise may have several systems to run simultaneously, the interface between them is the biggest headache for system developers.
For commercial end-user applications, enterprise information systems and software are obviously part of a large system. But for our developers, we have not compiled the requirement documents recognized by the customer. How do we know when the project will end? If we don't know what is important to our customers, how can we make them satisfied?
However, software requirements, even if not for commercial purposes, are required. Such as libraries, components, and tools for internal use by the development team. Of course, you may occasionally disagree with others' opinions without document instructions, but the more common is the inevitable consequence of repeated rework, the cost of code re-compilation is far more than the cost of rewriting a requirement document. These lessons are being learned by software developers in China.
Recently, I met a development team to develop a set of internally used computer-aided software, including the code editor. Unfortunately, after developing the tool, they found that the tool could not print the source code file, and the user certainly wanted this function. As a result, the team had to manually copy the source code document for code check. This shows that the requirement is clear and the concept is accurate. If we do not write a document, the software can only be self-defeating if it fails to achieve the desired goal.
On the contrary, I once saw a simple interface to be integrated into the "Error Tracking System" and wrote a page of Requirement Description. The operating system administrator found that a simple requirement list was so useful when processing scripts. When they test the system as needed, the system not only clearly implements all required functions, but also does not detect any errors.
In fact, the requirement document plays a guiding role in the development process.

3. Demand Analysis Process

The entire software requirement engineering research area can be divided into demand development and demand management, as shown in Figure 4-1:
Figure 4-1 layered decomposition of demand engineering Domains
Requirement development can be further divided into four stages: Problem acquisition, analysis, specification writing and verification. These subitems include requirement collection, evaluation, and documentation for software products. Demand development activities include the following:
Determine the expected user category of the product.
Obtain the requirements of each user class.
Understand the actual user tasks and objectives and the business requirements supported by these tasks.
Analyze user information to differentiate user task requirements, functional requirements, business rules, quality attributes, recommended solutions, and additional information.
Divide system-level requirements into several subsystems and allocate a part of the requirements to software components.
Understand the importance of relevant quality attributes.
Discuss implementation priorities.
Compile the collected user requirements into documents and models.
Review the Requirement Specification Description to ensure a common understanding and understanding of user requirements, and clarify the problem before the entire development team accepts the description.
Requirement management requires "establishing and maintaining contracts with customers in software engineering ". Such contracts are included in the requirement documents and models. The customer's acceptance is only half of the requirement's success. Developers must also be able to accept the requirement and apply it to the product. Common demand management activities include:
Define a requirement baseline (subject to quickly develop the requirement document ).
Reviews the proposed demand changes and evaluates the potential impact of each change to determine whether to implement the changes.
Integrate demand changes into the project in a controllable manner.
Make the current project plan consistent with the requirements.
It is estimated that the impact of the change needs will be affected and a new commitment will be negotiated on this basis. This commitment is embodied in the project solution.
Associate each requirement with the corresponding design, source code, and test cases for tracking.
Tracking the demand status and changes throughout the project.
I have summarized the experiences of system analysts after successfully implementing the project, and summarized the experiences of other systems at home and abroad.

4. Types of requirements

The following are definitions of common terms in the field of demand engineering.
Software requirements are divided into three levels: business requirements, user requirements, and functional requirements (including non-functional requirements ).
1. business requirement reflects the high-level objective requirements of organizations or customers on systems and products, which are described in the project view and scope document.
2. the user requirements document describes the tasks that must be completed by the user to use the product, which are described in the use case document or solution script description.
3. functional requirements define the software functions that developers must implement so that users can complete their tasks and meet business needs.
The functional requirements described in the Software Requirement Specification (SRS) fully describe the external behaviors of the software system. Software Requirement Specification descriptions play an important role in development, testing, quality assurance, project management, and related project functions. For a large system, software functional requirements may be a subset of system requirements, because others may belong to subsystems (or software components ).
As a supplement to functional requirements, the specification of software requirements should also include non-functional requirements, which describe the behaviors and operations performed by the system to users. It includes standards, specifications, and contracts that must be followed by the product, details of the external interface, performance requirements, design or implementation constraints and quality attributes. The constraint refers to the limitation on the design and construction of software products by developers. Quality Attributes describe product features from multiple perspectives to reflect product features. It is extremely important for users and developers to describe products from multiple perspectives.
The following uses a word processing program as an example to describe different types of requirements. The business requirement may be: "The user can effectively correct spelling mistakes in the document", and the product's packing box cover may indicate that this is a spelling checker meeting the business needs. The corresponding user requirement may be "finding out spelling errors in the document and using a provided replacement item list to choose to replace misspelled words ". At the same time, the spelling checker also has many functional requirements, such as finding and prompting incorrect words with high brightness; displaying a dialog box that provides replacement words and replacing the entire document scope.
From the above definition, we can find that the requirements do not include the design details, implementation details, project plan information or test information. The requirement has nothing to do with it. It focuses on fully explaining what you want to develop. Projects also have other requirements, such as development environment requirements, product release requirements, and migration to the support environment. Although these requirements are crucial to the success of the project, they are not discussed in this book.

5. Requirements Analysis principles

Project Teams that do not pay attention to the demand process will have their own fruits. Defects in the requirement project will bring great risks to the project's success, the "success" here means that the products launched can fully meet the user's expectations at reasonable prices and in a timely manner in terms of functions and quality. Some requirement risks are discussed below.
Risks arising from the inappropriate demand process:
1. Insufficient user participation
Customers often do not understand why it takes so much effort to collect requirements and ensure the quality of requirements, and developers may not attach importance to user participation. The reason is: first, developers feel that it is not as interesting to write code as they are working with users; second, they feel that they have understood the needs of users. In some cases, it is difficult for the customer to directly contact the user who actually uses the product, and the customer does not understand the real needs. However, representative users should be directly involved in the development team in the early stage of the project and go through the entire development process together.
In practice, system personnel also feel that if there are not enough users to participate in the implementation of a company's project, the requirements of system personnel are one-sided and incomplete, in this way, the system will pose risks at the beginning of the demand.
2. Increasing user requirements
If the demand is constantly supplemented during development, the project will become larger and larger, thus exceeding the scope of its plan and budget. The plan is not always consistent with the project demand scale and complexity, risks, development productivity, and actual demand changes, making the problem more difficult to solve. In fact, the root cause of the problem is changes in user requirements and changes made by developers to new requirements.
To minimize the scope of demand changes, the project view, scope, objectives, constraints, and success criteria must be clearly stated at the beginning, this description serves as a reference framework for evaluating demand changes and new features. The description includes the change control process for analyzing the impact factors of each change, which helps all risk owners understand the rationality of business decisions, that is, why some changes are made, time, resource, or feature compromise.
Continuous changes in product development will cause increasingly disordered overall structure, and patch code will make the entire program difficult to understand and maintain. Inserting the patch Code violates the strong cohesion and loose coupling design principles. In particular, if the project configuration management is not complete, revoking the change and deletion features will cause problems. If you differentiate the features that may bring changes as soon as possible, you can develop a more robust structure and better adapt to it. In this way, the requirement changes in the design phase will not directly cause the patch code, but will also help reduce the quality reduction caused by changes.
3. Ambiguous requirements
Ambiguity is the most terrible problem in the Requirement Specification Description. The meaning of this layer means that many readers have different understandings of the requirement description, and the meaning of this layer means that a single reader can explain a Requirement Description in more than one way.
Ambiguous requirements may lead to different risk owners to have different expectations, which will waste time on errors and make the tester and developer expectations different. A system tester once told me that her test group often had to rewrite many test cases and redo many tests because she had to understand the requirements.
One way to deal with ambiguous needs is to organize teams responsible for reviewing requirements from different perspectives. Simply browsing the requirement document cannot solve the problem of ambiguity. If different reviewers explain the requirements from different perspectives, but each reviewer truly understands the requirements document, the ambiguity will not be discovered until the project is later, if we find it again, it will make the correction very costly.
4. Unnecessary features
"Adding to the image" refers to the new features that developers try to add to the "user appreciation" but are not involved in the Requirement Specification Description. It is often the case that users do not think these functions are very useful, so that the effort spent on them is "useless. Developers should design solutions for customers and provide them with innovative ideas. Specific functions should be balanced between the customer's needs and the technical feasibility of developers within the allowed time limit, developers should strive to make the functions simple and easy to use, instead of leaving the customer's requirements without the customer's consent and making their own claims.
Similarly, customers may sometimes require functionality that looks "cool" but lacks practical value. However, implementing these features only consumes time and costs. In order to minimize the harm caused by "image farming", you should be sure that you understand why these features should be included and the "ins and outs" of these features ", in this way, the demand analysis process always focuses on the core functions that allow users to complete their business tasks.
5. Too simplified specifications
Sometimes, the customer does not understand the importance of requirement analysis. Therefore, the customer only provides a brief description of the specifications, which only covers the concept of the product, then let the developers improve the project progress. what is likely to happen is that the developers first establish the product structure and then complete the Requirement Description. This method may be suitable for situations where cutting-edge research products or requirements are flexible. But in most cases, this will bring setbacks to developers (so that they can work under the premise of incorrect assumptions and extremely limited guidance ), it will also bring troubles to customers (they cannot get the products they imagined ).
6. the user category is ignored.
Most products use different features by different people, and their usage frequency is also different. The user's educational level and experience level are also different. If you cannot classify all these major users in the early stages of the project, some users will be disappointed with the product. For example, menu-driven operations are too inefficient for advanced users, but undefined commands and shortcut keys make them difficult for unskilled users.
7. inaccurate plan
According to statistics, the main reasons for the inaccurate estimation of software costs in the demand process are as follows: frequent demand changes, missing demands, insufficient communication with users, low quality requirement specification descriptions, and imperfect demand analysis.
The correct response to the question asked for inaccurate requirements is "I will tell you when I really understand your needs ". The estimation of immature requirements based on inadequate information and unthought-provoking requirements is easily caused by some factors. It is best to give a range when making an estimate. Unprepared estimates are usually given as a kind of speculation, but the listener thinks it is a kind of promise. Therefore, we should try our best to give what can be achieved and stick to it.

6. Relationship between requirement analysts and users

Excellent Software products are built on excellent requirements. High-quality requirements come from effective communication and cooperation between customers and developers. In general, the relationship between developers and customers or customer agents, such as market personnel, becomes a confrontation. Managers on both sides only want their own interests and put aside the needs provided by users to generate friction. In this case, it will not bring any benefit to both sides.
A cooperative relationship can be established only when both parties understand what they need to succeed and what the partners need to succeed. Due to the increasing project pressure, it is easy to forget that all risk owners share a common goal. In fact, everyone wants to develop an excellent software product that can realize commercial value, meet user needs, and make developers feel satisfied.
The software customer demand right list ten legal requirements for the customer to communicate with analysts and developers during project demand project implementation. Each right corresponds to the obligations of software developers and analysts. The demand obligations of software customers also list ten obligations of customers in the demand process. If you like, you can use it as a developer's right book.
The customer has the following rights:
1: require analysts to use expressions that conform to customers' language habits
Demand discussions should focus on business needs and tasks. Therefore, to use business terms, you should teach them to analysts, and you do not have to understand computer industry terms.
2: require analysts to understand the customer's business and objectives
By communicating with users to obtain user requirements, analysts can better understand your business tasks and how to make the product better meet your needs. This will help developers design excellent software that truly meets your needs and meets your expectations. To help developers and analysts, you can consider inviting them to observe how you or your colleagues work. If the new development system is used to replace the existing system, developers should use the current system, which will help them understand how the current system works and how it works, and for improvement.
3: require analysts to prepare Software Requirement Specifications
Analysts should organize all the information you obtain from other customers to distinguish business requirements and specifications, functional requirements, quality objectives, solutions, and other information. Through these analyses, you can get a description of the Software Requirement Specification. The Software Requirement Specification agreement was reached between the developer and the customer for the product to be developed. The Software Requirement Specification can be compiled in a way that you think is easy to read and understand. You need to review the specifications to ensure that they fully and accurately express your needs. A high-quality software requirement specification can help developers develop products they really need.
4: Requirements for explanation of requirements work results
Analysts may use multiple charts to supplement the specification of Text software requirements. Because charts like work flow charts can clearly describe some aspects of system behavior. Therefore, various charts in the Requirement Description have extremely high value. Although they are not easy to understand, you may not be familiar with them. Therefore, analysts can be asked to explain the role of each chart or the significance of the development work results and symbols of other requirements, and how to check whether the charts are incorrect or inconsistent.
5: Ask developers to respect your opinions.
If users and developers cannot understand each other, there will be obstacles to the discussion about the requirements. co-working can make everyone "Listen to what is needed ". Customers involved in the demand development process have the right to ask developers to respect them and cherish the time they have paid for the success of the project. Similarly, the customer should respect and appreciate the efforts made by developers to achieve the success of the project.
6: developers are required to provide suggestions on requirements and product implementation and come up with ideas.
Generally, what the customer calls "demand" is a practical implementation solution. Analysts will try their best to understand the real business and needs from these solutions, at the same time, we should also find out the existing system is not suitable for the current business, to ensure that the product will not be invalid or inefficient. After thoroughly understanding the affairs in the business field, analysts can sometimes propose quite good improvement methods. Experienced and creative analysts can also propose more valuable system features that users have not discovered.
7: Describes the product's easy-to-use features
You can ask analysts to focus on the ease of use of software while implementing functional requirements. These easy-to-use features or quality attributes allow you to complete tasks more accurately and efficiently. For example, customers sometimes require products to be "user-friendly", "robust", or "efficient", but this is too subjective for developers and has no practical value. The correct answer should be: analysts should know the specific characteristics of the customer's friendliness, robustness, and efficiency through inquiry and investigation.
8: Adjust requirements and allow reuse of existing software components
Requirements usually require a certain degree of flexibility. Analysts may find that an existing software component is very consistent with the requirement you described. In this case, analysts should provide some options for modifying requirements so that developers can reuse existing software in new system development. If you have a reusable opportunity and can adjust your requirements, you can reduce costs and save time without having to strictly describe development based on your original needs. Therefore, if you want to use some frequently-used commercial components in the product, and they are not fully suited to the features you need, the demand flexibility to a certain extent becomes extremely important.
9: obtain a system that meets the customer's functional and quality requirements
Everyone wants the project to succeed. However, this not only requires you to clearly inform developers of all the information required for the system "what", but also requires developers to understand the trade-off and restrictions through communication. Be sure to clearly describe your assumptions and potential expectations. Otherwise, the products developed by developers may not satisfy you.
The customer has the following obligations:
1: Explain your business to analysts
Analysts rely on the business concepts and terms you have explained to them. However, you cannot expect analysts to become experts in this field, but you can only let them really understand your problems and goals. Do not expect analysts to grasp the nuances and potential of your business. They may not know the "common sense" that you and your colleagues take for granted ".
2: Take the time to clearly describe and improve the requirements
The customer is very busy and often needs to participate in demand development during the busiest time. However, in any case, you are obligated to take the time to participate in discussions, interviews, or other activities that require access. Sometimes analysts may first think they have understood your point of view, and later they will need your explanation. At this time, please be patient with the refinement of requirements and needs, because it is a natural phenomenon in people's communication, and this is extremely important to the success of software products.
3: Describe requirements accurately and in detail
It is very difficult to compile a clear and accurate requirement document. Because it is not only annoying but also time-consuming to deal with details, it is easy to leave ambiguous demands. However, this ambiguity and inaccuracy must be solved during the development process. You are the best candidate to make a decision to solve these problems. Otherwise, you have to rely on developers to make correct guesses. In the Requirement Specification Description, it is a good option to temporarily Add the logo (to be determined, TBD can also be omitted to "DQD: to be determined" in Chinese pinyin. This indicator can be used to identify the areas where further exploration, analysis, or information is required. However, sometimes it may be difficult to solve a special requirement or no one is willing to handle it and add the TBD mark. Try to clarify the content of each requirement so that analysts can accurately write it into the Software Requirement Specification Description. If you cannot accurately express the information at the moment, you must allow the necessary accurate information to be obtained. The so-called prototype technology is usually used. With the developed prototype, you can modify it repeatedly with the developer to continuously improve the requirement definition.
4: make a timely decision
If an architect builds a house for you, analysts will ask you to make some choices and decisions. These decisions include handling methods proposed by multiple users or selecting a compromise between quality and information accuracy. Customers with the right to make a decision must take this action actively and make decisions as soon as possible. This is because developers can take action only when they make a decision, and such a wait will delay the progress of the project.
5. Respect the feasibility and cost assessment of developers' needs
All software features have their own cost prices, and developers are best suited to budgeting these costs (although many developers are not good at evaluating and predicting ). Some of the product features you want may not work technically, or you may have to pay a very high price to implement them. Developers will give negative comments to certain requirements that attempt to require performance that is not possible in the operating environment or to obtain data that is not available at all. You should respect their opinions. Sometimes, you can re-provide a technically feasible and cost-effective demand. For example, it is not feasible to require an action to happen in an "instant, however, this can be achieved if there is no accurate technical analysis, because the time requirement is more specific ("within 50 ms.
6. Prioritize requirements
Most projects do not have enough time or resources to implement every detail of functionality. Determining which features are necessary, which are important, and which are good is the main part of demand development. You can only set the demand priority, because developers cannot decide the demand priority based on your point of view. The developer will give you priority information on the costs and risks of each requirement. When you set a priority, you help developers ensure the best effect with minimal expenses at the right time. With time and resource restrictions, the opinions of developers should be respected on whether or how many features are required. Although no one is willing to see that their desired needs are not implemented in the project, they have to face this reality after all. Business decisions sometimes have to narrow down the project scope or extend the construction period, increase resources, or look for trade-offs in terms of quality based on priorities.
7. Review Requirement documents and prototypes
As we will discuss in Chapter 4 of section 1st, reviewing the requirement documents in both formal and informal ways will help improve the quality of software. Only by allowing customers to participate in the review can they truly identify whether the requirement documents are complete and correctly describe the desired features. The review also provides an opportunity for customer representatives to provide feedback to requirement analysts to improve their work. If you believe that the required documents are not accurate enough, you are obligated to inform analysts as soon as possible and provide suggestions for improvement. By reading the Requirement Specification descriptions, it is hard to imagine what the actual software looks like. A better way is to first develop a prototype for the product. In this way, you can provide more valuable feedback to developers to help them better understand your needs. It must be realized that prototype is not a real product, but developers can transform and expand it to a complete system.
8: contact us immediately if the requirement is changed.
Constant demand changes will have a serious negative impact on the completion of high-quality products in the planned plan. Changes are inevitable, but the more advanced the change occurs in the development cycle, the more impact it has. Changes will not only lead to costly rework, but will also lead to delays in the construction period, especially when new features need to be added after the general structure is completed. Therefore, when you find that you need to change your requirements, you must immediately notify the analysts.
9: The change of requirements should be handled by the development organization.
To minimize the negative impact of changes, all participants must comply with the change control process of the project. This requirement does not discard all proposed changes, analyze and comprehensively consider the changes in each requirement, and finally make appropriate decisions to determine the introduction of certain changes to the project.
10: respect the engineering process of requirements adopted by developers
The most challenging part of software development is to collect requirements and determine their correctness. The method adopted by analysts is reasonable. Maybe you think the demand process is not very cost-effective, but please believe that the time spent on demand development is "very valuable. If you understand and support the technologies used by analysts to collect, compile Requirement documents, and ensure their quality, the entire process will be smoother. Ask analysts why they want to collect certain information or participate in activities related to requirements.
System analysts may encounter the following problems during the development process. Busy customers may not be willing to actively participate in the demand process. The lack of customer participation may lead to unsatisfactory products. Therefore, make sure that the main participants in demand development understand and accept their obligations. In case of disagreements, mutual understanding of their respective obligations can be achieved through negotiation, which can reduce future friction.

7. Requirement documents

The final result of demand development is that the customer and the development team reach an agreement on the products to be developed. The Protocol integrates business requirements, user requirements, and software functional requirements. As we can see earlier, the project view and scope document contain business requirements, while the instance document contains user requirements. You must compile the function requirement document derived from the instance, and the non-functional requirement document of the product, including the quality attribute and external interface requirements. Only when these documents are written in a structured and readable manner and reviewed and approved by the project risk owner can all parties be confident that the requirements they agree with are reliable.
You can use the following three methods to describe the Software Requirement Specification:
Make good use of structured and natural languages to compile text-based documents.
A graphical model is created to describe the conversion process, system status, changes between them, data relationships, logical flows, or object classes, and their relationships.
Write a description of the formal specification, which can be defined by using a mathematical and precise formal logic language.
Because the Formal Specification Description is highly rigorous and accurate, only a few software developers are familiar with the formal language, let alone the customer. Although structured natural language has many disadvantages, it is still the most realistic method for Writing Requirement documents in most software projects. Text-Based Software Requirement Specification descriptions that contain functional and non-functional requirements are accepted by most projects. The Graphical Analysis Model enhances the description of software requirement specifications by providing another requirement view.
The Software Requirement Specification Description is not only the basis of system testing and user documentation, but also the basis for planning, designing and coding for all sub-series projects. It should fully describe the expected external behaviors and visualized user behaviors of the system as much as possible. In addition to design and implementation constraints, the Software Requirement Specification Description should not include details of design, construction, testing, or engineering management. Many readers use the software requirement specification descriptions to achieve different purposes:
Customers and marketing departments rely on it to understand what products they provide.
The Project Manager plans and predicts the schedule, workload, and resources based on the products included in the Software Requirement Specification Description.
The software development team depends on it to understand the products they will develop.
The test team uses the description of product behavior in the Software Requirement Specification Description to develop a test plan, test cases, and test process.
The software maintenance and support personnel should explain what a certain part of the product is based on the requirement specification.
The product release Group prepares customer documents, such as user manuals and help screens, based on Requirement Specification instructions and user interface design.
The training personnel should specify the specifications and user documents according to their needs.
The Software Requirement Specification Description must be comprehensive as the final outcome of the Product Requirement: All requirements must be included. Developers and customers cannot make any assumptions. If any desired functional or non-functional requirement is not written into the software requirement specification, it cannot be part of the protocol and cannot appear in the product.
I have seen a project suddenly received a report of an error disaster from a tester. The result is that they are testing the specification of the old version of the software, and what they think is wrong is the unique feature of the product. Their testing work is futile because they have been searching for incorrect system behavior in the Specification descriptions of older versions of software requirements.
When writing a Software Requirement Specification Description, I hope readers will keep in mind the following suggestions:
The number orchestration for the section, section, and individual requirements must be consistent.
Leave the text comment area on the right.
Spaces are allowed without restrictions.
Correct use of various visual highlight marks (for example, simhei, underline, italic, and other different fonts ).
Creating directory tables and index tables helps readers find the required information.
Specify the number and ID number for all charts and tables, and view them by number.
Use the cross-reference function in the word processing program to view other items or locations in the document, rather than by page number or node number.
Each software requirement must be uniquely identified to meet traceability and corrective quality standards of Software Requirement Specifications. This allows you to view specific requirements in a change request, change history, cross-reference, or demand trackable matrix. To achieve this, it is not enough to use a single project list. Therefore, I will describe several different requirement identification methods and clarify their advantages and disadvantages. You can select the method that best suits you.
(1) the simplest method of serial numbers is to assign each requirement a unique serial number, such as a SRS-13. When a new requirement is added to the database of the business requirement management tool, these management tools assign a serial number to it (many such tools also support hierarchical numbers ). The prefix of the serial number represents the requirement type. For example, SRS represents the "Software Requirement Description ". Because serial numbers cannot be reused, When you delete a requirement from the database, the serial number occupied by the request is not released, and the new requirement can only get the next available serial number. This simple numbering method does not provide any logical or hierarchical differences between related requirements, and the requirement identification cannot provide any information about each requirement.
(2) Hierarchical encoding is perhaps the most common method. If functional requirements appear in part 3rd. 2 of the Software Requirement Specification, they will have identification numbers such as 3.2.4.3. The more numbers in the ID number, the more detailed the requirement is. Even in a medium-sized Software Requirement Specification Description, these identifiers are extended to many digits and do not provide any information about each purpose. If you want to insert a new requirement, the sequence number of all requirements will increase after the requirement is included. If a requirement is deleted or removed, the sequence numbers of all requirements after the requirement is located are reduced. However, references from other places will be chaotic. An improved method for this simple hierarchical number is to perform hierarchical numbers on the main parts of the demand, then, a short text code plus a serial number is used to identify a single functional requirement in each part. For example, the Software Requirement Specification Description may contain section 3.2.5-Edit function, compile this part into a sub-module document, and then manage the configuration.
Sometimes, you feel that some information is missing from a specific requirement. Before resolving this uncertainty, you may have to negotiate with the customer, check the interface with another system, or define another requirement. Use the to be determined, TBD, or DQD in Chinese pinyin to emphasize the defects of these requirements in the Software Requirement Specification Description. In this way, you can find the desired part in the Software Requirement Specification Description. Record who will solve the problem, how to solve it, and when to solve it. Add each TBD number and create a TBD list, which helps you easily track each project.
All TBD problems must be resolved before building a demand set, because any legacy uncertainties will increase the risk of errors and demand rework. When a developer encounters a TBD problem or other fuzzy points, he may not return to the original requirement to solve the problem. Most developers guess about it, but it is not always correct. If the TBD problem has not been solved, and you want to continue the development work, try to postpone the implementation of these requirements as much as possible, or solve the Open Problems of these requirements, and make the product design easy to change.
There is no fixed method to compile excellent Requirement documents, preferably based on experience. You may have benefited a lot from past problems. Many Requirement documents can be improved by writing styles and using user terminologies rather than computer terminologies using effective technologies.
When writing excellent Requirement documents, you may want to keep the following suggestions in mind:
Keep the statement and paragraph short.
Use the expression of active voice.
Compile a complete sentence with correct syntax, spelling, and punctuation.
The terms used should be consistent with those defined in the vocabulary.
The requirement statement should have a consistent style, such as "system must..." or "user must...", and keep up with an action and an observed result. For example, "the warehouse management subsystem must display a inventory list in the requested warehouse ."
To reduce uncertainty, you must avoid vague and subjective terms, such as user-friendly, simple, effective, up-to-date technology, superior, and acceptable. When users say "user friendly" or "fast", you should clarify their true meaning and clarify the user's intention in demand.
Avoid using comparative words to quantitatively describe the degree of improvement or clear the acceptable maximum and minimum values of some parameters. When the customer says that the system should "handle", "support", or "manage" some things, you should be able to understand the customer's intention. As requirements are written hierarchically, you can break down unclear requirements at the top level to the lower level until ambiguity is eliminated.
Document writers should not concentrate multiple requirements in one lengthy narrative section. A combination of requirements such as "and", "or" indicates that this Part has multiple requirements. Remember not to use joins like "and/or", "and so on" in the Requirement Description.

8. Requirement Analysis Process

Requirement acquisition is the first step to build a bridge between the problem and its final solution. An essential result for obtaining a requirement is a general understanding of the customer requirements described in the project. Once you understand the requirements, analysts, developers, and customers can explore a variety of solutions that describe these needs. Participants can only design the system after they understand the problem. Otherwise, any improvements to the requirement definition must be reworked in a large amount. Focusing requirement acquisition on user tasks rather than user interfaces helps prevent development teams from making mistakes due to hasty design issues.
Requirement acquisition, analysis, Writing Requirement Specification descriptions and verification do not follow a linear sequence. These activities are separated, incremental, and repeated. When you work with the customer, you will ask some questions and obtain the information they provide (the requirement is obtained ). At the same time, you will process the information to understand them, divide them into different categories, and link customer requirements with possible software requirements. Then, you can structure the customer information and write it into documents and. Next, let the customer representative review the document and correct the existing errors. These four processes run through the entire stage of demand development.
Because of the differences between software development projects and organizational culture, there is no simple and formula for demand development. The following lists the four steps that you can use to guide your demand development activities. Once you complete Step 1 for any subset of your requirements, you can proceed with the design and construction of each part of the system with confidence, because you will develop a good product:
1. Define the view and scope of the project.
2. determine the user class.
3. determine the appropriate representative in each user class.
4. determine the demand decision makers and their decision-making processes.
5. Select the desired retrieval technology.
6. Use the requirement Retrieval Technology to develop and set the priority of instances used as part of the system.
7. Collect quality attribute information and other non-functional requirements from users.
8. elaborate on the use of instances to integrate them into necessary functional requirements.
9. review instance descriptions and functional requirements.
10. If necessary, an analysis model should be developed to clarify the participants' understanding of the requirement.
11. Develop and evaluate the user interface prototype to help you imagine the need that has not yet been understood.
12. Start the concept test case from the instance.
13. Use test cases to demonstrate the use of instances, functional requirements, analysis models and prototypes.
14. Repeat 6 ~ Step 1.
Requirement acquisition may be the most difficult, critical, error-prone, and communication required in software development. Requirement acquisition can be successful only through cooperation between valid customers and developers. Analysts must establish an environment for thorough discussion of problems, which are related to products. To facilitate clear communication, it is necessary to list important groups, rather than imagining that all participants share the same view. A comprehensive investigation of the demand issue requires a technology that not only considers the functional requirements of the problem, but also discusses the non-functional requirements of the project. Confirm that the user understands that the discussion of some features does not mean that it will be implemented in the product soon. You must focus on the expected needs and set priorities to avoid an infinitely large project that cannot bring any benefits.
Requirement acquisition is a highly cooperative activity, not a simple copy of the customer's requirements. As an analyst, you must understand the real needs of the customer based on the customer's surface requirements. Asking a scalable question helps you better understand your current business processes and understand how new systems help or improve your work.
Demand retrieval utilizes all available information sources that describe the problem domain or the rational features in the software solution. A study shows that a successful project uses more communication methods between developers and customers than an unsuccessful project. Discussing with a single customer or potential user group is a traditional source of demand for business software packages or Information Management System (MIS) applications.
After each discussion, write down the items discussed and ask the users who participate in the discussion to comment and correct them. Early and frequent discussions are a key way to succeed in obtaining a requirement, because only those who provide the requirement can determine whether to actually obtain the requirement. Perform in-depth collection and analysis to eliminate any conflicts or inconsistencies. Try to understand the thinking process that users use to express their needs. Fully study the process of making decisions when users execute tasks and extract potential logical relationships. Flowcharts and decision trees are good methods to describe these logical decision paths.
When obtaining requirements, avoid being affected by immature details. You can easily list the exact design of each item in a report or dialog box before reaching consensus on the appropriate customer task. If these details are recorded as requirements, they will impose unnecessary restrictions on subsequent design processes. You may need to periodically check demand acquisition to ensure that user participants focus on the abstraction layer suitable for the topics discussed today. Assure them that their needs will be elaborated during the development process.
In a successive detailed description process, the requirements are repeatedly described to determine the user's objectives and tasks and use them as instances. Then, describe the task successfully to meet the requirement. These functional requirements can allow the user to complete their tasks, or describe them as non-functional requirements, these non-functional requirements describe System Restrictions and user expectations for quality. Although the initial screen design helps describe your understanding of the needs, you must refine the user interface design.