Chapter 4: Use Case Analysis
Chapter 4: Use Case Analysis
Chapter 4: Use Case Analysis
A use case is a document that depicts a set of activities that, when performed, produce a result. It shows
how a system interacts with its environment by illustrating the activities that are performed by the users,
and then the system's response to those activities.
Use cases help us better understand how a process works, and how the user interacts with that process.
Preconditions in a use case define what state the system must be in before the use case can begin.
In a use case, the actor is the person or thing that interacts with the system.
The normal course in a use case is where the major steps are listed. These steps are listed with their inputs
or outputs in a column to the right, with arrows indicating whether they are inputs out outputs.
In a use case, alternative courses are depictions of alternate paths that could be taken from the steps in the
normal course that would still end in a successful completion of the use case.
In a use case, what are postconditions?
In a use case, postconditions are how the system environment should be after a successful completion of
the use case. It defines the "product" of the use case, to a degree.
Exceptions in a use case are error conditions that may occur as the use case steps are performed. They
would prevent the successful completion of the use case.
The final section of a use case should be the inputs and outputs.
What are some examples of additional sections that might be added to use cases?
A fully-dressed use case is one that is exceptionally thorough, detailed, and highly structured.
Use cases are only able to convey the user's point of view, whereas a functional requirement looks at the
system through the developer's eyes, giving more detail as to what the system should do.
Use cases and testing mesh easily. Use cases can be studied early on to determine and create tests for
the system later on.
A process model is a graphical model that is used to further clarify the requirements definition and use
cases, showing how a system should operate. Process models can illustrate either the as-is or to-be
systems.
Examples of a process model would be:
- Data Flow Diagrams
- Logical Process Models
- Physical Models
The four data flow diagram symbols are processes, data flows, data stores, and external entities.
What is a process?
A process is an activity or function that is performed for some specific business reason. Processes can be
manual or automated.
In a data flow diagram, a process should always begin with a verb and end with a noun. They should also
have a number assigned to them. The symbol of a process is a rounded rectangle with a shaded upper
region, where the process number belongs. The unshaded area should contain the process name.
How are data flows represented and named in a data flow diagram?
Data flows are represented by arrows connecting either processes, data stores, or external entities. They
are named after nouns.
How are data stores represented and named in a data flow diagram?
Data stores are represented by a thin rectangle with a small shaded square filling the first 1/5th. Inside this
square, the data flow number (D1, D3, etc) is placed. Following it, the data store name is placed.
Every data store should have a noun-based name, a number, a description, and one or more input and
output data flows.
Data flow diagramming is the technique of diagramming business processes and the data that pass among
them.
A logical process model is a model that describes processes, without worrying about how they are
conducted (in regards to the steps behind the process, if it's manual or computerized, etc).
Why is it that one DFD cannot contain an entirety of a business's processes? How
is this gotten around?
Business processes are far too complex to be explained in any one DFD. This is gotten around by using
decomposition of business processes into multiple DFDs, with lower level DFDs representing a more
granular level of detail.
A context diagram is the very highest level of DFD, and the first DFD in any business process. It is called a
context diagram because it shows the entire system in context with its environment, representing the
overall business process as one process, and showing the data flows in and out of that process to external
entities.
A level 0 data flow diagram is a high-level DFD that shows all the major high-level processes of a system,
and how they are all interrelated, with each other and with the data stores, data flows, and external entities.
A process model will only have one level 0 DFD.
Balancing, in regards to data flow diagrams, is the act of ensuring that all information presented at one level
of data flow diagram is represented accurately at the next levels of DFD.
A level 1 data flow diagram is a subset of the level 0 DFD, decomposed from one of the processes shown
there.
It is worth knowing that the set of children together are identical to their parent DFD. In addition, there are
as many level 1 DFDs as there are processes in the level 0 DFD.
A level 2 data flow diagram is a subset of the level 1 DFD, decomposed from one of the processes shown
there.
It is worth knowing that the set of children together are identical to their parent DFD.
What are alternative data flows, and how are they represented in a data flow diagram?
Alternative data flows are a result when a process can produce different data flows in differing
circumstances. They are represented in a DFD by both being shown, with their differences explained in the
process description.
How are data flow diagrams created? What are the steps needed to build a DFD?
Data flow diagrams are created from consulting use cases and requirements definition. The steps are:
1. Build the context diagram.
2. Create DFD fragments from each use case.
3. Organize the DFD fragments in the level 0 DFD
4. Develop level 1 DFDs based on the steps in each use case. Decompose as necessary
5. Validate DFDs.
A context diagram is a simple thing to create. The system itself is represented by a process symbol, labeled
as "0" and either the process name or system. All inputs and outputs listed on the use cases become data
flows, and all external entities are added in. Data stores are NOT shown.
A data flow diagram fragment is one piece of a data flow diagram that will eventually be combined with
other fragments to form a full DFD. Each use case becomes a fragment, using a name, ID number, and its
major inputs and outputs. Major steps aren't used at this point.
A level 0 DFD is built by combining the data flow diagram fragments together into one diagram. There are
no formal layout rules for a level 0 DFD, save to attempt to prevent crossed lines whenever possible.
Rules of thumb:
There should be at least three and no more than seven processes per DFD. Processes need to be
decomposed until you can provide a detailed description of the process with no more than one page of
description.
Syntax errors in a data flow diagram are grammatical errors, things that violate the rules of DFD language.
Things like having a data flow between two entities between a data store and an entity, without having a
process to do it, or having a double-headed data flow.
A black hole in a DFD is a process, entity, or data store. that has no outputs, only inputs.
Semantics errors in a data flow diagram are any misunderstandings by the analyst in collecting, analyzing,
and reporting information about the system. Basically, something that is misrepresented.
A data model is a formal way of representing the data that are used and created by a business system, and
how those data are related to one another.
An entity-relationship diagram is a graphical illustration that shows the information that is created, stored,
and used by a business system.
What is an attribute?
An attribute is some type of information that is captured about an entity. Attributes are always nouns that
are listed with an entity. Some attributes are unique, and can be serve as the entity's identifier, or primary
key.
An identifier is an attribute of an entity that can be used to identify individual instances of that entity. A
concatenated identifier is a set of attributes that, together, are unique and can serve as an identifier.
A relationship is an association between entities. Each relationship has a parent and a child entity, and
should be labeled with a verb.
Cardinality is the ratio at which parent instances of an entry exist in proportion to child instances. The three
types of cardinality relationships are:
- 1:1 Relationship
- 1:M Relationship
- M:N Relationship
What is modality?
Modality is a way of describing whether or not a relationship is "optional", or whether or not a child entity
can exist without a related instance of the parent entity.
A data dictionary is a document or database that contains the metadata on a data, that is, data about the
data. Information on the entities, attributes, and relationships on the ERD.
An independent entity is an entity that can exist without other entities to support it. Things like cars, pencils,
customers, all exist without the need for other entities.
A dependent entity is an entity that requires attributes from other entities to be identifiable. Things like
"movie ticket" cannot exist without there being a "movie".
An intersection entity is an entity that is created to divide a M:N relationship, allowing for information on
their relationship to be shared.
What is normalization?
Normalization is a technique by which a series of rules are applied to a logical data model (ERD in this
case) to determine how well formed it is.
For an ERD to be in 1NF, no attributes in any entities can contain more than one value for a single
instance. For example, Phone can only contain one phone number, not a work phone AND a cell phone.
In addition, there cannot be any attributes with repeating values. Things like "AUTHOR1", "AUTHOR2", and
so on.
For an ERD to be in 2NF, all non-key attributes must be fully dependent on the entire primary key. This
means that, if there is a composite primary key, all non-key attributes must be dependent on all parts of the
composite key, and not just one.
For an ERD to be in 3NF, it cannot have any transitive functional dependencies. This means that, in a table
with attributes A, B, and C, if B is dependent on A, and C is dependent on B, C is TRANSITIVELY
dependent on A. This is bad.
During the design phase, it is decided HOW the new system will operate, developing system requirements
that will describe, in detail, the new system.
During the design phase, system requirements are modeled after business requirements.
System requirements are communicated through the use of design documents and physical models.
The final deliverable of the design phase is the system specification. It contains many documents, physical
process models, physical data models, architecture design, hardware & software specification, interface
design, data storage design, and program design docs.
What are the three primary ways to approach the creation of a new system?
Custom development, as approached in the design phase, is when a business designs a new system
entirely from scratch.
Packaged software is software that has been designed to meet common business needs. Due to it being
pre-made, buying it and installing it can be done cheaply and quickly. It can then be customized (usually) to
meet a more narrow set of needs.
Packaged software's largest problem is it contains "what it says on the tin". That is, the functionality it
provides is all that you are going to get.
Systems integration is the process of building a new system by combining packaged software with existing
legacy systems, through the use of new software written to integrate them. The biggest challenge with this
is the "translation" of data between software.
An application service provider, or ASP, is a firm that supplies software applications and/or services over
the internet. Software as a Service (SaaS) is an extension of the application service provider "model",
where licences aren't purchased for a particular software; instead, contracts over time for the use of
software are purchased.
How can the business need behind a project direct which development method is
best?
If the business need for the system is common, and the solutions already exist, then packaged software is
the way to go.
If the business need is unique and core to the business, a custom solution is key.
If the business need is unique, but it is not a core part of the company's strategy, outsourcing is
appropriate.
How can in-house experience direct which development method is the best?
If in-house technical experience exists and can handle all the functional and technical needs of the new
system, then go for a custom solution. Otherwise, go for packaged or outsourced.
How does time impact which development method is best-suited for a new
system?
If time is a factor, a pre-packaged solution is generally going to be best. If that isn't available, timeboxing is
a great way to ensure the system is moving ahead swiftly. Outsourcing is generally not a good option with a
short time frame.
What is a Request for Proposal? Request for Information? Request for Quote?
A Request for Proposal (RFP) is a formal document that requests a proposal from a potential
vendor/developer/service provider. They describe in detail the system/service needed. A shorter and less
detailed is the Request for Information. If we know all the equipment we need, then a Request for Quote
may be used.
An alternative matrix is a document that combines several feasibility analyses into one matrix, taking into
account technical, economic, and organizational feasibilities for each system candidate, pros and cons, and
so forth.
An alternative matrix is set up as a grid with alternatives across the top, and criteria along the sides,
occasionally with weights and scores (for a weighted alternative matrix).