software engineering lecture 4

What is a software requirement according to IEEE Standard?

A condition or capacity needed by a user to solve a problem or achieve an objective. A condition or capability that must be met by a system to satisfy a contract, standard, specification, or other formally imposed document.

What is Requirements Engineering?

A systematic process of developing requirements through an iterative way of discovering, documenting, and managing a set of requirements for a software system, including the constraints under which it operates.

What are the 2 main objectives of Requirements Engineering?

1. To decide precisely what to build and document the results, 2. To produce a set of requirements that is complete, consistent, relevant, and reflects what the customer actually wants.

Why is Requirements Engineering extremely important? (3 reasons)

1. Comprehension: People don't know what they want, 2. Communication: Requirements are difficult to communicate informally, 3. Protection: Changes can lead project over budget.

What percentage of software defects come from poor requirements?

40-60% of all defects come from failure to develop and document good requirements specifications.

What are Functional Requirements (FR)?

What the software product shall do. A system requirement that specifies a function that a system must be capable of performing. Defines the behavior of the system.

Give 3 examples of Functional Requirements from Quick Cup app

1. Browse coffee menu and view drink prices, 2. Add, customize, and remove drinks from cart, 3. Place order and receive confirmation number, 4. Barista view to see and update orders (any 3).

What are Non-Functional Requirements (NFR)?

Qualities the product needs to have. Describes not what the software will do, but HOW the software will do it. Qualities and constraints on how functional requirements are implemented.

Give 3 examples of Non-Functional Requirements from Quick Cup app

1. Usability: Order within 3 clicks, 2. Performance: Load in less than 2 seconds, 3. Reliability: Must not lose/duplicate orders, 4. Security: Protect sensitive data, 5. Scalability: Handle increasing users (any 3).

What are constraints in Non-Functional Requirements?

Define the non-functional aspects such as restrictions on technology, resources, or techniques to be used (e.g., software needs to run on Windows, Linux, and iOS).

Why are Non-Functional Requirements difficult?

They are difficult to quantify and state precisely. Imprecise requirements are difficult to verify.

What is a Goal vs Verifiable NFR?

Goal: General intention (e.g., "system should be easy to use"). Verifiable NFR: Statement using some measure that can be objectively tested (e.g., "Medical staff shall use all functions after 4 hours training").

Give the verifiable NFR example for medical system ease of use

"Medical staff shall be able to use all system functions after four hours of training. After training, average errors by experienced users shall not exceed two per hour of system use."

How can Speed NFR be measured?

Processed Transactions/Second, Response Time, Screen refresh time.

How can Ease of Use NFR be measured?

Training Time, Duration to perform a task, Steps/Clicks/Mouse Distance.

How can Reliability NFR be measured?

Mean time to failure, Rate of failure occurrence, Availability.

How can Portability NFR be measured?

Number of target systems, Percentage of target dependent statements, Ability to migrate system to another platform.

How can Size NFR be measured?

Megabytes.

How can Scaling NFR be measured?

Speed when increasing data, Speed when 1000+ users access at the same time.

How can Robustness NFR be measured?

Time to restart after failure.

What is the difference between System Requirements and Software Requirements?

System requirements = for the system as a whole (includes software + hardware requirements). Software requirements = for the software components only.

For Information Systems, what type of requirements engineering is primarily done?

Primarily software requirements engineering.

For Embedded Systems, what type of requirements engineering is done?

Both hardware and software requirements engineering.

What are Abstract Requirements vs Detailed Requirements?

Abstract: Sufficiently general that a solution is not predefined (used in contracts for bidding). Detailed: More specific system definition for client to understand and validate what software will do (after contract awarded).

What are the 4 activities in the Requirements Engineering Process?

1. Requirements Elicitation, 2. Requirements Analysis, 3. Requirements Documentation, 4. Validation.

What questions need to be addressed when engineering the RE process?

The structuring/schedule of activities, Who is responsible for each activity, Inputs and outputs to/from activity, Tools used to support the process, Output of the process.

What is Requirements Elicitation?

The process of discovering, gathering, and understanding the requirements from the stakeholders and other relevant sources.

Who is a stakeholder?

Any entity that has a vested interest in the system to be built.

What are the 2 types of stakeholders?

1. Internal: Project Manager, Team members (developers, testers), 2. External: Customer, end-user, supplier, government.

What is the objective of Requirements Elicitation?

Discover and understand the needs, expectations, and constraints of all stakeholders.

What are the 5 sources of requirements in Requirements Elicitation?

1. Goals and Problems, 2. Domain Knowledge, 3. Stakeholders, 4. Organizational Environment, 5. Operational Environment.

What should you NOT do when eliciting requirements?

Go to the end-user/customer and just ask questions in an improvised way. This wastes time and appears unprofessional.

What is required for a proper Requirements Elicitation process?

Have knowledge about: application domain, organizational/business process, problem. Choose an elicitation technique and prepare. Get as much information as possible about needs and constraints.

What are 4 techniques for gathering requirements?

1. Interviews (structured/unstructured), 2. Scenarios and Use Cases, 3. Prototyping, 4. Observation (Ethnography), 5. JAD, 6. Questionnaires/Surveys, 7. Document Analysis (any 4).

What is Ethnography in requirements gathering?

Observation technique where you observe users in their real work environment to uncover hidden needs.

What is JAD (Joint Application Development)?

Collaborative workshops involving users and developers to gather requirements together.

When are Questionnaires and Surveys useful?

When dealing with large or distributed user groups.

What is Problem 1 in Requirements Elicitation?

Stakeholders don't know what they want. Example: "We need a user-friendly interface" but can't specify what makes it user-friendly. Often realize what they wanted after seeing what they don't want.

What is Problem 2 in Requirements Elicitation?

Stakeholders express requirements in their own terms. Example: Doctor says "fast" (means <2 sec response), Business says "fast" (means processed by end of day). Terminology mismatch leads to wrong implementation.

What is Problem 3 in Requirements Elicitation?

Different stakeholders have conflicting requirements. Example: Marketing wants "easy signup, minimal fields" vs Security wants "comprehensive verification, multiple authentication steps."

What is Problem 4 in Requirements Elicitation?

Stakeholders unconvinced of need for new system. Example: "Our Excel spreadsheets work fine, why do we need a database?" Resistance leads to incomplete requirements gathering.

What is Problem 5 in Requirements Elicitation?

Stakeholders give unnecessary information. Example: "The button should be blue because my daughter likes blue" - mixing personal preferences with business requirements.

What is Problem 6 in Requirements Elicitation?

Organizational and political factors. Example: Department head insists on features that protect their budget. Hidden agenda: "This system must require 3 approval levels" to maintain control.

What is Problem 7 in Requirements Elicitation?

Requirements change during analysis. Example: New competitor launches feature mid-project, or regulation changes (GDPR, accessibility laws) force requirement updates.

What is the biggest problem in Requirements Elicitation?

Implicitness and Assumptions - Stakeholders assume certain requirements are common sense and don't mention them. Developers make assumptions about how end-users think and their needs.

Give an example of Stakeholder Assumption problem

Client says "Of course the system will save data automatically" assuming it's obvious, but never explicitly states it. Developers implement manual saving only.

Give an example of Developer Assumption problem

Developers assume all users have constant internet access, but many use app in areas with poor connectivity. System fails when offline.

What is the lesson about assumptions in Requirements Elicitation?

Never assume "common sense." All expectations must be made explicit, verified, and documented.

What are key questions to ask during Requirements Elicitation? (Give 3)

1. Why do you need to build new software?, 2. Who will be using the software?, 3. Where will the software be used?, 4. What problem are you expecting software to solve?, 5. How would you assess success? (any 3 from list).

What is Requirements Analysis?

The process of reviewing and analyzing raw requirements to discover: missing, overlapping, ambiguous, unrealistic, conflictual, inconsistent requirements. Negotiate with stakeholders to resolve conflicts and improve interpretation.

What is the goal of Requirements Analysis?

Examine elicited requirements to detect issues, gaps, and inconsistencies before specification.

What are Missing Requirements?

Some functionalities or constraints not mentioned at all. Example: "System prints reports" but format, data, or timing are unspecified.

What are Overlapping Requirements?

Different stakeholders express the same feature in multiple ways. Example: "Daily alerts" and "automatic reminders" refer to same notification function.

What are Ambiguous Requirements?

Statements that are vague or open to multiple interpretations. Example: "System should be fast and user-friendly" (What does "fast" mean?).

What are Unrealistic Requirements?

Requested features exceed technical, time, or budget constraints. Example: "Handle 1,000 transactions per second" on low-cost hardware.

What are Conflicting Requirements?

Different stakeholders want contradictory behaviors. Example: Managers need detailed logs; users demand minimal data for privacy.

What are Inconsistent Requirements?

Requirements contradict each other or use inconsistent terminology. Example: One states "Pay at pickup," another says "Online payment only."

What is Requirements Documentation?

The process of developing a document that clearly, precisely, formally, and officially records each requirement of the software system.

Who is the Requirements Documentation used to communicate with?

Customers, End-users, Software developers, Project Managers, Quality Assurance Engineers/Testers.

What is the resulting artifact from Requirements Documentation?

A DRAFT version of the Software Requirements Specification (SRS) document.

What is an SRS (Software Requirements Specification)?

Document that identifies customer requirements by detailing results of elicitation, problem analysis, and modeling. Serves as foundation for design, implementation, and testing.

What qualities must an SRS have? (Give 4)

Correct, Complete, Unambiguous, Consistent, Verifiable, Understandable, Modifiable, Traceable (any 4).

What IEEE standards guide SRS writing?

IEEE Std 830-1998 (Recommended Practice for Software Requirements Specifications), IEEE Std 1362-1998 (Guide for COOP Document), IEEE Std 1233-1998 (Guide for System Requirements Specification).

How are most requirements written in SRS?

Natural language sentences supplemented with diagrams, tables of detailed information, formal or semi-formal descriptions.

What is the Volere Requirements Template?

A requirements specification template and methodology by Suzanne and James Robertson. More human-centered and flexible than IEEE 830, organizes requirements with fit criteria, rationale, source, etc.

How does Volere relate to IEEE 830?

Volere is a refined and modernized version of IEEE 830 SRS concept. Provides template that maps easily to IEEE 830 sections, adding guidance for quality, rationale, and stakeholder communication.

What is Requirements Validation?

Certifies that the requirements document is an acceptable description of the system to be implemented. Finalizes the SRS document with stakeholders.

What does Requirements Validation check for? (Give 3)

Completeness and consistency, Requirements conflicts, Ambiguous requirements, Conformance to standards, Technical errors (any 3 from list).

What should be done iteratively during Requirements Validation?

Send your document/PV containing analyzed requirements to involved stakeholders after each meeting/interview/session.

What is Principle 1 of RE: Value-orientation?

Ask the right questions. Focus on the real problem or need, not the solution. Requirements are means to an end, not an end in itself. RE focuses on value creation.

Give an example of Value-orientation principle

If requirement is "record patient information," this is not the end—it's the means. Real value is to ensure accurate and accessible medical records for better patient care.

What is Principle 2 of RE: Stakeholder?

Involve all stakeholders and engage early and often. RE is about satisfying stakeholders' desires and needs. Different roles, ages, education levels—system must satisfy all their needs.

What is Principle 3 of RE: WRITE?

Write clear and concise requirements. Don't pretend you have solid memory. Ensure pen and notebook to write requirements using SMART method: Specific, Measurable, Achievable, Relevant, Time-bound.

What is Principle 4 of RE: Context?

Context is important. Systems cannot be understood in isolation. Systems are embedded in context. System context describes interaction with environment. When needed, write down the context.

What is Principle 5 of RE: Operational Management?

Ensure better operational management process. Traceability links: Link requirements to design, development, testing, integration. Versions & Changes: Track all changes to ensure they're justified, approved, communicated, implemented.

What is Principle 6 of RE: ReAdapt to Process Model?

If plan-driven, complete all requirements and validate them. For Agile models, embrace always evolving and potentially new requirements into product backlog.

What is Principle 7 of RE: Non-Functional Requirements?

Don't ignore NFRs, they can be vital to the success of the product. NFRs can be critical.

What is Principle 8 of RE: Done Definition?

Clearly set the "Done Definition" or Acceptance Criteria. Describe clearly when a requirement is considered completed. Ensures better common understanding between developers, testers, and stakeholders.

What is Principle 9 of RE: Cyclic Problem-Requirement-Solution?

Having understood the problem and requirement, it can be good to speak out and brainstorm solutions with stakeholders to bring new requirements, problems, and constraints (in their presence).

What is Principle 10 of RE: Visual Diagrams?

Use visual/graphical diagrams to communicate. Use use case diagrams, process flows, UI mockups to simplify and provide visual representation of requirements.

What is Principle 11 of RE: Prioritize?

Prioritize requirements based on: Business Value, Cost, Effort, Technical Complexity, Risk. May use MoSCoW notation (Must have, Should, Could, Won't have). All stakeholders can contribute.

What does MoSCoW stand for in requirement prioritization?

M: Must have, S: Should have, C: Could have, W: Won't have.

What are the 3 C's of User Stories?

Card + Conversations + Confirmation. Card: reminder for conversations during sprint. Conversations: PO explains to developers. Confirmation: tests PO performs to verify implementation (acceptance tests/criteria).

What is the format of a User Story?

As a [type of user], I want to [perform an action with the system], So that [Benefit/Value].

Give an example of a User Story from Library Management System

"As a student, I want to borrow books so that I can access the materials I need for my studies."

What does the Card represent in 3 C's?

A reminder for conversations during the sprint (not a complete specification).

What does Conversations represent in 3 C's?

Direct dialogue between PO and developers to explain requirements, payment methods, discount options, etc.

What does Confirmation represent in 3 C's?

Tests the PO will perform to verify the story's implementation; also called acceptance tests or acceptance criteria.

What happens during a Writing Workshop (or Inception)?

When: project beginning. Participants: key users. Goal: Define what software will do (initial list of stories) and what it will NOT do.

What is a Setup Sprint?

Some teams conduct this before starting. Goal: set up the development environment and tools.

What does INVEST stand for in User Stories?

Independent, Negotiable, Valuable, Estimable, Small, Testable.

What does Independent mean in INVEST?

The user story should stand alone, can be developed and delivered without relying on other stories.

What does Negotiable mean in INVEST?

The user story isn't a rigid contract; it's open to discussion and refinement based on feedback and collaboration.

What does Valuable mean in INVEST?

The user story must provide clear value to the user or business by addressing a real need or delivering an improvement.

What does Estimable mean in INVEST?

The scope and content should be clear enough for the team to estimate the effort required to complete the user story.

What does Small mean in INVEST?

The user story should be sized appropriately—small enough to be completed within a single sprint or workflow iteration.

What does Testable mean in INVEST?

There must be clear acceptance criteria so the user story can be tested and validated upon completion.

How can NFRs be represented in Scrum? (Option 1)

As Acceptance Criteria within User Stories. Attach NFRs directly to user stories they affect. Example: "Login must complete within 2 seconds." Best for story-specific NFRs.

How can NFRs be represented in Scrum? (Option 2)

As Separate Technical Stories. If NFR requires dedicated effort or infrastructure. Example: "As a DevOps engineer, I want to set up automated load testing pipeline." Best for NFRs requiring engineering work.

How can NFRs be represented in Scrum? (Option 3)

As Definition of Done (DoD) Items. Incorporate common NFRs into team's DoD. Example: "Code reviewed and passes security scan," "API latency under 500 ms." Best for recurring, system-wide NFRs.