Bài giảng Phân tích yêu cầu phần mềm: Chương 5 - PGS. TS.Huỳnh Quyết Thắng

Chia sẻ: _ _ | Ngày: | Loại File: PDF | Số trang:76

Thêm vào BST

Báo xấu

2
lượt xem 1
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Bài giảng "Phân tích yêu cầu phần mềm" Chương 5 - Các kỹ thuật nâng cao chất lượng yêu cầu phần mềm, được biên soạn gồm các nội dung chính sau: Kiểm soát thay đổi yêu cầu phần mềm; Các thuộc tính chất lượng của yêu cầu phần mềm; Truy hồi yêu cầu phần mềm (tracing); Quản lý thay đổi yêu cầu phần mềm; Một số công cụ quản lý thay đổi yêu cầu phần mềm;...Mời các bạn cùng tham khảo!

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài giảng Phân tích yêu cầu phần mềm: Chương 5 - PGS. TS.Huỳnh Quyết Thắng

PHÂN TÍCH YÊU CẦU PHẦN MỀM Năm học 2013-2014 Giáo viên: PGS.Huỳnh Quyết Thắng BM Công nghệ phần mềm Khoa CNTT, ĐHBK HN 1
Chương 5. Các kỹ thuật nâng cao chất lượng yêu cầu phần mềm l  V.1. Kiểm soát thay đổi yêu cầu phần mềm l  V.2. Các thuộc tính chất lượng của yêu cầu phần mềm l  V.3. Truy hồi yêu cầu phần mềm (tracing) l  V.4. Quản lý thay đổi yêu cầu phần mềm l  V.5. Một số công cụ quản lý thay đổi yêu cầu phần mềm 2
Introduction Traceability Baselines Change Management Requirements Management Tools Requirements Development (RD) and Management (RM) Source: Wiegers, 1999 3
Quality Requirements* Product description Programs and l  General requirements Data l  Identifications and indications l  Functionality l  Functionality l  Reliability l  Reliability l  Usability l  Usability l  Efficiency l  Efficiency l  Maintainability l  Maintainability l  Portability l  Portability User Documentation l  Completeness l  Correctness l  Consistency * ISO/IEC l  Understandability 12119: 1994(E) l  Ease of overview (IEEE 1465-1998)
Baseline l  Non-modifiable (read-only) version of a document •  Describes a moment in time •  May include multiple documents at the same time l  Enables document comparison and management l  Comes with a change history for the document •  Information on objects, attributes, and links created, deleted, or edited since the creation of the baseline •  Often also contains information on user sessions (when the document was opened, by whom…) l  Requires access control l  It is advisable to establish a baseline for a new document that is imported into the document management system •  In order not to lose any changes 5
Baseline for Requirements l  Represents the set of functional and non-functional requirements that the development team has committed to implement in a specific release l  Before going into the baseline, the requirements should be reviewed and approved by stakeholders l  Once in the baseline, all changes should follow a defined change control process Baseline l  Different viewpoints l  Shared understanding l  No formal documents l  Configuration management l  Always changing l  Change management 6
Baseline Usage l  Baselines may be •  Created •  Complete image of requirements state at a given time •  Deleted •  Visualized •  Possibility to go back •  Compared •  To see changes since a certain time •  Copied •  Signed •  For authorization, contract 7
Chương 5. Các kỹ thuật nâng cao chất lượng yêu cầu phần mềm l  V.1. Kiểm soát thay đổi yêu cầu phần mềm l  V.2. Các thuộc tính chất lượng của yêu cầu phần mềm l  V.3. Truy hồi yêu cầu phần mềm (tracing) l  V.4. Quản lý thay đổi yêu cầu phần mềm l  V.5. Một số công cụ quản lý thay đổi yêu cầu phần mềm 8
Requirements Engineering Activities Requirements Engineering Requirements Requirements Development Management Elicitation Analysis Specification Verification 9
Chương 5. Các kỹ thuật nâng cao chất lượng yêu cầu phần mềm l  V.1. Kiểm soát thay đổi yêu cầu phần mềm l  V.2. Các thuộc tính chất lượng của yêu cầu phần mềm l  V.3. Truy hồi yêu cầu phần mềm (tracing) l  V.4. Quản lý thay đổi yêu cầu phần mềm l  V.5. Một số công cụ quản lý thay đổi yêu cầu phần mềm 10
Why Do Requirements Change? l  Change in software development: as inevitable as difficult to control! •  Better understanding: new requirements become apparent •  Everything else is changing… •  Business •  Context •  Technologies •  Markets •  … l  Possible responses to change •  Add, modify, or remove requirements 11
Some Problems Due to Changing Requirements l  Requirements changing towards the end of development without any impact assessment l  Unmatched/outdated requirements specifications causing confusion and unnecessary rework l  Time spent coding, writing test cases or documentation for requirements that no longer exist 12
Requirements Management A systematic approach to eliciting, organizing, and documenting the requirement of the system, and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system.1 [1] Leffingwell & Widrig 1999, p.16 13
Requirements Management Activities (1) Requirements management includes all activities intended to maintain the integrity and accuracy of expected requirements l  Manage changes to agreed requirements l  Manage changes to baseline (increments) l  Keep project plans synchronized with requirements l  Control versions of individual requirements and versions of requirements documents l  Manage relationships between requirements l  Managing the dependencies between the requirements document and other documents produced in the systems engineering process l  Track requirements status 14
Requirements Management Activities (2) Requirements Management Change control Version control Requirements Requirements status tracking tracing l Proposing l Defining a version l Defining a l Defining links to changes identification possible other scheme requirement requirements l Analyzing impact statuses l Identifying l Defining links to l Making decisions requirements l Recording the other system l Updating document status of each elements requirements versions requirement documents l Identifying l Reporting the l Updates plans individual status distribution requirement of all l Measuring versions requirements requirements volatility Source: Wiegers, 1999 15
Requirements Development (RD) and Management (RM) Source: Wiegers, 1999 16
From Management to Tools l  Changes lead to a need for management l  There is no management without: •  Traceability •  Baselines enabling comparisons l  From a practical point of view, there is no traceability or management without appropriate tools In theory, practice and theory are similar… But in practice they are different J 17
Requirements Change Factors (1) l  Requirements errors, conflicts, and inconsistencies •  May be detected at any phase (when requirements are analyzed, specified, validated, or implemented) l  Evolving customer/user knowledge of the system •  When the requirements are developed, customers/users simultaneously develop a better understanding of what they really need l  Technical, schedule, or cost problems •  Difficult to plan and know everything in advance •  We may have to revisit the list of requirements and adapt it to the current situation 18
Requirements Change Factors (2) Changing customer priorities, new needs l May be caused by a change in the system environment (technological, business, political...), i.e., the context l Business and strategic goals may change l May be caused by the arrival of a new competitor l Laws and regulations may change l Collaborating systems may change l May also be caused by technology changes in the enterprise (migration to a new operating system, DBMS…) l May be caused by organizational changes (organizational structure, business processes, employees…) 19
Requirements Volatility Requirements continuously change l Whilethe requirements are being elicited, analyzed, specified, and validated and after the system has gone into service Some requirements are usually more subject to change than others l Stablerequirements are concerned with the essence of a system and its application domain •  Derived from the client’s principal business activities or the domain model •  They change more slowly than volatile requirements •  E.g., a hospital will always have doctors, nurses, patients… l Volatile requirements are specific to the instantiation of the system in a particular environment for a particular customer at a particular time •  E.g., in a hospital, we can think of requirements related to the policies of the government health system 20