L4 Flashcards
Q: Who are the primary stakeholders in software development?
A: Users, Customers, and Software Engineers.
Q: What are the roles of the stakeholders?
A:
Users: Use the system and provide feedback.
Customers: Fund the project and define business needs.
Software Engineers: Develop and implement the system.
Q: What is a software requirement?
A: A software capability needed by a user to solve a problem.
Q: What is an example of a valid requirement?
A: “The system shall allow the user to access his account balance.”
Q: What is NOT a requirement?
A: “Customer account balances will be stored in a table called ‘balance’ in a MySQL database.” (This is an implementation detail.)
Q: What is a key characteristic of a good requirement?
A: It describes what the system should do, not how it should do it.
Q: What is requirements elicitation?
A: The process of discovering, reviewing, articulating, understanding, and documenting user needs and system constraints.
Q: What are the five key activities in requirements elicitation?
A:
Discover the needs
Review existing knowledge
Articulate requirements clearly
Understand the constraints
Document everything
Q: What techniques can be used for requirements elicitation?
A:
Blueskying (brainstorming with an open mind)
Role-playing (acting out user interactions)
Observation (watching users perform tasks)
Q: What are the four key attributes of a requirement?
A:
Behavior – The required functionality.
Priority – The importance of the requirement.
Status – The progress (waiting, in progress, completed).
Time Estimate – The estimated time needed to implement it.
Q: Who sets the priority of a requirement?
A: The customer, based on business value.
Q: Who estimates the time required for a requirement?
A: The software developers, using techniques like Planning Poker.
Q: What is an ideal length for a user story estimate?
A: Less than 15 days – Estimates longer than this are usually inaccurate.
Q: What should you do if a user story is estimated at 40 days?
A: Break it into smaller user stories.
Q: What is the AND Rule for breaking down requirements?
A: If a requirement contains “and,” it can probably be split into two or more smaller stories.
Q: Why is traceability important in software development?
A: It ensures that every requirement is properly tracked from definition to implementation and testing.
Q: Who benefits from maintaining traceability?
A:
Developers (Check if the system is complete)
Testers (Ensure all requirements are met)
Designers (Understand design rationale)
Maintainers (Assess the impact of changes)
Q: What are the steps to refining requirements iteratively?
A:
Talk to the customer to clarify needs.
Play planning poker to estimate effort.
Clarify assumptions and eliminate misunderstandings.
Reach a consensus on final estimates.
Q: What are the two main types of software requirements?
A: Product and Process requirements.
Q: What is the difference between product and process requirements?
A:
Product requirements define the behavior of the software (e.g., “The system shall verify prerequisites before course registration.”).
Process requirements define constraints on how the software is developed (e.g., “The software must be written in Java.”).
Q: What are functional requirements?
A: Requirements that define specific behaviors and functions of the software (e.g., “The system shall allow users to log in.”).
Q: What are non-functional requirements (NFRs)?
A: Requirements that describe system qualities, constraints, or properties (e.g., “The response time shall be less than 2 seconds.”).
Q: What is another name for non-functional requirements?
A: “Ilities” – because they include scalability, usability, reliability, etc.
Q: What are the key characteristics of a good requirement?
A:
Completeness – All necessary features are described.
Consistency – No contradictions exist between requirements.
Unambiguous – Only one possible interpretation.
Correctness – Only describes intended features.
Realistic – Feasible within time and budget.
Verifiable – Can be tested and measured.
Traceable – Can be linked to implementation and testing.
Q: Why should requirements be quantifiable?
A: Quantifiable requirements are easier to verify (e.g., “Increase throughput by 20%”).
Q: What are the main sources of requirements?
A:
Goals – Business objectives and critical success factors.
Domain Knowledge – Industry-specific knowledge needed for software design.
Stakeholders – Different viewpoints from users, customers, and engineers.
Operational Environment – Physical and software constraints.
Organizational Environment – Business processes, politics, and culture.
Q: What are some common requirement elicitation techniques?
A:
Interviews – Ask stakeholders about their needs.
Scenarios (User Stories & Use Cases) – Describe real-world interactions.
Prototypes – Build a quick model for feedback.
Facilitated Meetings (Brainstorming) – Gather ideas in a group setting.
Observation – Watch users perform tasks without software
Q: Why is domain knowledge important in requirements elicitation?
A: It helps infer tacit knowledge that stakeholders may not explicitly mention.
Q: What is an SRS (Software Requirements Specification)?
A: A formal or informal document outlining the expected behavior and constraints of the software.
Q: What are the benefits of an SRS?
A:
Agreement between customer and software team.
Prevents miscommunication.
Serves as a reference throughout development.
Q: What is the difference between validation and verification?
Validation: “Are we building the right product?”
Verification: “Are we building the product right?”
Q: What are common techniques for requirement validation?
A:
Requirements Reviews – Discuss requirements with stakeholders.
Prototyping – Build a model to confirm expectations.
Model Validation – Use formal methods or diagrams.
Acceptance Tests – Define how each requirement will be tested.
Q: What are the steps to estimating a project?
Break down user stories into small, clear requirements.
Use Planning Poker to estimate effort.
Remove assumptions by clarifying with the customer.
Reach a consensus on estimates.
Sum up all estimates for a total project estimate
Q: What happens if the total project estimate is too long?
A:
Reevaluate the scope and remove low-priority features.
Refactor requirements into smaller, more manageable pieces.
Adjust the timeline or team capacity.
