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 Elicitation Analysis Requirements Managemen t Requirements Requirements Validation Specification R. Kuehl/J. Scott Hawker p. 3 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 System Technology Features Pull Push R. Kuehl/J. Scott Hawker p. 4 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 .” R. Kuehl/J. Scott Hawker p. 5 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 R. Kuehl/J. Scott Hawker p. 6 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 R. Kuehl/J. Scott Hawker p. 7 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 R. Kuehl/J. Scott Hawker p. 8 R I T Software Engineering
Iteratively Analyze the Problem and Synthesize a Solution Define Define Build Solution Analysis Problem Solution Requirements Design Implementation Classify and structure the requirements to provide a functional view of the architecture Go far enough into design to make sure you have gone far enough in requirements From a requirements perspective, synthesize a feasible design From a design perspective, analyze the requirements for clarity, completeness , etc. Don’t get hung up on whether analysis is a requirements or design activity R. Kuehl/J. Scott Hawker p. 9 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? R. Kuehl/J. Scott Hawker p. 10 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 ? R. Kuehl/J. Scott Hawker p. 11 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 R. Kuehl/J. Scott Hawker p. 12 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? R. Kuehl/J. Scott Hawker p. 13 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 R. Kuehl/J. Scott Hawker p. 14 R I T Software Engineering
A Picture Worth a 1000 Words Waterfall Requirements Incremental Evolutionary “Classic” or agile style Design Always maps Construction (coding & testing) Deployment The Requirements Engineering Model The General Software Engineering Framework R. Kuehl/J. Scott Hawker p. 15 R I T Software Engineering
Recommend
More recommend
