Scribd
Upload
20 views15 pages

pbl6 Understand User Requirements

This document discusses key concepts for understanding and developing use cases, including: 1. Identifying user-centric and product-centric requirements and defining use case approaches. 2. Distinguishing between users and actors and drawing use case diagrams. 3. Writing use case specifications, including normal flows, alternatives, exceptions, and pre/post conditions. 4. Applying include and extend relationships and deriving functional requirements from use cases.

Uploaded by

jayomaer
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
20 views15 pages

pbl6 Understand User Requirements

This document discusses key concepts for understanding and developing use cases, including: 1. Identifying user-centric and product-centric requirements and defining use case approaches. 2. Distinguishing between users and actors and drawing use case diagrams. 3. Writing use case specifications, including normal flows, alternatives, exceptions, and pre/post conditions. 4. Applying include and extend relationships and deriving functional requirements from use cases.

Uploaded by

jayomaer
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 15

understand user

requirements
Mosab_2802
objectives

Identify product centric and user centric?


Define use cases approaches
Difference between users and actors
Draw use cases diagram
Write use case specifications for specific system
Difference between pre condition and post condition
Write alternative, normal-flows, exceptions for specific use case
Apply include and extend in use case diagram
Derive functional requirements from use case specification
Identify product centric and user centric?

● The usage-centric strategy emphasizes understanding and exploring user goals to


derive the necessary system functionality.

● The product-centric approach focuses on defining features that you expect will lead to
marketplace or business success
Define use cases approaches

■ Who (or what) is notified when something occurs within the system?
■ Who (or what) provides information or services to the system?
■ Who (or what) helps the system respond to and complete a task?
Difference between users and actors

An actor is a person (or sometimes another software system or a hardware


device) that interacts with the system to perform a use case. For example,
the Chemical Tracking System’s “Request a Chemical” use case involves an
actor named Requester
Draw use cases diagram
Write use case specifications for specific system

● Use case specifications consist of numerous small packets of information: normal and alternative flows, exceptions,
preconditions and post-conditions, and so on. The example in Figure 8-3 illustrates a simple labeling convention
that can help keep these elements straight. Each use case has a sequence number and a meaningful name that
reflects the user’s goal: UC-4 Request a Chemical. The identifier for the normal flow for this use case is 4.0.
Alternative flows are identified by incrementing the number to the right of the decimal, so the first alternative flow
is 4.1, a second would be 4.2, and so on. Both the normal flow and alternative flows can have their own exceptions.
The first exception on the normal flow of use case number 4 would be labeled 4.0.E1. The second exception for the
first alternative flow for this use case would be 4.1
Difference between pre condition and post condition

● Preconditions define prerequisites that must be met before the system can begin executing the use
case. The system should be able to test all preconditions to see if it’s possible to proceed with the
use case. Preconditions could describe the system state, but they don’t describe the user’s intent

● Post conditions describe the state of the system after the use case executed successfully.

Post conditions can describe:


■ Something observable to the user (the system displayed an account balance).
■ Physical outcomes (the ATM has dispensed money and printed a receipt).
■ Internal system state changes (the account has been debited by the amount of a cash withdrawal,
plus any transaction fees).
Write alternative, normal-flows, exceptions for specific use case

One scenario is identified as the normal flow of events for the use case. It’s also called the main flow, basic
flow, normal course, primary scenario, main success scenario, sunny-day scenario, and happy path.

The normal flow for the “Request a Chemical” use case is to request a chemical that’s available in the chemical
stockroom , the normal flow is written as a numbered list of steps, indicating which entity the system or a specific actor
performs each step

alternative flows or secondary scenarios. Alternative flows deliver the same business outcome (sometimes with
variations) as the normal flow but represent less common or lower-priority variations in the specifics of the task or how
it is accomplished. The normal flow can branch off into an alternative flow at some decision point in the dialog
sequence; it might (or might not) rejoin the normal flow later.
The steps in the normal flow indicate where the user can branch into an alternative flow
Conditions that have the potential to prevent a use case from succeeding are called exceptions.
Exceptions describe anticipated error conditions that could occur during execution of the use case and
how they are to be handled. In some cases, the user can recover from an exception, perhaps by re-
entering some data that was incorrect. In other situations, though, the use case must terminate without
reaching its success conditions. One exception for the “Request a Chemical” use case is “Chemical Is
Not Commercially Available,
Apply include and extend in use case diagram

● You can show two types of relationships, called extend and include, between use cases in a use
case diagram. Figure 8-3 showed that the normal flow for the “Request a Chemical” use case is to
request a chemical from the Chemical Stockroom; an alternative flow is to request a chemical
from a vendor. In the use case diagram in Figure 8-2, the Buyer has a use case called “Search
Vendor Catalogs.” Suppose you wanted to let the Requester execute that same “Search Vendor
Catalog” use case as an option when requesting a chemical, as part of the alternative flow
processing.
Apply include and extend in use case diagram

Sometimes several use cases share a common set of steps. To avoid duplicating these steps in each
such use case, you can define a separate use case that contains the shared functionality and indicate
that the other use cases include that subordinate use case. This is analogous to calling a common
subroutine in a computer program. Consider an accounting software package. Two use cases are “Pay
a Bill” and “Reconcile Credit Card,” both of which might involve the user writing a check to make the
payment. You can create a separate use case called “Write a Check” that contains the common steps
involved in writing the check. The two transaction use cases both include the “Write a Check” use
case, as shown with the notation in Figure 8-6. “Write a Check” is a standalone use case, because
that’s another task someone might perform with the accounting software
Derive functional requirements from use case specification

● Software developers don’t implement business requirements or user requirements. They


implement functional requirements, specific bits of system behavior. Some practitioners
regard the use cases as being the functional requirements. However, we have seen many
organizations get into trouble when they simply pass their use cases to developers for
implementation. Use cases describe the user’s perspective, looking at the externally
visible behavior of the system. They don’t contain all the information that a developer
needs to write the software. The user of an ATM doesn’t know about any back-end
processing involved, such as communicating with the bank’s computer. This detail is
invisible to the user, yet the developer needs to know about it. Developers who receive
even fully dressed use cases often have many questions. To reduce this uncertainty,
consider having a BA explicitly specify the functional requirements necessary to
implement each use case
REFRENCES

● Software Requirements, Third Edition /Karl Wiegers Joy Beatty

You might also like