SDP RE2 Rys1-7

Requirement Engineering Tasks
ATM
Basic Questionaries
1.INCEPTION
Requirements engineer asks a set of

questions to establish
A basic understanding of the problem
Target People (WHO)
Nature of the solution (WHAT)
The effectiveness of preliminary communication
and collaboration between the customer and the
developer
Requirement Engineer Need to find
These questions enable the requirements engineer to gain a better
understanding of the problem and allow the customer to voice his or her
perceptions about a solution
How would you characterize "good" output that

would be generated by a successful solution?
What problem(s) will this solution address?
Can you show me (or describe) the business
environment in which the solution will be used?
Will special performance issues or constraints
affect the way the solution is approached?
ELICITATION(Extraction)
Eliciting requirements is difficult because of
Problems of scope
Problems of understanding
Problems of volatility
Elicitation may be accomplished through two
activities
Collaborative requirements gathering
Quality function deployment
Quality Function Deployment
This is a technique that translates the needs of the
customer into technical requirements for software
Valuable Requirements to customers can deploy
through Tasks, functions and information.
It identifies three requirements:
Normal Requirements
Expected Requirements
Exciting Requirements
If you dont note correct points,
Elicitation Process Guideline
Meetings conduction for both software engineers and
customers
Rules for preparation and participation are established
Agenda suggestion
Facilitator (can be a customer, a developer, or an
outsider) to control meeting
Definition mechanism (can be work sheets, flip
charts, or wall stickers or an electronic bulletin board,
chat room or virtual forum) is used
to identify the problem
propose elements of the solution
negotiate different approaches, and
specify a preliminary set of solution requirements
Elaboration (Explaination)
This is an analyzing phase
Use cases
Classes and objects decision
Take the information during inception and
elicitation and expand and refine it.
Developing a refined technical model of
software functions, features, and constraints
Analysis Model
Questions Used in Use cases
Who is the primary actor(s), the secondary actor(s)?
What are the actors goals?
What preconditions should exist before the scenario begins?
What main tasks or functions are performed by the actor?
What exceptions might be considered as the scenario is
described?
What variations in the actors interaction are possible?
What system information will the actor acquire, produce, or
change?
Will the actor have to inform the system about changes in the
external environment?
What information does the actor desire from the system?
Does the actor wish to be informed about unexpected changes?
Elements in Analysis Model
Scenario-based elements (Use case)
Class-based elements (Class Diagram)
Behavioral elements (Use state Diagram)
Flow-oriented elements (Data Flow Diagram)
Negotiation (Cooperation)
Requirement gathering analysis
Risks and Reconciling
Ranking for requirements by user,
stakeholders, Developers
Guesses about modification.
Art of Negotiation
Recognize that it is not competition
Map out a strategy
Listen actively
Focus on the other partys interests
Dont let it get personal
Be creative
Be ready to commit
Specification
It formalizes the informational,
functional, and behavioral
requirements of the proposed software
in both a graphical and textual format
Final Work product
Content for SRS
Requirements
Required states and modes
Software requirements grouped by capabilities (i.e., functions,
objects)
external interface requirements
internal interface requirements
data requirements
Other (safety, security, privacy, environment, hardware, software,
communications, quality, personnel, training, logistics, etc.)
Design and implementation constraints
Qualification provisions
Demonstration, test, analysis, inspection, etc.
Requirements traceability
Trace back to the system or subsystem where each requirement
applies
Users of SRS document
Properties of a good SRS document
Concise
Structured
Black-box view.
Conceptual integrity
Response to undesired events.
Verifiable
Validation
Unambiguity
Technical Reviews from stakeholders
Checkpoints
Validity
Consistency
Completeness
Realism
Verifiability
Requirement Managemnt
Requirements traceability table
Identify control track
Requirement Engineering Process
Inception,
Elicitation
Specificatio Elaboration
n, Validation
Negotiati
on
Spiral View of Process

SDP RE2 Rys1-7

Uploaded by

Copyright:

Available Formats

SDP RE2 Rys1-7

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SDP RE2 Rys1-7

Uploaded by

Copyright:

Available Formats

Requirement Engineering Tasks

Requirements engineer asks a set of

How would you characterize "good" output that

You might also like