Professional Documents
Culture Documents
Business Analyst Study Material
Business Analyst Study Material
Business Analysis
Business Analysis is one of the most important steps in developing a software
solution. It is crucial in identifying the business needs of customers and other
stakeholders in order to determine appropriate solutions to their business
problems.
Who is a Business Analyst?
A software solution needs to address the business requirements of a wide
range of stakeholders. A Business Analyst acts as a liaison between business
people who have a business problem and technology people who know how
to create automated solutions. They act as business problem solvers. A
Business Analyst's main responsibility is to gather, detail, and document
requirements in a format that is appropriate to the technical developers.
They provide the process, questions, and techniques to efficiently extract the
information needed from the Business Users for successful development of
projects.
Business Analysts formulate a customized business solution, taking the
requirements into account. They understand and document business
requirements and work with clients to gather requirements and formulate
business specifications, translating them into application functionality.
A structured business analysis process will consist of the following:
Understanding the business
Analyzing competition
Analyzing the market
Defining and scoping the project
Gathering requirements
Analyzing and documenting requirements
Communicating requirements
Identifying a solution
Verifying that the solution meets the requirements
Understanding the business - The first step in delivering a solution to a
business problem is to understand the business. This involves studying the
following:
The product or service offering of the business
The unique selling proposition (USP) of the business
Validity of the business model and its underlying assumptions
The potential opportunities present in new markets or market
segments
The marketing plan
Analyzing competition The business analysis team studies the
competition. This includes:
The investments made by the competitors in the area of business
The strengths and weakness of the competitors
The products/services and pricing offered by the competitors
Defining and scoping the project - Before he can begin to gather the
actual requirements, a business analyst needs to ensure that the scope of
the project is clear and complete. This involves understanding why the
project has been initiated and the goals of the project. A complete project
scope will name and define all the entities that are involved with the project.
This includes people, systems, internal departments, vendors and customers.
It should also include a high-level description of the business processes that
will be covered as part of the solution and a list of items that will not be
included.
A project scope document includes the following:
Vision and Statement of Purpose
Project Objectives
Project Viewpoint
Project Assumptions
Project External Interactions
Suggestions and Recommendations
Implementation options
Business Risks vs. Rewards
Competition Analysis
During this stage, a business analyst needs the following skills:
People skills to bring diverse groups together to agree on project scope
and build consensus
Ability to clearly document project scope using business terms
Ability to refrain from jumping to a solution before defining the
problem
Gathering requirements - This is one of the most important phases of the
business analysis process. It is absolutely critical that the business analyst
gathers the business requirements accurately before defining a software
solution.
To effectively gather requirements, the business analyst must assess the
type of the project, the people involved and the volume of information
required. Some of the techniques that he can use are:
Interviews with stakeholders
Facilitated information gathering sessions
Surveys and questionnaires
Observation of stakeholders performing their tasks
Study of existing systems and documentation
REQUIREMENTS
There are basically two types of software requirements Functional and
Non-Functional.
Functional Requirements
Functional requirements describe the functionality of the product. They
describe exactly what tasks the software must perform. Functional
requirements define the scope of the system, the product boundaries, and its
connections to adjacent systems. Functional requirements also define the
business rules. Business rules are the rules that the system must conform to,
based on the individual business. This includes defining the data that must be
tracked. The business rules are the most important type of functional
requirements and most of your requirements will be of this type.
Non-Functional Requirements
Non-Functional requirements describe the look and feel of the system. This
includes the visual properties of the system, its usability, and the
performance requirements how big, how fast, etc. Non-Functional
requirements also include the products intended operating environment
and any maintainability, portability and security issues. Non-Functional
requirements also include cultural and political issues as well as legal
requirements that the software must conform to.
Its important to point out that various sources, such as books and Web sites,
describe the different types of software requirements using other categories,
often with contradictory terminology. The important part, however, is not
which category the requirements fall into, but that all the requirements in the
business process have been identified and documented.
So, now that we know what types of information we should be collecting,
lets take a look at the characteristics of good requirements. Good
requirements have the following attributes. They are:
Complete they very thoroughly describe the criteria
Correct they are accurate and true
Feasible they can be accomplished and individual requirements do
not contradict each other.
Necessary they are truly needed for the system to function properly
and they are really what the client wants.
Prioritized in the case that not all parts of the system can be
implemented at the same time, its important to be able to distinguish
absolutely necessary from nice to have.
Unambiguous they are clear and cannot be misinterpreted
Verifiable once implemented, it can be confirmed that the system
has met the requirement through observation and testing
Looking at the above list, its obvious that quality and accuracy are extremely
important. One way to assure quality is to create a single checkpoint that
each requirement must pass through.
Thus, a single person or a group of people must eventually individually
approve every requirement no matter where it originated. Having a single
quality checkpoint is especially important in large or complex projects. In
addition, its vital to make sure that the requirements are not too general,
and that they are comprehensive and completely clear. Keep in mind that the
person collecting the requirements might not always be the same person who
will be writing the actual code.
So, where and how do we find out about the requirements for a system? The
best places are from:
Domain Experts people who are very knowledgeable and work in the
area of the system that is being built
Users people who will actually be the ones using the system once its
built
Existing processes and programs both manual processes and existing
programs
o Find out the limitations of existing systems and software
o Find out where the users time is spent
o Find out what they like and dont like
o Sit down with the users WHILE they are performing their tasks.
Be sure to ask questions to get a clear idea of what they are
doing.
Review similar software programs if there is a similar or competing
program, this can be a great resource
So, now we know what information we are looking for and we know where to
get it. The next items well discuss are the various methodologies for
collecting requirements. These techniques include cards, simple requirement
lists, matrices and templates, as well as complex software programs for
requirements management. Often, a combination of techniques works the
best, since each method has strengths and weaknesses.
One methodology for collecting requirements is to write each requirement on
a separate 5 x 7 index card. Using these cards is an excellent way to begin
the requirements collection process, and the cards have some other
advantages, as well. They are a fast and easy way to group, reorganize and
discard ideas. Additionally, they can easily be sorted and distributed among
different people or groups. There are several different techniques that involve
using these cards CRC cards, XP Story Cards and Volere Snow Cards.
Another technique for collecting requirements involves simply keeping a list
of requirements. As this list grows, it is grouped into logical elements from
the business domain.
Once this list has been compiled, the next step often is to create a
Requirements Trace Matrix. This matrix simply takes the list of
requirements, grouped by category, and puts them into a matrix that has
other information
Finally, a third methodology involves using a predefined template containing
various groups of information about the project. These templates are
extremely useful, since they insure that all the necessary information has
been gathered and that nothing has been overlooked. These templates
contain extensive information about the project the actual requirements
are just a small portion. In addition to sections for various types of
requirements, they also include items such as the vision of the solution, the
scope of the project, the product constraints, success factors and more. If
the list of requirements is large, its useful to create separate documents,
perhaps using requirement trace matrices, for the requirement portion of the
template and reference these external documents within the template.
Software Engineering
Software engineering is the practice of using selected process techniques to
improve the quality of a software development effort. This is based on the
assumption, subject to endless debate and supported by patient experience,
that a methodical approach to software development results in fewer defects
and, therefore, ultimately provides shorter delivery times and better value.
The documented collection of policies, processes and procedures used by a
development team or organization to practice software engineering is called
its software development methodology (SDM) or system development life
cycle (SDLC).
The challenge in selecting and following a methodology is to do it wisely -- to
provide sufficient process disciplines to deliver the quality required for
business success, while avoiding steps that waste time, squander
productivity, demoralize developers, and create useless administrative trivia.
The best approach for applying a methodology is to consider it as a means to
manage risk. You can identify risks by looking at past projects.
If your organization has been plagued by problems resulting from poor
requirements management, then a robust requirements management
methodology would be well advised. Once this problem has been solved,
through a repeatable process, the organization might then streamline its
process, while ensuring that quality is maintained.
Every step along the system development life cycle has its own risks and a
number of available techniques to improve process discipline and resulting
output quality.
Moving through the development life cycle the following major steps might
be encountered:
Project charter and business case
Definition of the business process and business requirements
Documentation of user, functional and system requirements
Top level architecture, technical approach, and system design
System decomposition into component and unit specifications and
design
Coding, unit test planning, and unit test
Generation of test data for unit testing and system testing
System integration and testing
Implementation, delivery and cut-over
Training and user support
System upgrades and routine software maintenance
In addition, there might be support activities throughout the development
effort such as:
Configuration management (version identification, baseline
management and change control)
Requirements management and traceability
Written guidance for all these steps would constitute the core of the
methodology. It wouldn't take long to fill a number of big binders with
development processes and procedures. Hence, the importance of selecting
processes wisely - to address known risks - keeping the methodology
streamlined, and allowing for some discretion on the part of the project
team.
10
11
12
The image below describes the various phases involved in the Software
Development Life Cycle.
Feasibility
The feasibility study is used to determine if the project should get the goahead. If the project is to proceed, the feasibility study will produce a project
plan and budget estimates for the future stages of development.
Requirement Analysis and Design
Analysis gathers the requirements for the system. This stage includes a
detailed study of the business needs of the organization. Options for
changing the business process may be considered. Design focuses on high
level design like, what programs are needed and how are they going to
interact, low-level design (how the individual programs are going to work),
interface design (what are the interfaces going to look like) and data design
(what data will be required). During these phases, the software's overall
structure is defined. Analysis and Design are very crucial in the whole
development cycle. Any glitch in the design phase could be very expensive to
solve in the later stage of the software development. Much care is taken
during this phase. The logical system of the product is developed in this
phase.
Implementation
In this phase the designs are translated into code. Computer programs are
written using a conventional programming language or an application
generator. Programming tools like Compilers, Interpreters, Debuggers are
used to generate the code. Different high level programming languages like
13
C, C++, Java are used for coding. With respect to the type of application, the
right programming language is chosen.
Testing
In this phase the system is tested. Normally programs are written as a series
of individual modules, these subject to separate and detailed test. The
system is then tested as a whole. The separate modules are brought together
and tested as a complete system. The system is tested to ensure that
interfaces between modules work (integration testing), the system works on
the intended platform and with the expected volume of data (volume testing)
and that the system does what the user requires (acceptance/beta testing).
Maintenance
Inevitably the system will need maintenance. Software will definitely undergo
change once it is delivered to the customer. There are many reasons for the
change. Change could happen because of some unexpected input values into
the system. In addition, the changes in the system could directly affect the
software operations. The software should be developed to accommodate
changes that could happen during the post implementation period.
14
SDLC Methodologies
WATERFALL METHODOLOGY
All projects can be managed better when segmented into a hierarchy of
chunks such as phases, stages, activities, tasks and steps. In system
development projects, the simplest rendition of this is called the "waterfall"
methodology, as shown in the following figure:
This presumes that the system requirement have already been defined and
scrubbed exhaustively, which is probably the most important step towards
project success. Nevertheless, the graphic illustrates a few critical principles of a
good methodology:
Work is done in stages,
Content reviews are conducted between stages, and
Reviews represent quality gates and decision points for continuing.
15
16
SPIRAL METHODOLOGY
The spiral methodology reflects the relationship of tasks with rapid
prototyping, increased parallelism, and concurrency in design and build
activities. The spiral method should still be planned methodically, with tasks
and deliverables identified for each step in the spiral.
17
18
PROTOTYPING MODEL
In software development, a prototype is a rudimentary working model of a
product or information system, usually built for demonstration purposes or as
part of the development process. In the systems development life cycle
(SDLC) Prototyping Model, a basic version of the system is built, tested, and
then reworked as necessary until an acceptable prototype is finally achieved
from which the complete system or product can now be developed.
In prototype-based programming, a prototype is an original object; new
objects are created by copying the prototype.
In hardware design, a prototype is a "hand-built" model that represents a
manufactured (easily replicable) product sufficiently for designers to visualize
and test the design.
The word prototype comes from the Latin words proto, meaning original, and
typus, meaning form or model. In a non-technical context, a prototype is an
especially representative example of a given category.
Prototyping is the development of an information system by delivering small
complete parts of a system. With each new implementation the application
provides additional functionality.
19
A prototype is a model, usually the first of its kind, after which future replicas
are produced.
Prototype Strengths
Strong Dialogue between users and developers
Missing functionality can be identified easily
Confusing or difficult functions can be identified
Requirements validation
Quick implementation of, incomplete, but functional, application
May generate specifications for a production application.
Environment to resolve unclear objectives
Project leader is experienced
Encourages innovation and flexible designs
Prototype Weaknesses
Prototype may not be given-up
Prototype may not have sufficient checks and balances incorporated.
Contract may be awarded without rigorous evaluation of Prototype
Identifying non-functional elements difficult to document
Incomplete application may cause application not to be used as the full
system was designed
Incomplete or inadequate problem analysis.
Client may be unknowledgeable
Approval process and requirement is not strict.
Requirements may frequently change significantly
20
Strengths
Greater flexibility for scope changes.
Being able to identify limitations earlier in the development process.
Can deliver partial functionality sooner than with the Waterfall model.
RAD Weaknesses
Not good for large projects. Would require sufficient resources to
create the right number of RAD teams.
Strong commitment required from both the developers as well as the
clients to the rapid-fire activities necessary to get the system
completed in a much-abbreviated time frame.
21
22
23
Testing code is good. Therefore, in XP, tests are written before the code is
written. The code is considered complete when it passes the tests (but then it
needs refactoring to remove complexity). The system is periodically, or
immediately tested using all pre-existing automated tests to assure that it
works. See test-driven development.
XP Controversy
Detailed specifications are not created or preserved.
Programmers are required to work in pairs - not all software developers
expect to be asked to work this way.
There is no Big Design Up Front. Most of the design activity takes place on
the fly and incrementally, starting with "the simplest thing that could possibly
work" and adding complexity only when it's required by failing tests. This
could result in more re-design effort than only re-designing when
requirements change.
A customer representative is attached to the project. This role can become a
single-point-of-failure for the project and some people have found it to be a
source of stress.
24
25
Traceability
A Traceability Matrix is used to show how work products are derived from
their inputs. For example, if the rows of a matrix are labeled with the names
of business activities and the columns are labeled with information needs, an
entry in a cell indicates that the information need was identified from the
intersecting activity.
A Traceability matrix can highlight where unnecessary inputs have not
contributed to the derivation of Work Products and cases where Work
products do not appear to have been derived from the available inputs.
26
27
of the system that is being designed. The UML doesnt really have a
standardized process the notation that is used for drawing the diagrams is
standard, but the process that is followed to create the diagrams is not
actually part of the UML.
Why We Model
Developing a model for an industrial-strength software system prior to its
construction or renovation is as essential as having a blueprint for large
building. Good models are essential for communication among project teams
and to assure architectural soundness. We build models of complex systems
because we cannot comprehend any such system in its entirety. As the
complexity of systems increase, so does the importance of good modeling
techniques. There are many additional factors of a projects success, but
having a rigorous modeling language standard is one essential factor.
A modeling language must include:
Model elements fundamental modeling concepts and semantics
Notation visual rendering of model elements
Guidelines idioms of usage within the trade
In the face of increasingly complex systems, visualization and modeling
become essential. The UML is a well-defined and widely accepted response to
that need. It is the visual modeling language of choice for building objectoriented and component-based systems.
Models are useful for understanding problems, communicating with
everyone involved with the project (customers, domain experts, analysts,
designers, etc.), modeling enterprises, preparing documentation, and
designing programs and databases.
Modeling promotes better understanding of requirements, cleaner designs,
and more maintainable systems.
Models are abstractions that portray the essentials of a complex problem or
structure by filtering out nonessential details, thus making the problem
easier to understand. Abstraction is a fundamental human capability that
permits us to deal with complexity. Engineers, artists, and craftsmen have
built models for thousands of years to try out
designs before executing them. Development of software systems should be
no exception.
To build complex systems, the developer must abstract different views of the
system, build models using precise notations, verify that the models satisfy
the requirements of the system, and gradually add detail to transform the
models into an implementation.
We build models of complex systems because we cannot comprehend such
systems in their entirety. There are limits to the human capacity to
understand complexity. This concept may be seen in the world of
28
architecture. If you want to build a shed in your backyard, you can just start
building; if you want to build a new house, you probably need a blueprint; if
you are building a skyscraper, you definitely need a blueprint. The same is
true in the world of software. Staring at lines of source code or even
analyzing forms in Visual Basic does little to provide the programmer with a
global view of a development project. Constructing a model allows the
designer to focus on the big picture of how a project's components interact,
without having to get bogged down in the specific details of each component.
Increasing complexity, resulting from a highly competitive and ever-changing
business environment, offers unique challenges to system developers. Models
help us organize, visualize, understand, and create complex things. They are
used to help us meet the challenges of developing software today and in the
future.
Development Project Artifacts
The choice of what models and diagrams one creates has a profound
influence upon how a problem is attacked and how a corresponding solution
is shaped. Abstraction, the focus on relevant details while ignoring others, is
a key to learning and communicating. Because of this:
Every complex system is best approached through a small set of
nearly independent views of a model. No single view is sufficient.
Every model may be expressed at different levels of fidelity.
The best models are connected to reality.
In terms of the views of a model, the UML defines the following graphical
diagrams:
Use case diagram
Class diagram
Behavior diagrams:
o State chart diagram
o Activity diagram
Interaction diagrams:
o Sequence diagram
o Collaboration diagram
Implementation diagrams:
o Component diagram
o Deployment diagram
Package diagram
Goals of the UML
The primary design goals of the UML are as follows:
Provide users with a ready-to-use, expressive visual modeling
language to develop and exchange meaningful models.
Furnish extensibility and specialization mechanisms to extend the core
concepts.
Support specifications that are independent of particular programming
languages and development processes.
29
student
Use Cases
Use cases model a dialogue between an actor and the system. They
represent the functionality provided by the system; that is, what capabilities
will be provided to an actor by the system. The collection of use cases for a
system constitute all the defined ways the system may be used.
30
The formal definition for a use case is: A use case is a sequence of
transactions performed by a system that yields a measurable result of values
for a particular actor.
The following questions may be used to help identify the use cases for a
system:
What are the tasks of each actor?
Will any actor create, store, change, remove, or read information in
the system?
What use case will create, store, change, remove, or read this
information?
Will any actor need to inform the system about sudden, external
changes?
Does any actor need to be informed about certain occurrences in the
system?
What use cases will support and maintain the system?
Can all functional requirements be performed by the use cases?
In the UML, a use case is represented as an oval
MaintainSchedule
31
Multiple use cases may share pieces of the same functionality. This
functionality is placed in a separate use case rather than documenting it in
every use case that needs it.
Include relationships are created between the new use case and any other
use case that "uses" its functionality. For example, a Course Registration use
case could start with the verification of the user. This functionality can be
captured in a User Verification use case, which is then used by other use
cases as needed. An include relationship is drawn as a dependency
relationship that points from the base use case to the used use case.
An extend relationship is used to show
Optional behavior
Behavior that is run only under certain conditions such as triggering an
alarm
Several different flows that may be run based on actor selection
An extend relationship is drawn as a dependency relationship that points
from the extension to the base use case.
include
PlaceOrder
include
ValidateOrder
include
TrackOrder
extend
ShipOrder
ShipPartialOrder
What is a Class?
A class is a description of a group of objects with common properties
(attributes), common behavior (operations), common relationships to other
objects, and common semantics. Thus, a class is a template to
create objects. Each object is an instance of some class and objects cannot
be instances of more than one class. For example, the CourseOffering class
may be defined with the following characteristics:
32
States
A state is a condition during the life of an object during which it satisfies
some condition, performs some action, or waits for an event. The state of an
object may be characterized by the value of one or more of the attributes of
the class. For example, a CourseOffering object may be open (able to add a
student) or closed (maximum number of students already assigned to the
CourseOffering object). The state depends upon the number of students
assigned to the particular CourseOffering object. Additionally, a state of an
object may be characterized by the existence of a link to another object. A
professor may be teaching or on sabbatical. This depends upon the existence
of a link to a CourseOffering object. Looking at the state of an object can
validate the multiplicity chosen for a relationship to another object. That is, if
being in a state depends upon the existence of a link to another object, this
implies that the multiplicity of the relationship modifying the role of the
associated class must include zero (i.e., the relationship is optional). Thus,
the states of an object are found by examining the attributes and links
defined for the object.
The UML notation for a state is a rectangle with rounded corners as shown
below.
OpenRegistration
33
Interfaces
An Interface is a collection of operations that specify a service of a class or a
component. An interface describes the externally visible behavior of an
element. An interface might represent the complete behavior of a class or
component or only a part of that behavior. An interface defines a set of
operation specifications but never a set of operation implementations.
IException
Components
A Component is a physical and replaceable part of a system that conforms to
and provides the realization of a set of interfaces. A component typically
represents a physical packaging of otherwise logical elements such as
classes, interfaces and collaborations. Examples of components could be
COM+ components, Java Beans as well as the source code files.
Graphically, a component is represented as a rectangle with tabs, usually
including only its name.
Register.exe
Node
A Node is a physical element that exists at runtime and represents a
computational resource, generally having at least some memory and, often,
processing capability. A set of components may reside on a node and may
also migrate from node to node.
Graphically a node is represented as a cube, usually including only its name.
Database
34
DIAGRAMS IN UML
USE CASE DIAGRAMS
A Use case diagram is a graphical view of some or all of the actors, use
cases, and their interactions identified for a system. Each system typically
has a Main Use Case diagram, which is a picture of the system boundary
(actors) and the major functionality provided by the system (use cases).
Other use case diagrams may be created as needed. Some examples follow:
A diagram showing all the use cases for a selected actor
A diagram showing all the use cases being implemented in an iteration
A diagram showing a use case and all its relationships
They are most valuable on a very large or complex system where the
interaction between Use Cases is not straightforward or easily apparent. Use
Case Diagrams are also especially useful when you have Use Cases that are
subclassed from other Use Cases. The Use Case Diagrams give you an easy
graphical way to display this inheritance.
student
MaintainSchedule
billing system
RequestCourse
Registrar
Professor
MaintainCurriculum
CLASS DIAGRAM
Class Diagrams describe the various types of objects that exist in the system
and the static relationships that exist between them. Class Diagrams also
show the attributes (properties) and the operations (methods) of a class.
35
Class Diagrams allow you to plan how the classes/objects will function and
interact. You find the classes by examining the objects in the sequence and
collaboration diagrams.
The UML modeling elements found in class diagrams include:
Classes and their structure and behavior.
Association, aggregation, dependency, and inheritance relationships.
Multiplicity and navigation indicators
Role names.
STATECHART DIAGRAM
State Diagrams describe the behavior of a system. They show all the possible
states an object can get into, and also how the objects state changes as a
result of events that happen to it. Usually, State Diagrams are drawn to show
the lifetime behavior of a single class. The large black dots indicate the
starting and ending points of the events. State transition diagrams are drawn
for objects that typically have a lot of dynamic behavior.
A state transition may have an action and/or a guard condition associated
with it and may also trigger an event. An action is behavior that occurs when
the state transition occurs.
An event is a message that is sent to another object in the system. A guard
condition is a Boolean expression of attribute values that allows a state
transition only if the condition is true. Both actions and guards are behaviors
of the object and typically become operations. Often, these operations are
privatethat is, they are used only by the object itself.
ACTIVITY DIAGRAMS
Similar to a flow chart, Activity Diagrams describe the sequencing of
activities. They are actually a variant of the State Diagram. Like State
Diagrams, the starting point is indicated with a large black dot. The
horizontal black lines indicate where the object may take one of several
different paths of action. Activity Diagrams are especially useful for objects
which contain a lot of complex logic that you wish to clearly present.
36
CreateCurriculu
m
SelectCourses
CreateCatalog
MailCatalog
PlaceCatalogIn
Library
OpenRegistratio
n
CloseRegistratio
n
37
SEQUENCE DIAGRAMS
Interaction Diagrams show how groups of objects collaborate in some behavior.
Sequence Diagrams are the most common type of Interaction Diagram, and
show an instance of an object and the life of that object. In addition, the
interaction between objects is shown.
Sequence diagrams show object interactions arranged in a time sequence.
: RegistrationForm
: RegistrationManager
: Course1
: student
CompleteForm
Submit
AddStudent
CheckAvailability
COLLABORATION DIAGRAMS
Collaboration Diagrams, like Sequence Diagrams, are also interaction
diagrams. Within the Collaboration Diagram, the objects are shown as icons.
The arrows as well as the numbers (in this case, 1 and 1.1) indicate the
order in which events occur. Collaboration Diagrams are good when you want
to get a quick overview of the general flow of events and object relations.
However, Sequence Diagrams are a better choice when you need to
demonstrate the timing and sequencing of events.
38
1: CompleteForm
2: Submit
: RegistrationForm
: student
3: AddStudent
4: CheckAvailability
: RegistrationManager
: Course1
COMPONENT DIAGRAMS
Component Diagrams show the various components in a system and their
dependencies. The component represents a physical module of code. The
components are often the same as the packages, but they can be different,
since the components represent the physical packaging of code.
The dependencies between the components show how changes in one
component can affect the other components.
DEPLOYMENT DIAGRAMS
Deployment Diagrams show the physical relationship among software and
hardware components in the system. This diagram is a good place to show
how components and objects are routed and how they move around in a
distributed system. Deployment Diagrams really show how the Component
Diagrams interact. Many times, developers will combine the Component and
Deployment Diagrams into a single diagram.
PACKAGE DIAGRAMS
Package Diagrams simply show groups of classes and the dependencies that
exist between them. Package Diagrams are similar to Class Diagrams.
However, instead of showing the individual classes, they show the related
classes grouped together into a unit called a package. A dependency exists
between two packages if any dependency exists between any two classes
inside each package. Package Diagrams can be really useful to obtain an
overview of a large system. Sometimes, developers also choose to display
the individual classes inside the packages.
39
40
41
42
Construction Phase
This phase is broken down into several iterations, fleshing out the
architecture baseline and evolving it in steps or increments towards the final
product. At each iteration, the various artifacts prepared during the
elaboration phase are expanded and revised, but they ultimately stabilize as
the system evolves in correctness and completeness.
New artifacts are produced during this phase beside the software itself:
documentation, both internal and for the end-users, test plans and test
cases, and deployment documents to support the next phase.
For each iteration we have:
Entry criteria:
The product and artifacts of the previous iteration. The iteration plan
must state the iteration specific goals:
Additional capabilities being developed: which use cases or scenarios
will be covered
Risks being mitigated during this iteration
Defects being fixed during the iteration.
Exit criteria:
The same products and artifacts, updated, plus:
A release description document, which captures the results of an
iteration
Test cases and results of the tests conducted on the products,
An iteration plan, detailing the next iteration
Objective measurable evaluation criteria for assessing the results of
the next iteration(s).
Towards the end of the construction phase the following artifacts must be
produced, and are additional exit criteria for the last iteration of the phase:
A deployment plan, specifying as necessary:
Packaging
Pricing
Roll Out
Support
Training
Transition strategy (e.g., an upgrade plan from an existing system)
Production (e.g., making floppies and manuals)
User documentation
Transition Phase
The transition phase is the phase where the product is put in the hands of its
end users. From a technical perspective the iterations continue with one or
more releases, general availability releases, bug fix or enhancement
releases. The phase is completed when the user community is satisfied with
the product: formal acceptance for example in a contractual setting, or when
all activities on this product are terminated. It is the point where some of the
43
44
45
46
47
48
Use cases are identified, representing the behavior of the system. Because
use cases are developed according to the actor's needs, the system is more
likely to be relevant to the users.
Each use case is described in detail. The use-case description shows how the
system interacts step by step with the actors and what the system does.
Non-functional requirements are described in Supplementary Specifications.
The use cases function as a unifying thread throughout the system's
development cycle. The same use-case model is used during requirements
capture, analysis & design, and test.
Analysis & Design
The goal of the Analysis & Design workflow is to show how the system will be
realized in the implementation phase. You want to build a system that:
Performsin a specific implementation environmentthe tasks and
functions specified in the use-case descriptions.
Fulfills all its requirements.
Is structured to be robust (easy to change if and when its functional
requirements change).
Analysis & Design results in a design model and optionally an analysis model.
The design model serves as an abstraction of the source code; that is, the
design model acts as a 'blueprint' of how the source code is structured and
written.
The design model consists of design classes structured into design packages
and design subsystems with well-defined interfaces, representing what will
become components in the implementation. It also contains descriptions of
how objects of these design classes collaborate to perform use cases.
The design activities are centered around the notion of architecture.
Architecture is represented by a number of architectural views. These views
capture the major structural design decisions. In essence, architectural views
are abstractions or simplifications of the entire design, in which important
characteristics are made more visible by leaving details aside. The
architecture is an important vehicle not only for developing a good design
model, but also for increasing the quality of any model built during system
development.
Implementation
The purpose of implementation is:
To define the organization of the code, in terms of implementation
subsystems organized in layers.
To implement classes and objects in terms of components (source
files, binaries, executables, and others).
To test the developed components as units.
To integrate the results produced by individual implementers (or
teams), into an executable system. The system is realized through
implementation of components.
49
The Rational Unified Process describes how you reuse existing components,
or implement new components with well-defined responsibility, making the
system easier to maintain, and increasing the possibilities to reuse.
Components are structured into Implementation Subsystems. Subsystems
take the form of directories, with additional structural or management
information. For example, a subsystem can be created as a directory or a
folder in a file system, or a subsystem in Rational/Apex for C++ or Ada, or
packages using Java.
Test
The purposes of testing are:
To verify the interaction between objects.
To verify the proper integration of all components of the software.
To verify that all requirements have been correctly implemented.
To identify and ensure defects are addressed prior to the deployment
of the software.
The Rational Unified Process proposes an iterative approach, which means
that you test throughout the project. This allows you to find defects as early
as possible, which radically reduces the cost of fixing the defect. Tests are
carried out along three quality dimensions reliability, functionality,
application performance and system performance.
Strategies for when and how to automate test are described. Test
automation is especially important using an iterative approach, to allow
regression testing at then end of each iteration, as well as for each new
version of the product.
Deployment
The purpose of the deployment workflow is to successfully produce product
releases, and deliver the software to its end users. It covers a wide range of
activities including:
Producing external releases of the software.
Packaging the software.
Distributing the software.
Installing the software.
Providing help and assistance to users.
In many cases, this also includes activities such as:
Planning and conduct of beta tests.
Migration of existing software or data.
Formal acceptance.
Although deployment activities are mostly centered around the transition
phase, many of the activities need to be included in earlier phases to prepare
for deployment at the end of the construction phase. The Deployment and
Environment workflows of the Rational Unified Process contain less detail
than other workflows.
50
Project Management
Software Project Management is the art of balancing competing objectives,
managing risk, and overcoming constraints to deliver, successfully, a product
that meets the needs of both customers (the payers of bills) and the users.
The fact that so few projects are unarguably successful is comment enough
on the difficulty of the task.
This workflow focuses mainly on the specific aspect of an iterative
development process.
It is not a recipe for success, but it presents an approach to managing the
project that will markedly improve the odds of delivering successful software.
Configuration & Change Management
In this workflow we describe how to control the numerous artifacts produced
by the many people who work on a common project. Control helps avoid
costly confusion, and ensures that resultant artifacts are not in conflict due to
some of the following kinds of problems:
Simultaneous Update -- When two or more workers work separately on the
same artifact, the last one to make changes destroys the work of the former.
Limited Notification -- When a problem is fixed in artifacts shared by several
developers, and some of them are not notified of the change.
Multiple Versions -- Most large programs are developed in evolutionary
releases. One release could be in customer use, while another is in test, and
the third is still in development.
This workflow provides guidelines for managing multiple variants of evolving
software systems, tracking which versions are used in given software builds,
performing builds of individual programs or entire releases according to userdefined version specifications, and enforcing site-specific development
policies.
This workflow describes how to manage parallel development, development
done at multiple sites, and how to automate the build process. This is
especially important in an iterative process.
This workflow also describes how to can keep an audit trail on why, when
and by whom any artifact was changed. This workflow also covers change
request management, i.e. how to report defects, manage them through their
lifecycle, and how to use defect data to track progress and trends.
Environment
The purpose of the environment workflow is to provide the software
development organization with the software development environmentboth
processes and toolsthat are needed to support the development team.
This workflow focuses on the activities to configure the process in the context
of a project. It also focuses on activities to develop the guidelines needed to
support a project. A step-by-step procedure is provided describing how to
implement a process in an organization.
The environment workflow also contains a Development Kit providing you
with the guidelines, templates and tools necessary to customize the process.
51
52
53
54
medium between the architect and other project team members regarding
architecturally significant decisions, which have been made on the project.
Product Incrementally Build and Test the Product
The essence of the Implementation and Test workflows in RUP is to
incrementally code, build and test the components of the system, with
executable releases at the end of each iteration after inception.
At the end of the elaboration phase, an architectural prototype is available
for evaluation; this might also include a user-interface prototype, if
necessary. Throughout each iteration of the construction phase, components
are integrated into executable, tested builds that evolve into the final
product.
Key to this essential element is an integrated set of test activities that
accompany the building of the product as well as ongoing Configuration
Management and review activities.
Evaluation Regularly Assess Results
The Iteration Assessment captures the results of an iteration, the degree to
which the evaluation criteria were met, the lessons learned and process
changes to be implemented. The Iteration Assessment is an essential artifact
of the iterative approach. Depending on the scope and risk of the project and
the nature of the iteration, it may range from a simple record of
demonstration and outcomes to a complete formal test review record.
Change Requests Manage and Control Changes
The essence of the Configuration and Change Management workflow is to
manage and control the scope of the project, as changes occur throughout
the project lifecycle, while maintaining the goal of considering all stakeholder
needs and meeting those, to whatever extent possible.
As soon as the first prototype is put before the users (and often even before
that), changes will be requested. In order to control those changes and
effectively manage the scope of the project and expectations of the
stakeholders, it is important that all changes to any development artifacts be
proposed through Change Requests and managed with a consistent process.
Change Requests are used to document and track defects, enhancement
requests and any other type of request for a change to the product. The
benefit of Change Requests is that they provide a record of decisions, and,
due to their assessment process, ensure that impacts of the potential change
are understood by all project team members. The Change Requests are
essential for managing the scope of the project, as well as assessing the
impact of proposed changes.
User Support Provide Assistance to the User
At a minimum, this should include a Users Guide, perhaps implemented
through online help, and may also include an Installation Guide and Release
Notes. Depending on the complexity of the product, training materials may
also be needed, as well as a bill of materials along with any product
packaging.
55
Rational SoDA
Overview
56
Rational ClearQuest
Overview
Rational ClearCase
Overview
57
o
o
Linux
Mainframe
58
Templates
Functional Specifications Document
Table of Contents
1. INTRODUCTION................................................................... 7
1.1.
1.2.
1.3.
1.4.
1.5.
1.6.
4. PRODUCT FUNCTIONALITY................................................. 26
4.1. USE CASE1 ................................................................................. 26
4.1.1. Related Use Case / Shared Service..................................... 26
4.1.2. Preconditions / Prerequisites............................................. 26
4.1.3. Primary Scenario............................................................. 26
4.1.4. Secondary Scenario......................................................... 27
4.1.5. Post Conditions............................................................... 27
4.1.6. Special Requirements....................................................... 28
4.1.7. Use Case Diagram........................................................... 28
4.1.8. Screen Layout................................................................. 29
4.1.9. Data Field Definitions....................................................... 30
4.1.10. Business Rules .............................................................. 32
4.2. USE CASE2 ................................................................................. 33
4.2.1. Related Use Case / Shared Service..................................... 33
4.2.2. Preconditions / Prerequisites............................................. 33
4.2.3. Primary Scenario............................................................. 33
4.2.4. Secondary Scenario......................................................... 34
4.2.5. Post Conditions............................................................... 34
4.2.6. Special Requirements....................................................... 34
4.2.7. Use Case Diagram........................................................... 35
4.2.8. Screen Layout................................................................. 36
4.2.9. Data Field Definitions....................................................... 37
59
6.
7.
8.
9.
PERFORMANCE................................................................... 78
RISKS................................................................................. 78
OPEN ITEMS.................................................................... 79
APPROVALS ....................................................................... 80
60
Primary Actors.1
Secondary Actors..2
3.
Flow of Events1
4.
5.
6.
Special Requirements3
Pre-Conditions..3
Post-Conditions .3
3.1
3.2
Basic Flow..1
Alternative Flows..2
61
Architecture Document
Table of Contents
1. BUSINESS OVERVIEW........................................................ 6
1.1.
1.2.
1.3.
1.4.
1.5.
Business Background................................................................... 6
Scope........................................................................................ 6
Definitions, Acronyms, Abbreviations.............................................. 7
References.................................................................................. 9
Architecturally Significant Process and Use Cases............................. 9
1.5.1. Use Case1..................................................................... 10
1.5.2. Use Case2..................................................................... 11
1.5.3. Use Case3......................................................................12
1.6. Architecturally Significant Non Functional Requirements................... 14
1.6.1. Data Requirements......................................................... 14
1.6.2. Performance Requirements.............................................. 14
1.6.3. Integration Requirements................................................ 14
3. SYSTEM ARCHITECTURE..................................................... 24
3.1. Logical Architecture...................................................................... 24
3.1.1 Logical Component Architecture........................................ 24
3.1.2 Logical System Architecture............................................. 24
3.1.3 Data Flow...................................................................... 25
3.2. Physical Architecture..................................................................... 26
3.2.1 Physical Architecture Diagram........................................... 26
3.2.2 Hardware Requirements................................................... 26
3.2.3 Software........................................................................ 27
3.2.4 Network......................................................................... 27
3.2.5 Domain Information........................................................ 28
3.3. Design Elements.......................................................................... 28
3.3.1 Availability..................................................................... 28
3.3.2 Sizing............................................................................ 28
3.3.3 Scalability Options........................................................... 28
3.3.4 Failure Points.................................................................. 29
3.3.5 Backup and Recovery...................................................... 29
62
4. SUPPORT SERVICES........................................................... 30
4.1. Client and Web Services................................................................ 30
4.1.1 Application Access Request............................................... 30
4.1.2 User Setup Request......................................................... 30
4.1.3 Online Help / internal Requirements.................................. 30
4.2. System Support........................................................................... 31
4.2.1 Help Desk...................................................................... 31
4.2.2 Customer Service............................................................ 31
5. APPROVALS ....................................................................... 32
63
Table of Contents
1. INTRODUCTION....................................................................5
1.1 PROJECT OVERVIEW........................................................................5
1.2 SCOPE...........................................................................................5
1.3 REFERENCES..................................................................................5
STRUCTURE...................................................................................7
DIRECTORIES, PACKAGES, AND NAMING CONVENTIONS.....................7
DIRECTORY STRUCTURE ..................................................................7
PACKAGE STRUCTURE.....................................................................8
OTHER NAMING STANDARDS...........................................................8
COMPONENTS................................................................................8
USE
USE
USE
USE
CASE1...................................................................................
CASE2...................................................................................
CASE3...................................................................................
CASE4...................................................................................
11
14
18
23
4. DATA VIEW.........................................................................37
4.1 DATABASE TABLES........................................................................37
4.2 TABLE DEFINITIONS.......................................................................37
4.3 STORED PROCEDURE DEFINITIONS..................................................37
4.3.1 STORED PROCEDURE1.......................................................37
4.3.2 STORED PROCEDURE2.......................................................37
4.4 PERSISTENCE METHODOLOGY.........................................................38
5. DEPLOYMENT VIEW.............................................................39
5.1 INSTALLATION REQUIREMENTS .......................................................39
5.2 MAINTENANCE CONSIDERATIONS....................................................39
5.2.1 SECURITY........................................................................39
5.2.2 AUTHENTICATION.............................................................39
5.2.3 AUTHORIZATION (ACCESS CONTROL) ................................39
5.2.4 LOGGING.........................................................................39
6. IMPLEMENTATION VIEW.....................................................40
6.1
6.2
6.3
6.4
SERVERS.....................................................................................40
SOFTWARE...................................................................................40
NETWORK ....................................................................................40
IMPLEMENTATION DIAGRAM............................................................41
64
65
2. TEST COVERAGE...................................................................4
2.1
2.2
2.3
2.4
2.5
2.6
3. APPENDIX.............................................................................8
66
What is SQL?
SQL
SQL
SQL
SQL
SQL
SQL
SQL
SQL
FirstName
BBB
DDD
FFF
Address
123 Street
456 Street
789 Street
City
New York
Princeton
Trenton
The table above contains three records (one for each person) and four
columns (LastName, FirstName, Address, and City).
SQL Queries
With SQL, we can query a database and have a result set returned.
A query like this:
SELECT LastName FROM Persons
Gives a result set like this:
LastName
AAA
CCC
EEE
67
68
To select all columns from the "Persons" table, use a * symbol instead of
column names, like this:
SELECT * FROM Persons
69
Using Quotes
SQL uses single quotes around text values (most database systems will also
accept double quotes). Numeric values should not be enclosed in quotes.
The LIKE Condition
The LIKE condition is used to specify a search for a pattern in a column.
Syntax
SELECT column FROM table WHERE column LIKE pattern
A "%" sign can be used to define wildcards (missing letters in the
pattern) both before and after the pattern.
Using LIKE
The following SQL statement will return persons with first names that start
with an 'A':
SELECT * FROM Persons WHERE FirstName LIKE 'A%'
The following SQL statement will return persons with first names that end
with an 'A':
SELECT * FROM Persons WHERE FirstName LIKE '%A'
70
71
Syntax
Use AND to display each person with the first name equal to "AAA", and the
last name equal to "BBB":
SELECT * FROM Persons
WHERE FirstName='AAA'
AND LastName='BBB'
Syntax
Use OR to display each person with the first name equal to "AAA", or the last
name equal to "BBB":
SELECT * FROM Persons
WHERE firstname='AAA'
OR lastname='BBB'
IN
The IN operator may be used if you know the exact value you want to return
for at least one of the columns.
SELECT column_name FROM table_name
WHERE column_name IN (value1,value2,..)
ALIASES
With SQL, aliases can be used for column names and table names.
Column Name Alias
The syntax is:
SELECT column AS column_alias FROM table
Table Name Alias
The syntax is:
72
Name
AAA, BBB
CCC, DDD
EEE, FFF
GGG, HHH
Product
Printer
Monitor
Mouse
Keyboard
Employee_ID
01
03
03
04
73
WHERE Employees.Employee_ID=Orders.Employee_ID
Example
Who ordered a keyboard?
SELECT Employees.Name
FROM Employees, Orders
WHERE Employees.Employee_ID=Orders.Employee_ID
AND Orders.Product='Keyboard'
Aggregate functions
Aggregate functions operate against a collection of values, but return a single
value. When used among many other expressions in the item list of a SELECT
statement, the SELECT must have a GROUP BY clause.
Some of the most commonly used Aggregate functions are
Function
Description
AVG(column)
Returns the average value of a column
COUNT(column)
Returns the number of rows (without a NULL
value) of a column
COUNT(*)
Returns the number of selected rows
FIRST(column)
Returns the value of the first record in a specified
field
LAST(column)
Returns the value of the last record in a specified
field
MAX(column)
Returns the highest value of a column
MIN(column)
Returns the lowest value of a column
SUM(column)
Returns the total sum of a column
74
Scalar functions
Scalar functions operate against a single value, and return a single value
based on the input value. Scalar functions differ from database to database.
Some of the most commonly used Scalar functions in MS Access are
Function
Description
UCASE(c)
Converts a field to upper case
LCASE(c)
Converts a field to lower case
MID(c,start[,end])
Extract characters from a text field
LEN(c)
Returns the length of a text field
INSTR(c)
Returns the numeric position of a named
character within a text field
LEFT(c,number_of_char) Return the left part of a text field requested
RIGHT(c,number_of_char) Return the right part of a text field requested
ROUND(c,decimals)
Rounds a numeric field to the number of decimals
specified
MOD(x,y)
Returns the remainder of a division operation
NOW()
Returns the current system date
FORMAT(c,format)
Changes the way a field is displayed
DATEDIFF(d,date1,date2) Used to perform date calculations
GROUP BY...
GROUP BY... was added to SQL because aggregate functions (like SUM)
return the aggregate of all column values every time they are called, and
without the GROUP BY function it was impossible to find the sum for each
individual group of column values.
The syntax for the GROUP BY function is:
SELECT column,SUM(column) FROM table GROUP BY column
HAVING...
HAVING... was added to SQL because the WHERE keyword could not be used
against aggregate functions (like SUM), and without HAVING... it would be
impossible to test for result conditions.
The syntax for the HAVING function is:
SELECT column,SUM(column) FROM table
GROUP BY column
HAVING SUM(column) condition value
75