Software Engineering Body of Knowledge (v3) (2014) (811503), страница 10
Текст из файла (страница 10)
The aim is to pick upany problems before resources are committed toaddressing the requirements. Requirements validation is concerned with the process of examining the requirements document to ensure that itdefines the right software (that is, the softwarethat the users expect).6.1. Requirements ReviewsPerhaps the most common means of validationis by inspection or reviews of the requirementsdocument(s). A group of reviewers is assigneda brief to look for errors, mistaken assumptions,lack of clarity, and deviation from standard practice. The composition of the group that conductsthe review is important (at least one representative of the customer should be included for acustomer-driven project, for example), and it mayhelp to provide guidance on what to look for inthe form of checklists.1-12 SWEBOK® Guide V3.0Reviews may be constituted on completion ofthe system definition document, the system specification document, the software requirementsspecification document, the baseline specification for a new release, or at any other step in theprocess.6.2. PrototypingPrototyping is commonly a means for validatingthe software engineer’s interpretation of the software requirements, as well as for eliciting newrequirements.
As with elicitation, there is a rangeof prototyping techniques and a number of pointsin the process where prototype validation maybe appropriate. The advantage of prototypes isthat they can make it easier to interpret the software engineer’s assumptions and, where needed,give useful feedback on why they are wrong. Forexample, the dynamic behavior of a user interface can be better understood through an animated prototype than through textual descriptionor graphical models. The volatility of a requirement that is defined after prototyping has beendone is extremely low because there is agreementbetween the stakeholder and the software engineer—therefore, for safety-critical and crucialfeatures prototyping would really help.
There arealso disadvantages, however. These include thedanger of users’ attention being distracted fromthe core underlying functionality by cosmeticissues or quality problems with the prototype. Forthis reason, some advocate prototypes that avoidsoftware, such as flip-chart-based mockups. Prototypes may be costly to develop. However, ifthey avoid the wastage of resources caused bytrying to satisfy erroneous requirements, theircost can be more easily justified. Early prototypes may contain aspects of the final solution.Prototypes may be evolutionary as opposed tothrowaway.6.3. Model ValidationIt is typically necessary to validate the quality ofthe models developed during analysis.
For example, in object models, it is useful to perform astatic analysis to verify that communication pathsexist between objects that, in the stakeholders’domain, exchange data. If formal analysis notations are used, it is possible to use formal reasoning to prove specification properties. This topic isclosely related to the Software Engineering Models and Methods KA.6.4. Acceptance TestsAn essential property of a software requirementis that it should be possible to validate that thefinished product satisfies it. Requirements thatcannot be validated are really just “wishes.” Animportant task is therefore planning how to verify each requirement. In most cases, designingacceptance tests does this for how end-users typically conduct business using the system.Identifying and designing acceptance testsmay be difficult for nonfunctional requirements(see section 1.3, Functional and NonfunctionalRequirements).
To be validated, they must firstbe analyzed and decomposed to the point wherethey can be expressed quantitatively.Additional information can be found in Acceptance/Qualification/Conformance Testing in theSoftware Testing KA.7. Practical Considerations[1*, c4s1, c4s4, c4s6, c4s7][2*, c3, c12, c14, c16, c18–21]The first level of topic decomposition presented in this KA may seem to describe a linearsequence of activities. This is a simplified viewof the process.The requirements process spans the wholesoftware life cycle.
Change management and themaintenance of the requirements in a state thataccurately mirrors the software to be built, or thathas been built, are key to the success of the software engineering process.Not every organization has a culture of documenting and managing requirements. It is common in dynamic start-up companies, driven by astrong “product vision” and limited resources, toview requirements documentation as unnecessaryoverhead.
Most often, however, as these companies expand, as their customer base grows, andas their product starts to evolve, they discoverthat they need to recover the requirements thatSoftware Requirements 1-13motivated product features in order to assess theimpact of proposed changes. Hence, requirementsdocumentation and change management are keyto the success of any requirements process.7.1. Iterative Nature of the RequirementsProcessThere is general pressure in the software industry for ever shorter development cycles, and thisis particularly pronounced in highly competitive,market-driven sectors.
Moreover, most projectsare constrained in some way by their environment,and many are upgrades to, or revisions of, existing software where the architecture is a given. Inpractice, therefore, it is almost always impracticalto implement the requirements process as a linear,deterministic process in which software requirements are elicited from the stakeholders, baselined, allocated, and handed over to the softwaredevelopment team. It is certainly a myth that therequirements for large software projects are everperfectly understood or perfectly specified.Instead, requirements typically iterate towardsa level of quality and detail that is sufficient topermit design and procurement decisions to bemade.
In some projects, this may result in therequirements being baselined before all theirproperties are fully understood. This risks expensive rework if problems emerge late in the software engineering process. However, softwareengineers are necessarily constrained by projectmanagement plans and must therefore take stepsto ensure that the “quality” of the requirements isas high as possible given the available resources.They should, for example, make explicit anyassumptions that underpin the requirements aswell as any known problems.For software products that are developed iteratively, a project team may baseline only thoserequirements needed for the current iteration.
Therequirements specialist can continue to developrequirements for future iterations, while developers proceed with design and construction of thecurrent iteration. This approach provides customers with business value quickly, while minimizing the cost of rework.In almost all cases, requirements understandingcontinues to evolve as design and developmentproceeds. This often leads to the revision ofrequirements late in the life cycle. Perhaps themost crucial point in understanding softwarerequirements is that a significant proportion ofthe requirements will change.
This is sometimesdue to errors in the analysis, but it is frequently aninevitable consequence of change in the “environment”—for example, the customer’s operatingor business environment, regulatory processesimposed by the authorities, or the market intowhich software must sell. Whatever the cause, it isimportant to recognize the inevitability of changeand take steps to mitigate its effects.
Change hasto be managed by ensuring that proposed changesgo through a defined review and approval process and by applying careful requirements tracing, impact analysis, and software configurationmanagement (see the Software ConfigurationManagement KA). Hence, the requirements process is not merely a front-end task in softwaredevelopment, but spans the whole software lifecycle. In a typical project, the software requirements activities evolve over time from elicitationto change management. A combination of topdown analysis and design methods and bottomup implementation and refactoring methods thatmeet in the middle could provide the best of bothworlds. However, this is difficult to achieve inpractice, as it depends heavily upon the maturityand expertise of the software engineers.7.2. Change ManagementChange management is central to the managementof requirements.
This topic describes the role ofchange management, the procedures that need tobe in place, and the analysis that should be appliedto proposed changes. It has strong links to the Software Configuration Management KA.7.3. Requirements AttributesRequirements should consist not only of a specification of what is required, but also of ancillaryinformation, which helps manage and interpretthe requirements. Requirements attributes mustbe defined, recorded, and updated as the software under development or maintenance evolves.This should include the various classification1-14 SWEBOK® Guide V3.0dimensions of the requirement (see section 4.1,Requirements Classification) and the verificationmethod or relevant acceptance test plan section.It may also include additional information, suchas a summary rationale for each requirement, thesource of each requirement, and a change history.The most important requirements attribute, however, is an identifier that allows the requirementsto be uniquely and unambiguously identified.7.4. Requirements TracingRequirements tracing is concerned with recovering the source of requirements and predicting theeffects of requirements.
Tracing is fundamentalto performing impact analysis when requirementschange. A requirement should be traceable backward to the requirements and stakeholders thatmotivated it (from a software requirement backto the system requirement(s) that it helps satisfy,for example). Conversely, a requirement shouldbe traceable forward into the requirements anddesign entities that satisfy it (for example, froma system requirement into the software requirements that have been elaborated from it, and oninto the code modules that implement it, or thetest cases related to that code and even a givensection on the user manual which describes theactual functionality) and into the test case thatverifies it.The requirements tracing for a typical project will form a complex directed acyclic graph(DAG) (see Graphs in the Computing Foundations KA) of requirements.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
