The document discusses software engineering concepts related to eliciting requirements and developing use cases. It defines eliciting requirements as collecting requirements through collaborative meetings between developers and customers. Key steps in eliciting requirements include quality function deployment to translate customer needs to technical requirements. Usage scenarios help understand how end users will utilize features. Developing use cases describes them as sequences of user-system interactions to achieve a goal from the user's perspective. Actors represent roles that interact with the system, and user stories provide abbreviated use case descriptions in a problem/solution format.

1. SOFTWARE ENGINEERING
Eliciting Requirements,Developing Use Cases
BY
R.RENUKA

2. ELICITING REQUIREMENTS
Eliciting Requirements
Eliciting requirement helps the user for
collecting the requirement.
Eliciting requirement steps are as follows:
1. Collaborative requirements gathering
2. Quality Function Deployment (QFD)
QFD consist of three types of requirement:
* Normal requirements
*Expected requirement
*Exciting requirements
3. Usage scenarios
4. Elicitation work product

3. 1. Collaborative requirements gathering
 Gathering the requirements by conducting the meetings
between developer and customer.
 Fix the rules for preparation and participation.
 The main motive is to identify the problem, give the
solutions for the elements, negotiate the different
approaches and specify the primary set of solution
requirements in an environment which is valuable for
achieving goal.

4. 2. Quality Function Deployment (QFD)
 In this technique, translate the customer need into the
technical requirement for the software.
 QFD system designs a software according to the demands
of the customer.
QFD consist of three types of requirement:
Normal requirements:
 The objective and goal are stated for the system through
the meetings with the customer.
 For the customer satisfaction these requirements should be
there.

5. Expected requirement
 These requirements are implicit.
 These are the basic requirement that not be clearly told
by the customer, but also the customer expect that
requirement.
Exciting requirements
 These features are beyond the expectation of the
customer.
 The developer adds some additional features or
unexpected feature into the software to make the
customer more satisfied.
For example, the mobile phone with standard features,
but the developer adds few additional functionalities like
voice searching, multi-touch screen etc. then the
customer more exited about that feature.

6. 3. Usage scenarios
 Till the software team does not understand how the
features and function are used by the end users it is
difficult to move technical activities.
 To achieve above problem the software team produces a
set of structure that identify the usage for the software.
 This structure is called as 'Use Cases'.

7. 4. Elicitation work product
 The work product created as a result of requirement
elicitation that is depending on the size of the system or
product to be built.
 The work product consists of a statement need, feasibility,
statement scope for the system.
 It also consists of a list of users participate in the
requirement elicitation.

8. DEVELOPING USE CASES
What is a use case?
• A requirements analysis concept • A case of a use of the
system/product
• Describes the system's actions from a the point of view
of a user
• Tells a story
• A sequence of events involving
• Interactions of a user with the system
• Specifies one aspect of the behavior of a system,
without specifying the structure of the system
• Is oriented toward satisfying a user's goal

9.  How do we describe use cases?
 • Textual or tabular descriptions
 • User stories
 • Diagrams

10. Use Case Descriptions
• actors - something with a behavior or role, e.g., a
person, another system, organization.
• scenario - a specific sequence of actions and
interactions between actors and the system, a.k.a. a use
case instance
• use case - a collection of related success and failure
scenarios, describing actors using the system to support
a goal

11. What is an Actor?
• Include all user roles that interact with the system
• Include system components only if they responsible for
initiating/triggering a use case.
• For example, a timer that triggers sending of an e-mail
reminder
• primary - a user whose goals are fulfilled by the system
• importance: define user goals
• supporting - provides a service (e.g., info) to the system
• importance: clarify external interfaces and protocols
• offstage - has an interest in the behavior but is not primary
or supporting, e.g., government
• importance: ensure all interests (even subtle) are
identified and satisfied

12. FINDING ACTORS [1]
External objects that produce/consume data:
• Must serve as sources and destinations for data
• Must be external to the system
Finding Actors [2]
Ask the following questions:
• Who are the system’s primary users?
• Who requires system support for daily tasks?
• Who are the system’s secondary users?
• What hardware does the system handle?
• Which other (if any) systems interact with the system in
question?
• Do any entities interacting with the system perform multiple
roles as actors?
• Which other entities (human or otherwise) might have an
interest in the system's output?

13. WHAT IS A USER STORY?
•An abbreviated description of a use case
•Used in agile development
Answers 3 questions:
1.Who?
2.Does what?
3.And why?
As a , I want so that

14. ELEMENTS OF USE CASE DIAGRAM:
Actor
• Actor is someone interacting with use case (system
function). Named by noun.
• Similar to the concept of user, but a user can play
different roles; (example: a prof. can be instructor
and researcher – plays 2 roles with two systems).
• Actor triggers use case.
• Actor has responsibility toward the system (inputs),
and Actor have expectations from the system
(outputs).

15. ELEMENTS OF USE CASE DIAGRAM:
Other details Boundary of system <> Include relationship
between Use Cases (one UC must call another; e.g.,
Login UC includes User Authentication UC) <> Extend
relationship between Use Cases (one UC calls Another
under certain condition; think of if-then decision points)