📚 Software Requirements Engineering

SE311 - Chapter 1: Fundamentals

🎯 What is Requirements Engineering?

Requirements Engineering (RE): The activity of development, elicitation, specification, analysis, and management of the stakeholder requirements, which are to be met by a new or evolving system.

RE is concerned with identifying the purpose of a software system and the contexts in which it will be used. A software system is assessed in terms of the extent to which it satisfies the purpose for which it was intended.

💡 Ten Truths About Requirements

Truth #1: If you don't get the requirements right, it doesn't matter how well you execute the rest of the project.
Truth #2: Requirements development is a discovery and invention process, not just a collection process.
Truth #3: Change happens.
Truth #4: The interests of all the project stakeholders intersect in the requirements process.
Truth #5: Customer involvement is the most critical contributor to software quality.
Truth #6: The customer is not always right, but the customer always has a point.
Truth #7: The first question an analyst should ask about a proposed new requirement is, "Is this requirement in scope?"
Truth #8: Even the best requirements document cannot - and should not - replace human dialogue.
Truth #9: The requirements might be vague, but the product will be specific.
Truth #10: You're never going to have perfect requirements.

📊 Project Success & Failure Factors

Top 10 Project Success Factors

  1. User involvement
  2. Executive management support
  3. Clear statement of requirements
  4. Proper planning
  5. Realistic expectations
  6. Smaller project milestones
  7. Competent staff
  8. Ownership
  9. Clear vision and objectives
  10. Hard-working, focused staff

Top 10 Challenged Project Factors

  1. Lack of user involvement
  2. Incomplete requirements and specifications
  3. Changing requirements and specifications
  4. Lack of executive support
  5. Technology incompetence
  6. Lack of resources
  7. Unrealistic expectations
  8. Unclear objectives
  9. Unrealistic timeframe
  10. New technology

📋 Types of Requirements

Requirement: A statement which translates or expresses a need and its associated constraints and conditions.

Business Requirements

Why implement this system?

Example: "Airline wants to reduce airport counter staff costs by 25 percent."

User Requirements

Describes goals/tasks the user must be able to do with the product.

Example: "User needs to be able to check-in for flight using airline's website."

Functional Requirements

Specify the behaviors the product will exhibit under specific conditions.

Example: "If the passenger's profile does not indicate a seating preference, the reservation system shall assign a seat."

System Requirements

Requirements for a product composed of multiple components or subsystems.

Example: "The airport check-in kiosks need a barcode reader to scan a passport."

Non-Functional Requirements

Describe how well the product carries out its tasks. Includes:

Quality Attributes

Product characteristics (performance, safety, availability, compatibility)

Example: "Flight search results should load within 5 seconds."
External Interfaces

Connections between system and outside world

Example: "A link to Tawakkalna database to verify COVID-19 status."
Constraints

Restrictions on developer options during construction

Example: "System shall conform to MIL-STD-498."

Application-Domain Requirements

  • Derived from the application domain
  • Describe system characteristics and features that reflect the domain
  • May be new functional requirements, constraints on existing requirements, or define specific computations
  • If domain requirements are not satisfied, the system may be unworkable

Domain Requirement Example

"A patient's designated physician is the only entity allowed to retrieve a patient's medical reports."

🔄 Requirements Engineering Process

Inception
→
Elicitation
→
Analysis
→
Specification
→
Validation


Management (Throughout)

Process Activities

Activity Description
Inception Start the process (business need, market opportunity, great idea), business case, feasibility study, system scope, risks, etc.
Elicitation Requirements discovered through consultation with stakeholders
Analysis & Negotiation Requirements are analyzed and conflicts resolved through negotiation
Specification A precise requirements document is produced
Validation The requirements document is checked for consistency and completeness
Management Needs and contexts evolve, and so do requirements

⚠️ General Problems with Requirements Process

  • Lack of the right expertise - Requirements engineers often lack domain expertise
  • Initial ideas are often incomplete - Stakeholders may not know exactly what they want
  • Difficulty of using complex tools - Complex methods associated with requirements gathering may negate anticipated benefits

📝 Past Exam Questions & Practice

Question 1 (Quiz 2)

Q: To properly manage the requirements, you need to maintain the accuracy and integrity of the collected requirements. How do the following terminologies affect the requirement management and how they can help in properly managing the requirements:

  • Baselines: A baseline is a non-modifiable version of requirements that has been formally reviewed and agreed upon. It serves as a reference point for managing changes and helps maintain requirement integrity by preventing unauthorized modifications.
  • Requirement synchronicity: Ensures all requirements documents and artifacts remain consistent with each other. When one requirement changes, related requirements must be updated to maintain synchronicity across the project.
  • Tracking requirements status: Each requirement should have a status (proposed, approved, implemented, verified, deleted). This helps monitor progress and identify which requirements need attention.

Question 2 (Midterm Sample)

Q: Which one of the following is not a step of requirement engineering?

Options:

  1. Elicitation
  2. Design ✓ (Correct Answer)
  3. Analysis
  4. Documentation

Explanation: Design is part of the software development process, not requirements engineering. RE focuses on understanding and documenting what needs to be built, while design focuses on how to build it.

Question 3 (Midterm Sample)

Q: A stakeholder is anyone who will purchase the completed software system under development.

Answer: False ✓

Explanation: A stakeholder is anyone who has an interest in or is affected by the project, not just purchasers. This includes users, developers, managers, domain experts, testers, and many others.

Question 4 (Midterm Sample)

Q: Which of the following is not defined in a good Software Requirement Specification (SRS) document?

  1. Functional Requirement
  2. Nonfunctional Requirement
  3. Goals of implementation
  4. Algorithm for software implementation ✓ (Correct Answer)

Explanation: SRS focuses on WHAT the system should do, not HOW it should be implemented. Algorithms are design/implementation details, not requirements.

Question 5 (Major-1 Exam)

Q: Collecting quality requirements is considered problematic, discuss what problems we may face as RE when collecting and specifying such requirements.

Sample Answer:

  • As requirements engineers, we lack the right expertise for many professions
  • Not many experienced software engineers or domain experts are always available
  • Extracting requirements from stakeholders can be problematic as stakeholders are not always available
  • Many stakeholders may view our presence as a threat to their job and thus will not always cooperate
  • Many important areas in requirements can be difficult to specify as clearly as possible

🎓 Key Takeaways

  • Requirements engineering is critical - errors in requirements account for 40-50% of all defects in software products
  • User involvement is the #1 success factor for projects
  • Understand the different types of requirements: Business, User, Functional, System, and Non-functional
  • RE is a process involving: Inception → Elicitation → Analysis → Specification → Validation, with Management throughout
  • Non-functional requirements are just as important as functional requirements - if not met, the system is useless
  • Stakeholders include anyone affected by or interested in the project, not just customers
  • Change is inevitable in requirements - plan for it
  • Requirements development is about discovery and invention, not just collection