Lecture 11

Requirement

Instructor: Nadeem Zaidkilani

[email protected]
 Requirements Engineering

• .
Requirements Engineering is the process of defining and managing what a software system should do. It involves:
1. Identifying Needs: Figuring out what stakeholders want from the software.
2. Creating Requirements: Writing clear and detailed descriptions of what the software needs to do.
3. Checking Requirements: Making sure the requirements are correct, complete, and achievable.

Tasks Involved:
• Understanding: Learning about the needs and constraints of everyone involved.
• Recording: Writing down requirements in an organized way.
• Managing: Handling any changes to the requirements as the project progresses
 Problems with Our Requirements Practices

•Understanding: We often don’t fully grasp what customers need.

Example: Misinterpreting a request for a feature, leading to an incomplete solution.

•Disorganization: Requirements are recorded in a messy or unclear way.

Example: Notes from meetings are scattered, making it hard to track what’s needed.

•Verification: We don’t spend enough time checking if requirements are correct.

Example: Not testing requirements thoroughly, leading to missed errors.

•Change Management: We let changes dictate the project without a system to manage them.
Example: Continuously changing project scope without a clear plan, causing delays.

•Foundation: We fail to build a strong base for what the user wants.
Example: Starting development without a clear and agreed-upon project plan.

•Rushing: Developers start coding before fully understanding the needs.

•Example: Jumping into development based on assumptions rather than a complete requirements list.

•Clarity Assumption: Belief that issues will become clear during development.
Example: Expecting that ambiguous requirements will sort themselves out as the project progresses.

•Perceived Waste: Some think requirements engineering is unnecessary due to rapid changes.
Example: Skipping detailed planning because it’s assumed the requirements will change frequently.
 The Impact of Requirements Engineering on Project Success

1. Errors in Requirements Engineering

• According to Boehm (1981), 60% of system development errors originate from the requirements phase,
often discovered only later in the process.
2. Cost of Fixing Errors
• Boehm (1981) highlights that fixing defects later in the development process is significantly more costly: up
to 20 times more during programming and up to 100 times more during acceptance testing compared to
addressing them during requirements engineering.
3. Symptoms and Causes
• Issues such as missing or unclear requirements often arise due to assumptions and poor communication
among stakeholders, as noted by Boehm (1981).
4. Importance
• Effective requirements engineering is essential for successful, timely, and cost-effective system
development. Early detection and resolution of issues are critical for project success.
Reference:
• Boehm, B. W. (1981). Software Engineering Economics.
 Definition of a Requirement:

• A requirement is a necessary feature or condition that a user needs to achieve a goal, or a specific criterion
that a system must meet to adhere to a contract or technical standard. It is clearly documented to represent
these needs and criteria.
• Requirements engineering is the process of determining and defining the services a system should offer,
involving:
• Feasibility Study: Assessing the system's potential value to the business.
• Elicitation and Analysis: Identifying and analyzing the needs.
• Specification: Documenting these needs in a standardized format.
• Validation: Confirming that the documented requirements meet the customer’s needs.
• Requirements management involves the continuous oversight of these requirements throughout the project
to ensure they are tracked, controlled, and effectively communicated.

This process is iterative, with ongoing cycles of elicitation, specification, and validation for both user and system
requirements.
 Failed Projects: How Poor Requirements Led to Catastrophic Outcomes

1. Air France Flight 447 (2009)

• Poor requirements for handling ice and sensor issues caused a crash that killed 228 people, showing
flaws in system design.
2. Denver Airport Baggage System (1995)
• Confusing and changing requirements led to a failed baggage system, costing $560 million and delaying
the airport's opening.
3. Heathrow Terminal 5 Baggage System (2008)
• Badly defined requirements caused chaos on the system's first day, with thousands of bags lost and many
flights canceled.
4. FBI Virtual Case File (VCF) System (2000s)
• Unclear requirements made the system unusable, wasting $170 million and forcing the FBI to start from
scratch.
5. NHS IT Project (2002-2011)
• Changing and unclear requirements led to a £10 billion healthcare project being canceled, with no
benefits realized.
 Requirements Type

1. Functional Requirements: Specify the particular functions and behaviors the system must achieve.

•For example, "The system shall allow users to log in using their email and password.“

2. Quality Requirements (Non-Functional Requirements): Describe the desired characteristics of the system,
such as performance, reliability, and scalability, which influence its architecture.

•For example, "The system shall process 1,000 transactions per minute" (performance) or
"The system shall be available 99.9% of the time" (reliability).

3. Constraints: Set limitations on the system or development process that the development team cannot change

•. For example, "The system must be compatible with Internet Explorer 11" or
The system must be delivered by the end of Q2 2024."
 Non-functional requirements (NFRs)
Non-functional requirements (NFRs) describe how a system should perform rather than what it should do. They
cover various aspects of system quality and performance. Here is a list of common non-functional requirements:

1. Performance: Specifies how fast the system should operate, including response time and throughput.
Example: "The system should respond to user queries within 2 seconds.“

2. Reliability: Describes the system's ability to operate without failure and recover from errors.
Example: "The system should have an uptime of 99.9%.“

3. Availability: Defines the system's readiness for use and the percentage of time it is operational.
Example: "The system should be available 24/7.“

4. Scalability: Indicates the system's capacity to handle increased load or expand to accommodate growth.
Example: "The system should handle up to 10,000 concurrent users.“

5. Maintainability: Describes how easy it is to update, modify, or fix the system.

Example: "The system should allow updates without downtime.“

6. Usability: Refers to how user-friendly and intuitive the system is for end-users.
Example: "The system should have an intuitive interface that requires less than 1 hour of training for new
users.“
7. Security: Specifies the measures to protect the system from unauthorized access and data breaches.
Example: "The system should use encryption for all sensitive data transmissions.“

8. Portability: Describes how easily the system can be transferred to different environments or platforms.
Example: "The system should be operable on both Windows and macOS.“

9. Compliance: Ensures that the system meets specific regulatory or standards requirements.
Example: "The system must comply with GDPR regulations.“

10. Compatibility: Specifies how well the system integrates or works with other systems or software.
Example: "The system should be compatible with existing CRM software.“

11. Accessibility: Refers to how easily users with disabilities can access the system.
Example: "The system should adhere to WCAG 2.1 guidelines for accessibility.“

12. Efficiency: Relates to how well the system uses resources such as memory and processing power.
Example: "The system should not use more than 50% of CPU resources under normal load."
Thank you for your attention.