Software Engineering Body of Knowledge (v3) (2014) (811503), страница 9
Текст из файла (страница 9)
In addition, requirements often depend on each other, and priorities are relative. In practice, software engineersperform requirements prioritization frequentlywithout knowing about all the requirements.Requirements prioritization may follow a costvalue approach that involves an analysis fromthe stakeholders defining in a scale the benefitsor the aggregated value that the implementation of the requirement brings them, versus thepenalties of not having implemented a particularrequirement.
It also involves an analysis fromthe software engineers estimating in a scale thecost of implementing each requirement, relativeto other requirements. Another requirements prioritization approach called the analytic hierarchyprocess involves comparing all unique pairs ofrequirements to determine which of the two is ofhigher priority, and to what extent.1-10 SWEBOK® Guide V3.04.5. Formal AnalysisFormal analysis concerns not only topic 4, butalso sections 5.3 and 6.3. This topic is also relatedto Formal Methods in the Software EngineeringModels and Methods Knowledge Area.Formal analysis has made an impact on someapplication domains, particularly those of highintegrity systems.
The formal expression ofrequirements requires a language with formallydefined semantics. The use of a formal analysisfor requirements expression has two benefits.First, it enables requirements expressed in thelanguage to be specified precisely and unambiguously, thus (in principle) avoiding the potentialfor misinterpretation. Secondly, requirements canbe reasoned over, permitting desired propertiesof the specified software to be proven.
Formalreasoning requires tool support to be practicablefor anything other than trivial systems, and toolsgenerally fall into two types: theorem provers ormodel checkers. In neither case can proof be fullyautomated, and the level of competence in formalreasoning needed in order to use the tools restrictsthe wider application of formal analysis.Most formal analysis is focused on relativelylate stages of requirements analysis.
It is generally counterproductive to apply formalizationuntil the business goals and user requirementshave come into sharp focus through means suchas those described elsewhere in section 4. However, once the requirements have stabilized andhave been elaborated to specify concrete properties of the software, it may be beneficial to formalize at least the critical requirements.
This permits static validation that the software specifiedby the requirements does indeed have the properties (for example, absence of deadlock) that thecustomer, users, and software engineer expect itto have.5. Requirements Specification[1*, c4s2, c4s3, c12s2–5] [2*, c10]For most engineering professions, the term “specification” refers to the assignment of numericalvalues or limits to a product’s design goals.
Insoftware engineering, “software requirementsspecification” typically refers to the production ofa document that can be systematically reviewed,evaluated, and approved. For complex systems,particularly those involving substantial nonsoftware components, as many as three differenttypes of documents are produced: system definition, system requirements, and software requirements. For simple software products, only thethird of these is required. All three documents aredescribed here, with the understanding that theymay be combined as appropriate.
A description ofsystems engineering can be found in the RelatedDisciplines of Software Engineering chapter ofthis Guide.5.1. System Definition DocumentThis document (sometimes known as the userrequirements document or concept of operationsdocument) records the system requirements. Itdefines the high-level system requirements fromthe domain perspective. Its readership includesrepresentatives of the system users/customers(marketing may play these roles for marketdriven software), so its content must be couchedin terms of the domain. The document lists thesystem requirements along with backgroundinformation about the overall objectives for thesystem, its target environment, and a statement ofthe constraints, assumptions, and nonfunctionalrequirements.
It may include conceptual modelsdesigned to illustrate the system context, usagescenarios, and the principal domain entities, aswell as workflows.5.2. System Requirements SpecificationDevelopers of systems with substantial softwareand nonsoftware components—a modern airliner, for example—often separate the description of system requirements from the descriptionof software requirements. In this view, systemrequirements are specified, the software requirements are derived from the system requirements,and then the requirements for the software components are specified.
Strictly speaking, systemrequirements specification is a systems engineering activity and falls outside the scope of thisGuide.Software Requirements 1-115.3. Software Requirements SpecificationSoftware requirements specification establishesthe basis for agreement between customers andcontractors or suppliers (in market-driven projects, these roles may be played by the marketingand development divisions) on what the softwareproduct is to do as well as what it is not expectedto do.Software requirements specification permitsa rigorous assessment of requirements beforedesign can begin and reduces later redesign.
Itshould also provide a realistic basis for estimating product costs, risks, and schedules.Organizations can also use a software requirements specification document as the basis fordeveloping effective verification and validationplans.Software requirements specification providesan informed basis for transferring a software product to new users or software platforms.
Finally, itcan provide a basis for software enhancement.Software requirements are often written innatural language, but, in software requirementsspecification, this may be supplemented by formal or semiformal descriptions. Selection ofappropriate notations permits particular requirements and aspects of the software architecture tobe described more precisely and concisely thannatural language. The general rule is that notations should be used that allow the requirementsto be described as precisely as possible. This isparticularly crucial for safety-critical, regulatory,and certain other types of dependable software.However, the choice of notation is often constrained by the training, skills, and preferences ofthe document’s authors and readers.A number of quality indicators have beendeveloped that can be used to relate the qualityof software requirements specification to otherproject variables such as cost, acceptance, performance, schedule, and reproducibility.
Qualityindicators for individual software requirementsspecification statements include imperatives,directives, weak phrases, options, and continuances. Indicators for the entire software requirements specification document include size, readability, specification, depth, and text structure.6. Requirements Validation[1*, c4s6] [2*, c13, c15]The requirements documents may be subject to validation and verification procedures.
The requirements may be validated to ensure that the softwareengineer has understood the requirements; it isalso important to verify that a requirements document conforms to company standards and that itis understandable, consistent, and complete. Incases where documented company standards orterminology are inconsistent with widely acceptedstandards, a mapping between the two should beagreed on and appended to the document.Formal notations offer the important advantageof permitting the last two properties to be proven(in a restricted sense, at least). Different stakeholders, including representatives of the customerand developer, should review the document(s).Requirements documents are subject to the sameconfiguration management practices as the otherdeliverables of the software life cycle processes.When practical, the individual requirements arealso subject to configuration management, generally using a requirements management tool (seetopic 8, Software Requirements Tools).It is normal to explicitly schedule one or morepoints in the requirements process where therequirements are validated.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
