Posts Tagged ‘Verification’

Business Requirements Vs System Requirements

March 12, 2011 3 comments
S No Business Requirements System Requirements


Business requirements are criteria in order for the software to be successful in meeting the user needs. Generally they focus on the “what” not the “how”. System requirements address the “how” associated with the business requirements (the “what”).


Business requirements concern the business. Software requirements concern the software solution to the “problem” stated in the business requirements.


Business requirements defined as benefits of the business desires. Software requirements define what the solution must do (or be) to assure the business requirements.


Business Requirements are goals and targets the business wants to achieve.

Examples:  No: 1 jobs consultancy company

System Requirements are technical goals

 Example: Implement web based job portal.


Audit Vs Assessment

January 10, 2010 Leave a comment

Audit Vs Assessment

S.No Audit Assessment
1 To verify the conformance of an entity to a given standard. It consists in gathering evidence of conformance or nonconformance. Evaluates the efficiency and/or effectiveness of an entity and results in a measure of its performance with regard to the scope of the assessment.
2 Verification and inspection are synonyms of audit. Appraisal and evaluation are synonyms of assessment.
3 An audit might explicitly point at specific people or groups of people as the cause for noncompliance (attribution). An assessment does not evaluate individuals (non-attribution). Of course, the result of an assessment might still be used to infer responsibility for failure or low scores
4 Example of audit: Verify all the practices established in the organization is followed or not. Example of assessment: Evaluate the CMMI level of an entity.
5 An audit results in a success or a failure An assessment usually provides a score that does not express success or failure

Types, Objectives & Techniques of Review

June 15, 2008 3 comments

Types, Objectives & Techniques

Defect Management

June 11, 2008 Leave a comment

Process for Software Design Phase (Part 1)

May 6, 2008 1 comment

System Overview

 To provide a general description of the software system including its functionality and matters related to the overall system and its design

System Architecture 

  1. To understand how and why the system was decomposed, and how the individual parts work together to provide the desired functionality. At the top-most level, describe the major responsibilities that the software must undertake and the various roles that the system (or portions of the system) must play.
  2. To describe how the system was broken down into its components/subsystems (identifying each top-level component/subsystem and the roles/responsibilities assigned to it).
  3. To describe how the higher-level components collaborate with each other in order to achieve the required results.

 Detailed System Design

  1. To establish a common classification of the component, such as subsystem, module, class, package, function, file, etc.
  2. To know the responsibilities and/or behavior of this component. What does this component accomplish? What roles does it play? What kinds of services does it provide to its clients? For some components, this may need to refer back to the requirements specification.
  3. To know the constraints i.e. any relevant assumptions, limitations, or constraints for this component. This should include constraints on timing, storage, or component state, and might include rules for interacting with this component (encompassing preconditions, post conditions, invariants, other constraints on input or output values and local or global values, data formats and data access, synchronization, exceptions, etc.)
  4. To know the resources utility I.e. a description of any and all resources that are managed, affected, or needed by this entity. Resources are entities external to the design such as memory, processors, printers, databases, or a software library. This should include a discussion of any possible race conditions and/or deadlock situations, and how they might be resolved.
  5. To know the process. I.e. Description of precisely how this component goes about performing the duties necessary to fulfill its responsibilities. This should encompass a description of any algorithms used; changes of state; relevant time or space complexity; concurrency; methods of creation, initialization, and cleanup; and handling of exceptional conditions.

Requirement Management

May 2, 2008 5 comments

Requirement Management



1.      To establish a common acceptance criteria between the Customer and the Project Team on the features and functionalities that are been developed and delivered.

2.      To translating the customer requirements into documented Software Requirements Specification.


Process Requirements:

The following are the process of the requirement management:


1. Elicitation – Identify the Requirements:


Entry Criteria: Business Proposal



  • Activity or Task: On approval of business proposal, the team will have to transform the client needs and expectations captured into formal System/ Software requirements


Mode of Contact:


By Direct Customer Interaction

Record the Customer requirements

Collect necessary materials from the customer

Get clarification on doubts


Customer provided requirement document

Analysis the Customer requirement

Comfortable with the requirement


Requirement against existing Project / Product

Arrange a demo and record the gaps

Feasibility Study

Prepare Gap Analysis document

  • Record Retention: Draft version of SRS


Exit Criteria: Established Requirement


2. Analysis


Entry Criteria: Established Requirement



  • Activities or Task: To identify the requirements in a complete, accurate, consistent, and unambiguous manner.
  • Record Retention: Revised version of SRS


Exit Criteria: Analyzed requirements


3. Prepare Software Requirement Specification (SRS)


Entry Criteria: Analyzed requirements




Exit Criteria: Software Requirement Specification


4. Validation:


Entry Criteria: Software Requirement Specification



  • Activity or Task

1.      The completed SRS document shall be reviewed. The details of the review shall be recorded in the Review Report-Work Product

2.      On closing all the review comments, SRS shall be approved.

  • Record Retention: Review Report (Software Requirement Review (SRR) – Work product


Exit Criteria: Approved Software Requirements Specification


Static Testing Vs Dynamic Testing

April 21, 2008 21 comments


Static Testing

Dynamic Testing


Static testing is a form of software testing where the software isn’t actually used.

In dynamic testing the software must actually be compiled and run.


It is generally not detailed testing, but checks mainly for the sanity of the code, algorithm, or document. It is primarily syntax checking of the code or and manually reading of the code or document to find errors

Dynamic analysis refers to the examination of the physical response from the system to variables that are not constant and change with time


This type of testing can be used by the developer who wrote the code, in isolation. Code reviews, inspections and walkthroughs are also used.


Some of dynamic testing methodologies include unit testing, integration testing, system testing and acceptance testing.


This is the verification portion of Verification and Validation

Dynamic testing is the validation portion of Verification and Validation.



These are verification activites. Code Reviews, inspection and walkthroughs are few of the static testing methodologies.

These are the Validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.