1. Trang chủ
  2. » Công Nghệ Thông Tin

slike môn thu thập và phân tích yêu cầu nguyễn ngọc tú chương 1 tầm quan trọng của kỹ nghệ yêu cầu

30 466 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 30
Dung lượng 1,29 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Requirement Engineering Lesson 01: The Importance of Requirements Email: Tu.NguyenNgoc@hoasen.edu.vn Web: sites.google.com/site/kythuatthuthapyeucauphanmem/... Requirement Engineering

Trang 1

Requirement Engineering

Lesson 01:

The Importance of Requirements

Email: Tu.NguyenNgoc@hoasen.edu.vn

Web: sites.google.com/site/kythuatthuthapyeucauphanmem/

Trang 2

Learning Outcomes

Requirement Engineering

Trang 3

 Requirement

requirements  the real requirements of customers

Requirement Engineering

[1] chapter 01, p001

Failed Succeeded Challenged

Trang 4

Requirement Engineering

Trang 5

Requirement Engineering

Trang 6

Outline

Requirement Engineering

[1] chapter 01

Trang 7

 A requirement is anything that the business needs to have implemented in the solution

requirements, non-functional requirements, business rules, and even what many people traditionally call design

Requirement Engineering

Requirements are what needs to be built, and design is how it will work

The system shall be able to automatically approve or deny credit Functional requirement

When the credit score is above 750, the system shall automatically

The system shall use the following algorithm when automatically

determining credit approvals for scores less than 750: [ algorithm would

Approvals shall be returned to the user within 30 seconds Non-functional

requirement

Trang 8

What are Requirements &

Why Are They Important?

 a statement that identifies a capability, characteristic, or quality factor of a system

in order for it to have value and utility to a customer or user

basis for all of the develop-ment work that follows

other technical work: system design, development, testing, implementa-tion, and operation

Requirement Engineering

Trang 9

provided by a customer at the

beginning of a system or

software development effort

a request for information, proposal,

or quote or in a statement of work

(SOW)

Trang 10

Ex A long list of requirements

REQ003 System shall require name is completed.

REQ004 System shall have a field for position or title.

REQ005 System shall require title is completed.

REQ006

System shall display a position or title if there is one in the stored profile

REQ007 System shall have a field for email address.

REQ008 System shall have a field for alternate email address.

System shall display an error message if not all characters

in the phone number field were digits.

REQ018 System shall have a field for a fax number.

REQ019 System shall require fax is completed.

System shall display an error message if not all characters

in the fax number field were digits.

REQ023 System shall have two fields for a street address.

Trang 11

 Identifying the real requirements requires an interactive and iterative requirements process, supported by effective practices, processes, mechanisms, methods, techniques, and tools

Requirement Engineering

Trang 12

“Limitations of the Human Brain”

Requirement Engineering

Visual Models for Software Requirements [p04]

Trang 13

 are familiar with several types of plans:

facilitates an understanding of the activities and efforts

Requirement Engineering

Trang 14

A Suggested Strategy

project

system life cycle

mechanisms, methods, techniques, tools, and training

Requirement Engineering

Trang 16

Requirements Activities in the System

Life Cycle

needs for the planned system and their expectations of

it

thing to all of the stakeholders

Requirement Engineering

Trang 17

 Specifying the requirements

Trang 18

Investment in the Requirements Process

Trang 19

Requirement Engineering

Trang 20

A Process Approach

activities involved in getting something done

understanding of what is involved

involved

suggest improvements to the process (enabling continuous improvement and empowering those who are involved to contribute ideas for making the process better)

Requirement Engineering

Trang 21

 should be developed by the RA early

and document how

Requirement Engineering

Trang 22

The Requirements Plan: topics

requirements

Requirement Engineering

Trang 23

 Roles and responsibilities of the project’s personnel involved in requirements-related activities

utilized

Requirement Engineering

Trang 24

The Requirements Plan: topics

Trang 25

 meet with a PM very early, perhaps even before an assignment to the project is finalized Discuss with him

or her perspectives concerning requirements

Requirement Engineering

Trang 26

A Comment Concerning Small Projects

achieve good results on small projects

Requirement Engineering

Trang 27

Requirement Engineering

[1] chapter 01, p008

Necessary If the system can meet prioritized real needs without the

requirement, it isn’t necessary.

Feasible The requirement is doable and can be accomplished within

budget and schedule.

Correct The facts related to the requirement are accurate, and it is

technically and legally possible.

Concise The requirement is stated simply.

Unambiguous The requirement can be interpreted in only one way.

Complete All conditions under which the requirement applies are stated,

and it expresses a whole idea or statement.

Consistent It is not in conflict with other requirements.

Verifiable Implementation of the requirement in the system can be proved.

Trang 28

Criteria of a Good Requirement

Allocated The requirement is assigned to a component of the designed

system.

Design independent It does not pose a specific implementation solution.

Nonredundant It is not a duplicate requirement.

Written using the standard construct The requirement is stated as an imperative using “shall.”

Assigned a unique identifier Each requirement shall have a unique identifying number.

Devoid of escape clauses

Language should not include such phrases as “if,” “when,” “but,”

“except,” “unless,” and “although.” Language should not be speculative or general (i.e., avoid wording such as “usually,”

“generally,” “often,” “normally,” and “typically”).

Trang 29

the top reasons that were reported by a set of PMs

1 The requirements for the project are not explicit

2 Requirements changes are made/accepted without addressing

the concomitant cost, schedule, and quality impacts

3 A requirements process is not used

4 There is no mechanism (such as a joint team) to reach agreement

on the definition of the requirements and to manage the requirements through the project life cycle

5 The “real” customer needs are not defined

6 There is no mechanism to maintain communication between the

parties involved in the project

7 Known, familiar, proven methods, techniques, and tools are not

Trang 30

Q/A ?!

Requirement Engineering

Ngày đăng: 23/10/2014, 09:05

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm

w