Professional Documents
Culture Documents
• Uses:
• Process improvement standards and models
• Requirements process measures and benchmarking
• Improvement planning and implementation
A. Elicitation
B. Analysis
C. Specification
D. Testing
• Users don’t know what they want; they only know what they
do.
• What they say they want may not be what they need or you
may begin to define what you think they need, instead of
what they want.
• Goals –
• Sometimes called ‘business concern’ or ‘critical success
factor’
• Provides motivation for the software, but are often
vaguely formulated
• Focus is to assess the value (relative priority) and cost of
goals
• A feasibility study can do this at low cost
• Domain knowledge -
• The software engineer needs to be knowledgeable of the
application domain
• Allows for assessment of that which is not articulated
• Interviews –
• A traditional means of eliciting requirements
• Scenarios –
• Provides a context for elicitation of user requirements
• Asks ‘what if’ and ‘how is this done’ questions
• The most common type of scenario is the use case
• Link to Conceptual Modeling because of scenario
notations such as use cases and diagrams are common
in modeling software
• Prototypes –
• Form paper mock-ups of screen designs to beta-test
versions of software products
• Valuable tool for clarifying unclear requirements
• Overlap for use in requirements elicitation and
requirements validation
• Facilitated meetings –
• A group of people may bring more insight to achieve a
summative effect to the requirements
• Conflicting requirements may surface earlier in this
setting
• Beware of stakeholder politics
• Observation –
• Software engineers are immersed in the environment to
observe the user interact between the software and other
users
• Expensive to implement
• Helps reveal process subtleties and complexities
• Scope (Clause 1)
• Identification
• Document overview
• System overview
• Notes (Clause 9)
• Appendices of the ConOps
• Glossary of the ConOps
A. Observations
B. Scenarios
C. Interviews
D. Prototypes
A. The prototype
B. The use case
C. The facilitator meeting
D. Observation
A. Prototypes
B. Facilitator meetings
C. Interviews
D. Observations
A. Identifier
B. Source
C. Verification procedure
D. Priority
A. Functionality
B. Performance
C. External Interface
D. Complexity
A. Requirements
B. Validation
C. External interfaces
D. Testing
A. External interfaces
B. Performance or functionality
C. Attributes or classification
D. Either design or project requirements
A. “A good operability”
B. “Well enough”
C. “According to Standard X”
D. “Usually acceptable”
A. Consistent
B. Ranked
C. Redundant
D. Verifiable
• Concerned with:
• Recovering the source of requirements
• From software requirement back to system
requirement it supports
• Predicting the effects of requirements
• From system requirement into software requirement
and code modules that satisfy it
A. Requirements tracing
B. Impact analysis
C. Software configuration management
D. System definition