Title Slide

• Title: Gathering User Requirements

• Subtitle: Key Concepts and Techniques
• Institution: Wollo University, Kombolcha
Institution of Technology
• Date: December 23, 2022
 Contents Overview
• 1. Gathering User Requirements
• 2. Use Case Scenario Testing
• 3. Fundamental Requirements Gathering
Techniques
• 4. Requirement Validation Techniques
• 5. Class Responsibility Collaborator (CRC)
• 6. Testing Early and Often
 Requirements Elicitation
• Focus: Describing the purpose of the system.
• Involves collaboration among clients, users,
and developers.
• Outcome: Requirements Specification
(contract) and Analysis Model.
• Both activities occur iteratively and
concurrently.
 Requirements Specification vs.
Analysis Model
• Specification: Written in natural language to
facilitate client and user understanding.
• Analysis Model: Uses formal or semi-formal
notation for effective communication among
developers.
 Activities in Requirements
Elicitation
• 1. Identifying Actors: Determine different
types of users.
• 2. Developing Scenarios: Observe user
interactions to outline detailed scenarios.
• 3. Identifying Use Cases: Derive use cases
representing all system functionalities.
• 4. Identifying Nonfunctional Requirements:
Agree on system aspects visible to users but
unrelated to functionality.
• 5. Analyzing Use Case Relationships: Identify
 Sources of Information for
Elicitation
• Client-supplied documents about the
application domain.
• Manuals and technical documentation of
legacy systems.
• Interaction with users and clients to
understand needs and context.
 Two Elicitation Methods
• 1. Joint Application Design (JAD): Collaborative
workshops involving stakeholders to develop
requirements specifications.
• 2. Traceability: Structuring and maintaining
links among requirements and other project
artifacts.
 Functional vs. Nonfunctional
Requirements
• Functional Requirements: Define interactions
between the system and its environment,
focusing on user and system behavior.
• Nonfunctional Requirements: Address system
aspects like usability, performance, reliability,
maintainability, and supportability.
 Nonfunctional Requirements
Categories
• 1. Usability: Ease of use for end-users.
• 2. Maintainability: Ease of system updates and
defect fixes.
• 3. Reliability: System's ability to perform under
specified conditions.
• 4. Performance: Attributes like response time
and throughput.
• 5. Supportability: Ability to support changes
after deployment.
 Techniques for Gathering
Requirements
• 1. Interviews: Engage diverse stakeholders to
capture contrasting needs and synergies.
• 2. Observation: Monitor workflows to identify
data handling and informational needs.
• 3. Document Analysis: Examine policies,
reports, and examples to uncover
organizational requirements.
 Document Analysis Insights
• Identify problems with current systems (e.g.,
redundancies).
• Highlight opportunities to meet new needs.
• Recognize organizational values and priorities.
• Pinpoint key individuals influencing system
design.
 Use Case Modeling
• Describes sequences of actions delivering
measurable value to an actor.
• Represents actors' goals and system tasks
through a use-case-centric approach.
• Each use case focuses on system behaviors
related to user objectives.
 Types of Use Case Models
• 1. Essential Models: Technology-independent
representations of behavioral requirements.
• 2. System Models: Technology-specific
analyses detailing user interactions and
system functionality.
 Essential Use Case Components
• Actors: Entities interacting with the system.
• Use Cases: Defined sequences of actions.
• Associations: Relationships between actors
and use cases.
• Diagrams: Visual representations using UML
standards.
 Identifying Actors and Use Cases
• Actors include end-users, external systems, or
organizations.
• Identify use cases by exploring stakeholder
requirements and potential system services.
 CRC Models
• Class: Generalized objects, e.g., Student,
Professor.
• Responsibility: Actions or knowledge a class
holds.
• Collaborator: Interacting classes assisting in
fulfilling responsibilities.
• Effective for conceptual modeling and detailed
design.
 CRC Card Advantages
• Enables expert analysis and user participation.
• Simple and portable format.
• Facilitates transition to object-oriented design.
• Breaks communication barriers among
stakeholders.
 CRC Card Drawbacks
• Inefficient for large systems.
• Limited detail captured on cards.
• Requires gathering users, which may be
challenging.
• Restricted by the physical format.
 Requirement Validation Overview
• Checks if requirements meet quality criteria.
• Involves stakeholders, external reviewers, and
standards.
• Ensures alignment with project goals and user
needs.
 Validation Quality Criteria
• 1. Completeness: Contains all relevant
information.
• 2. Consistency: Requirements are compatible.
• 3. Adequacy: Addresses actual system needs.
• 4. Unambiguity: Minimizes misinterpretations.
• 5. Comprehensibility: Stakeholders can
understand.
 Additional Validation Criteria
• 1. Importance: Prioritize critical requirements.
• 2. Traceability: Links to system objectives.
• 3. Measurability: Enables evaluation of
requirement fulfillment.
• 4. Necessity: Reflects project goals.
• 5. Viability: Feasible within constraints.
 Principles of Validation
• Involve relevant and independent
stakeholders.
• Separate defect detection from correction.
• Obtain multiple, independent viewpoints.
• Revalidate artifacts when necessary.
• Align documentation formats with validation
goals.
 Validation Techniques
• 1. Walkthroughs: Stakeholders review
requirements collaboratively.
• 2. Desk Checks: Stakeholders evaluate artifacts
individually.
• 3. Prototypes: Stakeholders test requirements
through simulation.
• 4. Inspections: Formal examination for errors
and standard violations.
 Validation vs. Verification
• Validation: Confirms system alignment with
user needs.
• Verification: Ensures completeness and
correctness of requirements specifications.
• Validation involves stakeholders; verification is
often internal.
 Testing Early and Often
• Initiate testing early to detect and resolve
defects sooner.
• Saves effort by addressing issues in initial
stages.
• Facilitates design and approach adjustments
based on findings.
 Thank You!
• Contact: [email protected] |
[email protected].