SWEBOK V4：软件工程新指南扩充与测试领域更新

需积分: 5 140 浏览量更新于2024-06-18 收藏 11.25MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"SWEBOK V4，全称为《软件工程Body of Knowledge》第四版，是软件工程领域的重要参考书籍。自SWEBOK V3发布以来，历经近十年的发展，新版在原有的基础上做出了重大扩展和改进。它旨在提升指南的时效性、易读性和一致性，使其更好地适应快速变化的软件开发环境。首先，新版增加了三个关键的 knowledge area (KA)，分别是软件架构、工程运作（区别于传统的运维）以及软件安全。这些新增内容反映了近年来软件工程领域的新趋势和技术进步。软件架构部分涵盖了系统设计、组件化、模块化等现代设计原则，帮助工程师构建更加灵活和可维护的系统。工程运作 KA 则强调了敏捷方法、DevOps实践以及项目管理在工程生命周期中的角色，区分于传统的IT运维职责。软件安全 KA 则着重于安全策略、风险评估和安全测试，确保软件产品的安全性。对于软件测试，正如描述中提及的，也有显著更新。这可能包括但不限于测试方法的进化，如自动化测试、性能测试、安全测试和持续集成/持续部署(CI/CD)中的测试实践的整合。此外，新版还可能涵盖了最新的质量管理和AI测试技术，如利用AI进行缺陷预测、测试优化或自动化测试用例生成。编写SWEBOK V4的目的是为了保持软件工程作为一门公认工程学科的地位，并确保工程师们能够掌握最新、最有效的实践。每个知识领域都包含了明确的知识要求，以及与之相关的组件过程、实践、输入、输出、工具和技术。同时，附录提供了详细的KA描述规范、与各KA相关的标准注释，以及引用文献列表，以供深入学习和参考。 SWEBOK V4是一个全面的指南，不仅涵盖基础的软件工程原理，也紧跟行业发展趋势，为软件工程师提供了一个不断更新和完善的框架，帮助他们应对日益复杂的软件开发挑战。无论是新手还是经验丰富的从业者，都可以从中受益匪浅。"

资源详情

资源推荐

Software Requirements 1-11

● degree of risk (e.g., probability, severity) of

incorrect requirements;

● staff turnover anticipated during the software’s

service life of the software;

● geographic distribution of the development

team members;

● stakeholder involvement over the course of the

project;

● whether the use of a packaged solution or open

source library is anticipated;

● whether any design or construction will be

outsourced;

● the degree of requirements-based testing

expected;

● effort needed to use a candidate specification

technique;

● accuracy needed from the requirements-based

estimates;

● extent of requirements tracing necessary, if any;

● contractual impositions of requirements

specification content and format.

As stated in this KA’s introduction, the whats and

hows of software requirements work on a project

should be determined by the nature of the software

constructed, not by the life cycle under which it is

constructed. Downstream maintainers should not be

able to discern the life cycle used in earlier

development from the form of those requirements

alone. The chosen life cycle’s effect should be

limited to the completeness of the requirements at

any point in the project. Under a waterfall life cycle,

the requirements are expected to be completely

specified at the end of the Requirements phase.

Under an Agile life cycle, the requirements are

expected to change, grow, or be eliminated

continuously and not be complete until the project’s

end.

Some organizations have a culture of documenting

requirements; some do not. Dynamic startup

projects are often driven by a strong product vision

and limited resources; their teams might view

requirements documentation as unnecessary

overhead. But as these products evolve and mature,

software engineers often recognize that they need to

recover the requirements that motivated product

features in order to assess the impact of proposed

changes. Hence, requirements documentation and

change management become important to long-term

success. A project’s approach to requirements in

general, and to requirements specification in

particular, may evolve over the service life of that

software.

The most basic recommendation for requirements

documentation is to base decisions on an audience

analysis. Who are the different consumers who will

need information from a requirements specification?

What information will they need? How can that

information be packaged and presented so that each

consumer can get the information they need with the

least effort?

There is a degree of overlap and dependency

between requirements analysis and specification.

Use of certain requirements specification techniques

— particularly model-based requirements

specifications — permit and encourage

requirements analysis that can go beyond what has

already been presented.

Documented software requirements should be

subject to the same configuration management

practices as the other deliverables of the software

life cycle processes. (See the Configuration

Management KA for a detailed discussion.) In

addition, when practical, the individual

requirements are also subject to configuration

management, which is generally supported by a

requirements management tool. (See Topic 8,

Software Requirements Tools.)

There are several general categories of requirements

specification techniques, each of which is discussed

below. The requirements specification for a given

project may also use various techniques.

ISO/IEC/IEEE 29148 [26], as well as [1*, c10-14],

[5, c4], [6, c16], and many others offer templates for

requirements documentation.

4.1. Unstructured Natural Language Requirements

Specification [1*, c11] [2*, s4.4.1]

14-12 SWEBOK® Guide V4.0

Natural language requirements specifications

express requirements in common, ordinary

language. Natural language requirements

specifications can be unstructured or structured.

A typical unstructured natural language

requirements specification is a collection of

statements in natural language, such as, “The system

shall . . . .” For example, business rules are

statements that define or constrain some aspect of

the structure or the behavior of the business to be

automated. “A student cannot register in next

semester’s courses if there remain any unpaid tuition

fees” is an example of a business rule that serves as

a requirement for a university’s course-registration

software. Some projects can publish a user manual

as a satisfactory requirements specification,

although there are limits to how effective this can be.

(See also [5, c4] [26].)

4.2. Structured Natural Language Requirements

Specification [1*, c8] [2*, s4.4.2]

Structured natural language requirements

specifications impose constraints on how the

requirements are expressed; the goal is to increase

precision and conciseness.

The simplest example might be the actor-action

format. The actor is the entity responsible for

carrying out the action, and action is what needs to

happen. A triggering event might precede the actor,

and the action might be followed by an optional

condition or qualification. The statement “When an

order is shipped, the system shall create an Invoice

unless the Order Terms are ‘Prepaid’” uses actor-

action format. The triggering event is “When an

order is shipped.” The actor is “the system.” The

action is “create an Invoice.” The

condition/qualification is “except the Order Terms

are ‘Prepaid’.”

Another example is a use case specification

template, as shown in Figure 1.6. (See [11] for

guidelines on writing good use case specifications.)

Figure 1.6. Example of Structured Natural Language

Specification for a Single Use Case

The user story format, “As a <user> I want

<capability> so that <benefit>” as well as decision

tables are other examples. (See also [5, c4] [6, c12,

c16] [7, c2-5].)

4.3. Acceptance Criteria-Based Requirements

Specification

This general approach includes two specific

variants: Acceptance Test Driven Development

(ATDD) and Behavior Driven Development (BDD).

ATDD [2*, s3.2.3, s8.2] is a part of the larger Test

Driven Development (TDD) approach. (See the

Software Testing KA.). The main idea of TDD is

that test cases precede construction. Therefore, no

new production code is written and no existing code

is modified unless at least one test case fails, either

at the unit test level or at the acceptance test level.

The ATDD process has three steps:

1. A unit of functionality (e.g., a user story) is

selected for implementation.

2. One or more software engineers, one or

more business domain experts, and

possibly one or more QA/test professionals

meet — before any production design or

construction work is done — to agree on a

set of test cases that must pass to show that

the unit of functionality has been correctly

implemented.

3. At least one of those acceptance test cases

must fail on the existing software. The

existence of at least one failing test case

gives the software engineer(s) permission

Software Requirements 1-13

to create or modify production code to pass

all of the agreed-upon test cases. This step

might require several iterations. The code

may also be refactored during this step.

When all acceptance test cases have passed, and

presumably all unit and integration test cases as

well, then the unit of functionality is deemed to have

been completely and correctly implemented. The

ATDD process returns to step 1, where a new unit of

functionality is selected, and the cycle repeats.

ATDD might seem to be a testing technique rather

than a requirements specification technique. On the

other hand, a test case has the general form of

“When given input that looks like X, we expect the

software to produce results that look like Y.” The

key is the underlined phrase, “we expect the

software to produce.” If we simply modify that

phrase to say, “the software shall produce,” as in

“When given input that looks like X, the software

shall produce results that look like Y,” what first

looked like a test case now looks like a requirement.

Technically, one acceptance test case can

encompass more than one single requirement, but

the general idea holds that the ATDD test cases are

essentially precise, unambiguous statements of

requirements.

The BDD approach [19] is slightly more structured,

and business domain experts typically prefer it over

ATDD because it is less technical in appearance. In

BDD, the unit of functionality is described as a user

story, in a form such as this: “As a <role>, I want

<goal/desire> so that <benefit>.” This leads to the

identification and specification of a set of

“scenarios” in this form: “Given <some context>

[and <possibly more context>], when <stimulus>

then <outcome> [and <possibly more outcomes>].”

If the story is “As a bank customer, I want to

withdraw cash from the Automated Teller Machine

(ATM) so that I can get money without going to the

bank,” one scenario could be that “the account has a

sufficient balance.” This scenario could be detailed

as “Given the account balance is $500, and the

customer’s bank card is valid, and the automated

teller machine contains enough money in its cash

box, when the Account Holder requests $100, then

the ATM should dispense $100 and the account

balance should be $400, and the customer’s bank

card should be returned.”

Another scenario could be that “the account has an

insufficient balance” and could be detailed as

“Given the account balance is $50, and the

customer’s bank card is valid, and the automated

teller machine contains enough money in its cash

box, when the Account Holder requests $100, then

the ATM should not dispense any money, and the

ATM should say there is an insufficient balance, the

balance should remain at $50, and the customer’s

bank card should be returned.”

The goal of BDD is to have a comprehensive set of

scenarios for each unit of functionality. In the

withdrawing cash situation, additional scenarios for

“The Bank Customer’s bank card has been disabled”

and “The ATM does not contain enough money in

its cash box” would be necessary.

The acceptance test cases are obvious from the BDD

scenarios.

Acceptance criteria-based requirements

specification directly addresses the requirements

ambiguity problem. Natural languages are

inherently ambiguous, but test case language is not.

In acceptance-based criteria requirements

specification, the requirements are written using test

case language, which is very precise. On the other

hand, this does not inherently solve the

incompleteness problem. However, combining

ATDD or BDD with appropriate functional test

coverage criteria, such as Domain Testing,

Boundary Value Analysis and Pairwise Testing (see

the Software Testing KA), can reduce the likelihood

of requirements incompleteness. (See also [9, c1,

c12].)

4.4. Model-Based Requirements Specification [1*,

c12] [2*, c5] [4*]

Another approach to avoiding the inherent

ambiguity of natural languages is to use modeling

languages such as selected elements of the Unified

14-14 SWEBOK® Guide V4.0

Modeling Language™ (UML) or Systems Modeling

Language™ (SysML). Much like the blueprints

used in building construction, these modeling

languages can be used in a computing technology-

free manner to precisely and concisely specify

functional requirements [9, c1-2]. This topic is

closely related to the Software Engineering Models

and Methods KA. Requirements models fall into

two general categories:

1. Structural models for specifying policies to be

enforced: These are logical class models as

described in, for example, [9, c8]. They are also

called conceptual data models, logical data

models and entity-relationship diagrams.

2. Behavioral models for specifying processes to

be carried out: These models include use case

modeling as described in [9, c7], interaction

diagrams as described in [9, c9] and state

modeling as described in [9, c10]. Other

examples are UML activity diagrams and data-

flow modeling, as described in [1*, c12-13],

[8], [10] and [18].

Model-based requirements specifications vary in the

degree of model formality. Consider the following:

● Agile modeling (see, for example, [10]) is the

least formal. Agile models can be little more

than rough sketches whose goal is to

communicate important information rather than

demonstrate proper use of modeling notations.

In this type of modeling, the effect of the

communication is considered more important

than the form of the communication.

● Semiformal modeling, for example [9, c6-12],

provides a definition of the modeling language

semantics ([9, Appendix L]), but that definition

has not been formally proved to be complete and

consistent.

● Formal modeling, for example, Z, the Vienna

Development Method (VDM), Specification

and Description Language (SDL) and [5, c6]

have very precisely defined semantics that allow

specifications to be mechanically analyzed for

the presence or absence of specific properties to

help avoid critical reasoning errors. The term

correctness by construction has been used for

development in this context. (See the Formal

Methods section in the Software Engineering

Models and Methods KA.)

Generally, the more formal a requirements model is,

the less ambiguous it is, so software engineers are

less likely to misinterpret the requirements. More

formal requirements models can also be:

● more concise and compact;

● easier to translate into code, possibly

mechanically;

● used as a basis for deriving acceptance test

cases.

One important message in [4*] is that while formal

modeling languages are stronger than semiformal

and Agile modeling, formal notations can burden

both the model creator and human readers. Wing’s

compromise is to use formally defined

underpinnings (e.g., in Z) for surface syntaxes that

are easier to read and write (e.g., UML statecharts).

4.5. Additional Attributes of Requirements [1*,

c27pp462-463]

Over and above the basic requirements statements

already described, documenting additional attributes

for some or all requirements can be useful. This

supplemental detail can help software engineers

better interpret and manage the requirements [6,

c16]. Possible additional attributes include the

following:

● tag to support requirements tracing;

● description (additional details about the

requirement);

● rationale (why the requirement is important);

● source (role or name of the stakeholder who

imposed this requirement);

● use case or relevant triggering event;

● type (classification or category of the

requirement — e.g., functional, quality of

service);

● dependencies;

Software Requirements 1-15

● conflicts;

● acceptance criteria;

● priority (see Requirements Prioritization later in

this KA);

● stability (see Requirements Stability and

Volatility later in this KA);

● whether the requirement is common or a variant

for product family development (e.g., [20]);

● supporting materials;

● the requirement’s change history.

Gilb’s Planguage (short for Planning Language) [7]

recommends attributes such as scale, meter,

minimum, target, outstanding, past, trend and record.

4.6. Incremental and Comprehensive Requirements

Specification

Projects that explicitly document requirements take

one of two approaches. One can be called

incremental specification. In this approach, a

version of the requirements specification contains

only the differences — additions, modifications and

deletions — from the previous version. An

advantage of this approach is that it can produce a

smaller volume of written specifications.

The other approach can be called comprehensive

specification. In this approach, each version’s

requirements specification contains all

requirements, not just changes from the previous

version. An advantage of this approach is that a

reader can understand all requirements in a single

document instead of having to keep track of

cumulative additions, modifications and deletions

across a series of specifications.

Some organizations combine these two approaches,

producing intermediate releases (e.g., x.1, x.2 and

x.3) that are specified incrementally and major

releases (e.g., 1.0, 2.0 and 3.0) that are specified

comprehensively. The reader never needs to go any

further back than the requirements specifications for

the last major release to obtain the complete set of

specifications.

5. Requirements Validation [1*, c17] [2*,

s4.5]

Requirements validation concerns gaining

confidence that the requirements represent the

stakeholders’ true needs as they are currently

understood (and possibly documented). Key

questions include the following:

● do these represent all requirements relevant at

this time?

● are any stated requirements not representative of

stakeholder needs?

● are these requirements appropriately stated?

● are the requirements understandable, consistent

and complete?

● does the requirements documentation conform

to relevant standards?

Three methods for requirements validation tend to

be used: requirements reviews, simulation and

execution, and prototyping. (See also [5, c5] [6, c17]

[9, c12].)

5.1. Requirements Reviews [1*, c17pp332-342] [2*,

c4p130]

The most common way to validate is by reviewing

or inspecting a requirements document. One or more

reviewers are asked to look for errors, omissions,

invalid assumptions, lack of clarity and deviation

from accepted practice. Review from multiple

perspectives is preferred:

● clients, customers and users check that their

wants and needs are completely and accurately

represented;

● other software engineers with expertise in

requirements specification check that the

document is clear and conforms to applicable

standards;

● software engineers who will do architecture,

design or construction of the software that

satisfies these requirements check that the

document is sufficient to support their work.

剩余381页未读，继续阅读

luoyong1111

粉丝: 0
资源: 7

会员权益专享

SWEBOK V4：软件工程新指南扩充与测试领域更新

《软件工程常识系统攻略SWEBOK》征求意见稿V1_0

软件测试第三版（中文）

软件工程 SWEBOK

软件工程知识体系SWEBOK

《软件工程知识体系指南SWEBOK》(征求意见稿)

软件工程swebok3.0

软件工程中的swebok是谁出版的

国际软件工程知识体系SWEBOK

《软件工程知识体系指南SWEBOK》（征求意见稿）.pdf

SWEBOK 软件工程知识体系指南 2004版中英文版 第三版英文版

SWEBOK 软件工程的ISO标准

MindeNLP+MusicGen-音频提示生成

WNM2027-VB一款SOT23封装N-Channel场效应MOS管

线上营销推广策略设计与效果评估研究

钢铁集团智慧工厂信息化建设解决方案两份文档.pptx

2024年投资策略-AIGC海阔凭鱼跃，数据要素破浪会有时.pdf

2023中国文化产业和旅游业年度盘点报告（2022）-北京京和文旅发展研究院.pdf

英锐恩电子烟相关芯片推荐

2024年东南亚断续器市场深度研究及预测报告.pdf

ElasticSearch.pdf

会员权益专享

最新资源

SWEBOK 软件工程知识体系指南 2004版中英文版第三版英文版