《软件工程概论》课程教学资源（参考资料）Guide to the Software Engineering Body of Knowledge（SWEBOK）Version 3.0

Software Requirements 1-7 may result in a richer and more consistent 4.Requirements Analysis set of requirements than might otherwise [1#,c4sl,c4s5,c10s4,c12s5] be achievable.However,meetings need to 2*,c7,cll,cl2,cl7刀 be handled carefully (hence the need for a facilitator)to prevent a situation in which This topic is concerned with the process of ana- the critical abilities of the team are eroded lyzing requirements to by group loyalty,or in which requirements reflecting the concerns of a few outspoken detect and resolve conflicts between (and perhaps senior)people that are favored requirements; to the detriment of others. discover the bounds of the software and how Observation.The importance of software it must interact with its organizational and context within the organizational environ- operational environment: ment has led to the adaptation of observa- elaborate system requirements to derive soft- tional techniques such as ethnography for ware requirements. requirements elicitation.Software engineers learn about user tasks by immersing them- The traditional view of requirements analysis selves in the environment and observing how has been that it be reduced to conceptual model- users perform their tasks by interacting with ing using one of a number of analysis methods. each other and with software tools and other such as the structured analysis method.While resources.These techniques are relatively conceptual modeling is important,we include the expensive but also instructive because they classification of requirements to help inform trad- illustrate that many user tasks and business eoffs between requirements (requirements clas- processes are too subtle and complex for sification)and the process of establishing these their actors to describe easily. tradeoffs (requirements negotiation). User stories.This technique is commonly Care must be taken to describe requirements used in adaptive methods (see Agile Meth- precisely enough to enable the requirements to ods in the Software Engineering Models be validated,their implementation to be verified. and Methods KA)and refers to short,high- and their costs to be estimated level descriptions of required functionality expressed in customer terms.A typical user 4.1.Requirements Classification story has the form:"As a <role>,I want <goal/desire>so that <benefit>."A user Requirements can be classified on a number of story is intended to contain just enough infor- dimensions.Examples include the following: mation so that the developers can produce a reasonable estimate of the effort to imple- Whether the requirement is functional or ment it.The aim is to avoid some of the waste nonfunctional (see section 1.3,Functional that often happens in projects where detailed and Nonfunctional Requirements). requirements are gathered early but become Whether the requirement is derived from one invalid before the work begins.Before a user or more high-level requirements or an emer- story is implemented,an appropriate accep- gent property (see section 1.4,Emergent tance procedure must be written by the cus- Properties),or is being imposed directly on tomer to determine whether the goals of the the software by a stakeholder or some other user story have been fulfilled. source. Other techniques.A range ofother techniques Whether the requirement is on the product for supporting the elicitation of requirements or the process (see section 1.2,Product and information exist and range from analyzing Process Requirements).Requirements on the competitors'products to applying data min- process can constrain the choice of contrac- ing techniques to using sources of domain tor,the software engineering process to be knowledge or customer request databases. adopted,or the standards to be adhered to

Software Requirements 1-7 may result in a richer and more consistent set of requirements than might otherwise be achievable. However, meetings need to be handled carefully (hence the need for a facilitator) to prevent a situation in which the critical abilities of the team are eroded by group loyalty, or in which requirements reflecting the concerns of a few outspoken (and perhaps senior) people that are favored to the detriment of others. • Observation. The importance of software context within the organizational environ￾ment has led to the adaptation of observa￾tional techniques such as ethnography for requirements elicitation. Software engineers learn about user tasks by immersing them￾selves in the environment and observing how users perform their tasks by interacting with each other and with software tools and other resources. These techniques are relatively expensive but also instructive because they illustrate that many user tasks and business processes are too subtle and complex for their actors to describe easily. • User stories. This technique is commonly used in adaptive methods (see Agile Meth￾ods in the Software Engineering Models and Methods KA) and refers to short, high￾level descriptions of required functionality expressed in customer terms. A typical user story has the form: “As a <role>, I want <goal/desire> so that <benefit>.” A user story is intended to contain just enough infor￾mation so that the developers can produce a reasonable estimate of the effort to imple￾ment it. The aim is to avoid some of the waste that often happens in projects where detailed requirements are gathered early but become invalid before the work begins. Before a user story is implemented, an appropriate accep￾tance procedure must be written by the cus￾tomer to determine whether the goals of the user story have been fulfilled. • Other techniques. A range of other techniques for supporting the elicitation of requirements information exist and range from analyzing competitors’ products to applying data min￾ing techniques to using sources of domain knowledge or customer request databases. 4. Requirements Analysis [1*, c4s1, c4s5, c10s4, c12s5] [2*, c7, c11, c12, c17] This topic is concerned with the process of ana￾lyzing requirements to • detect and resolve conflicts between requirements; • discover the bounds of the software and how it must interact with its organizational and operational environment; • elaborate system requirements to derive soft￾ware requirements. The traditional view of requirements analysis has been that it be reduced to conceptual model￾ing using one of a number of analysis methods, such as the structured analysis method. While conceptual modeling is important, we include the classification of requirements to help inform trad￾eoffs between requirements (requirements clas￾sification) and the process of establishing these tradeoffs (requirements negotiation). Care must be taken to describe requirements precisely enough to enable the requirements to be validated, their implementation to be verified, and their costs to be estimated. 4.1. Requirements Classification Requirements can be classified on a number of dimensions. Examples include the following: • Whether the requirement is functional or nonfunctional (see section 1.3, Functional and Nonfunctional Requirements). • Whether the requirement is derived from one or more high-level requirements or an emer￾gent property (see section 1.4, Emergent Properties), or is being imposed directly on the software by a stakeholder or some other source. • Whether the requirement is on the product or the process (see section 1.2, Product and Process Requirements). Requirements on the process can constrain the choice of contrac￾tor, the software engineering process to be adopted, or the standards to be adhered to

1-8 SWEBOK®Guide V.3.0 The requirement priority.The higher the pri- 4.2.Conceptual Modeling ority.the more essential the requirement is for meeting the overall goals of the software. The development of models of a real-world Often classified on a fixed-point scale such problem is key to software requirements analy- as mandatory,highly desirable,desirable,sis.Their purpose is to aid in understanding the or optional,the priority often has to be bal-situation in which the problem occurs,as well as anced against the cost of development and depicting a solution.Hence,conceptual models implementation. comprise models of entities from the problem The scope of the requirement.Scope refers domain,configured to reflect their real-world to the extent to which a requirement affects relationships and dependencies.This topic is the software and software components.closely related to the Software Engineering Mod- Some requirements,particularly certain els and Methods KA. nonfunctional ones,have a global scope in Several kinds of models can be developed. that their satisfaction cannot be allocated to These include use case diagrams,data flow mod- a discrete component.Hence,a requirement els,state models,goal-based models,user inter- with global scope may strongly affect the actions,object models,data models,and many software architecture and the design of many others.Many of these modeling notations are part components,whereas one with a narrow of the Unified Modeling Language (UML).Use scope may offer a number of design choices case diagrams,for example,are routinely used and have little impact on the satisfaction of to depict scenarios where the boundary separates other requirements. the actors (users or systems in the external envi- Volatility/stability.Some requirements will ronment)from the internal behavior where each change during the life cycle of the soft-use case depicts a functionality of the system. ware-and even during the development The factors that influence the choice of model- process itself.It is useful if some estimate ing notation include these: of the likelihood that a requirement will change can be made.For example,in a bank- The nature of the problem.Some types of ing application,requirements for functions software demand that certain aspects be ana- to calculate and credit interest to customers' lyzed particularly rigorously.For example. accounts are likely to be more stable than a state and parametric models,which are part requirement to support a particular kind of of SysML [4],are likely to be more impor- tax-free account.The former reflects a fun- tant for real-time software than for informa- damental feature of the banking domain(that tion systems,while it would usually be the accounts can earn interest),while the latter opposite for object and activity models. may be rendered obsolete by a change to The expertise of the software engineer.It is government legislation.Flagging potentially often more productive to adopt a modeling volatile requirements can help the software notation or method with which the software engineer establish a design that is more toler- engineer has experience. ant of change. The process requirements of the customer (see section 1.2,Product and Process Other classifications may be appropriate, Requirements).Customers may impose their depending upon the organization's normal prac- favored notation or method or prohibit any tice and the application itself. with which they are unfamiliar.This factor There is a strong overlap between requirements can conflict with the previous factor classification and requirements attributes (see section 7.3,Requirements Attributes). Note that,in almost all cases,it is useful to start by building a model of the software context.The software context provides a connection between the intended software and its external environment

1-8 SWEBOK® Guide V3.0 • The requirement priority. The higher the pri￾ority, the more essential the requirement is for meeting the overall goals of the software. Often classified on a fixed-point scale such as mandatory, highly desirable, desirable, or optional, the priority often has to be bal￾anced against the cost of development and implementation. • The scope of the requirement. Scope refers to the extent to which a requirement affects the software and software components. Some requirements, particularly certain nonfunctional ones, have a global scope in that their satisfaction cannot be allocated to a discrete component. Hence, a requirement with global scope may strongly affect the software architecture and the design of many components, whereas one with a narrow scope may offer a number of design choices and have little impact on the satisfaction of other requirements. • Volatility/stability. Some requirements will change during the life cycle of the soft￾ware—and even during the development process itself. It is useful if some estimate of the likelihood that a requirement will change can be made. For example, in a bank￾ing application, requirements for functions to calculate and credit interest to customers’ accounts are likely to be more stable than a requirement to support a particular kind of tax-free account. The former reflects a fun￾damental feature of the banking domain (that accounts can earn interest), while the latter may be rendered obsolete by a change to government legislation. Flagging potentially volatile requirements can help the software engineer establish a design that is more toler￾ant of change. Other classifications may be appropriate, depending upon the organization’s normal prac￾tice and the application itself. There is a strong overlap between requirements classification and requirements attributes (see section 7.3, Requirements Attributes). 4.2. Conceptual Modeling The development of models of a real-world problem is key to software requirements analy￾sis. Their purpose is to aid in understanding the situation in which the problem occurs, as well as depicting a solution. Hence, conceptual models comprise models of entities from the problem domain, configured to reflect their real-world relationships and dependencies. This topic is closely related to the Software Engineering Mod￾els and Methods KA. Several kinds of models can be developed. These include use case diagrams, data flow mod￾els, state models, goal-based models, user inter￾actions, object models, data models, and many others. Many of these modeling notations are part of the Unified Modeling Language (UML). Use case diagrams, for example, are routinely used to depict scenarios where the boundary separates the actors (users or systems in the external envi￾ronment) from the internal behavior where each use case depicts a functionality of the system. The factors that influence the choice of model￾ing notation include these: • The nature of the problem. Some types of software demand that certain aspects be ana￾lyzed particularly rigorously. For example, state and parametric models, which are part of SysML [4], are likely to be more impor￾tant for real-time software than for informa￾tion systems, while it would usually be the opposite for object and activity models. • The expertise of the software engineer. It is often more productive to adopt a modeling notation or method with which the software engineer has experience. • The process requirements of the customer (see section 1.2, Product and Process Requirements). Customers may impose their favored notation or method or prohibit any with which they are unfamiliar. This factor can conflict with the previous factor. Note that, in almost all cases, it is useful to start by building a model of the software context. The software context provides a connection between the intended software and its external environment

Software Requirements 1-9 This is crucial to understanding the software's con- 4.4.Requirements Negotiation text in its operational environment and to identify- ing its interfaces with the environment. Another term commonly used for this subtopic This subtopic does not seek to"teach"a particu- is "conflict resolution."This concerns resolv- lar modeling style or notation but rather provides ing problems with requirements where conflicts guidance on the purpose and intent of modeling. occur between two stakeholders requiring mutu- ally incompatible features,between requirements 4.3.Architectural Design and Requirements and resources,or between functional and non- Allocation functional requirements,for example.In most cases,it is unwise for the software engineer to At some point,the solution architecture must make a unilateral decision,so it becomes neces- be derived.Architectural design is the point at sary to consult with the stakeholder(s)to reach a which the requirements process overlaps with consensus on an appropriate tradeoff.It is often software or systems design and illustrates how important,for contractual reasons,that such deci- impossible it is to cleanly decouple the two tasks. sions be traceable back to the customer.We have This topic is closely related to Software Structure classified this as a software requirements analy- and Architecture in the Software Design KA.In sis topic because problems emerge as the result many cases,the software engineer acts as soft- of analysis.However,a strong case can also be ware architect because the process of analyzing made for considering it a requirements validation and elaborating the requirements demands that topic (see topic 6,Requirements Validation). the architecture/design components that will be Requirements prioritization is necessary,not responsible for satisfying the requirements be only as a means to filter important requirements, identified.This is requirements allocation-the but also in order to resolve conflicts and plan for assignment to architecture components respon-staged deliveries,which means making complex sible for satisfying the requirements. decisions that require detailed domain knowledge Allocation is important to permit detailed anal- and good estimation skills.However,it is often ysis of requirements.Hence,for example,once a difficult to get real information that can act as set of requirements has been allocated to a com- a basis for such decisions.In addition,require- ponent,the individual requirements can be further ments often depend on each other,and priori- analyzed to discover further requirements on how ties are relative.In practice,software engineers the component needs to interact with other com- perform requirements prioritization frequently ponents in order to satisfy the allocated require-without knowing about all the requirements ments.In large projects,allocation stimulates a Requirements prioritization may follow a cost- new round of analysis for each subsystem.As an value approach that involves an analysis from example,requirements for a particular braking the stakeholders defining in a scale the benefits performance for a car(braking distance,safety in or the aggregated value that the implementa- poor driving conditions,smoothness of applica-tion of the requirement brings them,versus the tion,pedal pressure required,and so on)may be penalties of not having implemented a particular allocated to the braking hardware (mechanical requirement.It also involves an analysis from and hydraulic assemblies)and an antilock braking the software engineers estimating in a scale the system (ABS).Only when a requirement for an cost of implementing each requirement,relative antilock braking system has been identified,and to other requirements.Another requirements pri- the requirements allocated to it,can the capabili- oritization approach called the analytic hierarchy ties of the ABS,the braking hardware,and emer- process involves comparing all unique pairs of gent properties (such as car weight)be used to requirements to determine which of the two is of identify the detailed ABS software requirements. higher priority,and to what extent. Architectural design is closely identified with conceptual modeling(see section 4.2,Conceptual Modeling)

Software Requirements 1-9 This is crucial to understanding the software’s con￾text in its operational environment and to identify￾ing its interfaces with the environment. This subtopic does not seek to “teach” a particu￾lar modeling style or notation but rather provides guidance on the purpose and intent of modeling. 4.3. Architectural Design and Requirements Allocation At some point, the solution architecture must be derived. Architectural design is the point at which the requirements process overlaps with software or systems design and illustrates how impossible it is to cleanly decouple the two tasks. This topic is closely related to Software Structure and Architecture in the Software Design KA. In many cases, the software engineer acts as soft￾ware architect because the process of analyzing and elaborating the requirements demands that the architecture/design components that will be responsible for satisfying the requirements be identified. This is requirements allocation–the assignment to architecture components respon￾sible for satisfying the requirements. Allocation is important to permit detailed anal￾ysis of requirements. Hence, for example, once a set of requirements has been allocated to a com￾ponent, the individual requirements can be further analyzed to discover further requirements on how the component needs to interact with other com￾ponents in order to satisfy the allocated require￾ments. In large projects, allocation stimulates a new round of analysis for each subsystem. As an example, requirements for a particular braking performance for a car (braking distance, safety in poor driving conditions, smoothness of applica￾tion, pedal pressure required, and so on) may be allocated to the braking hardware (mechanical and hydraulic assemblies) and an antilock braking system (ABS). Only when a requirement for an antilock braking system has been identified, and the requirements allocated to it, can the capabili￾ties of the ABS, the braking hardware, and emer￾gent properties (such as car weight) be used to identify the detailed ABS software requirements. Architectural design is closely identified with conceptual modeling (see section 4.2, Conceptual Modeling). 4.4. Requirements Negotiation Another term commonly used for this subtopic is “conflict resolution.” This concerns resolv￾ing problems with requirements where conflicts occur between two stakeholders requiring mutu￾ally incompatible features, between requirements and resources, or between functional and non￾functional requirements, for example. In most cases, it is unwise for the software engineer to make a unilateral decision, so it becomes neces￾sary to consult with the stakeholder(s) to reach a consensus on an appropriate tradeoff. It is often important, for contractual reasons, that such deci￾sions be traceable back to the customer. We have classified this as a software requirements analy￾sis topic because problems emerge as the result of analysis. However, a strong case can also be made for considering it a requirements validation topic (see topic 6, Requirements Validation). Requirements prioritization is necessary, not only as a means to filter important requirements, but also in order to resolve conflicts and plan for staged deliveries, which means making complex decisions that require detailed domain knowledge and good estimation skills. However, it is often difficult to get real information that can act as a basis for such decisions. In addition, require￾ments often depend on each other, and priori￾ties are relative. In practice, software engineers perform requirements prioritization frequently without knowing about all the requirements. Requirements prioritization may follow a cost￾value approach that involves an analysis from the stakeholders defining in a scale the benefits or the aggregated value that the implementa￾tion of the requirement brings them, versus the penalties of not having implemented a particular requirement. It also involves an analysis from the software engineers estimating in a scale the cost of implementing each requirement, relative to other requirements. Another requirements pri￾oritization approach called the analytic hierarchy process involves comparing all unique pairs of requirements to determine which of the two is of higher priority, and to what extent

1-10 SWEBOK®Guide V3.0 4.5.Formal Analysis a document that can be systematically reviewed, evaluated,and approved.For complex systems, Formal analysis concerns not only topic 4,but particularly those involving substantial nonsoft- also sections 5.3 and 6.3.This topic is also related ware components,as many as three different to Formal Methods in the Software Engineering types of documents are produced:system defini- Models and Methods Knowledge Area. tion,system requirements,and software require- Formal analysis has made an impact on some ments.For simple software products.only the application domains,particularly those of high-third of these is required.All three documents are integrity systems.The formal expression of described here,with the understanding that they requirements requires a language with formally may be combined as appropriate.A description of defined semantics.The use of a formal analysis systems engineering can be found in the Related for requirements expression has two benefits.Disciplines of Software Engineering chapter of First,it enables requirements expressed in the this Guide. language to be specified precisely and unambigu- ously,thus (in principle)avoiding the potential 5.1.System Definition Document for misinterpretation.Secondly,requirements can be reasoned over,permitting desired properties This document (sometimes known as the user of the specified software to be proven.Formal requirements document or concept of operations reasoning requires tool support to be practicable document)records the system requirements.It for anything other than trivial systems,and tools defines the high-level system requirements from generally fall into two types:theorem provers or the domain perspective.Its readership includes model checkers.In neither case can proofbe fully representatives of the system users/customers automated,and the level of competence in formal (marketing may play these roles for market- reasoning needed in order to use the tools restricts driven software),so its content must be couched the wider application of formal analysis. in terms of the domain.The document lists the Most formal analysis is focused on relatively system requirements along with background late stages of requirements analysis.It is gener-information about the overall objectives for the ally counterproductive to apply formalization system,its target environment,and a statement of until the business goals and user requirements the constraints,assumptions,and nonfunctional have come into sharp focus through means such requirements.It may include conceptual models as those described elsewhere in section 4.How-designed to illustrate the system context,usage ever,once the requirements have stabilized and scenarios,and the principal domain entities,as have been elaborated to specify concrete proper- well as workflows. ties of the software,it may be beneficial to for- malize at least the critical requirements.This per- 5.2.System Requirements Specification mits static validation that the software specified by the requirements does indeed have the proper-Developers of systems with substantial software ties (for example,absence of deadlock)that the and nonsoftware components-a modern air- customer,users,and software engineer expect it liner,for example-often separate the descrip- to have. tion of system requirements from the description of software requirements.In this view,system 5.Requirements Specification requirements are specified,the software require- [1*,c4s2,c4s3,c12s2-5][2*,cl0]ments are derived from the system requirements, and then the requirements for the software com- For most engineering professions,the term"spec-ponents are specified.Strictly speaking,system ification"refers to the assignment of numerical requirements specification is a systems engineer- values or limits to a product's design goals.In ing activity and falls outside the scope of this software engineering,"software requirements Guide. specification"typically refers to the production of

1-10 SWEBOK® Guide V3.0 4.5. Formal Analysis Formal analysis concerns not only topic 4, but also sections 5.3 and 6.3. This topic is also related to Formal Methods in the Software Engineering Models and Methods Knowledge Area. Formal analysis has made an impact on some application domains, particularly those of high￾integrity systems. The formal expression of requirements requires a language with formally defined semantics. The use of a formal analysis for requirements expression has two benefits. First, it enables requirements expressed in the language to be specified precisely and unambigu￾ously, thus (in principle) avoiding the potential for misinterpretation. Secondly, requirements can be reasoned over, permitting desired properties of the specified software to be proven. Formal reasoning requires tool support to be practicable for anything other than trivial systems, and tools generally fall into two types: theorem provers or model checkers. In neither case can proof be fully automated, and the level of competence in formal reasoning needed in order to use the tools restricts the wider application of formal analysis. Most formal analysis is focused on relatively late stages of requirements analysis. It is gener￾ally counterproductive to apply formalization until the business goals and user requirements have come into sharp focus through means such as those described elsewhere in section 4. How￾ever, once the requirements have stabilized and have been elaborated to specify concrete proper￾ties of the software, it may be beneficial to for￾malize at least the critical requirements. This per￾mits static validation that the software specified by the requirements does indeed have the proper￾ties (for example, absence of deadlock) that the customer, users, and software engineer expect it to have. 5. Requirements Specification [1*, c4s2, c4s3, c12s2–5] [2*, c10] For most engineering professions, the term “spec￾ification” refers to the assignment of numerical values or limits to a product’s design goals. In software engineering, “software requirements specification” typically refers to the production of a document that can be systematically reviewed, evaluated, and approved. For complex systems, particularly those involving substantial nonsoft￾ware components, as many as three different types of documents are produced: system defini￾tion, system requirements, and software require￾ments. For simple software products, only the third of these is required. All three documents are described here, with the understanding that they may be combined as appropriate. A description of systems engineering can be found in the Related Disciplines of Software Engineering chapter of this Guide. 5.1. System Definition Document This document (sometimes known as the user requirements document or concept of operations document) records the system requirements. It defines the high-level system requirements from the domain perspective. Its readership includes representatives of the system users/customers (marketing may play these roles for market￾driven software), so its content must be couched in terms of the domain. The document lists the system requirements along with background information about the overall objectives for the system, its target environment, and a statement of the constraints, assumptions, and nonfunctional requirements. It may include conceptual models designed to illustrate the system context, usage scenarios, and the principal domain entities, as well as workflows. 5.2. System Requirements Specification Developers of systems with substantial software and nonsoftware components—a modern air￾liner, for example—often separate the descrip￾tion of system requirements from the description of software requirements. In this view, system requirements are specified, the software require￾ments are derived from the system requirements, and then the requirements for the software com￾ponents are specified. Strictly speaking, system requirements specification is a systems engineer￾ing activity and falls outside the scope of this Guide

Software Requirements 1-11 5.3.Software Requirements Specification 6.Requirements Validation [1*,c4s6][2*,cl3,cl5] Software requirements specification establishes the basis for agreement between customers and The requirements documents may be subject to val- contractors or suppliers (in market-driven proj- idation and verification procedures.The require- ects,these roles may be played by the marketing ments may be validated to ensure that the software and development divisions)on what the software engineer has understood the requirements:it is product is to do as well as what it is not expected also important to verify that a requirements docu- to do. ment conforms to company standards and that it Software requirements specification permits is understandable,consistent,and complete.In a rigorous assessment of requirements before cases where documented company standards or design can begin and reduces later redesign.It terminology are inconsistent with widely accepted should also provide a realistic basis for estimat-standards,a mapping between the two should be ing product costs,risks,and schedules. agreed on and appended to the document. Organizations can also use a software require- Formal notations offer the important advantage ments specification document as the basis for of permitting the last two properties to be proven developing effective verification and validation (in a restricted sense,at least).Different stake- plans. holders,including representatives ofthe customer Software requirements specification provides and developer,should review the document(s). an informed basis for transferring a software prod- Requirements documents are subject to the same uct to new users or software platforms.Finally,it configuration management practices as the other can provide a basis for software enhancement. deliverables of the software life cycle processes. Software requirements are often written in When practical,the individual requirements are natural language,but,in software requirements also subject to configuration management,gener- specification,this may be supplemented by for- ally using a requirements management tool (see mal or semiformal descriptions.Selection of topic 8,Software Requirements Tools). appropriate notations permits particular require- It is normal to explicitly schedule one or more ments and aspects of the software architecture to points in the requirements process where the be described more precisely and concisely than requirements are validated.The aim is to pick up natural language.The general rule is that nota- any problems before resources are committed to tions should be used that allow the requirements addressing the requirements.Requirements vali- to be described as precisely as possible.This is dation is concerned with the process of examin- particularly crucial for safety-critical,regulatory,ing the requirements document to ensure that it and certain other types of dependable software. defines the right software (that is,the software However,the choice of notation is often con- that the users expect). strained by the training,skills,and preferences of the document's authors and readers. 6.1.Requirements Reviews A number of quality indicators have been developed that can be used to relate the quality Perhaps the most common means of validation of software requirements specification to other is by inspection or reviews of the requirements project variables such as cost,acceptance,per-document(s).A group of reviewers is assigned formance,schedule,and reproducibility.Quality a brief to look for errors,mistaken assumptions, indicators for individual software requirements lack of clarity,and deviation from standard prac- specification statements include imperatives,tice.The composition of the group that conducts directives,weak phrases,options,and continu-the review is important (at least one represen- ances.Indicators for the entire software require-tative of the customer should be included for a ments specification document include size.read- customer-driven project,for example),and it may ability,specification,depth,and text structure. help to provide guidance on what to look for in the form of checklists

Software Requirements 1-11 5.3. Software Requirements Specification Software requirements specification establishes the basis for agreement between customers and contractors or suppliers (in market-driven proj￾ects, these roles may be played by the marketing and development divisions) on what the software product is to do as well as what it is not expected to do. Software requirements specification permits a rigorous assessment of requirements before design can begin and reduces later redesign. It should also provide a realistic basis for estimat￾ing product costs, risks, and schedules. Organizations can also use a software require￾ments specification document as the basis for developing effective verification and validation plans. Software requirements specification provides an informed basis for transferring a software prod￾uct to new users or software platforms. Finally, it can provide a basis for software enhancement. Software requirements are often written in natural language, but, in software requirements specification, this may be supplemented by for￾mal or semiformal descriptions. Selection of appropriate notations permits particular require￾ments and aspects of the software architecture to be described more precisely and concisely than natural language. The general rule is that nota￾tions should be used that allow the requirements to be described as precisely as possible. This is particularly crucial for safety-critical, regulatory, and certain other types of dependable software. However, the choice of notation is often con￾strained by the training, skills, and preferences of the document’s authors and readers. A number of quality indicators have been developed that can be used to relate the quality of software requirements specification to other project variables such as cost, acceptance, per￾formance, schedule, and reproducibility. Quality indicators for individual software requirements specification statements include imperatives, directives, weak phrases, options, and continu￾ances. Indicators for the entire software require￾ments specification document include size, read￾ability, specification, depth, and text structure. 6. Requirements Validation [1*, c4s6] [2*, c13, c15] The requirements documents may be subject to val￾idation and verification procedures. The require￾ments may be validated to ensure that the software engineer has understood the requirements; it is also important to verify that a requirements docu￾ment conforms to company standards and that it is understandable, consistent, and complete. In cases where documented company standards or terminology are inconsistent with widely accepted standards, a mapping between the two should be agreed on and appended to the document. Formal notations offer the important advantage of permitting the last two properties to be proven (in a restricted sense, at least). Different stake￾holders, including representatives of the customer and developer, should review the document(s). Requirements documents are subject to the same configuration management practices as the other deliverables of the software life cycle processes. When practical, the individual requirements are also subject to configuration management, gener￾ally using a requirements management tool (see topic 8, Software Requirements Tools). It is normal to explicitly schedule one or more points in the requirements process where the requirements are validated. The aim is to pick up any problems before resources are committed to addressing the requirements. Requirements vali￾dation is concerned with the process of examin￾ing the requirements document to ensure that it defines the right software (that is, the software that the users expect). 6.1. Requirements Reviews Perhaps the most common means of validation is by inspection or reviews of the requirements document(s). A group of reviewers is assigned a brief to look for errors, mistaken assumptions, lack of clarity, and deviation from standard prac￾tice. The composition of the group that conducts the review is important (at least one represen￾tative of the customer should be included for a customer-driven project, for example), and it may help to provide guidance on what to look for in the form of checklists