SWR302 – NOTE

I. SLOT1
COURSE INTRODUCTION:
- Teacher information:
o Name: Lê Thị Tú Kiên
o Department: Software Engineering (SE)
o Email: kienltt@fpt.edu.vn
- Course information:
o Course name: Software Requirements
o Code: SWR302
o Syllabus: https://flm.fpt.edu.vn/
o Book, slide and others:

▪ https://cmshn.fpt.edu.vn/

▪ SWR302 - General information for all classes

o Teacher's documents:

▪ https://cmshn.fpt.edu.vn/
o EDUnext: https://fu-edunext.fpt.edu.vn/
o Tool:

▪ Visual Paradigm: https://www.visual-paradigm.com/

SLOT 1
- Giới thiệu môn học
- Chương 1
SLOT 2
- Chương 2
- Chương 3

SLOT 3
- Học chương 3 +5
- Bài tập chuẩn bị slot4
https://drive.google.com/file/d/1Fs2fGEFDKlQkZ7kLolX7P6w6XJZ4CZLO/view?usp=sharing

SLOT 4
- Báo cáo kết quả bài tập: Giới thiệu về dự án
- Học chương 5

SLOT 5
- Chữa bài tập
- Chương 6, 7
SLOT 6
- Chương 8,9
SLOT 7
- BT: Vẽ biểu đồ UC
- PT1
- Chương 10
- Review biểu đồ UC ( Hw slot 6)

SLOT 8
- Review version and scope document + UC diagram
- Chỉnh sửa UC diagram sau báo cáo
- Write UC description ( Mỗi thành viên viết ít nhất 3 mô tả CSD)

SLOT 9

CHAPTER 11: Writing excellent requirements.

Q1. What are characteristics of excellent requirements?

Q2. How to write requirements?

Practice on examples.

CHAPTER 12: A picture is worth 1024 words

Q1. What is purpose of Data flow diagram/

Swimlane diagram/
 State-transition diagram and state table/

Decision tables and decision trees.

Given examples for each type of diagram (Explain the diagram).

CHAPTER 13: Specifying data requirements

Q1. What is the purpose of ERD and class diagrams?

Given examples for each type of diagram (Explain the diagram).

Q2. What is a data dictionary (Given example and explanation)? What is data analysis and CRUD matrix?

Q3. How to specify reports and what is dashboard reporting?

Homework:

1. Mỗi sinh viên viết ít nhất 3 mô tả ca sử dụng theo mẫu chương 8 (use case description/scenario) hoặc SRS template
chương 10.

2. Xây dựng biểu đồ thực thể liên kết cho dự án của nhóm (Chương 13)

SLOT 10

Review UC description and ERD of the project.

SLOT 11

- Review ERD CHAPTER 13

CHAPTER 14: Beyond functionality

Objectives:

- After finishing this chapter, student could:

- detect and specify nonfunctional requirements

- Understand the role of quality requirements in software development

Contents:

1. Software quality attributes

2. Exploring quality attributes (www.clarrus.com/resources/articles/software-quality-attributes)

3. Defining quality requirements

4. Specifying quality requirements with Planguage

5. Quality attribute trade-offs

6. Implementing quality attribute requirements

7. Constraints

8. Handling quality attributes on agile projects

Questions

1. Software quality attributes

Q1. What is the importance of software quality attributes?

Lê Quang Huy

There’s more to software success than just delivering the right functionality. Users also have expectations, often
unstated, about how well the product will work. Such expectations include how easy it is to use, how quickly it
executes, how rarely it fails, how it handles unexpected conditions—and perhaps, how loud it is. Such
characteristics, collectively known as quality attributes, quality factors, quality requirements, quality of service
requirements, or the “–ilities,” constitute a major portion of the system’s nonfunctional requirements. In fact, to
many people, quality attributes are synonymous with nonfunctional requirements, but that’s an
oversimplification.”

Quality attributes can distinguish a product that merely does what it’s supposed to from one that delights its users.
Excellent products reflect an optimum balance of competing quality characteristics
Quality attributes serve as the origin of many functional requirements. They also drive significant architectural and
design decisions. It’s far more costly to re-architect a completed system to achieve essential quality goals than to
design for them at the outset.

Q2. What is the importance of external and internal quality attributes to users, development staff, and maintenance
staff?
 - External quality attributes are crucial for users as they directly impact their satisfaction and experience with the
software, influencing factors like usability, reliability, performance, and security. On the other hand, internal quality
attributes are vital for development and maintenance staff, as they affect the efficiency of development processes,
collaboration, and long-term maintenance efforts. A well-designed system with high internal quality attributes
facilitates easier modification, testing, and maintenance, ultimately contributing to better user experiences and overall
software success.( Phùng Tiến Đạt)

- Users place a high value on external quality qualities since they have a direct influence on how satisfied and happy
they are with the program. These attributes include usability, dependability, performance, and security. However,
because they impact teamwork, long-term maintenance, and the effectiveness of development processes, internal
quality qualities are crucial for development and maintenance personnel. Better user experiences and the success of
software as a whole are ultimately facilitated by well-designed systems with high internal quality qualities that make
modification, testing, and maintenance simpler.(Đặng Vũ Minh)

Q3. Show some external and internal attributes?

External attributes in software requirements refer to features and functionalities of the software that are visible to users or external
stakeholders. Examples include:

Availability

Installability
 Integrity

Interoperability

Performance

Reliability

Robustness

Safety

Security

Usability

Internal attributes in software requirements are characteristics that are not visible to users but are important for the development and
maintenance of the software. Examples include:

Efficiency

Modifiability
 Portability

Reusability

Scalability

Verifiability

Understanding both external and internal attributes in software requirements is essential for ensuring that the software meets the needs of
users and can be effectively developed, deployed, and maintained.
1.

Internal attributes in software requirements are characteristics that are not visible to users but are important for the development and
maintenance of the software. Examples include:

1. Code quality
2. Maintainability
3. Portability
4. Reusability
5. Modularity
6. Testability

Nguyễn Hải Đăng

External Attributes

1.Functionality
2.Usability

3.Reliability

4.Performance Efficiency

5.Security

Internal Attributes

1.Modularity

2.Maintainability

3.Testability

4.Reusability

5.Portability

2. Exploring quality attributes

Q4. Why can be impossible to simultaneously maximize all external and internal attributes in a project?
4 - Chu Thế Văn: It is impossible to simultaneously optimize all external and internal attributes in a project due to trade-offs and
conflicts between them. Since perfection is unattainable, you need to identify which attributes are most important for the success of
the project and set quality objectives based on those attributes so that designers can make appropriate choices.

Vũ Tuấn Hải: there are trade-offs and conflicts between certain attributes that make it impossible to simultaneously
maximize all of them. Because perfection is unattainable, you have to determine which attributes are most important to
your project’s success. Then you can craft specific quality objectives in terms of these essential attributes so designers can
make appropriate choices.

Q5. What are steps (in short) in the approach that Brosseau (2010) recommends for identifying and specifying the
most important attributes for a project?

Nguyễn Mạnh Vinh,

Brosseau (2010) recommends the following steps for identifying and specifying the most important attributes for a
project:

1. Start with a Broad Taxonomy: Begin with a comprehensive list of potential quality attributes.

2. Reduce the List: Engage stakeholders to determine which attributes are relevant and important.

3. Prioritize the Attributes: Use pairwise comparisons to rank the attributes based on importance.

4. Elicit Specific Expectations: Gather detailed user expectations and requirements for each prioritized attribute.
5. Specify Well-Structured Quality Requirements: Formulate clear, measurable, and verifiable requirements based on the
elicited information.

Nguyễn Thị Ngọc

Step 1: Start with a broad taxonomy: Starting with a rich set of quality attributes to consider reduces the likelihood of
missing an important quality aspect.

Step 2: Reduce the list: Engage multiple stakeholders to evaluate which attributes may be important

to the project. Record the reason and decide whether a particular quality attribute is considered or not considered.

Step 3: Prioritize the attributes: Use pairwise comparisons to rank the attributes based on importance.

Step 4: Elicit specific expectations for each attribute: Gather detailed user expectations and requirements for each
prioritized attribute.

Step 5: Specify well-structured quality requirements :Formulate clear, measurable, and verifiable requirements based on
the elicited information.

3. Defining quality requirements

3.1 External quality attributes:

Q6. What are Availability quality attributes? Give an example.

26-Dương Hải Phong

-Availability quality attributes is a measure of the planned up time during which the system’s services are available for use
and fully operational.
-Example: The system shall be at least 95 percent available on weekdays between 6:00 A.M. and midnight Eastern Time,
and at least 99 percent available on weekdays between 3:00 P.M. and 5:00 P.M. Eastern Time.

Q7. What are Installability quality attributes? Give an example.

(27.Vũ Văn Lộc)

Installability quality attributes refer to the ease with which software can be successfully installed and configured on
its intended platforms. This attribute is crucial because software is not useful until it is properly installed on the
appropriate device or system. Good installability ensures that the installation process is straightforward, requires
minimal user intervention, and includes helpful error messages or rollback mechanisms in case something goes
wrong.

Example: Downloading Apps to a Phone or Tablet: Modern mobile applications are typically easy to install via app
stores like Google Play or Apple App Store. Users simply need to search for the app, click the "Install" button, and
the app is automatically downloaded and installed.

Q8. What are Integrity quality attributes? Give an example.

Integrity in the context of software quality attributes refers to the protection of software and data against
unauthorized access and modification. It ensures that the data within a system remains accurate, consistent, and
trustworthy throughout its lifecycle. Integrity is a critical aspect of security and involves measures to prevent data
corruption, unauthorized data alteration, and unauthorized access.
Example Scenario: Online Banking System

Consider an online banking system where maintaining integrity is crucial to protect users' financial information and
ensure the trustworthiness of transactions.

1. Data Integrity:
○ Transaction Validation: Every financial transaction must be validated to ensure that it adheres to the
rules (e.g., sufficient funds are available, transaction limits are not exceeded).
○ Checksum and Hash Functions: Use checksums and cryptographic hash functions to verify that data
has not been altered during transmission between the client and server.
2. Authentication:
○ Multi-Factor Authentication (MFA): Implementing MFA, requiring users to provide multiple forms of
verification (e.g., password, OTP, biometric), to confirm their identity.
○ Session Management: Ensuring that user sessions are securely managed and terminated after a period
of inactivity to prevent unauthorized access.
3. Authorization:
○ Role-Based Access Control (RBAC): Assigning different levels of access to users based on their roles
within the system (e.g., customer, bank employee, admin), ensuring users can only access the data and
perform actions relevant to their role.
○ Access Control Lists (ACLs): Defining specific permissions for resources to control which users or
systems can read, write, or modify the data.
4. Non-repudiation:
○ Digital Signatures: Using digital signatures for transactions to ensure that the origin and integrity of the
transaction can be verified and that the sender cannot deny having sent the transaction.
 ○ Logging and Auditing: Maintaining detailed logs of all transactions and user activities to provide an
audit trail that can be reviewed in case of disputes or security investigations.

Q9. What are Interoperability quality attributes? Give an example.(Le Quoc Tuan)

Interoperability indicates how readily the system can exchange data and services with other software systems and
how easily it can integrate with external hardware devices

Example of Interoperability: The Chemical Tracking System needs to be able to import chemical structures from
ChemDraw (version 13.0 or earlier) and MarvinSketch (version 5.0 or earlier). This means the system can easily
work with these popular tools, making it easier for users to exchange data without needing special changes.

Q10. What are Performance quality attributes? Give an example.

How quickly and predictably the system responds to user inputs or other events

Quỳnh :Performance is one of the quality attributes that users often will bring up spontaneously. Performance represents the
responsiveness of the system to various user inquiries and actions, but it encompasses much more than that, as shown in
Table 14-2. Withall (2007) provides patterns for specifying several of these classes of performance
requirementsPerformance is one of the quality attributes that users often will bring up spontaneously. Performance
represents the responsiveness of the system to various user inquiries and actions, but it encompasses much more than that,
as shown in Table 14-2. Withall (2007) provides patterns for specifying several of these classes of performance
requirements

Response Time:

● Definition: The amount of time it takes for a system to respond to a user's request.
 ● Example: A mobile banking app should display the account balance within 1 second of the user pressing the "Check
Balance" button.

Throughput:

● Definition: The amount of work a system can process in a given period.

● Example: An e-commerce website should handle 2000 transactions per minute during peak shopping times.

Scalability:

● Definition: The ability of a system to handle an increasing load without performance degradation.
● Example: A video streaming service should support scaling up to 1 million concurrent users during major events
without buffering.

Capacity:

● Definition: The maximum load a system can handle.

● Example: A cloud storage service should be able to store up to 100 petabytes of data.

Efficiency:

● Definition: The ability of the system to use resources optimally while maintaining performance.
● Example: A data analysis tool should perform complex calculations using less than 70% of CPU resources.

Resource Utilization:

● Definition: The extent to which system resources (CPU, memory, disk, network) are used effectively.
● Example: A real-time analytics application should keep network bandwidth usage below 80% to ensure data is
processed without delays.
Q11. What are Reliability quality attributes? Give an example.

(Nguyễn Phú Anh) Reliability in software is the probability that the software will execute without failure for a
specific period of time (Musa 1999). Reliability issues can arise due to improper inputs, software code errors,
unavailable components, and hardware failures. Reliability is closely related to robustness and availability. It can be
measured by the percentage of correctly completed operations, the average time the system operates before failing
(MTBF), and the maximum acceptable failure probability over a given period. Quantitative reliability requirements
should be established based on the severity of potential impacts and the cost-effectiveness of maximizing reliability.
High-reliability systems should also be designed for high verifiability to facilitate defect detection.

Example:

The mean time between failures of the card reader component shall be at least 90 days. There’s no way to tell if the
system has satisfied this requirement until at least 90 days have passed. However, you can tell if the system has failed
to demonstrate sufficient reliability if the card reader component fails more than once within a 90-day period

(Nguyễn Quốc Bảo) Reliability is defined as the probability that a product, system, or service will perform its
intended function adequately for a specified period of time, or will operate in a defined environment without failure.

Example: Suppose an airline operates a fleet of airplanes and records that over a year, 95% of their flights were
completed without any technical failures that impacted safety or required unscheduled maintenance. This would
imply a reliability rate of 0.95, or 95%.

Q12. What are Robustness quality attributes? Give an example.

(12 - Chu Đức Thắng)

Robustness is the degree to which a system continues to function properly when confronted with invalid inputs, defects in
connected software or hardware components, external attack, or unexpected operating conditions.

Ex: If a server in the banking system's cluster fails, the system can reroute traffic to other servers to ensure uninterrupted
service. This might involve load balancing and redundancy measures.

Q13. What are Safety quality attributes? Give an example. (Nguyễn Đức Long)

● Safety requirements aim to prevent harm to people and damage to property. These requirements can be mandated by
government regulations, business rules, or legal and certification issues. They are often expressed as conditions or
actions that the system must avoid allowing.

Ex1: An application to let people order meals from a cafeteria might include a safety requirement like the following:

The user shall be able to see a list of all ingredients in any menu item, with ingredients highlighted that are known to cause
allergic reactions in more than 0.5 percent of the North American population.

● Web browser features like parental controls can address safety or security requirements. However, safety
requirements are more commonly written for hardware systems.

Ex2: It’s more common to see safety requirements written for systems that include hardware, such as the following
examples:

If the reactor vessel’s temperature is rising faster than 5°C per minute, the Chemical Reactor Control System shall turn off
the heat source and signal a warning
Q14. What are Security quality attributes? Give an example.( Dang Hung)

Security is essential for preventing unauthorized access and protecting software from malware. It's especially critical
for internet software, like e-commerce platforms, where users expect their data to be secure. Companies also aim to protect
against denial-of-service (DoS) attacks and hacking.

Key Security Considerations

1. User Authorization: Define user roles and access levels using a roles and permissions matrix.
2. Authentication: Implement password policies, security questions, biometric ID, and account lockout after failed
attempts.
3. Data Privacy: Specify who can create, view, modify, copy, print, and delete data.
4. Data Protection: Safeguard against data destruction, corruption, or theft.
5. Malware Protection: Defend against viruses, worms, Trojans, and spyware.
6. Network Security: Use firewalls and other network security measures.
7. Data Encryption: Encrypt sensitive data in transit and at rest.
8. Audit Trails: Log operations and access attempts for accountability.

Eliciting Security Requirements

● What sensitive data needs protection?

● Who is authorized to view sensitive data?
● When can authorized users access functionality?
● What checks confirm a secure user environment?
● How often should virus scans occur?
● Is a specific authentication method required?
Example:
Following are some examples of security requirements. It’s easy to see how you could design tests

to verify that these requirements are correctly implemented.

SEC-1. The system shall lock a user’s account after four consecutive unsuccessful

logon attempts within a period of five minutes.

SEC-2. The system shall log all attempts to access secure data by users having

insufficient privilege levels.

SEC-3. A user shall have to change the temporary password assigned by the security

officer to a previously unused password immediately following the first successful

logon with the temporary password.

SEC-4. A door unlock that results from a successful security badge read shall keep

the door unlocked for 8.0 seconds, with a tolerance of 0.5 second.

SEC-5. The resident antimalware software shall quarantine any incoming Internet

traffic that exhibits characteristics of known or suspected virus signatures.

SEC-6. The magnetometer shall detect at least 99.9 percent of prohibited objects,

with a false positive rate not to exceed 1 percent.

Security requirements often originate from business rules, such as corporate security policies, as the

following example illustrates:

SEC-7. Only users who have Auditor access privileges shall be able to view customer

transaction histories.
Q15. What are Usability quality attributes? Give an example. Nguyen Ba Duc

Usability quality attributes are criteria that define how user-friendly and efficient a software or system is. Key
attributes include:

● Learnability: How easily users can perform basic tasks on first use. Example: A website with a step-by-step
tutorial for new visitors.
● Efficiency: How quickly users can perform tasks after learning the system. Example: A streamlined interface
in a software application that reduces the number of steps to complete a task.
● Memorability: How easy it is for users to remember how to use the system after not using it for a time.
Example: Consistent menu layouts in an application.
● Errors: The rate and severity of errors made by users, and how easily they can recover from them. Example:
A form that validates information as it's entered and provides helpful error messages.
● Satisfaction: The overall satisfaction of users with the system. Example: A visually appealing and intuitive
user interface in a mobile app.

3.2. Internal quality attributes

Q16. What are Effciency quality attributes? Give an example. (Tuấn Long)
Efficiency is closely related to the external quality attribute of performance. Efficiency is a measure of

how well the system utilizes processor capacity, disk space, memory, or communication bandwidth.

Examples :

■EFF-1. At least 30 percent of the processor capacity and memory available to the

application shall be unused at the planned peak load conditions.

EFF-2. The system shall provide the operator with a warning message when the

usage load exceeds 80 percent of the maximum planned capacity

Q17. What are Modifiability quality attributes? Give an example.

Phùng Anh Tuấn

Modifiability addresses how easily the software designs and code can be understood, changed,

and extended. Modifiability encompasses several other quality attribute terms that relate to
different forms of software maintenance. It is closely related to verifiability.

If developers anticipate making many enhancements, they can choose design approaches that

maximize the software’s modifiability. High modifiability is critical for systems that will undergo

frequent revision, such as those being developed by using an incremental or iterative life cycle.

Example :A maintenance programmer experienced with the system shall be able to

modify existing reports to conform to revised chemical-reporting regulations from

the federal government with 10 hours or less of development effort.

Q18. What are Portability quality attributes? Give an example.(Nguyễn Chí Hưởng)

Portability measures the effort needed to move software between different environments, including
internationalization and localization. Designing portable software is similar to designing reusable software. With
various environments such as Windows, Mac, Linux; iOS, Android; and devices like computers, tablets, and phones,
portability has become crucial.

The goal of portability is to identify the parts that need to be moved and the target environments. Understanding
customer expectations helps select appropriate development methods.

Examples of portability requirements:

● Modifying the iOS version to run on Android requires changing no more than 10% of the source code.
● Users can transfer bookmarks between different browsers.
● The platform migration tool transfers user profiles without user action.

Q.19 What are Reusability quality attributes? Give an example. ( Đinh Quốc Khánh)

Thuộc tính chất lượng tái sử dụng đề cập đến các đặc điểm của một thành phần phần mềm hoặc hệ thống cho phép
nó được sử dụng trong nhiều ngữ cảnh hoặc ứng dụng khác nhau. Các thuộc tính chính bao gồm:
 1. Tính mô-đun: Phần mềm được chia thành các đơn vị hoặc mô-đun tự chứa với chức năng xác định.
2. Tính đóng gói: Che giấu các chi tiết nội bộ của mô-đun khỏi các mô-đun khác.
3. Tính liên kết: Mỗi mô-đun thực hiện một nhiệm vụ duy nhất hoặc các nhiệm vụ liên quan chặt chẽ.
4. Tính tách rời: Giảm thiểu sự phụ thuộc giữa các mô-đun.
5. Tài liệu hóa: Cung cấp tài liệu rõ ràng và chi tiết.
6. Tham số hóa: Mô-đun chấp nhận các tham số để tùy chỉnh hành vi.
7. Tính linh hoạt: Dễ dàng mở rộng và thay đổi.
8. Chuẩn hóa: Tuân thủ các tiêu chuẩn công nghiệp.

Ví dụ

Hệ thống quản lý thư viện:

Một mô-đun quản lý tài khoản người dùng có các chức năng như đăng ký, đăng nhập và quản lý hồ sơ.

Thuộc tính:

● Tính mô-đun: Mô-đun quản lý tài khoản người dùng độc lập và thực hiện các nhiệm vụ cụ thể.
● Tính đóng gói: Chi tiết nội bộ về xác thực và lưu trữ dữ liệu được che giấu.
● Tính liên kết: Tất cả các chức năng liên quan đến quản lý tài khoản.
● Tính tách rời: Mô-đun có ít phụ thuộc vào các phần khác của hệ thống.
● Tài liệu hóa: Có tài liệu hướng dẫn rõ ràng.
● Tham số hóa: Chấp nhận các tham số như vai trò và quyền của người dùng.
● Tính linh hoạt: Có thể thêm tính năng mới mà không ảnh hưởng lớn đến mã hiện có.
● Chuẩn hóa: Tuân theo các giao thức chuẩn như OAuth hoặc LDAP
Q20. What are Scalability quality attributes? Give an example.( Đỗ Đăng Phương)

-Scalability requirements address the ability of the application to grow to accommodate more users, data, servers,
geographic locations, transactions, network traffic, searches, and other services without compromising performance or
correctness

Example:

Scalability:

+The system should handle increasing workloads. Example: An IoT device network that can scale from 10 to 10,000
devices with minimal performance loss.

+The capacity of the emergency telephone system must be able to be increased from 500 calls per day to 2,500 calls per day
within 12 hours

Q21. What are Verifiability quality attributes? Give an example.

(Trịnh Quốc Toản)

Verifiability là một trong những thuộc tính chất lượng của hệ thống, thể hiện khả năng kiểm tra, xác minh và đánh
giá các khía cạnh khác nhau của hệ thống để đảm bảo rằng nó hoạt động đúng như mong đợi và đáp ứng các yêu
cầu đặt ra.

Các thuộc tính chất lượng của Verifiability bao gồm:

· Kiểm tra tự động (Automatability)

· Tính rõ ràng (Clarity)

· Khả năng quan sát (Observability)

· Tính đo lường (Measurability)

Ví dụ: Giả sử chúng ta đang phát triển một hệ thống quản lý bán hàng trực tuyến. Để đảm bảo tính verifiability của hệ thống này, chúng
ta có thể thực hiện các bước sau:

1. Kiểm tra tự động: Thiết lập các bộ kiểm tra tự động để kiểm tra các chức năng chính như đặt hàng, thanh toán, và quản lý
hàng tồn kho. Sử dụng các công cụ như Selenium để kiểm tra giao diện người dùng, JUnit để kiểm tra các thành phần back-end.

2. Tính rõ ràng: Đặc tả các yêu cầu của hệ thống một cách rõ ràng và chi tiết, sử dụng các tài liệu và biểu đồ để minh họa các
quy trình nghiệp vụ và các tình huống sử dụng khác nhau.

3. Khả năng quan sát: Thiết lập hệ thống log để ghi lại các sự kiện quan trọng như giao dịch mua hàng, lỗi hệ thống, và các cảnh
báo bảo mật. Sử dụng các công cụ giám sát như ELK Stack (Elasticsearch, Logstash, Kibana) để phân tích và hiển thị các log này.

4. Tính đo lường: Xác định các chỉ số đo lường hiệu suất như thời gian phản hồi của hệ thống, tỷ lệ thành công của các giao dịch,
và mức độ hài lòng của khách hàng. Sử dụng các công cụ phân tích như Google Analytics hoặc các dashboard tùy chỉnh để theo
dõi các chỉ số này.
SLOT 12

CHAPTER 15: Risk reduction through prototyping

Objectives

• This chapter describes how prototyping provides value to the project and different kinds of prototypes you might
create for different purposes.

• It also offers guidance on how to use them during requirements development, as well as ways to make
prototyping an effective part of your software engineering process

Contents

1. Prototyping: What and why

2. Mock-ups and proofs of concept

3. Throwaway and evolutionary prototypes

4. Paper and electronic prototypes

5. Working with prototypes

6. Prototype evaluation

7. Risks of prototyping

8. Prototyping success factors

Group prepare and present.

Chapter 15 – Risk reduction through prototyping

I. Prototyping: What and why

1. What is a software prototype?

2. What are the three major purposes of prototypes? Explain more about them.

3. What is the primary reason for creating a prototype?

4. What are the three classes of prototype attributes and their alternatives?

II. Mock-ups and proofs of concept

5. What is a mock-up? What are its characteristics? (G1)

A mock-up, often referred to as a horizontal prototype, is a simplified representation of a software system's user interface. It
is designed to demonstrate the visual aspects, navigational flow, and general look and feel of the application without delving
into detailed functionality or backend processes.

1.Focus on User Interface: A mock-up primarily concentrates on illustrating the user interface screens. It shows how
different screens would look, the arrangement of elements (such as buttons, menus, etc.), and the overall layout.

2.Limited Functionality: Unlike a fully functional prototype or proof of concept, a mock-up does not implement real
functionality. It simulates user interactions and may show responses to actions, but these are often predefined or simulated
rather than dynamic or based on actual data or computations.
3.Behavior Simulation: It simulates user interaction to a certain extent, allowing navigation between screens and
demonstrating how users might interact with the system. However, interactions are often superficial and do not execute real
processes or operations.

4.Visual Representation: It provides a visual representation of the system's intended appearance, including colors, graphics,
fonts, and overall graphical user interface (GUI) elements.

5.Use for Requirements Refinement: The primary goal of a mock-up is to gather feedback and refine requirements. It helps
stakeholders, including users and developers, visualize and discuss the proposed user interface and its usability aspects.

6.Enhanced Validity with Sample Data: While mock-ups do not use real data or perform real computations, using sample
data in displays and outputs can enhance their validity as a model of the real system.

7.Exploration and Evaluation: Mock-ups are useful for exploring design alternatives and evaluating different user interface
approaches before committing to detailed design and development.

6. What is a proof of concept? What are its characteristics? (G2)

- A proof of concept (PoC) is a type of vertical prototype that implements a slice of application functionality from the
user interface through all the technical services layers. Its primary purpose is to demonstrate whether a proposed
architectural approach is feasible and sound.
- Characteristics of a Proof of Concept:
1. Implementation of Application Functionality:
 ○ A PoC touches on all levels of the system implementation, from the user interface to the technical service
layers.
○ Unlike mock-ups, it doesn't just simulate behavior; it actually implements it.
2. Validation of Feasibility:
○ A PoC is used to determine whether a proposed architectural approach is feasible.
○ It helps in verifying whether the proposed system can meet critical requirements, such as performance and
reliability.
3. Optimization and Evaluation:
○ A PoC can be used to optimize algorithms, evaluate a proposed database schema, and confirm the soundness
of a cloud solution.
○ It also helps test critical timing requirements and other technical constraints.
4. Production Tools and Environment:
○ To make the results meaningful, PoCs are constructed using production tools in a production-like operating
environment.
○ This ensures that the prototype is realistic and can provide accurate insights into the feasibility of the
approach.
5. Estimation and Planning:
○ A PoC helps gather information to improve the team’s ability to estimate the effort involved in implementing
a specific user story or block of functionality.
○ This is particularly useful in agile development projects where accurate estimations are crucial.
6. Limited Scope:
○ A PoC typically focuses on a specific aspect or a small slice of the system rather than attempting to cover the
entire application.
○ This focused approach allows for in-depth evaluation of critical components without the overhead of a full
implementation.
III. Throwaway and evolutionary prototypes

7. What is a throwaway prototype? What are its characteristics? (G3)

A throwaway prototype is a type of prototype that is developed quickly and used primarily to help stakeholders understand
and refine requirements. A throwaway prototype is most appropriate when the team faces uncertainty, ambiguity,
incompleteness, or vagueness in the requirements, or when they have difficulty envisioning the system from the
requirements alone.

Characteristics :

1. Purpose: The primary purpose of a throwaway prototype is to explore and clarify requirements. It is not intended to
be a part of the final product but serves as a means to validate and refine the understanding of user needs and system
requirements.
2. Speed of Development: Throwaway prototypes are developed rapidly, often using tools and technologies that allow
quick creation of user interfaces or mockups. This rapid development enables stakeholders to visualize the proposed
system functionalities early in the development process.
3. Limited Scope and Functionality: They typically focus on specific aspects or functionalities of the system rather than
attempting to replicate the entire system. This narrow scope allows developers to concentrate efforts on critical or
unclear requirements.
4. Disposable Nature: Unlike evolutionary prototypes that may evolve into the final product, throwaway prototypes are
not designed to be part of the final system. Once their purpose of validating requirements is served, they are
discarded or set aside.
 5. Feedback and Refinement: Throwaway prototypes facilitate feedback from stakeholders, including users, analysts,
and developers. Based on this feedback, requirements can be refined, clarified, or changed to better meet user needs
and expectations.
6. Risk Reduction: By allowing stakeholders to interact with a tangible representation of the system early in the
development process, throwaway prototypes help reduce the risk of misunderstandings and misinterpretations of
requirements. This ultimately contributes to a more accurate and effective final system design.

8. What is the other name of the throwaway prototype?

9. What throwaway prototyping is commonly used for custom user interface design and website design?

10. What are three aspects of a website that wireframes help to reach a better understanding?

11. Which tool is an excellent tool for exploring and iterating on page navigation for a website?

12. What is an evolutionary prototype? What are its characteristics? (G3)

An evolutionary prototype is a type of prototype used in software development to gradually evolve into the final product.
Prototype evaluation is related to usability testing (Rubin and Chisnell 2008). You’ll learn more by watching users work
with the prototype than just by asking them to tell you what they think of it.
Characteristics :

1. Iterative Development: Evolutionary prototypes are developed incrementally in multiple iterations. Each iteration
builds upon the previous one, incorporating feedback and new requirements as the prototype progresses closer to the
final system.
2. Continuous Refinement: Unlike throwaway prototypes, which are discarded after requirements clarification,
evolutionary prototypes are continuously refined and enhanced throughout the development process. They serve as a
basis for refining and validating requirements iteratively.
3. Integration with Final System: Evolutionary prototypes are designed with the intention that parts of or the entire
prototype will eventually become part of the final system. As development progresses, components of the prototype
may be re-engineered or extended to meet the evolving requirements and design goals.
4. Feedback Loop: Stakeholders, including users, analysts, and developers, provide continuous feedback throughout the
iterative development of the evolutionary prototype. This feedback is crucial for identifying and addressing issues,
refining requirements, and ensuring that the evolving system meets user needs effectively.
5. Risk Management: By allowing stakeholders to interact with and provide feedback on an evolving system early in
the development process, evolutionary prototypes help mitigate risks associated with misunderstandings or
misinterpretations of requirements. Issues and challenges can be identified and addressed early, reducing the
likelihood of costly changes later in the development lifecycle.
6. Support for Agile Methods: Evolutionary prototypes align well with agile development methodologies, such as
Scrum or Extreme Programming (XP). These methodologies emphasize iterative development, customer
collaboration, and responsiveness to change, making evolutionary prototypes a suitable approach for agile teams.

13. What type of project often uses evolutionary prototype?

14. Can we combine prototypes?

15. How to incorporate prototyping into the software development process?

IV. Paper and electronic prototypes

16. What is a paper prototype? What are its characteristics?

17. List some electronic throwaway prototypes?

18. What should the business analyst be careful of when use any prototype?

V. Working with prototypes

19. Explain an activity sequence from use cases to user interface design using a throwaway prototype shown in figure 15-2.
Re-illustrated this sequence by the PearlsFromSand.com example.

Self-Study:

VI. Prototype evaluation

20. How to evaluate prototype?

VII. Risks of prototyping

21. What are the risks of prototyping?

VIII. Prototyping success factors

22. What are prototyping success factors?

CHAPTER 16: First things first: Setting requirement priorities

1. Why prioritize requirements?

2. Some prioritization pragmatics.

3. Games people play with priorities.

4. Some prioritization techniques

- In or out

- Pairwise comparison and rank ordering

- Three-level scale

- MoSCoW

- $100

5. Prioritization based on value, cost, and risk.

--

1. Why prioritizes requirements?

 - Prioritization, also called requirements triage (Davis 2005), helps reveal competing goals, resolve
conflicts, plan for staged or incremental deliveries, control scope creep, and make the necessary trade-off
decisions.

- Prioritization is a critical strategy for agile or other projects that develop products through a series of
fixed-schedule timeboxes

- Establish priorities early in the project, when you have more flexibility for achieving a successful
project outcome, and revisit them periodical.

2. Some prioritization pragmatics.

Alan Davis (2005) indicates that successful prioritization requires an understanding of six issues:

• The needs of the customers

• The relative importance of requirements to the customers

• The timing at which capabilities need to be delivered

• Requirements that serve as predecessors for other requirements and other relationships among requirements

• Which requirements must be implemented as a group

• The cost to satisfy each requirement

3. Games people play with priorities.

To encourage customers to acknowledge that some requirements have lower priority, the analyst can ask
questions such as the following:

• Is there some other way to satisfy the need that this requirement addresses?

• What would the consequences be of omitting or deferring this requirement?

• What effect would it have on the project’s business objectives if this requirement weren’t implemented for several
months?

• Why might a customer be unhappy if this requirement were deferred to a later release?

• Is having this feature worth delaying release of all of the other features with this same priority?

4. Some prioritization techniques

(Mô tả ngắn gọn ý tưởng của phương pháp)

- In or out (G6)

-In or out The simplest of all prioritization methods is to have a group of stakeholders work down a list of
requirements and make a binary decision: is it in, or is it out? Keep referring to the project’s business objectives to
make this judgment, paring the list down to the bare minimum needed for the first release. Then, when
implementation of that release is under way, you can go back to the previously “out” requirements and go through
the process again for the next release

- Pairwise comparison and rank ordering (G6)

Pairwise comparison and rank ordering People sometimes try to assign a unique priority sequence number to each
requirement.Rank ordering a list of requirements involves making pairwise comparisons between all of them so you
can judge which member of each pair has higher priority.
In reality, rank ordering all of the requirements by priority is overkill. You won’t be implementing all of these in
individual releases; instead, you’ll group them together in batches by release or development timebox.

- Three-level scale (G5)

Description: This method divides requirements or tasks into three priority levels: high, medium, and low. Each level
represents a different degree of importance and urgency:

High: These tasks or requirements are crucial and need immediate attention. Failure to address them could
significantly impact the project’s success.

Medium: These are important but not critical. They should be addressed after the high-priority items are completed.

Low: These tasks or requirements are least critical and can be attended to later. They have minimal impact on the
project if delayed.

Benefits: Simple to understand and implement, helping teams quickly identify the most critical items.

- MoSCoW (G5)

Description: The MoSCoW method categorizes requirements into four groups based on their importance:

Must have: These are essential requirements that the project cannot do without. They are critical for the system’s
functionality.
Should have: These requirements are important but not essential. They add significant value but are not critical to
the project's success.

Could have: These are desirable but not necessary. They are nice-to-have features that do not affect the project’s
core objectives if omitted.

Won't have: These requirements are agreed to be excluded from the current project scope. They can be considered
for future phases.

Benefits: Helps in clearly defining and communicating priorities, ensuring that essential requirements are not
overlooked while managing scope and resources effectively.

- $100 (G5)

Description: In this method, each team member is given a hypothetical $100 to allocate to different requirements or
tasks based on their perceived importance. Each person distributes their $100 among the tasks, indicating their
priorities:

Allocation: Team members decide how much of their $100 to allocate to each requirement or task. For instance, if a
task is deemed very important, a member might allocate $50 to it.

Summation: After allocation, the totals for each requirement or task are summed up. The items with the highest
totals are prioritized.
 Benefits: Encourages participation from all team members, providing a democratic and quantitative way to prioritize
tasks. It helps in reaching a consensus on what is most important based on collective input.

5. Prioritization based on value, cost, and risk. (G4)

( Mô tả cách tính)

To summarize the prioritization process for features, use cases, user stories, or functional requirements in a project,
here are the steps:

1. List and Categorize: Start by listing all the items (features, use cases, user stories, etc.) that need prioritization.
Ensure they are at the same level of abstraction and do not mix different types of requirements.
2. Estimate Benefit: Have customer representatives estimate the relative benefit of each item on a scale from 1 to 9.
This rating indicates how valuable each item is to the customer or business objectives.
3. Assess Penalty: Estimate the relative penalty if each item were not included, also using a scale of 1 to 9. Consider
factors like competitive disadvantage, legal or contractual consequences, user expectations, etc.
4. Calculate Total Value: Calculate the total value for each item as the sum of its benefit and penalty scores. This
provides a weighted view of its importance.
5. Estimate Implementation Cost: Developers estimate the relative cost of implementing each item on a scale from 1
(quick and easy) to 9 (time-consuming and expensive). This considers complexity, UI work, testing requirements,
etc.
6. Evaluate Technical Risk: Developers rate the relative technical risk associated with each item on a scale from 1 to
9. This assesses the probability of encountering challenges during implementation, such as feasibility or complexity
issues.
 7. Calculate Priority: Use the formula to calculate a priority value for each item:
Priority = Value % / (Cost % + Risk %)
This formula combines the weighted value with the percentages of cost and risk to determine the overall priority.
8. Prioritize and Discuss: Sort the list of items in descending order based on their calculated priority values. Items with
higher priority are considered more critical due to their balance of value, cost, and risk. Discussions can focus on
refining this prioritized list based on stakeholder input and project goals

SLOT 13:

CHAPTER 17: Validating the requirements

1. Why do we need to validate the requirements? (G1)Lê Quang Huy

Verifying requirements to ensure that they have all the desired properties of high-quality requirements is also an essential
activity.Verification determines whether the product of some development activity meets its requirements (doing the thing
right). Validation assesses whether a product satisfies customer needs (doing the right thing).

2. Distinguish between Verification and Validation. What are requirements validation activities? (G2)

● Requirements validation is the fourth component of requirements development, along with elicitation, analysis, and
specification. Verifying requirements to ensure that they have all the desired properties of high-quality requirements
is also an essential activity.
● Verification determines whether the product of some development activity meets its requirements (doing the thing
right).
● Validation assesses whether a product satisfies customer needs (doing the right thing).
 ● Extending these definitions to requirements, verification determines whether you have written the requirements right:
your requirements have the desirable properties. Validation of requirements assesses whether you have written the
right requirements: they trace back to business objectives.

Validating requirements allows teams to build a correct solution that meets the stated business objectives.

■ The software requirements accurately describe the intended system capabilities and properties that will satisfy the various
stakeholders’ needs.

■ The software requirements are correctly derived from the business requirements, system requirements, business rules, and
other sources.

■ The requirements are complete, feasible, and verifiable.

■ All requirements are necessary, and the entire set is sufficient to meet the business objectives.

■ All requirements representations are consistent with each other.

■ The requirements provide an adequate basis to proceed with design and construction.
3. How to review requirements by the inspection process? (G1)Trịnh Quốc Toản
1. Initial Work Product

● Start with the Initial Work Product: This is the requirements document or any initial set of requirements that need
to be inspected.

2. Planning

● Planning Phase:
○ Schedule the inspection.
○ Assign roles to the participants (e.g., moderator, author, reviewers).
○ Set goals for the inspection.
○ Ensure necessary materials are available.

3. Preparation

● Preparation Phase:
○ Each participant individually reviews the requirements document.
○ Note down potential defects, ambiguities, inconsistencies, or issues.
○ Familiarize with the content to effectively contribute to the inspection meeting.

4. Inspection Meeting

● Conduct the Inspection Meeting:

○ Moderator leads the meeting.
○ Each reviewer presents their findings.
○ Discuss each identified issue thoroughly.
○ The author of the document takes notes on the feedback.
○ Aim to reach a consensus on defects and necessary changes.
5. Rework

● Rework Phase:
○ The author revises the requirements document based on the feedback received during the inspection meeting.
○ Address all identified defects and issues.
○ This phase may involve significant revisions depending on the extent of the feedback.

6. Follow-Up

● Follow-Up Phase:
○ The moderator checks the revised requirements document to ensure all identified defects have been addressed.
○ Confirm that the changes made during rework are correct and complete.

7. Potential Reinspection

● Reinspection (if necessary):

○ If the rework was extensive or if significant changes were made, portions of the inspection process might be
repeated.
○ Reinspect the revised document to ensure no new issues were introduced and all initial defects were resolved.

8. Baseline Work Product

● Final Approval:
○ Once the follow-up confirms that all issues are resolved, the requirements document is baselined.
○ This means it is officially approved and can be used as a reference for further project phases.
4. How to test the requirements? (G2)

● Tests that are based on the functional requirements or derived from user requirements help make the expected system
behaviors tangible to the project participants. Vague and ambiguous requirements will jump out at you because you
won’t be able to describe the expected system response.
● You can begin deriving conceptual tests from user requirements early in the development process.
● Ideally, a BA will write the functional requirements and a tester will write the tests from a common starting point: the
user requirements
CHAPTER 18: Requirements reuse

1. Why do we reuse requirements? (G3)

Reusing trusted requirements can provide several benefits:

- Faster delivery: Reduces development time and speeds up the approval process.

- Lower development costs: Optimizes development costs through reuse.

- Consistency: Ensures consistency both within a single application and across different applications.

- Higher team productivity: Teams work more efficiently with pre-validated requirements.

- Fewer defects and reduced rework: Minimizes errors and reduces the need for rework.

Additionally, reusing requirements helps improve the ability to estimate implementation effort based on data from previous
projects. From the user's perspective, requirements reuse ensures functional consistency across related products or within a
set of business applications.

2. What are three dimensions of requirements reuse?(G3)

3 dimensions of requirements reuse are:

Extent of Reuse: This dimension measures how much of the existing requirement is reused in a new project. It
ranges from complete reuse, where requirements are used without any changes, to partial reuse, where only parts of the
requirements are applicable and used.
 Extent of Modification: This dimension refers to the degree of changes required to adapt the reused requirements to
the new project. Modifications can vary from minor adjustments to substantial rewrites, depending on the specific needs and
constraints of the new project.

Reuse Mechanism: This dimension describes the methods or tools used to facilitate reuse. Mechanisms can include
documentation templates, requirement patterns, repositories, and requirement management tools that help catalog and
retrieve reusable requirements efficiently.

3. What types of requirements information to reuse? (G4)

Following are some other groupings of related requirements information to reuse in sets:

● Functionality plus associated exceptions and acceptance tests

● Data objects and their associated attributes and validations
● Compliance-related business rules, such as Sarbanes–Oxley, other regulatory constraints by industry, and
organization policy-focused directives
● Symmetrical user functions such as undo/redo (if you reuse the requirements for an application’s undo function, also
reuse the corresponding redo requirements)
● Related operations to perform on data objects, such as create, read, update, and de

4. What are common reuse scenarios of requirements? (G4)

- Software product lines:

- Common Features: Features that appear in all members of the product line.
- Optional Features: Features that appear in certain family members but not others.
- Variants: Different versions of a feature appearing in different family members.
 - Reengineered and replacement systems:
- Reuse of requirements from the original system
- Reverse-engineering requirements from an older system
- Harvesting and updating business rules embedded in the old system
- Other likely reuse opportunities:
- Situations where reusing requirements information is common, which might include projects with similar
objectives, functionalities, or contexts within the same organization.
- Accumulating reusable artifacts into a shared repository and managing this information as an enterprise-level
asset.
- Using artifacts from previous projects that are similar to the current one

5. What are requirement reuse barriers and success factors?

 CHAPTER 19: Beyond requirements development

1. What are the effects of requirements on software development? (G5)

Requirements drive the project's planning, design, coding, and testing activities, acting as the central framework that
connects the initial concept of the project with its final outcome. This ensures that the developed software aligns well with
business objectives and user expectations, helping to manage scope and mitigate risks associated with the project.

2. How to estimate requirements effort? (G5)

three complementary estimates:

● The first estimate is based on a percentage of the estimated total project work.
● The second type of estimate assumes a typical ratio of developers to business analysts.
● The third estimate considers the various activities a BA performs, based on estimates of the numbers of various
artifacts that might be created on a specific project. The BA can estimate the number of process flows, user stories,
 screens, reports, and the like and then make reasonable assumptions of how many other requirements artifacts are
needed.

3. How do requirements affect the project plan? (G6)

1. Foundation for Estimation and Scheduling: Requirements serve as the basis for estimating the project's size and
effort. Clear requirements enable accurate estimates of time and resources needed.
2. Facilitating Detailed Planning: Defining software requirements before making detailed plans ensures the feasibility
of the schedule and commitments.
3. Impact on Effort and Time Estimates: Estimating the product size based on functional requirements, user stories,
analysis models, prototypes, or user interface designs determines the effort and time required for development.
4. Stability of Requirements: Stable requirements allow for accurate scheduling and estimation. Conversely,
frequently changing requirements increase uncertainty and may necessitate continual adjustments to the project plan.
5. Prioritizing Requirements and Scope Decisions: When time or resources are limited, prioritizing requirements
determines which functionalities can be included in the plan, focusing on the most critical features.
6. Dealing with Volatile Requirements: Projects with highly volatile requirements benefit from incremental and
iterative development methods, allowing the project plan to be adjusted based on early customer feedback.
7. Risk Management and Contingency: Including contingency buffers in the schedule and budget to accommodate
requirement growth helps manage the risk of changing or unclear requirements.
8. Negotiation and Adjustment: When there is a mismatch between imposed deadlines and estimated schedules,
negotiation is necessary to adjust requirements, time, or resources to achieve project goals.

4. How to requirements effect to design and code?(G6)

Impact on Design
Clarity of Scope:

Requirements: Clear and well-defined requirements help in understanding the scope of the project.

Design: Designers can create a system architecture that meets the defined scope without over-engineering or under-
engineering.

User Experience (UX):

Requirements: User needs and usability requirements dictate the user interface and experience.

Design: UX designers create wireframes, prototypes, and user flows that ensure the system is user-friendly and meets user
expectations.

System Architecture:

Requirements: Functional and non-functional requirements (like performance, scalability, security) influence the system
architecture.

Design: Architects design the system's overall structure, including components, data flow, and interaction patterns.

Technology Stack:

Requirements: Specific requirements may dictate or restrict the choice of technology stack (programming languages,
frameworks, databases).
Design: The chosen technologies impact how the system is designed, including its modularity and integration points.

Data Modeling:

Requirements: Data-related requirements (data types, relationships, constraints) influence the data model.

Design: Database designers create schemas and data models that support the required data operations and relationships.

Impact on Coding

Functionality Implementation:

Requirements: Functional requirements specify what the system should do.

Code: Developers write code to implement these functionalities, ensuring that each requirement is met.

Quality Assurance:

Requirements: Non-functional requirements such as performance, security, and reliability set quality standards.

Code: Developers follow coding standards and best practices to meet these quality benchmarks.

Modularity and Maintainability:

Requirements: Requirements might specify modularity, reuse, and maintainability aspects.

Code: Developers write modular, reusable, and maintainable code to facilitate future enhancements and maintenance.

Testing:

Requirements: Requirements serve as the basis for creating test cases and acceptance criteria.

Code: Developers and testers use these criteria to write unit tests, integration tests, and perform user acceptance testing
(UAT).

Documentation:

Requirements: Detailed requirements necessitate thorough documentation.

Code: Developers document the code to ensure it aligns with the requirements and can be understood by other team
members.

5. How do requirements affect tests? (G6)

- Foundation for Testing: Requirements guide the creation of test cases ensuring the system meets user needs.
- Early Involvement: Including testers in requirements reviews ensures requirements are clear and testable.
- Agile and Acceptance Tests: In Agile, acceptance tests specify expected behavior, guiding development and
ensuring requirements are met.
- Verification Methods: Testing, inspection, demonstration, and analysis are used to verify requirements.
- Early Test Thinking: Identifying how to verify each requirement early helps catch ambiguities and improves
requirements.
- Requirements-Based Testing: Uses action-driven, data-driven, logic-driven, event-driven, and state-driven
strategies for comprehensive coverage.
- Testing at All Levels: Testing must occur at all levels, not just the user level, ensuring each module meets its
specifications.
SLOT 14

- PT2
- Review ERD and Class diagram

SLOT 15

Part III. Requirements for specific project classes

Chapter 20: Agile projects (G1)

1. What is an Agile Project? Give a Real-Life Example.

An Agile project uses iterative and incremental methodologies to manage and develop projects, focusing on collaboration,
customer feedback, and rapid delivery.

Real-Life Example: Mobile Banking App Development

● Initiation: Form a cross-functional team and identify high-level features (e.g., account management, bill payments).
● Backlog Creation: Create user stories (e.g., "As a user, I want to view my account balance.").
● Sprints: Break the project into 2-4 week sprints, each involving planning, development, testing, review, and
retrospective.
● Development: Develop prioritized features each sprint, continuously incorporating stakeholder feedback.
● Continuous Improvement: Regularly review and improve the process based on retrospectives.

2. How to Determine Requirements in Agile Projects?

1. User Stories: Capture requirements as user stories from the user's perspective.
 2. Product Backlog: Collect and prioritize user stories in a dynamic backlog.
3. Backlog Refinement: Regularly update and detail user stories.
4. Sprint Planning: Select and agree on user stories for each sprint with the team.
5. Stakeholder Involvement: Engage stakeholders for feedback and requirement validation.
6. Prototyping: Use prototypes and mockups to validate requirements early.
7. Acceptance Criteria: Define clear acceptance criteria for each user story.

Chapter21: Enhancement and replacement projects (G2)S

-What is Enhancement and replacement project?

An enhancement project is one in which new capabilities are added to an existing system. Enhancement projects might also
involve correcting defects, adding new reports, and modifying functionality to comply with revised business rules or needs.

A replacement (or reengineering) project replaces an existing application with a new custom-built system, a commercial off-
the-shelf (COTS) system, or a hybrid of those. Replacement projects are most commonly implemented to improve
performance, cut costs (such as maintenance costs or license fees), take advantage of modern technologies, or meet
regulatory requirements.

Replacement and enhancement projects face some particular requirements issues. The original developers who held all the
critical information in their heads might be long gone
-Expected challenges:

The changes made could degrade the performance to which users are accustomed.

Little or no requirements documentation might be available for the existing system.

Users who are familiar with how the system works today might not like the changes they are about to encounter.

You might unknowingly break or omit functionality that is vital to some stakeholder group.

Stakeholders might take this opportunity to request new functionality that seems like a good idea but isn’t really
needed to meet the business objectives

Mind the gap: A gap analysis is a comparison of functionality between an existing system and a desired new system. A gap
analysis can be expressed in different ways, including use cases, user stories, or features. Gap analysis for a replacement
project entails understanding existing functionality and discovering the desired new functionality
Maintaining performance levels: Existing systems set user expectations for performance and throughput. Stakeholders
almost always have key performance indicators (KPIs) for existing processes that they will want to maintainin the new
system. Unless you explicitly plan to maintain them, performance levels can be compromised as systems are enhanced. For
replacement systems, prioritize the KPIs that are most important to maintain. Look for thebusiness processes that trace to
the most important KPIs and the requirements that enable thosebusiness processes; these are the requirements to implement
first

When old requirements don’t exist: Most older systems do not have documented—let alone accurate—requirements. In
the absence of reliable documentation, teams might reverse-engineer an understanding of what the system does from the
user interfaces, code, and database.

How to discover the requirements of an existing system: In enhancement and replacement projects, even if you don’t
have existing documentation, you do have a system to work from to discover the relevant requirements. During
enhancement projects, consider drawing a dialog map for the new screens you have to add, showing the
navigationconnections to and from existing display elements.

Encouraging new system adoption: You’re bound to run into resistance when changing or replacing an existing system.
People arenaturally reluctant to change. Introducing a new feature that will make users’ jobs easier is a goodthing. But users
are accustomed to how the system works today, and you plan to modify that, whichis not so good from the user’s point of
view.
Chapter 22: Packaged solution projects (G3) G5

1. What is the X project? Give a real-life example.

The X project refers to a project involving the selection and implementation of Commercial Off-The-Shelf (COTS) software
solutions. These projects focus on purchasing, configuring, integrating, and potentially extending pre-existing software
products to meet an organization's needs rather than developing software from scratch.
Real-life example:

A law office needs a new software system to manage client records and case files. Instead of developing custom
software, they decide to purchase a COTS solution. The project involves identifying the key features and requirements
such as client information management, case tracking, and document management. The law office evaluates several
available software packages, comparing their features, costs, and suitability. They select the one that best meets their
needs and proceed with its implementation.

2. How to determine requirements in the X project?

1. Understand Business Activities:
○ Begin by thoroughly understanding the business activities that the software must support. This foundational
understanding helps in defining the high-level requirements necessary for evaluating potential software
solutions.
2. Identify High-Level Requirements:
○ Requirements should be identified at a high level initially, with detailed requirements defined based on the
package costs, evaluation timeline, and number of candidate solutions.
3. Use Cases and User Stories:
○ Focus on user requirements by utilizing use cases and user stories to describe how different users will
interact with the system. This approach helps in identifying the essential features and functionalities needed.
4. Process Models:
○ If available, use process models to map current business processes (as-is) and to design new processes
(to-be) that the COTS solution will support. This helps in understanding the workflow changes that the new
software will bring.
5. Identify Features:
○ Derive features from user needs and business processes. For example, an approval workflow feature might
be identified from a user story about a research manager needing to review and approve experiments.
6. Prioritize Requirements:
 ○ Prioritize user requirements or features and trace them back to business requirements. It’s important to
distinguish between capabilities needed immediately, those that can wait for future extensions, and those
that are optional.

Chapter 23: Outsourced projects (G4)

Q1. What is the Outsourced project? Give an real life example.

-Outsource project: Rather than building systems by using their own staff, many organizations outsource their
development efforts to contract development companies. They might outsource the work to take advantage of development
skills they do not have available in-house, to augment their internal staff resources, to save money, or to accelerate
development. The outsourced development supplier could be located physically nearby, on the other side of the world, or
anywhere in between. Outsourced teams in other countries are typically referred to as being offshore. Offshoring is
sometimes called nearshoring if the supplier’s country is close by or shares a language and/or culture with the acquirer’s
country

-An real life example:

Q2. How to determine requirements in the Outsorced project? (Các yêu cầu được xác định như thế nào trong dự án
X?)

1. High-Quality Written Requirements:

-Essential for outsourcing due to minimal direct interaction with the development team.

-Includes detailed requirements in the Request for Proposal (RFP), requirements specification, and product
acceptance criteria.

2. Early Engagement and Agreement:

-Both parties must review, negotiate, and agree on the requirements before development begins.

-Detailed and precise requirements are crucial to avoid misinterpretation and ensure the supplier builds exactly
what is requested.

3. Challenges of Minimal Interaction:

-Limited opportunities for daily clarifications and decision-making.

-Critical to document all requirements explicitly, including those that may seem obvious.

4. RFP Development:

-Requires detailed user and nonfunctional requirements for suppliers to provide accurate responses and
estimates.

-Outsourced projects necessitate more detailed requirements earlier compared to in-house projects.
 5. Importance of Visual Models and Prototypes:

-Visual models enhance communication and help clarify requirements.

-Prototypes allow both parties to verify interpretations and make adjustments early.

6. Clarity and Specificity:

-Avoid ambiguous terms that can lead to confusion.

-Use glossaries and structured notations (e.g., Planguage) to ensure explicit and clear requirements.

7. Compliance and Certification:

-Include specific deliverables required for process certification or compliance in the RFP.

Practical Implications:

● Over-specify requirements for outsourced projects to avoid gaps in understanding.

● Use visual and prototype models to supplement written specifications and enhance cross-cultural communication.
● Maintain clear and unambiguous language in all documentation, supported by glossaries and standardized notations.
Chapter 24: Business process automation projects (G5)==> G3

Business process automation (BPA) projects involve using technology to automate repetitive, everyday tasks to
streamline processes, reduce costs, and increase efficiency and accuracy. These projects focus on automating
workflows in departments such as HR, finance, and operations.

Real-Life Example: Automated Invoice Processing

Problem:

A mid-sized manufacturing company faces inefficiencies and errors in its manual invoice processing system, leading to late
payments, lost invoices, and strained vendor relationships.

BPA Project:

The company implements an automated invoice processing system to streamline its accounts payable process.

Steps Involved:

1. Document Scanning and OCR:

- Emails with invoices are imported automatically.

- Paper invoices are scanned and converted to digital using OCR, extracting relevant data.

2. Automated Data Entry:

- Extracted data is automatically entered into the accounting system.

3. Validation and Matching:

- The system matches invoices with purchase orders and delivery receipts.

- Discrepancies are flagged for manual review.

4. Approval Workflow:

- Valid invoices go through an automated approval workflow based on business rules.

- Approvers receive notifications and can approve/reject via web or mobile app.

5. Payment Processing:

- Approved invoices are scheduled for payment.

- The system integrates with the banking system for electronic payments.

6. Reporting and Analytics:

- Real-time reports on invoice status and payment cycles are generated.

- Analytics provide insights into spending patterns and process bottlenecks.

Benefits:

- Efficiency: Reduced manual effort and processing time.

- Accuracy: Lower error rates due to automated data handling.

- Cost Savings: Lower operational costs and fewer late payment fees.

- Visibility: Improved transparency and real-time tracking of invoices.

- Compliance: Enhanced compliance with policies and regulations through systematic processes.

Determining requirements in a Business Process Automation (BPA) project involves several systematic steps to
ensure that the project meets the needs of the organization and delivers the expected benefits. Here’s a structured
approach:

Steps to Determine Requirements in a BPA Project

1. Define Objectives and Scope

- Identify Goals: Understand the primary objectives of the BPA project, such as improving efficiency, reducing
costs, enhancing accuracy, or compliance.

- Scope Definition:Clearly define the scope of the project, including which processes will be automated and any
constraints.

2. Stakeholder Analysis

- Identify Stakeholders: Identify all stakeholders, including process owners, end-users, IT staff, and management.

- Stakeholder Needs Gather and document the needs, expectations, and pain points of each stakeholder group.

3. Process Mapping and Documentation

 - Current Process Analysis: Document the current state of the processes to be automated. Use tools like flowcharts,
process maps, and diagrams to visualize workflows.

- Process Bottlenecks: Identify inefficiencies, bottlenecks, and areas prone to errors in the current processes.

4. Requirement Gathering Techniques

- Interviews and Workshops: Conduct interviews and workshops with stakeholders to gather detailed
requirements.

- Surveys and Questionnaires: Use surveys and questionnaires to collect requirements from a broader audience.

- Observation: Observe the current processes in action to identify unspoken requirements and inefficiencies.

- Document Analysis: Review existing documentation, such as SOPs (Standard Operating Procedures), manuals,
and policy documents.

5. Define Functional and Non-Functional Requirements

- Functional Requirements: Specify what the system should do, including task automation, data handling, user
interactions, and integration with other systems.

- Non-Functional Requirements: Define performance metrics, security requirements, compliance needs, usability
standards, and other quality attributes.

6. Prioritize Requirements

- Categorize Requirements: Categorize requirements based on priority (e.g., must-have, should-have, could-have).

- Feasibility Analysis: Assess the feasibility and impact of implementing each requirement.
7. Gap Analysis

- Identify Gaps Compare current process capabilities with the desired automated process to identify gaps.

- Mitigation Plans: Develop plans to address any identified gaps.

8. Draft Requirement Specifications

- Requirement Document: Create a detailed requirement specification document that outlines all gathered
requirements.

- Validation: Review and validate the requirements with stakeholders to ensure accuracy and completeness.

9. Use Case Scenarios

- Develop Use Cases: Create use case scenarios to illustrate how the automated process will function.

- User Stories: Write user stories that describe the desired outcomes from the perspective of end-users.

10. Review and Approval

- Stakeholder Review: Share the requirement specifications and use cases with stakeholders for feedback.

- Approval:Obtain formal approval of the requirements document from key stakeholders and decision-makers.
Example Scenario: Automating Employee Onboarding

1. Define Objectives and Scope

- Objective: Reduce onboarding time and improve new hire experience.

- Scope: Automate tasks such as document collection, training schedule, and system access setup.

2. Stakeholder Analysis

- Stakeholders: HR team, IT department, new hires, department managers.

- Needs: HR wants reduced manual work, IT requires smooth integration, new hires need a seamless onboarding
experience.

3. Process Mapping and Documentation

- Document the current onboarding process, identify repetitive tasks, and note where delays occur.

4. Requirement Gathering Techniques

- Conduct interviews with HR and IT, survey new hires about their onboarding experience, and observe the
current onboarding sessions.
5. Define Functional and Non-Functional Requirements

- Functional: Automate sending welcome emails, collect necessary documents, assign training modules.

- Non-Functional: Ensure data security, system uptime, and user-friendly interfaces.

6. Prioritize Requirements

- Must-have: Automated email workflows, document upload portal.

- Should-have: Integrated training schedule.

- Could-have: Personalized welcome messages.

7. Gap Analysis

- Identify gaps in the current manual process and potential challenges in automation.

8. Draft Requirement Specifications

- Compile requirements into a document for review.

9. Use Case Scenarios

- Create scenarios such as "New hire receives welcome email" and "New hire completes document upload."

10. Review and Approval

 - Present the requirement document and use cases to HR and IT for feedback and appro

Chapter 25: Business analytics projects (G5)==>G6

Business Analytics Projects

Business analytics projects involve the use of data analysis and statistical methods to understand and improve business
performance. These projects typically aim to extract actionable insights from data to inform decision-making, enhance processes,
and achieve strategic objectives.

Real-Life Example: Customer Segmentation for a Retail Company

Project Overview:

A retail company wants to improve its marketing strategies by understanding its customers better. The goal is to segment customers
based on their purchasing behavior to tailor marketing efforts, improve customer satisfaction, and increase sales.

Steps Involved:

1. Define Objectives:
○ Improve targeted marketing campaigns.
○ Increase customer retention and satisfaction.
○ Boost sales by understanding customer needs.
2. Data Collection:
○ Gather data from various sources such as sales transactions, customer demographics, website interactions, and
social media.
3. Data Preparation:
○ Clean and preprocess the data to handle missing values, duplicates, and inconsistencies.
 ○ Transform data into a suitable format for analysis.
4. Exploratory Data Analysis (EDA):
○ Analyze the data to understand patterns and relationships.
○ Visualize key metrics like average purchase value, frequency of purchases, and customer demographics.
5. Segmentation:
○ Apply clustering algorithms (e.g., K-means clustering) to segment customers based on purchasing behavior.
○ Identify key segments such as high-value customers, frequent buyers, and occasional shoppers.
6. Analysis and Insights:
○ Analyze each segment to understand their characteristics and preferences.
○ Determine the most effective marketing strategies for each segment.
7. Implementation:
○ Develop targeted marketing campaigns for different segments.
○ Personalize offers and communications based on segment preferences.
8. Evaluation and Monitoring:
○ Monitor the performance of the marketing campaigns.
○ Adjust strategies based on feedback and performance metrics.

Determining Requirements in Business Analytics Projects

1. Stakeholder Interviews:
○ Conduct interviews with key stakeholders to understand their needs, goals, and challenges.
○ Identify the business problems that need to be addressed and the desired outcomes.
2. Define Business Objectives:
○ Clearly define the business objectives and how the analytics project will support them.
○ Ensure alignment with the organization’s strategic goals.
3. Gather Data Requirements:
○ Identify the types of data needed (e.g., sales data, customer data, operational data).
○ Determine data sources and assess data quality and availability.
4. Determine Analytical Techniques:
○ Decide on the analytical methods and tools that will be used (e.g., statistical analysis, machine learning, data
visualization).
○ Ensure the team has the necessary skills and resources to implement these techniques.
 5. Establish Success Metrics:
○ Define key performance indicators (KPIs) and metrics to measure the success of the project.
○ Determine how these metrics will be tracked and reported.
6. Develop a Project Plan:
○ Create a detailed project plan outlining tasks, timelines, and responsibilities.
○ Include milestones and checkpoints to monitor progress.
7. Data Security and Compliance:
○ Ensure that data privacy and security measures are in place.
○ Comply with relevant regulations and standards (e.g., GDPR, HIPAA).
8. Iterative Feedback:
○ Implement a process for continuous feedback and iteration.
○ Involve stakeholders throughout the project to ensure their requirements are met and make adjustments as needed.

Chapter 26: Embedded and other real-time systems projects (G)

Prepare presentation (Nội dung trình bày):

1. What is the X project? Give an real life example. (Dự án X (20-26) là gì? Cho ví dụ.)

2. How to determine requirements in the X project? (Các yêu cầu được xác định như thế nào trong dự án X?)
SLOT 16

CHAPTER 27: Requirements management practices

1. Requirements management process (G1)

Explain the FIGURE 27-1 Major requirements management activities.

2. Requirement attributes (G2)

List of potential requirement attributes

■ Date the requirement was created

■ Current version number of the requirement

■ Author who wrote the requirement

■ Priority

■ Status

■ Origin or source of the requirement

■ Rationale behind the requirement

■ Release number or iteration to which the requirement is allocated

■ Stakeholder to contact with questions or to make decisions about proposed changes

■ Validation method to be used or acceptance criteria

3. Tracking requirements status (G3)

Explain requirement status in the TABLE 27-1 Suggested requirement statuses

The table titled "Suggested Requirement Statuses" from "Software Requirements, Third Edition" outlines various statuses
that can be assigned to requirements during the software development lifecycle. Here’s a detailed explanation of each status:

1. Proposed:
○ Definition: The requirement has been requested by an authorized source.
○ Explanation: This is the initial status of a requirement when it is first suggested by a stakeholder or user.
2. In Progress:
○ Definition: A business analyst is actively working on crafting the requirement.
○ Explanation: The requirement is being developed and refined by the business analyst to ensure it is clear and
complete.
3. Drafted:
○ Definition: The initial version of the requirement has been written.
○ Explanation: The requirement has been documented in its initial form, but it may still require further review
and revisions.
4. Approved:
○ Definition: The requirement has been analyzed, its impact on the project has been estimated, and it has been
allocated to the baseline for a specific release. The key stakeholders have agreed to incorporate the
requirement, and the software development group has committed to implement it.
○ Explanation: The requirement has gone through necessary evaluations and approvals, and it is ready to be
implemented in the designated release.
5. Implemented:
 ○ Definition: The code that implements the requirement has been designed, written, and unit tested. The
requirement has been traced to the pertinent design and code elements. The software that implemented the
requirement is now ready for testing, review, or other verification.
○ Explanation: The requirement has been successfully coded and is prepared for further testing and validation
processes.
6. Verified:
○ Definition: The requirement has satisfied its acceptance criteria, meaning that the correct functioning of the
implemented requirement has been confirmed. The requirement has been traced to pertinent tests. It is now
considered complete.
○ Explanation: The requirement has passed all necessary tests and reviews, confirming that it meets the
specified criteria and is fully functional.
7. Deferred:
○ Definition: An approved requirement is now planned for implementation in a later release.
○ Explanation: The requirement has been approved but will not be implemented in the current release. It is
scheduled for a future release.
8. Deleted:
○ Definition: An approved requirement has been removed from the baseline. Include an explanation of why and
by whom the decision was made to delete it.
○ Explanation: The requirement was initially approved but has been removed from the project scope. The
reasons for this decision are documented.
9. Rejected:
○ Definition: The requirement was proposed but was never approved and is not planned for implementation in
any upcoming release. Include an explanation of why and by whom the decision was made to reject it.
○ Explanation: The requirement was reviewed but did not gain approval. The rationale for its rejection is
recorded.
These statuses help in tracking the progress and current state of requirements throughout the development process, ensuring
clear communication and proper management of requirements.

4. Resolving requirements issues (G4)

5. Common types of requirements issues (G5)

- What are common types of requirements issues?

(Explain the TABLE 27-2 Common types of requirements issues)

Common Types of Requirements Issues (Table 27-2)

1. Requirement Question: Uncertainty or lack of clarity about a requirement, leading to misunderstandings if

unresolved.
2. Missing Requirement: An overlooked requirement discovered later, causing incomplete functionality.
3. Incorrect Requirement: A wrong requirement that needs correction, leading to wasted effort if implemented.
4. Implementation Question: Questions during implementation about how something should work, delaying
development.
5. Duplicate Requirement: Equivalent requirements that need consolidation to avoid confusion and inefficiency.
6. Unneeded Requirement: A requirement that becomes unnecessary, wasting resources if worked on.
6. Measuring requirements effort (G6)

- How to measure requirement effort?

Measuring effort requires a culture change and the individual discipline to record daily work activities.

Team members gain valuable insight from knowing how they actually spent their time, compared to how they thought they
spent their time, compared to how they were supposed to spend their time.

Tracking the BA’s time will help you plan how much BA effort is needed on future projects (see Chapter 19, “Beyond
requirements development,” for more about estimating BA time). Measuring the total effort spent on requirements activities
by all stakeholders gives you a sense of the total cost of requirements activities on a project.

Record the number of hours spent on requirements development activities such as the

following:

■ Planning requirements-related activities for the project

■ Holding workshops and interviews, analyzing documents, and performing other elicitation

activities

■ Writing requirements specifications, creating analysis models, and prioritizing requirements

■ Creating and evaluating prototypes intended to assist with requirements development

■ Reviewing requirements and performing other validation activities

Count the effort devoted to the following activities as requirements management effort:

■ Configuring a requirements management tool for your project

■ Submitting requirements changes and proposing new requirements

■ Evaluating proposed changes, including performing impact analysis and making decisions

■ Updating the requirements repository

■ Communicating requirements changes to affected stakeholders

■ Tracking and reporting requirements status

■ Creating requirements trace information

7. Managing requirements on agile projects (self-study)

SLOT 17
- SRS presentation
SLOT 18

(Các nhóm chuẩn bị trước)

CHAPTER 28: Change happens

1. Why manage changes? (G4)

The world changes as development progresses: new market opportunities arise, regulations and policies change, and
business needs evolve. An effective software team can nimbly respond to necessary changes so that the product they
build provides timely customer value. An organization that’s serious about managing its software projects must
ensure that:

- Proposed requirements changes are thoughtfully evaluated before being committed to.

- Appropriate individuals make informed business decisions about requested changes.

- Change activity is made visible to affected stakeholders.

- Approved changes are communicated to all affected participants.

- The project incorporates requirements changes in a consistent and effective fashion.

But change always has a price.

 Problems can also arise if a developer implements a requirement change directly in the code

without communicating with other team members. The documented requirements then become an

inaccurate representation of what the product does. The code can become brittle if changes are made

without respecting the architecture and design structure

2. What are change control policies? (G4)

Management should communicate a policy that states its expectations of how project teams will handle
proposed changes in requirements and all other significant project artifacts. The following change control policy
statements can be helpful:

● All changes must follow the process. If a change request is not submitted in accordance with this process, it
will not be considered.
● No design or implementation work other than feasibility exploration will be performed on unapproved
changes.
● Simply requesting a change does not guarantee that it will be made. The project’s change control board
(CCB) will decide which changes to implement.
● The contents of the change database must be visible to all project stakeholders.
● Impact analysis must be performed for every change.
● Every incorporated change must be traceable to an approved change request.
● The rationale behind every approval or rejection of a change request must be recorded.

Of course, tiny changes will hardly affect the project, and big changes will have a significant impact.
 3. What is a change control process description? (G4)

Purpose and Scope:Describe the purpose of this process and the organizational scope to which it applies.

Roles and Responsibilities: List the project team roles that participate in the change control activities and describe
their responsibilities

Change Request States:A change request passes through a defined life cycle of states. You can represent these
states by using a state-transition diagram

Entry Criteria: The basic entry criterion for your change control process is that a change request with all the
 necessary information has been received through an approved channel

Tasks: This section details the specific activities involved in the change control process. It typically includes:

● Evaluate Change Request: Begin by evaluating the request for technical feasibility, cost, and alignment with the
project’s
● business requirements and resource constraints.
●
● Make Change Decision: The appropriate decision makers, chartered as the CCB, then decide whether to approve or
reject
● the change.
●
● Implement the Change:The assigned Modifier (or Modifiers) updates the affected work products as necessary to
fully implement the change.
● Verify the Change:Requirements changes typically are verified through a peer review to ensure that modified
deliverables correctly address all aspects of the change.
●

Exit Criteria: Satisfying the following exit criteria indicates that an execution of your change control process was
properly completed:

The status of the request is Rejected, Closed, or Canceled.

All modified work products are updated and stored in the correct locations.

The relevant stakeholders have been notified of the change details and the status of the
 change request

Change Control Status Reporting:Identify the charts and reports you’ll use to summarize the contents of the
change database. These charts might show the number of change requests in each state as a function of time, or trends in the
average time that a change request is unresolved

4. The change control board (G4)

- What is the change control board?

The Change Control Board (CCB) is a body responsible for deciding on proposed changes, new requirements, and reported
defects. It can be a single individual or a group and may have the authority to make decisions or just recommendations for
management. Establishing a CCB formalizes the group's composition and procedures.

Some view the CCB as bureaucratic, but it provides valuable structure for managing changes, even in small projects. Small
projects may have one or two people making decisions, while large projects or programs might have multiple CCB levels
for different types of decisions. In large programs, a program-level CCB handles issues affecting multiple projects or
significant changes, while individual project CCBs handle changes specific to their projects.

4o
 - Who are members of the CCB?

The CCB membership should represent all groups who need to participate in making decisions within the scope of that
CCB’s authority. Consider selecting representatives from the following areas:
● Project or program management
● Business analysis or product management
● Development
● Testing or quality assurance
● Marketing, the business for which the application is being built, or customer representatives
● Technical support or help desk

Only the subset of these people who need to make the decisions will be part of the CCB, although all stakeholders
must be informed of decisions that affect their work. The CCB for a project with both software and hardware components
might also include representatives from hardware engineering, systems engineering, and/or manufacturing. Keep the CCB
small so the group can respond promptly and efficiently to change requests. Make sure the CCB members understand and
accept their responsibilities. Invite other individuals to CCB meetings as necessary to ensure that the group has adequate
technical and business information.

5. Change control tools (G5)

What change control tool should we use?

 Many teams use commercial issue-tracking tools to collect, store, and manage requirements changes. While it
does not provide specific tool recommendations, it outlines features to look for in a change control tool:

● Define the attributes that constitute a change request.

● Implement a change request life cycle with multiple statuses.
● Enforce a state-transition model so that only authorized users can make specific status changes.
● Record the date of each status change and the identity of the person who made it.
● Provide customizable, automatic email notifications for new requests or status updates.
● Produce both standard and custom reports and charts.

Some commercial requirements management tools include built-in change-request systems that link proposed
changes to specific requirements, notifying responsible individuals when relevant changes are submitted.

6. Measuring change activity (G5)

- What aspects of requirements change activity should we track?

To assess the stability of the requirements and identify opportunities for process improvements, the following aspects
of requirements change activity should be tracked:

● The total number of change requests received, currently open, and closed.
● The cumulative number of added, deleted, and modified requirements.
● The number of requests originating from each change origin.
● The number of changes received against each requirement since it was baselined.
● The total effort devoted to processing and implementing change requests
7. Change impact analysis (G5)

- What is the impact analysis procedure?

The impact analysis procedure involves three main steps:

1. Understand the possible implications of making the change: A requirement change can produce a ripple
effect, leading to modifications in other requirements, architectures, designs, code, and tests. Changes can also
lead to conflicts with other requirements or compromise quality attributes like performance or security.
2. Identify all the requirements, files, models, and documents that might need modification if the requested
change is incorporated.
3. Estimate the effort required for the anticipated tasks: Use a worksheet to estimate the effort for each task,
sum the effort estimates, identify the sequence and interleaving of tasks with currently planned ones, estimate
the impact on the project’s schedule and cost, evaluate the change’s priority compared to other pending
requirements, and report the impact analysis results to the Change Control Board (CCB)

- What is an impact analysis template?

An impact analysis template is a structured format used to document the potential consequences of a proposed
change in requirements. It helps in understanding the scope, effort, and implications of making the change. Here is an
example template you could use:
8. How to change management on agile projects? (self -study)
CHAPTER 29: Links in the requirements chain

1. Tracing requirements (G6)

- Why do we need tracing requirements?

Ensuring Completeness and Coverage:

● Forward Traceability: By linking individual functional and nonfunctional requirements to specific system
elements, you can ensure that every requirement is addressed. This helps verify that the design and
implementation cover all specified needs.
● Backward Traceability: Tracing product elements back to their corresponding requirements ensures that
each element serves a purpose and is not superfluous. This helps avoid "orphan code," which may not be
necessary.

Facilitating Verification and Validation:

● Testing: Tests derived from and traced back to individual requirements provide a mechanism for verifying
that all requirements are implemented correctly. If a test fails or a functionality is missing, it indicates
unimplemented or incorrectly implemented requirements.

Managing Changes and Dependencies:

● Impact Analysis: Traceability helps identify the impact of changes in requirements on the rest of the system.
Understanding dependencies between requirements and system elements aids in assessing how modifications
can affect the overall project.

Supporting Accountability and Compliance:

 ● Regulatory and Standards Compliance: Many industries require stringent documentation and traceability to
meet regulatory standards. Trace links help demonstrate that all necessary requirements have been fulfilled
and documented appropriately.

Improving Communication and Understanding:

● Stakeholder Clarity: Traceability provides a clear, unambiguous link between requirements and system
components, aiding communication among stakeholders, including developers, testers, and business analysts.
It helps ensure everyone has a shared understanding of what the system is supposed to do and why.

Enhancing Maintenance and Evolution:

● Future Modifications: When maintaining or evolving a system, trace links provide valuable insight into why
certain elements were created and how they interrelate. This knowledge is crucial for making informed
decisions about future changes and for avoiding unintended consequences.

Detecting and Handling Deviations:

● Unexpected Functionality: If testers encounter unexpected functionality, trace links can help determine
whether this functionality corresponds to a legitimate requirement or is unnecessary "gold-plating." This helps
maintain the integrity and relevance of the system's features.

- What are types of requirements tracing? (Figure 29-1)

 + Forward to requirements
+ Forward from requirements
+ backward to requirements
+ backward fromrequirements

- Give some examples of requirements trace links. (Explain the figure 29-2)
Business requirement:

● Drives the specification of the System requirement, User requirement, Feature, External interface
requirement, Quality attribute.
● Is influenced by Business rule.

System requirement, User requirement, Feature, External interface requirement, Quality attribute:

● Originates from or constrains the Functional requirement.

● Modified by Change request.

Change request:

● Modifies the System requirement, User requirement, Feature, External interface requirement, Quality
attribute.
● Modifies the Functional requirement.
● Modifies the Architecture, User interface, Software design.

Business rule:

● Is the origin of the System requirement, User requirement, Feature, External interface requirement,
Quality attribute.

Functional requirement:

● Originates from or is constrained by the System requirement, User requirement, Feature, External
interface requirement, Quality attribute.
● Depends on another Functional requirement.
● Satisfied by the Architecture, User interface, Software design.
 ● Verified by the System test, Acceptance test.
● Modified by Change request.

Architecture, User interface, Software design:

● Is verified by the Integration test.

● Implemented in Code.
● Modified by Change request.

System test, Acceptance test:

● Verifies the Functional requirement.

Integration test:

● Verifies the Architecture, User interface, Software design.

Code:

● Is implemented in Architecture, User interface, Software design.

● Verified by the Unit test.

Unit test:

● Verifies the Code.

2. What are motivations for tracing requirements? (G6)

Tracing requirements is essential in software development and engineering to ensure consistency, completeness, and
alignment with stakeholder needs. It facilitates change management, verification, validation, impact analysis, and
compliance with standards. By providing a clear audit trail and enhancing communication, tracing requirements improves
project transparency, supports documentation, and aids in project planning and estimation. Ultimately, it ensures that the
final product meets its intended objectives and satisfies customer requirements effectively.

(List and short explain)

3. The requirements traceability matrix (G1)

- Explain the tables 29-1, 29-2, 29-3 and the figure 29-3

table 29-1

This table is a requirements traceability matrix (RTM), which maps and traces user requirements with the corresponding
functional requirements, design elements, code elements, and tests. Here's a breakdown of each column:

1. User requirement: This column lists the specific user requirements, denoted as UC-28 and UC-29.
2. Functional requirement: This column specifies the functional requirements associated with each user requirement.
For example, UC-28 has the functional requirement catalog.query.sort.
3. Design element: This column identifies the design elements related to the functional requirements. Both user
requirements (UC-28 and UC-29) refer to the "Class catalog" design element.
 4. Code element: This column indicates the specific code elements or functions that implement the functional
requirements. For UC-28, the code element is CatalogSort(). For UC-29, the code elements are
CatalogImport() and CatalogValidate().
5. Test: This column lists the tests that verify the implementation of the functional requirements. For UC-28, the tests
are search.7 and search.8. For UC-29, the tests are search.12, search.13, and search.14.

table 29-2

This table is another type of requirements traceability matrix (RTM), showing the links between use cases and functional
requirements. Here's a breakdown of the columns and rows:

1. Functional requirement: This column lists the functional requirements, denoted as FR-1 through FR-6.
2. Use case: The columns labeled UC-1 through UC-4 represent different use cases.
The table cells indicate the presence of a relationship between a specific functional requirement and a use case. The arrows
or checkmarks in the cells denote that the corresponding use case addresses or includes the given functional requirement.

● FR-1 is linked to UC-1.

● FR-2 is linked to UC-1 and UC-2.
● FR-3 is linked to UC-3.
● FR-4 is linked to UC-3.
● FR-5 is linked to UC-2 and UC-4.
● FR-6 is linked to UC-4.

In summary, this RTM ensures that all functional requirements are covered by the specified use cases, indicating which use
cases are responsible for fulfilling which functional requirements. This helps in verifying that all requirements are
considered during the development and testing phases.

Table 29-3

identifies some typical sources of knowledge about links between various types of source and target

objects. objects. Determine the roles and individuals who should provide each type of trace information for

your project. Expect some pushback from busy people whom the analyst or project manager asks to provide this data. Those
practitioners are entitled to an explanation of requirements tracing,

why it provides value, and why they’re being asked to contribute to the process. Point out that the

incremental cost of capturing trace information at the time the work is done is small; it's mainly a
matter of habit, discipline, and having the storage mechanism established
4. What is the requirement tracing procedure? (G1)

The requirement tracing procedure involves a series of steps to ensure that all requirements in a project are
documented and linked properly, facilitating traceability from inception to implementation. Below is a detailed
breakdown of the procedure based on the provided information:

1. Educate the Team and Management:

○ Explain the concepts and importance of requirements tracing.
○ Define objectives for the activity.
○ Describe where the trace data is stored.
○ Explain techniques for defining the links.
○ Ensure all participants understand their responsibilities and commit to them.
2. Select Link Relationships:
○ Choose which link relationships to define (as illustrated in a reference figure, such as Figure 29-2).
○ Avoid trying to implement all possible links at once to prevent being overwhelmed.
3. Choose a Traceability Matrix Type:
○ Decide between a single-matrix style (like in Table 29-1) or multiple matrices (like in Table 29-2).
○ Select a data storage mechanism: table in a text document, spreadsheet, or a dedicated requirements
management tool (preferred).
4. Identify Critical Product Parts:
○ Focus on maintaining traceability information for critical core functions, high-risk portions, or sections
expected to undergo significant maintenance and evolution.
5. Assign Responsibilities:
○ Determine who will supply each type of link information.
○ Appoint a coordinator (likely a Business Analyst) to manage the tracing activities and data.
6. Modify Development Procedures:
 ○ Ensure developers are reminded to update links after implementing a requirement or an approved
change.
○ Update trace data soon after completing a task that creates or changes a link.
7. Define Labeling Conventions:
○ Establish unique identifiers for each system element to facilitate linking.
○ Refer to Chapter 10 for ways to label requirements.
8. Ongoing Data Collection:
○ Encourage participants to provide trace information as they complete small bodies of work.
○ Highlight the benefits of accumulating trace data continuously rather than at major milestones or
project end.
9. Periodic Audits:
○ Regularly audit the trace information to ensure it remains current.
○ Address discrepancies where implemented and verified requirements have incomplete or inaccurate
trace data.

Special Considerations for Existing Systems:

● If maintaining an existing system without trace data, begin collecting it during enhancements or
modifications.
● Document connections between code, tests, designs, and requirements during these changes.
● Although reconstructing a complete traceability matrix may not be possible, incremental efforts will simplify
future maintenance tasks.
CHAPTER 30: Tools for requirements engineering (self-study)

Top 20+ Best Requirements Management Tools (The Complete List) (softwaretestinghelp.com)

CHAPTER 31: Improving your requirements processes (G2)

1. How do requirements relate to other project processes?

- Explain the figure 31-1

2. How do requirements-related contributions from various stakeholders to the software development team?

- Explain the figure 31-2

3. Gaining commitment to change

- What are signs that your organization’s management is truly committed to excellent requirements processes?

4. What are the fundamentals of software process improvement?

5. What is root cause analysis?

- Definition

- What is the name of the diagram that is a useful way to depict the results of a root cause analysis?

6. What is the software process improvement cycle?

- Explain the figure 31-5

CHAPTER 32: Software requirements and risk management (G3)

1. What is the risk?

Risk in the context of software development refers to the potential for a negative outcome that can affect the project's
success. It encompasses the likelihood of an event occurring and the potential impact of that event on the project's
objectives.

2. Fundamentals of software risk management

a. What are the elements of risk management?

Risk Identification: Determining what risks might affect the project.

Risk Analysis: Understanding the nature of the risk and its potential impact.

Risk Prioritization: Ranking risks based on their significance.

Risk Response Planning: Developing options and actions to enhance opportunities and reduce threats.

Risk Monitoring and Control: Tracking identified risks, monitoring residual risks, and identifying new
risks.

b. What are elements in the template for documenting an individual risk statement?
 Risk Description: A clear statement of the risk.

Risk Impact: The potential effect on the project if the risk materializes.

Risk Probability: The likelihood that the risk will occur.

Risk Mitigation: Actions to reduce the probability or impact of the risk.

Risk Contingency: Actions to take if the risk occurs.

Risk Owner: The person responsible for managing the risk.

c. How to plan for risk management?

Define a Risk Management Plan: Outline the approach, resources, and activities for managing risk.

Assign Risk Ownership: Identify who is responsible for each risk.

Integrate Risk Management into Project Activities: Ensure risk management is part of the project lifecycle.

Develop Risk Mitigation Strategies: Plan actions to reduce the impact and probability of risks.

Establish Risk Monitoring Procedures: Set up methods to track and report on risks.

3. Requirements-related risks

a. How are the risk factors organized?

Requirements-related risks are typically organized into categories based on their nature and origin. These categories can
include:

1. Ambiguity Risks: Unclear or incomplete requirements.

2. Volatility Risks: Changing requirements over time.
3. Feasibility Risks: Technically challenging requirements.
4. Stakeholder Risks: Misalignment or lack of stakeholder engagement.
5. Validation Risks: Difficulties in verifying requirements.

b. Each group explains one.

Ambiguity Risks: Ambiguity risks arise when requirements are not clearly defined or are open to multiple
interpretations. This can lead to misunderstandings among stakeholders and developers, resulting in incorrect
implementations or missed functionality. Mitigating ambiguity risks involves ensuring that requirements are
clearly documented, reviewed, and understood by all stakeholders.

SLOT 19

- SRS presentation (cont)

SLOT 20
- PT3
- PE review