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