How to perform software requirements analysis

1. Concept

Requirements are defined from the user's perspective (the external behavior of the system) and from the developer's perspective (some internal features) to illustrate the requirements.

The key issue is to be sure to write the requirements documentation. I've seen a project change all the developers halfway through, and the client was forced to sit with the new demand analyst. The system analyst said: "We want to talk to you about your needs." "The customer's first reaction was:" I have told your predecessors my request, and now I want to make a system for me. " In fact, the requirements are not documented, so the new analyst has to start from scratch. So if there's just a bunch of emails, conversations, or some fragmented, unfinished conversation, you're sure you know what the user wants, and that's totally self-deceiving.

Another definition of demand is that the requirement is "a description that the user needs and can trigger a program or system development work." Some demand analysis experts expand the concept: "From outside the system can be found to meet the user's characteristics, functions and attributes." These definitions emphasize what the product is, not how the product is designed and constructed. The following definition is further transferred from the user to the system features:
A requirement is a specification indicating what must be achieved. It describes the behavior, attributes, or attributes of a system and is a constraint on the system during development.

From these different forms of definition is not difficult to find: there is no clear, no ambiguity of the "need" terminology exists, the real "demand" actually in people's minds, this people mainly refers to the customer, but in general, users can not describe their own needs, Only need the system analysis personnel according to the user's own language description to collate the related need to further and customer check. System analysts and customers need to ensure that all project stakeholders have a common understanding of the terms that describe the requirements.
Any requirements in the form of documentation (such as the requirements specification described below) are just a model, a description.

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

At present, the complexity of domestic products, an enterprise may have several systems run in one another, the interface between them is the most headache of the system developers.

For commercial end-user applications, enterprise information systems and software as part of a large system are obvious products. But for our developers, we didn't write out the customer-approved requirements document, how we knew when the project ended. And if we don't know what is important to our customers, how can we make our customers satisfied?

However, even software requirements that are not for commercial purposes are necessary. For example, libraries, components, and tools are software that is used internally by the development team. Of course you may not need documentation to be more consistent with others, but more often than not, the inevitable consequence of repetitive rework, and the cost of rewriting the code far outweighs the cost of overwriting a requirement document, which is happening to software developers in the country.

Recently, I met a development team that developed a set of internal computer-aided software, including a code editor. Unfortunately, when they developed the tool, they found that the tool could not print out the source code files, the user certainly wanted to have this function. As a result, the team had to hand-copy the source code documentation for Code inspection. This means that the need to be clear and accurate, if we do not write a document, the software can not reach the desired goal is only the own.

On the contrary, I have seen a simple interface to integrate into the error tracking system to write a page of requirements description. and the operating system administrator found a simple list of requirements to work with the script that was so useful. When they tested the system on demand, the system not only realized all the necessary functions very clearly, but also found no errors.

In fact, the requirements document has been a guiding role in the development process.

3. Requirements Analysis Process

The entire software requirements Engineering research area can be divided into requirements development and demand management two parts more appropriate, as shown in Figure 4-1:

Requirements development can be further divided into: problem acquisition, analysis, writing specifications and validation of four stages. These children include all activities such as requirements collection, evaluation, documentation, etc. in software products. Requirements development activities include the following:

Determine the user category that the product expects.
Gets the requirements for each user class.
Understand the actual user tasks and goals and the business requirements that these tasks support.
Analyze information originating from users to differentiate user task requirements, functional requirements, business rules, quality attributes, suggested solutions, and additional information.

Divide system-level requirements into subsystems and assign parts of the requirements to software components.
Understand the importance of related quality attributes.
To discuss the implementation of priority division.
Write the collected user requirements into documents and models.
Review requirements specifications to ensure a common understanding and understanding of user needs, and clarify issues before the entire development team accepts the instructions.

Demand management needs to "establish and maintain contracts with customers in software engineering." Such contracts are included in the written requirements documentation and model. Customer acceptance is only half the success of the demand, and developers must be able to accept them and actually apply the requirements to the product. Common requirements management activities include:

Define the requirements baseline (the subject of the rapidly developing requirements document).
Review the proposed requirements changes, assess the possible impact of each change and decide whether to implement it.
Incorporate requirements changes into your project in a controlled way.
Align the current project plan with the requirements.
Estimating the impact of change requirements and negotiating new commitments on the basis of this commitment is embodied in the project solution.
Allow each requirement to be linked to its corresponding design, source code, and test case for tracking.
Track the status of requirements and their changes throughout the project.

The above points are my summary of the successful implementation of the project after the system analyst experience, but also according to the other system implementation of the relevant domestic and foreign successful experience, has been summarized.

4. Types of requirements

The following definitions are definitions of common terminology in the field of requirements engineering.

Software requirements include three different tiers: business requirements, user requirements, and functional requirements (including non-functional requirements).

1. Business requirement reflects organizational or customer requirements for high-level systems and products, which are described in the Project view and scope documentation.

2. The user requirement document describes the tasks that the user must complete to work with the product, as described in the use cases document or scenario script description.

3. Functional requirements (functional requirement) define the software features that developers must implement to enable users to complete their tasks to meet business needs.
The functional requirements described in the Software Requirements Specification (SRS) fully describe the external behavior that the software system should have. Software Requirements specification plays an important role in development, testing, quality assurance, project management, and related project functions. For a large system, software functional requirements may only be a subset of the system requirements, since others may belong to subsystems (or software parts).

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

The following is an example of a word processing program that illustrates the different kinds of requirements. The business requirement may be: "The user can effectively correct the spelling errors in the document," The product's box cover may indicate that it is a spelling checker that meets the business needs. The corresponding user requirement might be "finding spelling errors in the document and replacing misspelled words with a list of alternatives provided." At the same time, the spelling checker has a number of functional requirements, such as finding and highlighting the wrong word, displaying a dialog box that provides a replacement word, and replacing the entire document scope.

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

5. Principles of demand analysis

A project team that does not attach importance to the demand process will reap the consequences. The defects in demand engineering will bring great risk to the success of the project, and the "success" here means that the product can meet the users ' expectations in a reasonable price and in a timely manner in function and quality. Some requirements risks are discussed below.

Some of the risks caused by inappropriate demand processes:

1. Not enough user participation

Customers often do not understand why it takes so much effort to gather demand and ensure quality, and developers may not take the user's participation seriously. The reason: First, because developers feel that working with users is not as interesting as writing code, but because developers feel that they already understand the needs of users. In some cases, direct contact with the user who actually uses the product is difficult, and the customer is less aware of their real needs. However, a representative user should be allowed to participate directly in the development team early in the project and go through the whole development process together.
System personnel in the practice process, there are some feelings, in the implementation of a company's projects, if not enough user participation, the system personnel to obtain the demand is one-sided, incomplete, so that the system at the beginning of the need to bury the risk.

2. Increasing user demand

In the development of the continuous replenishment of demand, the project becomes larger and larger than its planning and budget. The plan is not always consistent with the size and complexity of the project requirements, the risks, the development productivity, and the actual requirements changes, making the problem more difficult to solve. In fact, the root of the problem is the change in user needs and the changes that developers make to new requirements.

To minimize the scope of requirements change, it is necessary to start with a clear description of the project view, scope, objectives, constraints and success criteria, and use this as a frame of reference for evaluating requirements changes and new features. The description includes a change-control process to analyze the impact factors of each change, helping all stakeholders to understand the rationality of the business decision, namely why some changes have been made, and the time, resources, or characteristics of the corresponding compromise.

Continuous changes in product development will make its overall structure increasingly chaotic, patch code also makes the entire program difficult to understand and maintain. Inserting a patch code causes the module to violate strongly cohesive, loosely coupled design principles, especially if the project configuration management is not working well, and recovering the change and deletion features can cause problems. If you differentiate these features as early as possible, you can develop a more robust structure and adapt to it better. This design-time requirement change does not directly lead to patch code, but also helps to reduce the quality degradation caused by the change.

3. Ambiguous needs

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

One way to deal with ambiguous requirements is to organize teams responsible for reviewing requirements from different perspectives. Simply browsing through the requirements document does not solve the ambiguous problem. If different reviewers interpret the requirement description from different angles, but each reviewer really understands the requirements document so that ambiguity won't be discovered until late in the project, then finding out will make the correction costly.

4. Unnecessary features

"Superfluous" means that the developer tries to add some new features that are not covered by the "User appreciation" but the requirements specification. What happens most often is that users do not consider these functions to be useful, so that the effort expended on them is "wasted". Developers should develop solutions for their customers and provide them with innovative ideas that provide a balance between what the customer needs and the developer's technical viability within the allowable time frame, and the developer should strive to make the functionality simple and easy to use without the customer's consent to leave the customer's claim without permission.
Similarly, customers may sometimes demand features that look "cool" but lack practical value, while implementing these features can only be time-consuming and cost-effective. In order to minimize the harm of "superfluous", you should be sure that you understand why you should include these features and the "ins and outs" of these features, so that the requirements analysis process is always focused on the core functions that enable users to accomplish their business tasks.

5. Overly streamlined specification

Sometimes, the customer does not understand that the requirement analysis is so important, so that only a brief specification, only the product concept of content, and then let the developer in the progress of the project to improve, the result is likely to appear that the developer first build the structure of the product before completing the requirements description. This approach may be appropriate for sophisticated research-focused products or for situations where the requirements themselves are very flexible. But in most cases, this can be frustrating for developers (making them work under incorrect assumptions and under very limited guidance) and can also cause annoyance to customers (they can't get the product they envision).

6. Ignore the user classification

Most products are used by different people using their different characteristics, the use of frequent degrees also vary, users of education and experience level is not the same. If you can't categorize all of these major users early in the project, it's inevitable that some users will be frustrated with the product. For example, menu-driven actions are too inefficient for advanced users, but ambiguous commands and shortcut keys can make it difficult for unskilled users.

7. Inaccurate plans

According to statistics, the reason why the software cost estimation is inaccurate in the process of demand is mainly the following five points: Frequent demand change, missing demand, lack of communication with users, low quality requirement specification and imperfect demand analysis.
The correct response to the questions raised by inaccurate requests is "I'll tell you when I really understand your needs." Estimates of immature demand based on insufficient information and non-thought-provoking are easily related to some factors. To make an estimate, it is best to give a range. An unprepared estimate is usually given as a guess, but the listener considers it a promise. So we have to do our best to give achievable goals and stick to them.

6. Relationship between demand analysts and users

Excellent software products are built on the basis of excellent demand. High-quality demand comes from effective communication and cooperation between customers and developers. Typically, the relationship between a developer and a customer or client agent, such as a market person, can be an antagonistic relationship. The managers of both sides just want to own their own interests and shelve the needs of users to produce friction, in this case, will not bring a little benefit to both parties.

A partnership can only be established when both participants understand what they need to be successful and what they need to be successful partners. Because of the increasing pressure on the project, it is easy to forget that all stakeholders have a common goal. In fact, we all want to develop a business value that can meet the needs of users, but also to make developers feel satisfied with the excellent software products.

The software customer demand rights book lists 10 legal requirements for customers to communicate with analysts and developers during project requirements engineering implementation. Each of these rights corresponds to the obligations of the software developer and analyst. The software customer demand obligation also lists 10 obligations that customers should take in the process of demand. If you want, you can use it as a developer's entitlement book.

The customer has the following rights:

1: Require the analyst to use the expression that conforms to the customer's language habit
Demand discussions should focus on business needs and tasks, so use business terminology and you should teach it to analysts, and you don't necessarily have to understand the industry terminology of computers.

2: Ask analysts to understand the customer's business and objectives

By communicating with users to get the user's needs, analysts can better understand your business tasks and how to make them better meet your needs. This will help developers design the best software that really meets your needs and meets your expectations. To help developers and analysts, consider inviting them to see how you or your colleagues work. If a new development system is used to replace an existing system, developers should use the current system, which will help them understand how the system works, how it works, and where it can be improved.

3: Require analysts to write software requirements specification

The analyst will collate all information obtained from you and other customers to separate business requirements and specifications, functional requirements, quality objectives, solutions, and other information. These analyses will give you a copy of the software Requirements specification. This software Requirements specification provides an agreement between the developer and the customer for the product content to be developed. The software Requirements specification can be organized in a way that you think is easy to read and understand. Review the written specifications to ensure that they express your needs accurately and completely. A high-quality software Requirements Specification can help developers develop the products they really need.

4: Explanation of requests for results of demand work

Analysts may use a variety of charts as a complement to the textual software requirements specification. Because diagrams like workflow diagrams can clearly describe some aspects of the system's behavior. So the various charts in the requirements specification are of great value. Although they are not very difficult to understand, but you are probably not familiar with this. Therefore, the analyst can be asked to explain the role of each chart or other requirements of the development work and the meaning of the symbol, and how to check the chart for errors and inconsistencies.

5: Ask the developer to respect your opinion

If there is no mutual understanding between the user and the developer, there will be an obstacle to the discussion of the demand, and co-operation will make everyone "instead". Customers involved in the demand development process have the right to ask developers to respect them and value the time they spend on project success. Similarly, customers should respect and appreciate the efforts of developers to achieve this common goal of project success.

6: Require developers to provide advice on requirements and product implementation, take advice

In general, what customers call "requirements" is already a practical implementation solution, and analysts will try to understand the real business and its needs from these solutions, while also identifying existing systems that are not suitable for the current business, to ensure that the product is not ineffective or inefficient. Once you have a thorough understanding of what's going on in your business, analysts can sometimes offer a pretty good way to improve. Experienced and creative analysts can also raise valuable system features that some users have not discovered.

7: Describe the characteristics of the product easy to use

You can ask analysts to focus on the ease of use of the software while implementing functional requirements. Because these easy-to-use features or quality attributes enable you to accomplish tasks more accurately and efficiently. For example, customers sometimes require products to be "user-friendly" or "robust" or "efficient", but this is too subjective for developers to have practical value. The right thing to do is to ask and investigate the specific characteristics that the customer needs to be friendly, robust, and efficient.

8: Adjust requirements to allow reuse of existing software components

Requirements usually have some flexibility. Analysts may find that an existing software component matches the requirements you describe. In this case, the analyst should provide some choice to modify the requirements so that developers can reuse some existing software in the development of new systems. If there are opportunities for reuse, and you can adjust your requirements, you can reduce costs and save time, without having to strictly follow the original requirements for development. So if you want to use some of the existing commercially available components in your product, and they are not exactly right for the features you need, then a certain degree of demand flexibility is very important.

9: Access to a system that meets the customer's functional and quality requirements

Everyone wants the project to be successful. But this not only requires you to clearly tell developers all the information they need to "do what", but it also requires developers to communicate about clear trade-offs and limitations. Be sure to articulate your assumptions and potential expectations. Otherwise, developers will probably not be able to satisfy your product.

The client has the following obligations:

1: Explain your business to analysts

Analysts rely on the business concepts and terminology that you explain to them. But you can't expect analysts to be experts in the field, but only to let them really understand your problems and goals. Don't expect analysts to grasp the nuances and potential of your business, and they probably don't know the "common sense" that you and your colleagues take for granted.

2: Take time to clearly articulate and refine your needs

The customer is busy, often in the busiest time also need to participate in demand development. However, you are obligated to take the time to participate in brainstorming sessions, interviews or other needs-gathering activities. Sometimes the analyst may think that you understand your point of view, and later found that you need to explain. At this point, please be patient with the needs and needs of the refinement of the process of work, because it is a natural phenomenon of communication, and this is very important to the success of software products.

3: Accurate and detailed description of requirements

It is difficult to write a clear, accurate requirement document. Because processing details are annoying and time-consuming, it is easy to leave vague demands. However, this ambiguity and inaccuracy must be addressed in the development process. And you are the best person to make a decision to solve these problems. Otherwise, you have to rely on the developers to guess correctly. It is a good idea to temporarily add a pending (to being determined, TBD can also use the pinyin "DQD: Pending") in the requirements specification. This flag identifies where further information needs to be explored, analysed or added. Sometimes, however, it may be because a particular requirement is difficult to resolve or no one is willing to deal with it and the TBD mark. Try to articulate the content of each requirement so that the analyst can accurately write it into the software requirements specification. If you are not accurate in the moment, you have to allow the process of obtaining the necessary accurate information. The so-called prototyping technique is commonly used. With the development of the prototype, you can work with developers to revise and refine the requirements definition continuously.

4: Making decisions in a timely manner

As an architect builds a house for you, the analyst will ask you to make some choices and decisions. These decisions include the processing methods presented by multiple users or the selection of tradeoffs in the quality of conflict and accuracy of information. A customer who has the right to make a decision must take the initiative to deal with it and make decisions as soon as possible. Because developers usually have to wait until you make a decision to act, and this wait can delay the progress of the project.

5: Respect the needs of developers and cost evaluation

All software features have their cost price, and developers are best suited to budget these costs (although many developers are not good at estimating forecasts). Some of the product features you want may not be technically feasible, or can be very costly to implement. While some requirements try to demand impossible performance in the operating environment or try to get some data that is not available at all, developers will make negative comments and you should respect their opinions. Sometimes, you can re-give a technically feasible, cost-effective demand, for example, it is not feasible to ask for an action to occur in an "instant", but to change a more specific time requirement ("within 50ms", but without an accurate technical analysis can not easily be concluded), this will be achieved.

6: Prioritize requirements

Most projects do not have enough time or resources to implement every detail of functionality. Decide which features are necessary, which are important, which are good, and are the main components of demand development. It is up to you to prioritize your requirements, because it is not possible for developers to prioritize requirements based on your point of view. The developer will prioritize you to provide information about the cost and risk of each requirement. When you prioritize, you help developers ensure that the best results are achieved with minimal expense at the right time. Under Time and resource constraints, developers ' opinions should be respected as to how much of the required features can be completed or completed. Although no one wants to see that the needs that they want are not being fulfilled in the project, they have to face this reality. Business decisions sometimes have to be prioritized to narrow the scope of the project or to extend the duration, or to increase resources, or to find compromises in quality.

7: Review requirements documentation and prototypes

As we will discuss in Chapter 1th 4, whether formal or informal, reviewing the requirements document will help improve the quality of the software. Allowing customers to participate in the review to truly identify the requirements of the document is complete, correct description of the desired characteristics. The review also provides an opportunity for client representatives to bring feedback to the needs analysts to improve their work. If you think that the required documentation is not accurate enough, you have an obligation to inform the analyst as soon as possible and provide recommendations for improvement. By reading the requirements specification, it is hard to imagine what the actual software looks like. A better approach is to develop a prototype for the product first. This allows you to provide more valuable feedback to developers, helping them to better understand your needs. It must be recognized that the prototype is not an actual product, but the developer can transform it into a fully functional system.

8: Changes in demand need to be contacted immediately

Constant changes in demand will have a serious negative impact on the completion of high quality products within a predetermined schedule. Change is unavoidable, but the more advanced the change is in the development cycle, the greater the impact. Changes lead not only to costly rework, but also to delays, especially when the general structure has been completed and new features need to be added. So once you find that you need to change your needs, be sure to notify the analyst immediately.

9: Follow the process of the development organization to handle the change in requirements

In order to minimize the negative impact of the change, all participants must follow the project's change control process. This requires that all proposed changes are not discarded, that the changes to each requirement are analyzed, taken into consideration, and that the appropriate decision is made to determine the introduction of certain changes into the project.

10: Respect the needs of the developers to apply the engineering process
The most challenging thing in software development is collecting demand and determining its correctness. The method used by the analyst is reasonable. You may think that the demand process is not a good deal, but believe that the time spent on demand development is "valuable". If you understand and support the technology that analysts use to collect, write, and ensure the quality of the requirements documentation, the process will be smoother. Ask analysts why they want to collect certain information or participate in requirements-related activities.

System analysts may encounter the following issues during the development process, and some busy customers may be reluctant to actively participate in the requirements process, and lack of customer involvement will likely lead to undesirable products. It is important to ensure that key players in demand development understand and accept their obligations. If differences are encountered, the mutual understanding of their obligations can be achieved through consultation, thus reducing future frictions.

7. Requirements Documentation

The end result of demand development is that customers and development teams agree on the products to be developed. The protocol synthesizes business requirements, user requirements, and software functional requirements. As we saw earlier, the Project view and scope document contain the business requirements, while the use of the instance document contains the user requirements. You must write the functional requirements document derived from the usage instance, and also write the non-functional requirements documentation for the product, including the quality attributes and external interface requirements. Only when these documents are written in a structured and readable manner, and approved by the stakeholders of the project, can all personnel be assured that the requirements they endorse are reliable.

You can use the following three ways to write software Requirements specification:

Write text-based documents in a good structured and natural language.

Create graphical models that depict the transformation process, the state of the system, and the changes between them, data relationships, logical flows, or object classes and their relationships.

Write formal specifications, which can be defined by using mathematically accurate formal logical language.
Due to the strong rigor and precision of formal specifications, only a handful of software developers are familiar with the formal language used, let alone the customer. Although structured natural language has many drawbacks, in most software engineering it is still the most realistic way to write requirements documents. Text-based software requirements specifications that contain both functional and non-functional requirements have been accepted by most projects. The graphical analysis model enhances the software requirements specification by providing a different view of the requirements.

The software Requirements specification is not only the basis for system testing and user documentation, but also the basis for planning, designing, and coding all sub-series projects. It should describe as fully as possible the expected external behavior of the system and the user's visual behavior. In addition to design and implementation limitations, the software Requirements specification should not include details of design, construction, testing, or engineering management. Many readers use the software Requirements specification to achieve different purposes:

Customers and marketing departments rely on it to understand the products they can offer.
The project manager plans and forecasts the schedule, workload, and resources based on the products that are included in the software Requirements specification.
The software development team relies on it to understand the products they will be developing.
The Test team uses a description of the software requirements specification to develop test plans, test cases, and test procedures.
The software maintenance and support staff understands what part of the product is doing according to the requirements specification.
The product release group prepares customer documentation, such as user manuals and help screens, based on requirements specification and user interface design.
Trainers prepare training materials according to requirements specification and user documentation.

The software Requirements specification indicates that the final outcome of the product requirement must be comprehensive: all needs must be included. Developers and customers cannot make any assumptions. If any of the expected functional or non-functional requirements are not written to the software requirements specification, it will not be part of the agreement and cannot appear in the product.

I've seen a project that suddenly received a report from a tester about a bug disaster. The result is that they are testing older versions of the software Requirements specification, and where they feel wrong is the product's unique features. Their testing work was futile because they had been looking for the wrong system behavior in the old version of the software Requirements specification.

In writing the software Requirements specification, readers are expected to keep the following recommendations in mind:

The numbering of sections, subsections, and individual requirements must be consistent.
Leave the text comment area in the right section.
Allow spaces to be used without restrictions.
Use various visual accent markers correctly (for example, bold, underline, italic, and other different fonts).
Creating catalog tables and Index tables helps readers find the information they need.
Specify numbers and identification numbers for all charts and tables, and can be consulted by number.
Use cross-referencing features in a word processor to look up other items or locations in a document, rather than by page numbers or section numbers.

To meet the traceability and modifiable quality standards of the software Requirements specification, you must uniquely identify each software requirement. This allows you to review specific requirements in the traceability matrix for change requests, modification history, cross-references, or requirements. Because it is not enough to use a single list of items to achieve this, I will describe several different requirements identification methods and clarify their pros and cons. You can choose the method that works best for you.

(1) The simplest way to sequence numbers is to give each requirement a unique serial number, such as SRS-13. When a new requirement is added to the business Requirements management tool's database, these management tools assign a serial number to it (many of these tools also support hierarchical numbering). The prefix of the serial number represents the requirement type, for example, the SRS represents the software requirement description. Since the serial number cannot be reused, deleting the requirement from the database does not release the serial number it occupies, and the new requirement can only get the next available serial number. This simple numbering method does not provide a logical or hierarchical distinction between any related requirements, and the identity of the requirement cannot provide any information about the content of each requirement.

(2) Hierarchical coding This is perhaps the most common method. If functional requirements appear in the Software Requirements specification, 3rd. 2 sections, they will have an identification number such as 3.2.4.3. The more numbers in the identification number indicate that the requirement is more detailed and that it is at a lower level. Even in a medium-sized software Requirements specification, these identification numbers are extended to many digits, and these identifiers do not provide any information about the purpose of each requirement. If you want to insert a new requirement, then the sequence number of all requirements will be increased after the requirement. Delete or remove a requirement, then the sequence number of all requirements will be reduced after the requirement is in the same part. But the references elsewhere will be confusing, and an improvement to this simple hierarchical numbering is to have a hierarchical numbering of the main parts of the requirement, and then identify the single functional requirement in each section with a sequence number with a short text code. For example, the software Requirements specification may contain "section 3.2.5-editing features", and this section is written as a submodule document and then configured for management.

Sometimes, you feel a lack of certain information about a particular need. Before resolving this uncertainty, it may be necessary to negotiate with the customer, check the interface with another system, or define another requirement. Use the "Pending" (to be determined, TBD, or DQD) notation as standard indicators to emphasize the deficiencies of these requirements in the software Requirements specification. In this way, you can find the part of the software requirements specification that you want to clarify requirements. Record who will solve the problem, how to solve it, and when to resolve it. Number each TBD and create a TBD list, which helps you easily track each item.

All TBD issues must be addressed before continuing with the fabric requirements collection, as any remaining uncertainties will increase the risk of errors and rework of requirements. When a developer encounters a TBD problem or other ambiguity, he may not return to the original requirement to resolve the problem. Most developers speculate on it, but it's not always the right thing to do. If there are TBD issues unresolved and you need to continue with the development effort, defer the implementation of these requirements as much as possible, or open-ended issues that address these needs, making this part of the product easy to change.

Writing excellent requirements documents is not a fixed approach, preferably based on experience. You can benefit from the problems you have encountered in the past. Many requirements documents can be improved by using effective technical writing styles and using user terminology rather than computer terminology.
When you write excellent requirements documentation, you will want to keep the following suggestions in mind:

Keep the statements and paragraphs short.
Adopt the expression of the active voice.
Write complete sentences with the correct syntax, spelling, and punctuation.
The terms used should be consistent with those defined in the glossary.
The requirement statement should have a consistent style, such as "system must ..." Or "User must:", followed by a behavioral action and observable result. For example, the warehouse management subsystem must display a list of inventory that is in stock in the requested warehouse. ”

In order to reduce uncertainty, vague and subjective terminology, such as user-friendliness, simplicity, effectiveness, the latest technology, superior and acceptable, must be avoided. When customers say "user-friendly" or "fast," you should be clear about what they really mean and clarify the user's intentions in the requirements.

Avoid using comparative vocabulary to quantify the degree of improvement required or to clarify the maximum and minimum values acceptable for some parameters. When the customer indicates that the system should "process", "support" or "manage" something, you should be able to understand the customer's intentions. Because the requirements are written hierarchically, it is possible to decompose the top-level ambiguity into the lower levels until the ambiguity is eliminated.

The author of the document should not concentrate multiple requirements in a lengthy narrative paragraph. Conjunctions such as "and", "or" in a requirement indicate that the part concentrates on multiple requirements. It is important to remember not to use conjunctions such as "and/or", "et cetera" in the requirement description.

8. The process of demand analysis

Demand acquisition is the first step in bridging the problem and its final solution. An essential result of acquiring requirements 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 requirements. Participants need to be able to design the system only after they understand the problem, otherwise, any improvements to the requirements definition must be heavily reworked. Centralizing demand acquisition on user tasks-rather than focusing on user interfaces-helps prevent the development team from failing to handle design problems hastily.

Requirements acquisition, analysis, writing requirements specification and validation do not follow a linear sequence of activities that are separated, incremental, and iterative. When you work with clients, you will ask questions and get the information they provide (demand access). At the same time, you will process this information to understand them, divide them into different categories, and link customer needs to potential software requirements. Then, you can make the customer information structured and written into documents and diagrams. Next, you can have the Customer representative review the document and correct any errors. These four processes run through the entire phase of demand development.

Because of the differences between software development projects and organizational culture, there is no simple, formulaic approach to demand development. Here are 1 4 steps that you can use to guide your requirements development activities. For any subset of requirements, once you have completed the 13th step, you can confidently proceed with the design and construction of each part of the system, as you will develop a good product:

1. Define the view and scope of the project.
2. Determine the user class.
3. Identify the appropriate representative in each user class.
4. Identify the needs of decision makers and their decision-making processes.
5. Select the requirements you use to acquire the technology.
6. Use demand acquisition technology to develop and prioritize usage instances that are part of a system.
7. Collect information about quality attributes from users and other non-functional requirements.
8. Elaborate the use of examples to integrate them into the necessary functional requirements.
9. Review the description and functional requirements of the usage examples.
10. If necessary, an analytical model is developed to clarify the needs of the participants in the requirements acquisition.
11. Develop and evaluate user interface prototypes to help visualize requirements that are not yet understood.
12.