SLIDE 1
- R. Kuehl/J. Scott Hawker
- p. 1
R I T
Software Engineering
- R. Kuehl/J. Scott Hawker
- p. 2
R I T
Software Engineering
Software Requirements Engineering Activities R. Kuehl/J. Scott - - PowerPoint PPT Presentation
Software Requirements Engineering Activities R. Kuehl/J. Scott - - PowerPoint PPT Presentation
Software Requirements Engineering Activities R. Kuehl/J. Scott Hawker p. 1 R I T Software Engineering R. Kuehl/J. Scott Hawker p. 2 R I T Software Engineering Requirements Engineering Activities Framework Requirements Requirements
SLIDE 2
SLIDE 3
- R. Kuehl/J. Scott Hawker
- p. 3
R I T
Software Engineering
Requirements Engineering Activities Framework
Requirements Elicitation Requirements Analysis Requirements Management Requirements Validation Requirements Specification
SLIDE 4
- R. Kuehl/J. Scott Hawker
- p. 4
R I T
Software Engineering
Elicitation: Domain Learning, Discovering and Capturing Requirements More challenging than writing code Users know what they have, and may think they know what they need
Better understanding of needs after they see it, often too late
- I’ll Know It When I See It (IKIWISI)
Users often don’t envision the possibilities enabled by technology
“To take better pictures, I need a better camera or better film”
- Never envision a digital camera
Requirements Pull Technology Push
System Features
SLIDE 5
- R. Kuehl/J. Scott Hawker
- p. 5
R I T
Software Engineering
“Requirements elicitation is perhaps the most difficult, most critical, most error-prone, and most communication- intensive aspect of software development. Elicitation can succeed only through a collaborative partnership between customers and the development team.” Weigers “Collecting requirements is an inherently difficult problem due to the psychology of expressing uncertain desires in an ambiguous language.”
SLIDE 6
- R. Kuehl/J. Scott Hawker
- p. 6
R I T
Software Engineering
Why is Requirements Elicitation Challenging?
Usually a domain learning curve User and stakeholder diversity with competing perspectives and goals User and stakeholder needs and missions are constantly changing A new system will impact user needs, resulting in new system needs, which will impact user needs, ... (cycle) Complex systems are never fully understood, especially at the beginning Hard to understand the constraints of legacy systems and the system environment
SLIDE 7
- R. Kuehl/J. Scott Hawker
- p. 7
R I T
Software Engineering
Requirements Analysis
Requirements analysis
- 1. The process of studying user needs to arrive at a
definition of system, hardware, or software requirements.
- 2. The process of studying and refining system,
hardware, or software requirements.
[IEEE-STD-610.12-1990 Software Engineering Glossary]
Transition from an informal user domain view to a more formal system view of system requirements
SLIDE 8
- R. Kuehl/J. Scott Hawker
- p. 8
R I T
Software Engineering
Requirements Analysis Activities
Semantic analysis to detect ambiguity, derived requirements, etc. User and functional modeling of requirements from the user’s external perspective (e.g., use case modeling) Quality attribute scenario identification Class analysis modeling of requirements to form an internal system perspective Requirements attribute classification for planning, reporting and tracking
Priority, source, type, risk, cost, scope, volatility/stability
Requirements negotiation and conflict resolution
SLIDE 9
- R. Kuehl/J. Scott Hawker
- p. 9
R I T
Software Engineering
Iteratively Analyze the Problem and Synthesize a Solution
From a requirements perspective, synthesize a feasible design From a design perspective, analyze the requirements for clarity, completeness, etc. Requirements Design Implementation Classify and structure the requirements to provide a functional view of the architecture Define Problem Define Solution Analysis Go far enough into design to make sure you have gone far enough in requirements Build Solution
Don’t get hung up on whether analysis is a requirements or design activity
SLIDE 10
- R. Kuehl/J. Scott Hawker
- p. 10
R I T
Software Engineering
Requirements Specification
A formal document describing the needs(requirements) a system must satisfy. Valid if it correctly, completely, unambiguously, and verifiably captures the needs the system must satisfy. Or requirements may be captured incrementally in more informal descriptions such as user stories Are these really valid requirements specifications?
SLIDE 11
- R. Kuehl/J. Scott Hawker
- p. 11
R I T
Software Engineering
Requirements Validation
How do you know you have the right requirements?
Requirements validation:
Requirements meet the stakeholders’ intentions Ensure a common understanding across the project team and among the stakeholders
Validation should not be confused with verification
Validation: are we building the right system? Verification: have we built the system right?
SLIDE 12
- R. Kuehl/J. Scott Hawker
- p. 12
R I T
Software Engineering
Requirements Validation Techniques
Requirements reviews (internal and with stakeholders) Analysis modeling
Can a system design solution be envisioned without making assumptions?
Prototyping to elicit and validate user requirements Plan how each requirement will be verified in acceptance tests
Requirements define black-box customer acceptance tests If you cannot write a test case, the requirement is probably deficient in quality (ambiguous, inconsistent, etc.)
Observe operational usage of the system to see if it truly meets the stakeholders needs
SLIDE 13
- R. Kuehl/J. Scott Hawker
- p. 13
R I T
Software Engineering
Requirements Management
Change control Tracing Version control Status (attribute) tracking Why? Necessary communications to “maintain the integrity, accuracy, and currency of requirements agreements throughout the project” Why do requirements change?
SLIDE 14
- R. Kuehl/J. Scott Hawker
- p. 14
R I T
Software Engineering
Why Requirements Need Management
The “what” not always obvious Many sources, and interested and responsible parties Communication - not always easy to express in words plus jargon Diversity of requirements at different levels of detail Unique properties Can be time sensitive The number of requirements can become unmanageable Complex interrelationships to each other, and to other software deliverables Conflicting perceptions on priority
SLIDE 15
- R. Kuehl/J. Scott Hawker
- p. 15
R I T
Software Engineering