Demand Analysis-how to analyze software requirements

1. Concept

Requirements are defined from the user perspective (external behavior of the system) and from the developer perspective (some internal features.

Off
The key issue is that you must write the requirement document. 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 you.
." 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 written into documents, so new analysts
You 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.

Additional requirements
A definition considers that a requirement is 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 needs of users.
Features, 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.

Slave
The definitions of these different forms are not hard to find: there is no clear and unambiguous "demand" term, and the true "demand" is actually in people's minds, this person mainly refers to customers, but generally
In this case, you cannot describe your own needs. Instead, you only need to analyze the requirements and check the requirements with the customer based on the user's own language description. System analysts and customers need to ensure that all projects
The risk owner must reach a consensus on the terms used to 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
However, even software requirements that are not for commercial purposes are necessary. Such as libraries, components, and tools for internal use by the development team. Of course, you may not need to provide instructions on this document to compare your opinions with others.
But more often, repetitive rework is an inevitable consequence, and 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.

Near
Come on, 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,
Users certainly want this function. As a result, the team had to manually copy the source code document for code check. This shows that the requirements are clear and the ideas are accurate. If we do not write documents, the software will not meet our expectations.
The target can only be self-defeating.

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.

In
Software Requirement Specification
The functional requirements described in (SRS) fully describe the external behaviors of the software system. Software Requirement Specification descriptions are important 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, soft
The Requirement Specification Description 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 the product
Function. 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: "users can effectively correct
Spelling mistake in the document ", which may be indicated on the cover of the product as a spelling checker meeting business needs. The corresponding user requirement may be "To Find Out spelling errors in the document and use a replacement provided
To replace the misspelled word ". At the same time, the spelling checker 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
Change.

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

Customer
Users often do not understand why it takes so much effort to collect requirements and ensure the quality of requirements, and developers may not pay attention to user participation. The reason is: first, developers feel that working with users is inferior to writing code.
The second reason is that developers have understood the user's needs. 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 directly participate 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.

Yes
To minimize the scope of demand changes, you must specify the project view, scope, objectives, constraints, and success criteria from the very beginning, this description serves as a reference framework for evaluating demand changes and new features. Description
It includes the change control process for analyzing the impact factors of changes for each change, which helps all risk owners understand the rationality of business decisions, that is, why certain changes are made, and the time, resources, or characteristics consumed accordingly.
.

Continuous changes in product development will cause increasingly disordered overall structure, and patch code will make the entire program difficult to understand and maintain. Insert patch code so that the module violates strong cohesion and loose coupling settings
Design principles, especially if the project configuration management is incomplete, the recovery of changes 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 knot.
And can 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.

Location
One way to address ambiguous requirements 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 have different requirements
The explanation is provided, but every reviewer understands the requirement document, so that the ambiguity will not be discovered until the later stage of the project. Otherwise, the correction will be costly.

4. Unnecessary features

"Painting
"Snake" refers to the new features that developers try to add but are not involved in the Requirement Specification Description. It is often the case that users do not consider these functions to be useful, resulting in effort consumption.
It's "nothing. Developers should design solutions for customers and provide them with innovative ideas. Specific functions should be obtained between the customer's needs and the technical feasibility of developers within the allowed time limit.
Balance, developers should strive to make the function 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 something that looks "cool", but lacks real
With value functions, achieving these functions can only consume time and cost. 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 "lailong go" 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 that demand analysis is so important, so
A brief description of the specifications only covers the concept of the product and allows developers to improve the project progress, the result is that the developer first establishes the product structure and then completes the Requirement Description.
Ming. 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 (making them on the premise of incorrect assumptions and extremely limited
It also brings troubles to customers (they cannot get the products they want ).

6. the user category is ignored.

Most products are used by different people
The usage frequency varies with different features, and 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
The user is 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.

Pair
The correct response to an inaccurate requirement 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. Yes
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
Show's software products are built on the basis of excellent requirements. High-quality requirements come from effective communication and cooperation between customers and developers. Usually, between developers and customers or customer agents, such as marketing personnel
Instead, it becomes an inverse relationship. 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.

Only
A cooperative relationship can be established only when both parties understand what they need to succeed and what is required by a successful partner. Due to the increasing project pressure, all risk owners have one
Common goals are easy to forget. 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

Connect
Through communication 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 and meet your needs
The excellent software you expect. 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 helps them understand how the current system works, how it works, and how it can be improved.

3: require analysts to prepare Software Requirement Specifications

Minute
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, we can get a piece of software.
Requirement Specifications. 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 easily read and understood by you
Organization and writing. 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

Minute
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
Has a 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 other requirements for development work results and symbols,
And how to check for errors and inconsistencies in charts.

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.

Connect
Often, 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 find out that 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
Users do not find very valuable system features.

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 much for developers
It is subjective 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

Yes
It usually requires 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 to modify the 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. Institute
To put it bluntly, if you want to use some existing frequently-used commercial components in the product, and they are not fully suited to the features you need, then a certain degree of demand flexibility is very 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

Customer
Users are very busy. They often have to participate in demand development when they are the busiest. 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
I thought I understood your point of view, and later I found that I still need your explanation. At this time, please be patient with the repetitive work process of refining requirements and needs, because it is a natural phenomenon in people's communication, not to mention this
The success of software products is extremely important.

3: Describe requirements accurately and in detail

It is very difficult to compile a clear and accurate requirement document. Handling details is not only annoying
It is time-consuming, so 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 a correct guess. To be determined,
TBD can also use Chinese pinyin to slightly write "dqd: To be determined") is a good way. This indicator can be used to identify the areas where further exploration, analysis, or information is required. However, sometimes
Add the TBD mark to a special requirement that is hard to solve or that nobody is willing to handle. Try to clarify the content of each requirement so that analysts can accurately write it into the Software Requirement Specification Description. If you
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 developers to continuously improve requirements.
.

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 recommendations from multiple users
Or choose a compromise between the quality conflicts and Information accuracy. Customers with the right to make a decision must take this action actively and make decisions as soon as possible. Because developers usually only wait for you to do
A decision can be taken, and such a wait will delay the progress of the project.

5. Respect the feasibility and cost assessment of developers' needs

All software functions have their cost price
However, developers are best suited to budgeting these costs (although many developers are not good at evaluating predictions ). Some of the product features you want may not work technically, or you may have to pay a very high price to implement them. While
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 a behavior to happen in an "instant, however, for more specific time requirements ("within 50 ms ",
Accurate technical analysis cannot be easily concluded.

6. Prioritize requirements

Most projects do not have enough time or resources to implement functionality.
. Determining which features are necessary, which are important, and which are good is the main part of demand development. It is up to you to set the demand priority, because developers cannot decide based on your point of view.
Requirement priority. The developer will give you priority information on the costs and risks of each requirement. When you set a priority, you help developers make sure they get the best effect with minimal expenses at the right time.
Result. 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, after all, they have to face
This is a reality. 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 be in 1st
Chapter 4 discusses whether formal or informal, reviewing Requirement documents will help improve software quality. Allow customers to participate in the review to identify whether the requirement documents are complete and correct
Required 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 tell the score as soon as possible.
Analyze personnel 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 help developers 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.

No
Changing demand 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 cause high costs
High rework, and the construction period will be forced to delay, 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

Soft
The most challenging thing in component 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
Value. 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. Despite asking analysts why they want to collect
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

Yes
The final result of 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
The document contains 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 connection.
Port requirement. 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.

By
The Formal Specification Description is highly rigorous and accurate. Therefore, only a few software developers are familiar with the formal language, let alone the customer. Although structured natural languages have many weaknesses
But in most software projects, it is still the most realistic way to write Requirement documents. Text-Based Software Requirement Specification descriptions that contain functional and non-functional requirements are accepted by most projects. Graphical Analysis Model
By providing another demand view, the specification of software requirements is enhanced.

The Software Requirement Specification Description is not only the basis for system testing and user documentation, but also the basis for planning, design, 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 restrictions, the specification of software requirements should not include details of design, construction, testing or engineering management.
Section. 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 can be
This allows you to view specific requirements in a change request, change history, cross-reference, or demand trackable matrix. To achieve this goal, it is not enough to use a single project list, so I will describe several different
And clarify their advantages and disadvantages. You can select the method that best suits you.

(1)
The simplest way to 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 will assign
Serial numbers (many such tools also support hierarchical serial 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, the requirements are removed from the database.
When a sequence is deleted, the sequence number occupied by it is not released, but the new requirement can only get the next available sequence number. This simple numbering method does not provide any difference in logic or hierarchy of related requirements.
.

(2) Hierarchical encoding is perhaps the most common method. If the functional requirements appear in the Software Requirement Specification Description 3rd.
2, 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
The numbers are also extended to many digits, and they do not provide any information about each purpose. If you want to insert a new requirement
The sequence number is to be added. If a requirement is deleted or removed, the sequence numbers of all requirements after the requirement is located are reduced. However, references elsewhere will be confusing. One way to improve this simple hierarchical number is
Perform hierarchical numbers on the main parts of the requirement, and then use a short text code plus a serial number to identify a single functional requirement in each part. For example, the Software Requirement Specification Description may contain
3.2.5-Edit function, and write this part into a sub-module document, and then configure and manage.

Sometimes, you feel that some information is missing from a specific requirement. Solving this uncertainty
You may have to negotiate with the customer, check the interface with another system, or define another requirement. Use "to be determined" (to be determined,
TBD, or dqd in Chinese pinyin, is used as a standard indicator to emphasize the defects of these requirements in the Software Requirement Specification Description. In this way, you can find the requirement to be clarified 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.

Continue
All TBD problems must be solved before a collection of requirements is constructed, because any legacy uncertainties will increase the risk of errors and demand rework. When a developer encounters a TBD problem or other fuzzy
When, 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 problem TBD has not been solved and you want to continue development
This may delay the implementation of these needs, or solve the Open Problems of these needs, so that this part of the product can be easily changed.

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.

Dodge
Without using comparative words, it can quantitatively describe the degree of improvement or clarify 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

Yes
Obtaining 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 and developers
Users and customers can explore a variety of solutions to describe these needs. Participants can design the system only after they understand the problem. Otherwise, any improvements to the definition of the requirement must be significant.
Amount of rework. 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 customers, you will ask some questions and obtain the information they provide (requirements
). 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 make the customer information structured and write
File 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.

Due to the lack of software development projects and organizational culture
At the same time, there is no simple and formula for demand development. 1 is listed below
You can use these four steps to guide your demand development activities. Once you have completed Step 1 for any subset of the requirements, you can proceed with the design and construction of each part of the system with great 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.

Yes
Retrieval 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. The analyst must establish a question
Thoroughly explore the environment, and these problems are related to the product. To facilitate clear communication, it is necessary to list important groups, rather than imagining that all participants share the same view. Need for a comprehensive investigation of demand issues
A technology is required, which not only considers the functional requirements of the problem, but also discusses the non-functional requirements of the project. Confirm that the user has understood: the discussion of some features does not mean that it will be implemented in the product soon.
It. 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.

Yes
Obtain and utilize all available information sources, which describe the problem domain or reasonable features in the software solution. A study shows that a successful project is available for developers and customers compared to an unsuccessful project.
More communication methods are adopted between them. 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.

In
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 success, because only the persons who provide the requirements 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. Target customers
You can easily list the exact design of each item in a report or dialog box before reaching a consensus. If these details are recorded as requirements, they will bring unnecessary limitations to the subsequent design process.
. 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 requirements. These functional requirements can be
Users can also describe their tasks as non-functional requirements. These non-functional requirements describe System Restrictions and users' expectations for quality. Although the initial screen concept helps describe your understanding of your needs
You must refine the user interface design.