Learning: Software Requirement Specification

 

 

Software requirementsYes (1) The conditions or capabilities required by the user to solve the problem or achieve the goal ). (2) systems or system components shall meet the conditions or capabilities required by contracts, standards, norms or other formal provision documents. (3) A document describing the conditions or capabilities described above (1) or (2. (Defined in the IEEE software engineering standard vocabulary (1997) I. Development of software requirements Demand engineering develops with the development of computers. In the early stage of computer development, the software scale is not large.CodeWriting, demand analysis is rarely valued. Later, Software Development introduced the concept of lifecycle, and demand analysis became its first stage. As the scale of the software system expands, demand analysis and definition become more and more important throughout the software development and maintenance process, directly related to the success of the software. People gradually realize that the demand analysis activity is no longer limited to the initial stage of software development. It runs through the entire lifecycle of system development. In the middle of 1980s, a sub-domain of software engineering-Requirement Engineering (re) was formed ). Demand engineering has become one of the hot topics of research since 1990s. An international demand engineering seminar (isre) will be held every two years from January 1, 1993, and an international demand Engineering Conference (ICRE) will be held every two years from January 1, 1994 ), in 1996, Springer-Verlag published a new publication, Requirements engineering. Some teams on demand engineering have also been established, such as European RENOIR (Requirements Engineering Network of International Cooperating research groups) and started their work. 2. Layers of software requirements The following are definitions of common terms in the field of demand engineering. Software requirements include three levels-business requirements, user requirements, and functional requirements-and non-functional requirements. 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. The user requirement document describes the tasks that must be completed by the user to use the product. This is described in the use case document or solution script (scenario) description. Functional requirements define the software functions that developers must implement so that users can complete their tasks and meet business needs. A feature is a set of logical functional requirements that provide processing capabilities and meet business needs. Relationship between components of software requirements. In addition, the specification of software requirements should include non-functional requirements, which describe the behaviors and operations performed by the system to users. It includes standards, specifications, and contracts that must be followed by the product, details of the external interface, performance requirements, design or implementation constraints and quality attributes. The constraint refers to the limitation on the design and construction of software products by developers. Quality Attributes describe product features from multiple perspectives to reflect product features. It is extremely important for users and developers to describe products from multiple perspectives. It is worth noting that the requirements do not include 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. Frederick Brooks's classicArticle"No silver bullet: essence and accidents ofsoftware engineering" fully demonstrates the important role of the demand process in software projects: 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. In most software systems, end users may not know what their needs are. If your user tells you that this is all about your needs, don't trust him and continue to ask questions until you are exhausted. Although it sounds incredible, this is a lesson. In my project, no one of the users called me when the software was nearing completion and said, "I have read your software, I think I have to make some changes. In those days, I even got a call-tone phobia. Iii. Demand risks The following lists some very dangerous methods used in demand analysis. If you find that some of your methods are similar, give yourself some time and think about them, these practices will have a fatal impact on your software. 1. Insufficient user participation Customers often do not understand why it takes so much effort to collect requirements and ensure the quality of requirements, and developers may not attach importance to user participation. The reason is: first, it is not as interesting to write code as it is to work with users; second, it is because developers feel that they have understood the needs of users. In some cases, it is difficult for the customer to directly contact the user who actually uses the product, and the customer does not understand the real needs. However, representative users should be directly involved in the development team in the early stage of the project and go through the entire development process together. The most important thing is that the user must pay attention to his software and make him understand that if he fails, his loss will be the greatest (of course, your loss will not be small, but at this time you must let him pay attention to this job ). If the user does not pay enough attention to it, find a solution. Otherwise, you will not need to continue. 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. This makes the problem more difficult to solve. In fact, the root cause of the problem is changes in user requirements and changes made by developers to new requirements. To minimize the scope of demand changes, the project view, scope, objectives, constraints, and success criteria must be clearly stated at the beginning, this description serves as a reference framework for evaluating demand changes and new features. The description includes the change control process for analyzing the impact factors of each change, which helps all risk owners understand the rationality of business decisions, that is, why some changes are made, time, resource, or feature compromise. Continuous changes in product development will cause increasingly disordered overall structure and patch code will also cause the entireProgramDifficult to understand and maintain. Inserting the patch Code violates the strong cohesion and loose coupling design principles. In particular, if the project configuration management is not complete, revoking the change and deletion features will cause problems. If you differentiate the features that may bring changes as soon as possible, you can develop a more robust structure and better adapt to it. In this way, the requirement changes in the design phase will not directly cause the patch code, but will also help reduce the quality reduction caused by changes. The worst thing is that users feel sorry if they don't add any more features. I have seen a data warehouse Phase I project and there is no well defined scope in the design phase. When I asked the project manager this question, he thought it was all done, the contract was also clearly written and not paid much attention. However, the user's suggestion for modification is far beyond the scope, and the project time is doubled. The entire project team members were exhausted, but they repeatedly received complaints from users that the project failed. 3. Ambiguous requirements Ambiguity is the most terrible problem in the Requirement Specification Description (Lawrence 1996 ). 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. The inevitable consequence of ambiguous demands is rework-redo what you think is done well. Rework will consume 40% of the total development cost, and 70% ~ 85% of redo results from demand side errors (leffingwell 1997 ). Imagine what would happen if you could reduce the number by half? You can develop products faster, develop more and better products in the same time, and even occasionally go home to rest. One way to deal with ambiguous needs is to organize teams responsible for reviewing requirements from different perspectives. Simply browsing the requirement document cannot solve the problem of ambiguity. If different reviewers explain the requirements from different perspectives, but each reviewer truly understands the requirements document, the ambiguity will not be discovered until the project is later, if we find it again, it will make the correction very costly. 4. Unnecessary features "Adding to the image" refers to the new features that developers try to add to the "user appreciation" but are not involved in the Requirement Specification Description. It is often the case that users do not think these functions are very useful, so that the effort spent on them is "useless. Developers should design solutions for customers and provide them with innovative ideas. Specific functions should be balanced between the customer's needs and the technical feasibility of developers within the allowed time limit, developers should strive to make the functions simple and easy to use, instead of leaving the customer's requirements without the customer's consent and making their own claims. Similarly, customers may sometimes require functionality that looks "cool" but lacks practical value. However, implementing these features only consumes time and costs. In order to minimize the harm caused by "image farming", you should be sure that you understand why these features should be included and the "ins and outs" of these features ", in this way, the demand analysis process always focuses on the core functions that allow users to complete their business tasks. Keep in mind that the software's success standard is to determine whether to solve the user's problems, rather than having multiple cool functions. 5. Too simplified specifications Sometimes, the customer does not understand the importance of requirement analysis. Therefore, the customer only provides a brief description of the specifications, which only covers the concept of the product, then let the developers improve the project progress. what is likely to happen is that the developers first establish the product structure and then complete the Requirement Description. This method may be suitable for cutting-edge research products or needs (McConnell 1996), but this is not the case for most commercial applications. In most cases, this will bring setbacks to developers (so that they can work under incorrect assumptions and extremely limited guidance ), it will also bring troubles to customers (they cannot get the products they imagined ). 6. the user category is ignored. Most products use different features by different people, and their usage frequency is also different. The user's educational level and experience level are also different. If you cannot classify all these major users in the early stages of the project, some users will be disappointed with the product. For example, menu-driven operations are too inefficient for advanced users, but undefined commands and shortcut keys make them difficult for unskilled users. 7. inaccurate plan "The above is my opinion on the new product. OK. Can you tell me when you will finish it ?" Many developers have encountered this problem. A lack of understanding of demand analysis will lead to overly optimistic estimates, which may cause a lot of trouble when overspending is inevitable. According to reports, the main reasons for the inaccurate estimation of software costs during the demand process are as follows: frequent demand changes, missing demands, insufficient communication with users, low quality requirement specification descriptions, and imperfect Demand Analysis (Davis 1995 ). The correct response to the question asked for inaccurate requirements is "I will tell you when I really understand your needs ". The estimation of immature requirements based on inadequate information and unthought-provoking requirements is easily caused by some factors. To make an estimate, it is best to give a range (for example, the best case, the most likely, the worst case) or a trustable degree (I have 0% confidence, can be completed within 8 weeks ). 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. 4. What are excellent demands? There are many articles about software requirements, and the requirements vary. Here I want to use the concept of NASA's software development process. The software requirements process standards are: Clear), complete, consistent, and testable. In addition, there are other concepts, such as trackable and modifiable. Clear: at present, most demand analysis still uses natural language (because communication with users becomes a major problem if formal language is used, this means that the customer must first perform formal language training before developing the software. This is unrealistic ). The biggest drawback of natural language demand analysis is its ambiguity. Therefore, we have to impose certain restrictions on the language used in the requirement analysis. For example, try to use a simple expression of Subject + action. To put it bluntly, the description in the demand analysis looks like a child who has just learned to write. Do not use questions or modify these gorgeous expressions. In addition to the ambiguity of language, it is a computer term. The most important part of requirement analysis is to communicate with users. However, most users are not computer professionals. If you use a line in requirement analysis, it will cause difficulties for users to understand. For example, if you want to create a bank's credit card system, you can describe the software requirement as follows: the Bank's card Department manages credit cards, and each credit card belongs to only one account. The credit card has a card number and balance. A credit card has multiple transaction records. Complete: nothing is worse than finding a demand that is close to completion than software development. The integrity of the demand is very important. It is a nightmare to imagine that the demand has to be reworked due to omission. Unfortunately, the omission of requirements often occurs, not just your problems, but also users who don't know what to do. It is very difficult to ensure the integrity of the demand. It involves all aspects of the demand analysis process, from initial planning to the final demand review. As for the detailed discussion of integrity, we will discuss it in the following chapter. Now you only need to think hard about the disadvantages of integrity until you get out of a cold sweat. Are you out? Okay, let's continue. Consistency: consistency is also a big concept and it is difficult to make it clear in a few words. Do you still remember the level of requirements we mentioned at the beginning? Simply put, user needs must be consistent with business needs, and functional requirements must be consistent with user needs. Strictly observe the consistency between different levels to ensure that the last developed software system will not deviate from the initial goal. In the implementation process, we must also refine the consistency relationship. For example, the user requirement cannot exceed the previously specified range. Testable: When do you think a project test starts? Some people say that it starts after the encoding is complete. More clearly, unit tests are conducted at the same time during encoding, and the system tests are conducted after encoding. None of these errors. However, the test starts from the requirement analysis process. Requirement analysis is the input and reference of the test plan. This requires that the requirement analysis be testable. What is testability? "We need to use a new system to automate report processing". Do you think this requirement is testable? Of course not. What are the reports? What are the criteria for automated processing? These are not described in the requirements. Therefore, this requirement cannot be tested, that is, it is not testable. Speaking of this, you may understand the previous requirements to ensure the testability of the requirements. The fact is that only when all requirements of the system can be tested can the software always focus on the needs of users and ensure that the software system is successful. 5. Software Requirement Process Software Requirement Engineering mainly includes two aspects: requirement development and requirement management. Requirement development can be further divided into four stages: requirement acquisition, requirement analysis, requirement specification writing, and requirement verification. The phases are described as follows: Demand acquisition phase: At this stage, the core task is to determine the needs of three layers. The business layer should emphasize the business overall goal and scope of use, and the user layer should emphasize the clarification of user workflow, the functional layer also collects non-functional requirements such as system running environment restrictions. Different users at different times may have different requirements due to different business objectives and scope of use. At the same time, there may be different forms of presentation due to the absence of an agreement. To address the above problems, we must first determine the user representatives and divide their primary and secondary roles in the needs. Secondly, we must determine the entire development process of the needs, at last, it should be clarified that the requirements at different levels should be issued in an agreed form for communication and issue checks between the two parties. Demand analysis stage: The core task of this phase is to determine and improve the needs. In the initial stage, a large number of demands are often not systematic, incomplete, or even individual requirements are incorrect and unnecessary. Only by refining, analyzing, and carefully reviewing requirements, can they communicate with each other, use appropriate forms, such as drawing business target association diagrams, drawing functional structures, compiling data dictionaries, and compiling user instances, understand the meaning of the requirement and identify the errors, omissions, or deficiencies. In particular, use specific symbols to identify the priority of the requirement. Requirement Specification writing stage: The tasks at this stage emphasize the compilation of the collected and analyzed requirements to form a standardized visual document, that is, the software requirement specification. Requirement verification stage. This stage is the final stage of demand development. It is necessary to determine whether the requirements documents prepared in the third stage are consistent with the expected results and whether they meet the evaluation criteria for high-quality requirements. This work can be completed through review. The review may review the requirements based on the personal preferences and habits of the user representative, or follow strict steps in the industrial quality control measures, this mainly depends on the project size, requirements, and importance of each part. Requirement management requires "establishing and maintaining contracts with customers in software engineering ". Such a contract is included in the Requirement Specification Description and model. 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. Estimate the impact of changes and negotiate new commitments (agreements) on this basis ). So that each requirement can correspond to its design,Source codeAssociate with test cases for tracking. Track demand status changes throughout the project. Vi. software requirements Software Requirement analysis methods are divided into the following four types: structured methods, object-oriented methods, control-oriented methods, and data-oriented methods. Due to the limited length of the article, this article will briefly discuss the three aspects of the structured method, the object-oriented method, and the RUP. 1. Structured Analysis Method The structured analysis (SA) method is a simple functional decomposition method that gradually improves from top to bottom. The analyst first uses the context chart (DFD) to represent all input/output of the system, and then repeatedly improves the system, each refinement represents a more detailed DFD to establish a DFD level about the system. To save the information in DFD, you can use a data dictionary to access related definitions, structures, and purposes. The SA method is a widely used engineering technology. It has good separation and abstraction capabilities, and finds an intermediate language for the development team, which is easy for software personnel to master. However, it is still a certain distance from the application field, and it is difficult to directly apply the field to the public and software design. Therefore, it has brought some difficulties for the development team to exchange ideas. 2. Object-Oriented Analysis Methods Object-oriented (OO) analysis is based on system objects and interactions between objects, this allows us to define and communicate requirements with three basic method frameworks: objects and their attributes, classification structures, and collection structures. The object-oriented problem analysis model is described from three aspects: Object Model (static structure of object) and dynamic model (sequence of object interaction) and function model (data transformation and functional dependency ). The abstract principles, hierarchy principles, and segmentation Principles of Demand engineering are also applicable to object-oriented methods, that is, object abstraction and functional abstraction principles are the same, from advanced to low level, from logic to physics, step by step. each level of abstraction repeats the process of Object Modeling (Object Recognition), dynamic modeling (Event Recognition), and functional modeling (Operation recognition) until each object instance is physically (Program encoding) so far. Object-oriented Demand Analysis (oora) uses some basic concepts to establish corresponding models to express different aspects of the target system. Although different methods use different models, the following five basic models are used to describe software requirements: Overall-partial model: This model describes how an object (class) is composed of Simple objects (classes. The ability to describe a complex object (class) into a structure composed of several interactive objects (classes) is a prominent advantage of the OO approach. This model is also called an aggregation model. Classification Model: A classification model describes the inheritance relationship between classes. Different from the aggregation relationship, it indicates that a class can inherit the components of another or other classes to achieve the reuse of points in the class. Class-object model: the analysis process must describe the behavior of objects belonging to each class. The details of this behavior description can be determined based on the actual situation. Only the input, output, and functions of behaviors can be described, you can also use a comparative method to accurately describe the input, output, and corresponding types, or even use a pseudo code or a small description to describe them in detail. Object interaction model: an object-oriented system model must describe the interaction methods of objects. As mentioned above, object interaction is implemented through message transmission. Real-person object interaction can also be seen as a reference relationship between object behaviors. Therefore, the object interaction model depicts the message streams between objects. There are different message stream description analyses corresponding to different levels of detail. Analysts should choose based on the specific museum conditions. Generally, a detailed object interaction model can describe the messages between objects and their flows, and describe the objects and behaviors that the message will be activated. An object interaction model that is not very detailed only indicates that there is a message between objects and its flow direction. There is also a situation between the two. State model: In the state model, an object is regarded as a finite state machine. The transition from one State to another is called state transformation. The state model describes the behavior of an object as a path between different States. It can also describe the creation and abolition of objects in a dynamic system, and return the lifetime of an object from the creation of an object to the abolition of an object. The state model can be a table in the form of a decision table or a decision matrix. 3. software requirements based on RUP Rational Unified Process is a process product developed and maintained by rational. As an engineering software development process, RUP provides a disciplined approach for assigning tasks and responsibilities in development institutions. RUP is not just a simple process, but a general process framework, it can be used for different types of software systems, different application fields, different types of organizations, different functional levels, and different project scales. The following three keywords can be used to demonstrate the highlights of RUP: case-driven, architecture-centric, iterative, and incremental. These are unique to the RUP and equally important. The architecture provides a structure to guide the work in the iteration process, and the use case determines the work that the target well drives each iteration. The basis for requirement analysis is to obtain the user's needs. To do this, you must establish a business model by describing business rules and business logic, clarify the business process and standardize and optimize it. When establishing a business model for a system, we should describe its features in three aspects: functions, behaviors, and data, which correspond to these features. 4. Comparative Analysis of Software Requirement Methods Based on the above analysis, we can see that the differences between the structured analysis method and the object-oriented analysis method are mainly reflected in two aspects: * The system is divided into different methods. The former describes the processing of a group of interactions, and the latter describes a group of interaction objects. * The Interaction Between subsystems is described in different ways. The interaction between processing objects is expressed through inaccurate data streams, while the interaction between processing objects is expressed through message transmission. Therefore, the results of object-oriented software requirement analysis can better portray the real world and handle complex problems. objects are more stable than processes, facilitating maintenance and reuse. (Source: UML software engineering, blog China) VII,Software Requirement Specification The software requirement specification is prepared to give both users and software developers a common understanding of the initial provisions of the software and to make it the basis of the entire development work. The requirements for preparing the software requirement specification are as follows: 1 Introduction 1.1 Writing Purpose Describe the purpose of writing this software requirement specification and point out the intended readers. 1.2 Background Note: A. Name of the software system to be developed; B. the submitter, developer, user, and computing center or computer network that implements the software; C. Basic relationships between the software system and other systems or institutions. 1.3 Definition Lists the definitions of specialized terms used in this document and the original phrases of the foreign acronyms. 1.4 references List useful references, such: A. approved plans and tasks or contracts and approvals from higher authorities for this project; B. Other published documents of the project; C. Documents and materials referenced everywhere in this document, including the software development standards to be used. Lists the titles, document numbers, publication dates, and publishing units of these documents, indicating the source of these documents. 2 task Overview 2.1 goals Describe the intent, purpose, scope of application of the software development, and other background materials related to the software development to the reader. Explains the relationship between the developed software and other related software. If this software product is an independent software and all content is self-contained, this is described. If the defined product is an integral part of a larger system, the relationship between the product and other components of the system should be described, to this end, you can use a block diagram to describe the composition of the system and the contact and interface between the product and other parts. 2.2 user features Describe the features of end users of the software, fully describe the educational level and technical expertise of operators and maintenance personnel, and the expected frequency of rejection of the software. These are important constraints of software design. 2.3 assumptions and constraints List the assumptions and constraints for the software development work, such as funding restrictions and development periods. 3 Requirements 3.1 functional provisions Use a list (for example, an IPO table in the form of an input, processing, or output table) to describe the functional requirements of the software in a quantitative and qualitative manner one by one, describe the inputs, processes, and outputs. Describe the number of terminals to be supported by the software and the number of concurrent operations to be supported. 3.2 Performance Requirements 3.2.1 precision The requirements on the input and output data accuracy of the software may include the precision during transmission. 3.2.2 time characteristics requirements Specifies the time requirements for the software, such: A. response time; B. Update the processing time; C. Data Conversion and transfer time; D. Problem Solving time; and other requirements. 3.2.3 flexibility Describes the flexibility required for the software, that is, the ability of the software to adapt to these changes when the demand changes, such: A. Changes in operation methods; B. Changes in the runtime environment; C. Changes in interfaces with other software; D. Changes in accuracy and validity period; E. Planned changes or improvements. Specific designs for the purpose of providing such flexibility should be noted. 3.3 output requirements Describe the input and output data types, and describe the media, format, value range, and accuracy one by one. The data output of the software and the control output that must be indicated are explained and used as an example, including the hard copy report (normal result output, status output, and abnormal output) and the description of the graphic or display report. 3.4 Data management capability requirements Describe the number of volumes and records to be managed, the size and size of tables and volumes, and estimate the storage requirements of data and its components based on foreseeable growth. 3.5 troubleshooting requirements List possible software and hardware faults, as well as the consequences for various performance and fault handling requirements. 3.6 Other Special Requirements For example, user organizations require security and confidentiality, convenient use, and special requirements for maintainability, complementarity, accessibility, reliability, and conversion of the operating environment. 4. runtime environment requirements 4.1 Devices List the hard devices required to run the software. Describes the new devices and their special functions, including: A. Processor Model and memory capacity; B. External storage capacity, online or offline, media and its storage format, device model and quantity; C. Model and quantity of input and output devices, online or offline; D. Model and quantity of data communication equipment; E. function keys and other dedicated hardware 4.2 support software List the supported software, including the operating system to be used, compiled (or compiled) programs, and test support software. 4.3 Interface Describes the interfaces and data communication protocols between the software and other software. 4.4 Control Describes how to control the running of the software and the control signals, and describes the sources of these control signals. Article by: http://hi.baidu.com/zwl232/blog/item/f5e38794f595141ed31b7057.html