01/31/08 EEC 421/521: Software Engineering 1 EEC 421/521: Software Engineering Requirements Engineering 01/31/08 EEC 421/521: Software Engineering 2 Requirements Analysis is Hard Frederick P. Brooks, Jr. “The hardest single part of building a software system is deciding what to build. No part of the work so cripples the resulting system if done wrong.” “The seeds of major software disasters are usually sown in the first three months of commencing the software project.” Capers Jones 01/31/08 EEC 421/521: Software Engineering 3 Requirements Engineering Tasks • Inception – Roughly define scope • Elicitation – Define requirements • Elaboration – Further define requirements Requirements engineering is accomplished through the execution of seven major tasks • Negotiation – Reconcile conflicts • Specification – Create analysis model • Validation – Ensure quality of requirements Requirements Management (Umbrella Activities) 01/31/08 EEC 421/521: Software Engineering 4 Requirements Process Elicitation Analysis Specification Validation Software Requirements Specification Collecting the user’s requirements Understanding and modeling the desired behavior Documenting the behavior of the proposed system Checking that specification matches user’s requirement
6
Embed
Requirements Engineering Tasks - selab.csuohio.eduselab.csuohio.edu/~nsridhar/teaching/spring08/eec521/slides/... · Requirements engineering is accomplished through the execution
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
01/31/08 EEC 421/521: Software Engineering 1
EEC 421/521: SoftwareEngineering
Requirements Engineering
01/31/08 EEC 421/521: Software Engineering 2
Requirements Analysis isHard
Frederick P. Brooks, Jr.
“The hardest single part ofbuilding a software systemis deciding what to build.No part of the work socripples the resulting
system if done wrong.”
“The seeds of majorsoftware disasters are
usually sown in the firstthree months ofcommencing the
software project.”
Capers Jones
01/31/08 EEC 421/521: Software Engineering 3
Requirements EngineeringTasks
• Inception
– Roughly define scope
• Elicitation
– Define requirements
• Elaboration
– Further definerequirements
Requirements engineering is accomplished through theexecution of seven major tasks
• During the initial project meetings, the followingtasks should be accomplished– Identify the project stakeholders
• These are the folks we should be talking to
– Recognize multiple viewpoints• Stakeholders may have different (and conflicting) requirements
– Work toward collaboration• It’s all about reconciling conflict
– Ask the first questions• Who? What are the benefits? Another source?
• What is the problem? What defines success? Other constraints?
• Am I doing my job right?
01/31/08 EEC 421/521: Software Engineering 13
Collaborative Elicitation
• One-on-one Q&A sessions rarely succeed in practice;collaborative strategies are more practical
• Collaborative elicitation should result in several workproducts.
– A bounded statement of scope
– A list of stakeholders
– A description of the technical environment
– A list of requirements and constraints
– Any prototypes developed
– A set of use cases
• Characterize how users will interact with the system
• Use cases tie functional requirements together
01/31/08 EEC 421/521: Software Engineering 14
Narrative Use Case
• A use case describes a sequence of steps in aninteraction.
• Buy a Product Scenario:– The customer browses the catalog and adds
desired items to the shopping basket. When thecustomer wishes to pay, the customer describesthe shipping and credit care information andconfirms the sale. The system checks theauthorization on the credit card and confirms thesale both immediately and with a follow-up e-mail.
01/31/08 EEC 421/521: Software Engineering 15
The Analysis Model(Specification)• Purpose
– Precisely describes desired function and performance
– Precisely describes all relevant constraints
– Serves as the foundation for all subsequent activities
• Structure
– Consists of many different views
– Views range from informal to semi-formal to fully-formal
01/31/08 EEC 421/521: Software Engineering 16
Validating the Analysis Model
• Before design activities can proceed, the analysismodel must be validated
– Is the model intellectually manageable?
– Does the model reflect the system to be built?
– Are the requirements consistent?
– Is each requirement bounded and unambiguous?
– Is each requirement achievable?
– Is each requirement really necessary?
– Is each requirement testable?
– Does each requirement have attribution?
01/31/08 EEC 421/521: Software Engineering 17
The Analysis ModelThe analysis model consists of a wide variety of
diagrammatic forms used to bridge an important gap.
• Describe what the customer wants built
• Establish the foundation for the software design
• Provide a set of validation requirements
SystemDescription
DesignModel
AnalysisModel
Purpose:
• System information
• System function
• System behaviors
01/31/08 EEC 421/521: Software Engineering 18
Some Rules of Thumb
• Make sure all points of view are covered
• Every element should add value
• Keep it simple
• Maintain a high level of abstraction
• Focus on the problem domain
• Minimize system coupling
01/31/08 EEC 421/521: Software Engineering 19
Analysis ModelingApproaches
• Models data elements
– Attributes
– Relationships
• Models processes that transformdata
Structured Analysis
• Models analysis classes
– Data
– Processes
• Models class collaborations
Object-Oriented Analysis
Techniques from both approaches are typically used in practice.
01/31/08 EEC 421/521: Software Engineering 20
Data Objects
• Plays a necessary role
• Characterized by attributes
• Uniquely identifiable
• Roles
• Events
• Places
A data object is a domain element that will be manipulated by thesystem.
Characteristics: Examples:
• External entities
• Structures
• Other things
Object: car
Attributes:• VIN #• Make• Model• Price
Modeling
01/31/08 EEC 421/521: Software Engineering 21
Relationships, Cardinality,Modality
• Cardinality
– Defines the number of items oneither end of a connection