Software Engineering Body of Knowledge (v3) (2014) (811503), страница 6
Текст из файла (страница 6)
The process-based breakdown reflectsthe fact that the requirements process, if it is tobe successful, must be considered as a processinvolving complex, tightly coupled activities(both sequential and concurrent), rather than as adiscrete, one-off activity performed at the outsetof a software development project.The Software Requirements KA is relatedclosely to the Software Design, Software Testing,Software Maintenance, Software ConfigurationManagement, Software Engineering Management, Software Engineering Process, SoftwareEngineering Models and Methods, and SoftwareQuality KAs.Confidentiality, Integrity, andAvailabilityDAGDirected Acyclic GraphFSMFunctional Size MeasurementInternational Council on SystemsINCOSEEngineeringUMLUnified Modeling LanguageSysMLSystems Modeling LanguageCIAINTRODUCTIONThe Software Requirements knowledge area (KA)is concerned with the elicitation, analysis, specification, and validation of software requirementsas well as the management of requirements during the whole life cycle of the software product.It is widely acknowledged amongst researchersand industry practitioners that software projectsare critically vulnerable when the requirementsrelated activities are poorly performed.Software requirements express the needs andconstraints placed on a software product thatcontribute to the solution of some real-worldproblem.The term “requirements engineering” is widelyused in the field to denote the systematic handlingof requirements.
For reasons of consistency, theterm “engineering” will not be used in this KAother than for software engineering per se.For the same reason, “requirements engineer,”a term which appears in some of the literature,will not be used either. Instead, the term “softwareengineer” or, in some specific cases, “requirements specialist” will be used, the latter wherethe role in question is usually performed by anindividual other than a software engineer. ThisBREAKDOWN OF TOPICS FORSOFTWARE REQUIREMENTSThe breakdown of topics for the SoftwareRequirements KA is shown in Figure 1.1.1. Software Requirements Fundamentals[1*, c4, c4s1, c10s1, c10s4] [2*, c1, c6, c12]1.1. Definition of a Software RequirementAt its most basic, a software requirement is aproperty that must be exhibited by something in1-11-2 SWEBOK® Guide V3.0Figure 1.1.
Breakdown of Topics for the Software Requirements KAorder to solve some problem in the real world. Itmay aim to automate part of a task for someoneto support the business processes of an organization, to correct shortcomings of existing software,or to control a device—to name just a few of themany problems for which software solutions arepossible. The ways in which users, business processes, and devices function are typically complex.By extension, therefore, the requirements on particular software are typically a complex combination from various people at different levels of anorganization, and who are in one way or anotherinvolved or connected with this feature from theenvironment in which the software will operate.An essential property of all software requirements is that they be verifiable as an individualfeature as a functional requirement or at thesystem level as a nonfunctional requirement.
Itmay be difficult or costly to verify certain software requirements. For example, verificationof the throughput requirement on a call centermay necessitate the development of simulationsoftware. Software requirements, software testing, and quality personnel must ensure that therequirements can be verified within availableresource constraints.Requirements have other attributes in addition to behavioral properties. Common examplesinclude a priority rating to enable tradeoffs inthe face of finite resources and a status value toenable project progress to be monitored. Typically, software requirements are uniquely identified so that they can be subjected to software configuration management over the entire life cycleof the feature and of the software.1.2. Product and Process RequirementsA product requirement is a need or constraint onthe software to be developed (for example, “Thesoftware shall verify that a student meets all prerequisites before he or she registers for a course”).A process requirement is essentially a constraint on the development of the software (forexample, “The software shall be developed usinga RUP process”).Some software requirements generate implicitprocess requirements.
The choice of verificationSoftware Requirements 1-3technique is one example. Another might be theuse of particularly rigorous analysis techniques(such as formal specification methods) to reducefaults that can lead to inadequate reliability. Process requirements may also be imposed directlyby the development organization, their customer,or a third party such as a safety regulator.1.3. Functional and Nonfunctional RequirementsFunctional requirements describe the functionsthat the software is to execute; for example, formatting some text or modulating a signal. Theyare sometimes known as capabilities or features.A functional requirement can also be describedas one for which a finite set of test steps can bewritten to validate its behavior.Nonfunctional requirements are the ones thatact to constrain the solution.
Nonfunctionalrequirements are sometimes known as constraintsor quality requirements. They can be further classified according to whether they are performancerequirements, maintainability requirements,safety requirements, reliability requirements,security requirements, interoperability requirements or one of many other types of softwarerequirements (see Models and Quality Characteristics in the Software Quality KA).1.4. Emergent PropertiesSome requirements represent emergent properties of software—that is, requirements that cannot be addressed by a single component but thatdepend on how all the software componentsinteroperate. The throughput requirement for acall center would, for example, depend on howthe telephone system, information system, andthe operators all interacted under actual operating conditions.
Emergent properties are cruciallydependent on the system architecture.1.5. Quantifiable RequirementsSoftware requirements should be stated as clearlyand as unambiguously as possible, and, whereappropriate, quantitatively. It is important toavoid vague and unverifiable requirements thatdepend for their interpretation on subjectivejudgment (“the software shall be reliable”; “thesoftware shall be user-friendly”). This is particularly important for nonfunctional requirements. Two examples of quantified requirementsare the following: a call center’s software mustincrease the center’s throughput by 20%; and asystem shall have a probability of generating afatal error during any hour of operation of lessthan 1 * 10−8.
The throughput requirement is at avery high level and will need to be used to derivea number of detailed requirements. The reliability requirement will tightly constrain the systemarchitecture.1.6. System Requirements and SoftwareRequirementsIn this topic, “system” meansan interacting combination of elementsto accomplish a defined objective. Theseinclude hardware, software, firmware,people, information, techniques, facilities,services, and other support elements,as defined by the International Council on Software and Systems Engineering (INCOSE) [3].System requirements are the requirements forthe system as a whole.
In a system containingsoftware components, software requirements arederived from system requirements.This KA defines “user requirements” in arestricted way, as the requirements of the system’s customers or end users. System requirements, by contrast, encompass user requirements,requirements of other stakeholders (such as regulatory authorities), and requirements without anidentifiable human source.2. Requirements Process[1*, c4s4] [2*, c1–4, c6, c22, c23]This section introduces the software requirementsprocess, orienting the remaining five topics andshowing how the requirements process dovetailswith the overall software engineering process.1-4 SWEBOK® Guide V3.02.1. Process ModelsThe objective of this topic is to provide an understanding that the requirements process• is not a discrete front-end activity of the software life cycle, but rather a process initiatedat the beginning of a project that continues tobe refined throughout the life cycle;• identifies software requirements as configuration items and manages them using thesame software configuration managementpractices as other products of the softwarelife cycle processes;• needs to be adapted to the organization andproject context.In particular, the topic is concerned with howthe activities of elicitation, analysis, specification, and validation are configured for differenttypes of projects and constraints.
The topic alsoincludes activities that provide input into therequirements process, such as marketing and feasibility studies.2.2. Process ActorsThis topic introduces the roles of the people whoparticipate in the requirements process. This process is fundamentally interdisciplinary, and therequirements specialist needs to mediate betweenthe domain of the stakeholder and that of software engineering. There are often many peopleinvolved besides the requirements specialist, eachof whom has a stake in the software.
The stakeholders will vary across projects, but will alwaysinclude users/operators and customers (who neednot be the same).Typical examples of software stakeholdersinclude (but are not restricted to) the following:• Users: This group comprises those who willoperate the software. It is often a heterogeneous group involving people with differentroles and requirements.• Customers: This group comprises those whohave commissioned the software or who represent the software’s target market.• Market analysts: A mass-market productwill not have a commissioning customer, somarketing people are often needed to establish what the market needs and to act asproxy customers.• Regulators: Many application domains, suchas banking and public transport, are regulated. Software in these domains must comply with the requirements of the regulatoryauthorities.• Software engineers: These individuals havea legitimate interest in profiting from developing the software by, for example, reusingcomponents in or from other products.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
