business analysis session 3 industry terms definition
TRANSCRIPT
Session 3.
Industry Terms and DefinitionsRAM N SANGWAN
WWW.RNSANGWAN.COM
YOUTUBE CHANNEL : HTTP://YOUTUBE.COM/USER/THESKILLPEDIA
TO LEARN OR TEACH JOIN WWW.THESKILLPEDIA.COM
1
Agenda• Syntax
• Artifacts
• Declarative Requirement Statement
• Use Cases
• Data Models
• Process Models
• Business Rules
• Intranet
• Project Charter
• Business Model
• Sand Box Environment
2
Syntax in Computer Science
• It refers to the ways symbols may be combined to create well-
formed programs in a computer language.
• It defines the formal relations between the constituents of a
language, thereby providing a structural description of the various
expressions that make up legal strings in the language.
3
Syntax as defined by Morris
In ‘Foundations of the Theory of Signs 1938’ by C.W. Morris, Syntax is
defined within the study of signs as one of its three subfields –
• Syntax - the study of the interrelation of the signs.
• Semantics - the study of the relation between the signs and the objects to
which they apply.
• Pragmatics - the relationship between the sign system and the user.
4
Artifacts
• Observations in a scientific investigation or experiment that is not
naturally present but occurs as a result of the preparative or
investigative procedure.
• Requirements Artifacts:
• Declarative Requirement Statements
• Use Cases
• Data Models
• Process Models
• Business Rules
• Each artifact was adopted to document one aspect of
Requirements…
• Could they be used together?
5
Declarative Requirement Statement
• The Declarative Requirement Statement format is a direct
assertion of one
"...property that is essential for an IT system to perform its functions."
• They are 'declarative' i.e. they do not imply any order or flow upon
the information system.
• Such statements are usually part of a larger group or list of
Requirement Statements, and can be documented at various
levels --- from High-Level Requirements to detailed statements
used as input to Design and as the source of Test Cases.
• The common structure is: “…the System must .”
6
Declarative Requirement Statement Contd..
Variations on the structure include the following:
• Referring to the 'Solution' instead of 'System' as information or other type
of 'System' is not always what is needed to meet the requirements of the
business.
• For instance, Business analysis can identify the need for procedure or
process change
• Variations on the verb "must," such as "shall" or "will."
• A "must" statement is often interpreted as a mandatory requirement, while
statements using other verbs mean the requirement is optional or nice to
have.
• If multiple verbs are used in a set of requirement statements, the specific
meaning of the use of each verb should be clearly defined.
7
Declarative Requirement Statement Examples
“ The System must provide security such that a Manager can view
salary data only for their own reporting staff.”
“The System must calculate the monthly payment for a loan, given
• the Interest Rate,
• the Amount Borrowed,
• the Number of Payments, &
• the Payment Frequency”
8
Use Cases
Two basic types:
1. A multiple-step interaction between actor and system, which relates
to user interface design and captures the required functionality the
system must provide to support the interaction.
2. A single step or occurrence format where an actor initiates the use
case, and it executes a set of actions that produces a result of interest
to the actor. (There may be multiple actors.)
The set of actions that are first defined are those that will normally execute if
no exceptions or other variations occur.
Also known as happy path, as some author or instructor in my past called it.
9
Data Models
• Data models are used to define the data needed for a system to use
and/or control, and they often form the basis for the definition and
creation of databases.
• The most common format used to capture data requirements is
the entity-relationship diagram.
10
Process Models
• As a format for documenting system requirements, process models
can have a negative impact on the resulting system.
• The process as it exists at the time of requirements documentation has
often been "hard-coded" into delivered systems.
• When the process needs to change, the system cannot support a
different process, and the business starts to adapt or create
workarounds to get the work done despite the constraints of the
system.
11
Process Models Contd..
• So, automation of the current business process should not be a
system requirement.
• In fact, more generic process and workflow software have been
developed over the years to specifically support rapid change in
process, adding or changing or reordering process steps as needed.
• These tools are enjoying a new high-profile a Business Process
Management (BPM) products, as companies look for ways to
integrate disparate systems and vendors look for a front-end to
service-oriented architecture (SOA) approaches
12
Business Rules
“A business rule is a statement that defines or constrains some aspect
of the business. It is intended to assert business structure or to control or
influence the behavior of the business. The business rules that concern
(an Information Systems ) project are atomic – that is, they cannot be
broken down further.”
13
Intranets
• Intranet is Intra+ Net so an Intranet is an internal or private Internet
used strictly within the confines of a company, university, or
organization. "Inter" means "between or among," hence the difference
between the Internet and an Intranet.
Some formal definitions of Intranets
• Brown & Duguid: “Intranets help present and circulate boundary
objects”
• Choo, Detlor, & Turnbull: “Intranets… support the creation, sharing, and
use of knowledge”
• Stenmark: “Intranets are organizationally restricted”
14
Project Charter
• Or Simply Charter, is a high-level document used to initiate, propose, define,
and promote the understanding of a project’s business needs and to provide
information supporting the decision to further investigate the need/solution.
• The information is gathered and documented during the Identification phase
of the project and may be refined during the initial phases, subject to
approval of the Project Sponsor. The Charter describes the project's purpose,
goals, scope, impact, cost, and success criteria.
• The Charter is approved by the Project Sponsor and provides the Project
Manager and his/her team with the authority to apply organizational
resources to project activities.
15
Responsibilities
In relation to the Charter:
• The Project Sponsor is accountable for the project and therefore
must make sure that the project has a completed and up-to-date
Charter.
• The Project Owner is responsible for providing all the necessary
information to the Project Manager in completing the project
charter.
• The Project Manager, once assigned, is responsible for creating the
Charter and receiving approval from the Sponsor and the Owner.
The Project Manager is responsible for the maintenance and
updating of the charter.
16
Business Modeling
• A business model is the conceptual structure supporting the viability of a business,
including its purpose, its goals and its ongoing plans for achieving them. or
• A specification describing how an organization fulfills its purpose. All business
processes and policies are part of that model.
• According to management expert Peter Drucker, a business model answers the
questions: Who is your customer, what does the customer value, and how do youdeliver value at an appropriate cost?
• A business model is similar to a business plan in its makeup and content. However,
a business plan specifies all the elements required to demonstrate the feasibility of
a prospective business, while a business model demonstrates the elements that
make an existing business work successfully.
17
Definition - Sandbox
• A sandbox is a type of software testing environment that enables the
isolated execution of software or programs for independent
evaluation, monitoring or testing.
• In an implementation, a sandbox also may be known as a test
server, development server or working directory.
• It isolates untested code changes and outright experimentation from
the production environment or repository, in the context of software
development including Web development and revision control.
18
Types of Sandboxes 19
Types of sandboxes-1. Development.
• This is the working environment of individual developers,
programming pairs, or individual feature teams.
• The purpose of this environment is for the developer/pair/team to
work in seclusion from the rest of their project team, enabling them
to make and validate changes without having to worry about
adversely affecting the rest of their project team.
20
Types of sandboxes-2. Project integration.
• Each project team should have its own integration environment,
often referred to as a build environment or simply a build
box. Developers will promote their changed code to this
environment, test it, and commit it to their teams configuration
management system.
• The goal of this environment is to combine and validate the work
of your entire project team so it can be tested before being
promoted into your Test/QA sandbox.
21
Types of sandboxes-3. Demo sandbox
• This sandbox is where you deploy working software which you can
use to demo software to your stakeholders and they can use
for acceptance testing purposes.
22
Types of sandboxes-4. Pre-production test/QA
• This sandbox is shared by several project teams and is often
controlled by a separate team, typically your testing/QA group.
• This environment is often referred to as a pre-production sandbox, a
system testing area, or simply a staging area.
• Its purpose is to provide an environment that simulates your actual
production environment as closely as possible so you can test your
application in conjunction with other applications.
23
Thankyou
24