Software Engineering Body of Knowledge (v3) (2014) (811503), страница 8
Текст из файла (страница 8)
Low fidelity prototypes are often preferred to avoid stakeholder“anchoring” on minor, incidental characteristics of a higher quality prototype that canlimit design flexibility in unintended ways.• Facilitated meetings. The purpose of thesemeetings is to try to achieve a summativeeffect, whereby a group of people can bringmore insight into their software requirements than by working individually. Theycan brainstorm and refine ideas that may bedifficult to bring to the surface using interviews. Another advantage is that conflictingrequirements surface early on in a way thatlets the stakeholders recognize where theseoccur. When it works well, this techniqueSoftware Requirements 1-7may result in a richer and more consistentset of requirements than might otherwisebe achievable.
However, meetings need tobe handled carefully (hence the need for afacilitator) to prevent a situation in whichthe critical abilities of the team are erodedby group loyalty, or in which requirementsreflecting the concerns of a few outspoken(and perhaps senior) people that are favoredto the detriment of others.• Observation. The importance of softwarecontext within the organizational environment has led to the adaptation of observational techniques such as ethnography forrequirements elicitation. Software engineerslearn about user tasks by immersing themselves in the environment and observing howusers perform their tasks by interacting witheach other and with software tools and otherresources.
These techniques are relativelyexpensive but also instructive because theyillustrate that many user tasks and businessprocesses are too subtle and complex fortheir actors to describe easily.• User stories. This technique is commonlyused in adaptive methods (see Agile Methods in the Software Engineering Modelsand Methods KA) and refers to short, highlevel descriptions of required functionalityexpressed in customer terms.
A typical userstory has the form: “As a <role>, I want<goal/desire> so that <benefit>.” A userstory is intended to contain just enough information so that the developers can produce areasonable estimate of the effort to implement it. The aim is to avoid some of the wastethat often happens in projects where detailedrequirements are gathered early but becomeinvalid before the work begins. Before a userstory is implemented, an appropriate acceptance procedure must be written by the customer to determine whether the goals of theuser story have been fulfilled.• Other techniques. A range of other techniquesfor supporting the elicitation of requirementsinformation exist and range from analyzingcompetitors’ products to applying data mining techniques to using sources of domainknowledge 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 analyzing requirements to• detect and resolve conflicts betweenrequirements;• discover the bounds of the software and howit must interact with its organizational andoperational environment;• elaborate system requirements to derive software requirements.The traditional view of requirements analysishas been that it be reduced to conceptual modeling using one of a number of analysis methods,such as the structured analysis method.
Whileconceptual modeling is important, we include theclassification of requirements to help inform tradeoffs between requirements (requirements classification) and the process of establishing thesetradeoffs (requirements negotiation).Care must be taken to describe requirementsprecisely enough to enable the requirements tobe validated, their implementation to be verified,and their costs to be estimated.4.1. Requirements ClassificationRequirements can be classified on a number ofdimensions. Examples include the following:• Whether the requirement is functional ornonfunctional (see section 1.3, Functionaland Nonfunctional Requirements).• Whether the requirement is derived from oneor more high-level requirements or an emergent property (see section 1.4, EmergentProperties), or is being imposed directly onthe software by a stakeholder or some othersource.• Whether the requirement is on the productor the process (see section 1.2, Product andProcess Requirements).
Requirements on theprocess can constrain the choice of contractor, the software engineering process to beadopted, or the standards to be adhered to.1-8 SWEBOK® Guide V3.0• The requirement priority. The higher the priority, the more essential the requirement isfor meeting the overall goals of the software.Often classified on a fixed-point scale suchas mandatory, highly desirable, desirable,or optional, the priority often has to be balanced against the cost of development andimplementation.• The scope of the requirement. Scope refersto the extent to which a requirement affectsthe software and software components.Some requirements, particularly certainnonfunctional ones, have a global scope inthat their satisfaction cannot be allocated toa discrete component.
Hence, a requirementwith global scope may strongly affect thesoftware architecture and the design of manycomponents, whereas one with a narrowscope may offer a number of design choicesand have little impact on the satisfaction ofother requirements.• Volatility/stability. Some requirements willchange during the life cycle of the software—and even during the developmentprocess itself. It is useful if some estimateof the likelihood that a requirement willchange can be made. For example, in a banking application, requirements for functionsto calculate and credit interest to customers’accounts are likely to be more stable than arequirement to support a particular kind oftax-free account. The former reflects a fundamental feature of the banking domain (thataccounts can earn interest), while the lattermay be rendered obsolete by a change togovernment legislation.
Flagging potentiallyvolatile requirements can help the softwareengineer establish a design that is more tolerant of change.Other classifications may be appropriate,depending upon the organization’s normal practice and the application itself.There is a strong overlap between requirementsclassification and requirements attributes (seesection 7.3, Requirements Attributes).4.2. Conceptual ModelingThe development of models of a real-worldproblem is key to software requirements analysis.
Their purpose is to aid in understanding thesituation in which the problem occurs, as well asdepicting a solution. Hence, conceptual modelscomprise models of entities from the problemdomain, configured to reflect their real-worldrelationships and dependencies. This topic isclosely related to the Software Engineering Models and Methods KA.Several kinds of models can be developed.These include use case diagrams, data flow models, state models, goal-based models, user interactions, object models, data models, and manyothers. Many of these modeling notations are partof the Unified Modeling Language (UML).
Usecase diagrams, for example, are routinely usedto depict scenarios where the boundary separatesthe actors (users or systems in the external environment) from the internal behavior where eachuse case depicts a functionality of the system.The factors that influence the choice of modeling notation include these:• The nature of the problem. Some types ofsoftware demand that certain aspects be analyzed particularly rigorously. For example,state and parametric models, which are partof SysML [4], are likely to be more important for real-time software than for information systems, while it would usually be theopposite for object and activity models.• The expertise of the software engineer.
It isoften more productive to adopt a modelingnotation or method with which the softwareengineer has experience.• The process requirements of the customer(see section 1.2, Product and ProcessRequirements). Customers may impose theirfavored notation or method or prohibit anywith which they are unfamiliar. This factorcan conflict with the previous factor.Note that, in almost all cases, it is useful to startby building a model of the software context. Thesoftware context provides a connection betweenthe intended software and its external environment.Software Requirements 1-9This is crucial to understanding the software’s context in its operational environment and to identifying its interfaces with the environment.This subtopic does not seek to “teach” a particular modeling style or notation but rather providesguidance on the purpose and intent of modeling.4.3. Architectural Design and RequirementsAllocationAt some point, the solution architecture mustbe derived.
Architectural design is the point atwhich the requirements process overlaps withsoftware or systems design and illustrates howimpossible it is to cleanly decouple the two tasks.This topic is closely related to Software Structureand Architecture in the Software Design KA. Inmany cases, the software engineer acts as software architect because the process of analyzingand elaborating the requirements demands thatthe architecture/design components that will beresponsible for satisfying the requirements beidentified.
This is requirements allocation–theassignment to architecture components responsible for satisfying the requirements.Allocation is important to permit detailed analysis of requirements. Hence, for example, once aset of requirements has been allocated to a component, the individual requirements can be furtheranalyzed to discover further requirements on howthe component needs to interact with other components in order to satisfy the allocated requirements.
In large projects, allocation stimulates anew round of analysis for each subsystem. As anexample, requirements for a particular brakingperformance for a car (braking distance, safety inpoor driving conditions, smoothness of application, pedal pressure required, and so on) may beallocated to the braking hardware (mechanicaland hydraulic assemblies) and an antilock brakingsystem (ABS). Only when a requirement for anantilock braking system has been identified, andthe requirements allocated to it, can the capabilities of the ABS, the braking hardware, and emergent properties (such as car weight) be used toidentify the detailed ABS software requirements.Architectural design is closely identified withconceptual modeling (see section 4.2, ConceptualModeling).4.4. Requirements NegotiationAnother term commonly used for this subtopicis “conflict resolution.” This concerns resolving problems with requirements where conflictsoccur between two stakeholders requiring mutually incompatible features, between requirementsand resources, or between functional and nonfunctional requirements, for example.
In mostcases, it is unwise for the software engineer tomake a unilateral decision, so it becomes necessary to consult with the stakeholder(s) to reach aconsensus on an appropriate tradeoff. It is oftenimportant, for contractual reasons, that such decisions be traceable back to the customer. We haveclassified this as a software requirements analysis topic because problems emerge as the resultof analysis. However, a strong case can also bemade for considering it a requirements validationtopic (see topic 6, Requirements Validation).Requirements prioritization is necessary, notonly as a means to filter important requirements,but also in order to resolve conflicts and plan forstaged deliveries, which means making complexdecisions that require detailed domain knowledgeand good estimation skills. However, it is oftendifficult to get real information that can act asa basis for such decisions.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
