Understanding

Requirements
Module2

-Anuradha Pai
- BTI College of Engineering
1. Challenges in Understanding Requirements
1. Initial Assumptions vs. Reality:
o Common Misconception: It's often assumed that customers and end-users
have a clear understanding of their needs and can articulate them precisely.
o Reality:
▪ Many customers may lack clarity about what they want.
▪ End-user needs and priorities can be vague or evolve over time.
2. Dynamic Nature of Requirements:
o Requirements tend to change throughout the project due to:
▪ Evolving business goals.
▪ New insights gained during development.
▪ Market or technological changes.
1. Challenges in Understanding
Requirements
3. Communication Gaps:
o Misinterpretation often occurs between what customers say and what
engineers understand.
o As projects progress, differing interpretations lead to delays and
dissatisfaction.
2. The Nightmare Scenario
• Illustrative Anecdote:
o A customer revisits requirements late in the project, claiming the development
team misunderstood their original intent.
o Consequences include:
▪ Broken deadline commitments.
▪ Reputational damage to the team or organization.
▪ Financial losses due to rework and overruns.
• Lessons from Experience:
o Many experienced professionals encounter these challenges but fail to learn or
implement effective solutions to mitigate them.
3. Requirements Engineering
• The Nature of Software Building: • Detailed requirements gathering is
• Involves creativity, problem-solving, and unnecessary in a rapidly changing
collaboration, making it exciting but also environment.
complex. • The primary goal is delivering a working
• Developers often feel eager to dive into program; everything else is secondary.
coding without fully understanding the
• Risks of Skipping Requirements
problem.
Engineering:
• Common Misconceptions: • Misalignment between stakeholders'
• Requirements will become clear during expectations and deliverables.
development. • Increased likelihood of project failure
• Stakeholders can only articulate needs due to incomplete or misunderstood
after seeing prototypes. requirements
3. What is Requirements Engineering?
• Definition:
o A systematic approach to understanding, documenting, and managing software
requirements.
• Purpose:
o Acts as a foundation for software design and construction.
o Ensures alignment between stakeholders and the software development team.
• Scope:
o Begins during the communication phase and extends into modeling.
o Adapts to the specific needs of the process, project, and product.
3.1 Importance of Requirements
Engineering
• Building the Foundation:
o Establishes the scope, priorities, and constraints of the project.
o Helps identify functions, features, and behaviors needed in the software.

• Bridging Stakeholders and Developers:

o Translates business needs into actionable technical requirements.
o Enables stakeholders to visualize the system context and its functionality.

• Facilitating Decision-Making:
o Provides clarity for prioritizing tasks and managing project risks.
4. Seven Key Tasks of
Requirements Engineering
1. Inception
• Objective:
o Understand the problem and identify preliminary solutions.
• Activities:
o Define business needs and potential markets.
o Develop a rough feasibility analysis.
o Establish the project scope and initiate discussions with stakeholders.
• Outcomes:
o Basic understanding of the problem, stakeholders, and solution requirements.
4.2 Elicitation
• Objective:
o Gather and document detailed requirements from stakeholders.
• Challenges:
o Scope Problems:
▪ Undefined system boundaries or unnecessary technical details.
o Understanding Problems:
▪ Stakeholders may lack clarity or knowledge of technical constraints.
▪ Miscommunication can lead to conflicting or ambiguous requirements.
o Volatility:
▪ Requirements often evolve due to changing business needs.
• Solution:
o Use structured methods for requirements gathering (e.g., interviews, workshops).
4.3 Elaboration
• Objective:
o Refine and expand the information gathered during inception and elicitation.

• Activities:
o Create user scenarios describing system interactions.
o Identify analysis classes, their attributes, and required services.
o Develop supplementary diagrams for detailed modeling.

• Outcome:
• A refined requirements model describing software functions, behaviors, and information.
4.4 Negotiation
• Objective:
o Reconcile conflicting requirements and prioritize stakeholder needs.

• Challenges:
o Stakeholders often request conflicting or unrealistic features.

• Activities:
o Rank requirements based on priority, feasibility, and risk.
o Iteratively address conflicts through discussions and trade-offs.

• Outcome:
• A balanced set of requirements acceptable to all parties.
4.5 Specification
• Objective:
o Document the system requirements in a clear, unambiguous, and consistent manner.

• Formats:
o Written documents, graphical models, mathematical models, usage scenarios, or prototypes.

• Guidelines:
o Use a "standard template" for consistency in complex projects.
o Be flexible for smaller systems, using lightweight formats like scenarios or prototypes.
4.6 Validation
• Objective:
o Ensure the requirements are complete, consistent, and error-free.

• Activities:
o Conduct technical reviews involving stakeholders.
o Identify and address inconsistencies, ambiguities, and omissions.

• Outcome:
o Validated requirements that serve as a reliable foundation for design and development.
4.7 Requirements Management
• Objective:
o Track, control, and adapt requirements as they evolve throughout the project lifecycle.

• Challenges:
o Managing frequent changes while maintaining project focus.

• Activities:
o Maintain a requirements repository for tracking.
o Use software configuration management (SCM) techniques for version control.
5. Key Insights for Effective
Requirements Engineering
1. Proactive Communication: 4. Iterative Process:
o Engage stakeholders early and frequently o Revisit and refine requirements as the
to minimize misunderstandings. project progresses.

2. Organized Documentation: 5. Robust Validation:

o Clearly record and refine requirements to o Regularly review requirements to ensure
avoid misinterpretation. alignment with stakeholder goals.

3. Adaptability: 6. Change Management:

o Tailor techniques to the project's o Implement mechanisms to handle
complexity, size, and stakeholders' needs. evolving requirements systematically.
5.1 Practical Outcomes of
Requirements Engineering
• A well-defined foundation for design and development.

• Increased stakeholder satisfaction by aligning deliverables with expectations.

• Reduced risk of project failure due to clear, validated requirements.

• Enhanced ability to adapt to changes while maintaining control over the project.
6. Establishing the Groundwork in
Requirements Engineering
• Effective groundwork is essential for understanding software requirements.

• Ideally, stakeholders and engineers work as a team; however, real-world scenarios

often present challenges:
• Stakeholders might be geographically dispersed.
• They may lack a clear idea of their needs or have conflicting requirements.
• Limited technical expertise and time constraints can hinder effective
interaction.
6.1 Key Steps to Establish Groundwork:
Identifying Stakeholders
• Definition of Stakeholders:
• According to Sommerville and Sawyer, stakeholders are individuals or groups that directly or
indirectly benefit from the developed system.
• Examples include business managers, product managers, marketing teams, internal/external
customers, end-users, engineers, and maintenance personnel.
• Key Insights:
• Stakeholders often have varying expectations, benefits, and risks associated with the system.
• Different stakeholders may have conflicting opinions or unclear requirements.
• Steps:
• Initial Identification:
• Create an initial list of stakeholders likely to provide input during the elicitation process.
• Iterative Expansion:
• Ask each stakeholder, “Who else should I talk to?” to expand the stakeholder list.
6.2Recognizing Multiple Viewpoints
• Diverse Perspectives:
• Different stakeholders bring varying priorities and expectations:
• Marketing Teams: Focus on features that excite potential customers and boost sales.
• Business Managers: Prioritize budget-friendly features that align with deadlines.
• End-Users: Desire ease of use, familiarity, and intuitive interfaces.
• Software Engineers: Ensure robust infrastructure for system scalability and functionality.
• Support Engineers: Seek maintainable and stable software solutions.
• Handling Conflicting Requirements:
• Collect and categorize requirements, including conflicting ones, for further analysis.
• Use a structured approach to reconcile inconsistencies and select a consistent set of
requirements.
6.3 Working Toward Collaboration
• Challenges in Collaboration:
• Multiple stakeholders often have conflicting opinions, making consensus difficult.
• Turf wars or individual biases can hinder effective teamwork.
• Role of Requirements Engineer:
• Identify common requirements agreed upon by all stakeholders.
• Highlight areas of conflict or inconsistency for resolution.
• Facilitation of Decision-Making:
• Stakeholders provide their input, but a “project champion” (e.g., senior manager or
lead technologist) may make the final decision.
• Key Techniques:
• Encourage open communication to promote mutual understanding.
• Use tools like priority points (explained below) to resolve conflicts.
6.4 Asking the First Questions
• Context-Free Questions:
• Designed to gain a broad understanding of the project without preconceived assumptions.
• Examples:
• Who initiated this project?
• Who will use the final product?
• What economic benefits does this project aim to achieve?
• Are there existing solutions for this problem?
• Problem-Focused Questions:
• Aim to clarify the specific issues the solution will address.
• Examples:
• What problems will the software solve?
• How will the solution integrate into the business environment?
• Are there performance constraints to consider?
6.4 Asking the First Questions
• Meta-Questions for Feedback:
• Evaluate the elicitation process to improve stakeholder interaction.
• Examples:
• Are you the right person to answer these questions?
• Are my questions relevant to the problem?
• Can anyone else provide additional insights?
6.5 Resolving Conflicts Using Priority
Points
• Voting Mechanism:
• Stakeholders are given a fixed number of priority points to allocate across requirements.
• Points reflect the relative importance of each requirement from their perspective.
• Benefits:
• Ensures stakeholders focus on the most critical requirements.
• Helps identify high-priority features while revealing differences in stakeholder priorities.
• Process:
• Create a list of all requirements.
• Each stakeholder distributes their points among the requirements based on importance.
• Aggregate the points to identify overall priorities.
6.6 Key Outcomes of Establishing the
Groundwork
1. Comprehensive Stakeholder List
• Ensures all relevant voices are considered during the project.
2. Categorized Viewpoints
• Facilitates conflict resolution and prioritization of requirements.
3. Collaborative Decision-Making Framework
• Promotes stakeholder alignment and minimizes disputes.
4. Structured Elicitation Process
• Leads to a well-rounded understanding of the project goals and constraints.
7. Requirements Elicitation Overview
• Requirements elicitation, or gathering, involves:Problem-solving,
elaboration, negotiation, and specification.
• Collaboration among stakeholders to define the problem, propose
solutions, and negotiate approaches.
• A preliminary set of solution requirements is specified.
7.1 Key Methods for Requirements
Elicitation
Collaborative Requirements Gathering
• Guidelines for Collaboration:
• Meetings include both software engineers and stakeholders.
• Rules for preparation and participation are established.
• Meetings have a structured but flexible agenda.
• A facilitator controls the discussion and ensures focus.
• A definition mechanism (e.g., flip charts, virtual forums) organizes and
records ideas.
7.2 Steps in Collaborative Gathering:
1.Preparation:
• A "product request" document outlines initial problem scope and potential
solutions.
• Meeting logistics (date, time, attendees) and facilitator are decided.
2.Discussion:
• Stakeholders review the product request and prepare lists of:
• Objects related to the system.
• Services or functions interacting with those objects.
• Constraints and performance criteria.
3.Post-Meeting:
• Lists are consolidated and refined through discussion.
• Mini-specifications are created for clarity.
• Unresolved issues are added to an "issues list" for follow-up.
7.3 Quality Function Deployment (QFD)
• Purpose: Align customer needs with technical requirements for the software.
• Types of Requirements Identified:
• Normal Requirements: Explicit goals stated by the customer.
• Expected Requirements: Implicit requirements assumed by the customer
(e.g., reliability, usability).
• Exciting Requirements: Features exceeding customer expectations, creating
delight (e.g., innovative functionalities).
• Methods:
• Customer interviews, surveys, and data analysis.
• Use of the "customer voice table" and evaluation tools to categorize and
prioritize requirements.
7.4 Usage Scenarios
• Objective: Understand how system functions and features will be used.
• Methodology:
• Develop scenarios, or use cases, that describe interactions between the system
and different user classes.
• Provide insight into system usage under various conditions.
7.5 Elicitation Work Products
• Outcome of Requirements Gathering:
• Statement of Need and Feasibility: Clarifies why the system is needed and if
it is achievable.
• Scope Definition: Bounded description of the system's functionalities.
• Stakeholder List: Details participants involved in elicitation.
• System Environment Description: Specifies technical constraints and
settings.
• Requirements List: Organized by functionality and associated domain
constraints.
• Usage Scenarios: Demonstrate the system's operation in different contexts.
• Prototypes: May be developed to clarify requirements.
7.6 Example: SafeHome Project
• Initial Product Request:
• A home security system function as the first feature, addressing common
safety concerns (e.g., fire, flood, break-ins).
• Wireless sensors and automatic alerts to monitoring agencies.
• Pre-Meeting Preparation:
• Stakeholders list objects (e.g., sensors, control panels) and services (e.g.,
monitoring, alarms).
• Constraints (e.g., cost, user-friendliness) and performance criteria (e.g., event
recognition speed) are identified.
• Meeting Activities:
• Lists are presented, combined, and refined.
• Consensus is achieved on features, constraints, and performance metrics.
• Mini-specifications are developed for critical components (e.g., control panel
dimensions and features).
7.7 Summary
• Collaborative Process: Requirements elicitation emphasizes teamwork,
structured communication, and iterative refinement.
• Focus Areas:
• Identifying diverse stakeholder needs.
• Addressing ambiguities, omissions, and conflicts.
• Balancing technical feasibility with customer satisfaction.
• Outputs: Clearly defined, reviewed, and agreed-upon requirements ensure
alignment and project success.
8. Developing Use Cases
What is a Use Case?
• Definition:
• A use case describes the system's behavior in response to requests from
stakeholders under specific conditions.
• It is a "contract" that captures how the system behaves in various scenarios.
• Purpose:
• Tells a story about how an end-user (actor) interacts with the system.
• Depicts the system from the user’s perspective.
• Formats:
• Narrative text.
• Task or interaction outline.
• Template-based description.
• Diagrammatic representation.
8. Steps to develop Use Case
1. Identify Actors: 2. Define Actor Goals:
•Definition: An actor is any external entity •Understand the objectives that each actor
(person, device, or system) interacting with wants to achieve.
the system. •Example: A homeowner’s goal in a home
•Types of Actors: security system could be activating the
•Primary actors: Interact directly with system or checking its status.
the system to perform its main
functions.
•Secondary actors: Support system
operations indirectly (e.g., maintenance
or monitoring).
•Roles: An actor represents a role rather
than a specific user (e.g., a machine operator
may act as a programmer, tester, or
monitor).
 8. Steps to develop Use Case
3. Establish Preconditions: 5. Consider Exceptions:
• Define the conditions that must exist • Address scenarios where standard
before the use case begins (e.g., a system operations might fail or behave
differently.
must be powered on, sensors must be
• Example: What happens if the
operational). password is incorrect?
4. Outline Main Tasks/Functions: 6. Describe Variations:
• Identify the core actions that an actor • Highlight alternative paths or
performs with the system. variations in interactions (e.g.,
• Example: Entering a password or activating only perimeter sensors vs.
selecting "stay" or "away" mode.? all sensors).
8. Steps to develop Use Case
7. System Information:
• Specify what information the actor acquires, produces, or modifies
in the system.
• Example: Status of security zones or activated alarms.
8. Open Questions:
•Explore unresolved issues or ambiguities, such as:
•Should additional messages be displayed?
•What is the time limit for entering a password?
8. Use Case Template Example
1. Use Case Name: Initiate Monitoring. 7. Exceptions:
2. Primary Actor: Homeowner. • System not ready (sensors open): Close
3. Goal in Context: To activate the security open windows/doors.
system. • Incorrect password: Reenter the correct
4. Preconditions: System is programmed with a password.
password and recognizes sensors. • Control panel not functional: Contact
5. Trigger: Homeowner decides to activate the support.
alarm. 8. Priority: Essential.
6. Scenario: 9. Frequency of Use: Multiple times daily.
• Homeowner observes the control panel. 10. Channels to Actor: Via the control panel.
• Enters a password.
11. Secondary Actors: Sensors, support
• Selects "stay" or "away" mode.
• Observes the red alarm light indicating technicians.
activation. 12. Open Issues:
•Should an abbreviated password option exist?
•Is a deactivation option needed before full
activation?
8. UML Use Case diagram for
SafeHome home security function
8. Reviewing and Refining Use Cases
• Ambiguities: Review use cases to identify unclear interactions or incomplete
descriptions.
• Feedback: Engage stakeholders to ensure accuracy and clarity.
• Iteration: Update and refine use cases as requirements evolve.
8. Benefits of Use Cases
• Provide a clear view of system functionality from an end-user perspective.
• Serve as a foundation for further technical development.
• Help identify system boundaries, features, and exceptions early in the design
process.
9. Building the Requirement model
• Purpose of the Analysis Model • Representation Modes for Requirements
• Provides a description of the • Single Representation Approach: Some
informational, functional, and prefer using a single method like use
behavioral aspects required for a cases for simplicity.
computer-based system. • Multiple Representation Approach:
• Evolves dynamically as stakeholders and Others advocate using various methods to
developers gain clarity about system identify omissions, inconsistencies, or
ambiguities.
requirements.
• Acts as a snapshot of the current • The chosen method often dictates the
specific elements included in the model.
requirements, expected to change as
understanding grows.
• Stable elements form the foundation for
subsequent design tasks, while volatile
ones indicate incomplete stakeholder
understanding.
9.1 Generic Elements of Requirement
model
1. Scenario-Based Elements
• Represent the system from the user's
perspective using use cases or scenario
templates.
• Serve as the foundation for developing
other model components.
• Example: UML activity diagrams detail
how scenarios evolve into comprehensive
representations.

Fig: UML activity diagrams for eliciting requirements

9.2 Generic Elements of Requirement
model
2. Class-Based Elements
• Define objects manipulated during system
interaction and group them into classes
(e.g., with attributes and behaviors).
• Example: UML class diagrams for a
"Sensor" class listing attributes (e.g.,
name, type) and operations (e.g., enable,
identify).
• Illustrate collaborations and relationships
between classes.
9.3 Generic Elements of Requirement
model
3. Behavioural Elements
• Focus on how the system responds to
events and transitions between states.
• Example: UML state diagrams represent
system states and event-driven transitions,
highlighting system actions and reactions.
• Behavioural modelling extends to
individual classes.
9.4 Generic Elements of Requirement
model
4. Flow-Oriented Elements
• Show how information transforms as it moves through the system.
• Inputs (e.g., user commands, network packets) are processed by functions and result in outputs
(e.g., reports, signals).
• Flow models are applicable to systems of all sizes and complexities.
10. Building the Requirement model :
Analysis Pattern
• Experienced requirements engineers often observe that certain issues tend to recur across
multiple projects within the same application domain. Analysis patterns offer predefined
solutions (e.g., a class, function, or behavior) tailored to address these common problems.
These patterns can be reused when modeling various applications, streamlining the
development process.
• Benefits of Analysis Patterns (as noted by Geyer-Schulz and Hahsler):
1.Accelerating Model Development
• Analysis patterns help create abstract models more efficiently by providing
reusable examples, along with descriptions of their advantages and limitations.
2.Simplifying Design Transformation
• They assist in transitioning the analysis model into a design model by suggesting
reliable solutions and design patterns for frequent challenges.
10. Building the Requirement model :
Analysis Pattern
• Integration and Accessibility
• Analysis patterns are incorporated into the requirements model by referencing
their names.
• They are stored in a repository, making it easy for engineers to search and
apply relevant patterns.
• Each pattern is documented using a standardized template, ensuring clarity and
consistency in their usage.
11. Negotiating Requirements
12. Validating Requirements
12. Validating Requirements