Posts Tagged ‘Validation’

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.


Process for Bug Life Cycle

June 13, 2008 4 comments

Defect Management

June 11, 2008 Leave a comment

Process of Software / System Design (Part 2)

Process of Software / System Design



  1. To describe design goals set.
  2. To define system architecture and detailed design of the system.

Process Requirement:


1. System Architecture:


Entry Criteria: Approved SRS



Ø     On approval of SRS from internally and externally the team which is involved with design activity start to prepare HLD (High Level Design).

Ø     The same as to be review and approved by Project Head / manager

Ø     Refer:


Record Retention: HLD


Exit Criteria: Approved HLD


2. Detailed Design Document:


Entry Criteria: Approved HLD



Ø     On approval of High Level Design, the team involve in the low level design start to prepare (LLD)

Ø     LLD involves web page design and Usability (Navigation)

Ø     The same as to be review and approved by Project Head / manager


Record Retention: LLD


Exit Criteria: Approved LLD


3. Validation


Entry Criteria: HLD & LLD



Ø     Conducting informal reviews and walkthroughs or inspections of the detailed software and data base designs.

Ø     The Critical Design Review (CDR) that completes the software detailed design phase.


Record Retention: HLD & LLD


Exit Criteria: Approved HLD & LLD


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


Implementation of process in SDLC

April 29, 2008 1 comment

Implementation of process in SDLC


As all our previous post is about Software Development Life Cycles, so this is the time to have next few posts is on process implementation in SDLC’s.


Different Phases of SDLC:

  1. Requirement
  2. Design & Coding
  3. Testing
  4. Implementation

Requirement Management:


A requirement is a “function or characteristic of a system that is necessary…the quantifiable and verifiable behaviors that a system must possess and constraints that a system must work within to satisfy an organization’s objectives and solve a set of problems”.


 Similarly, “requirement” has the following definitions [IEEE 90]:


  1. A condition or capability needed by a user to solve a problem or achieve an objective
  2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents
  3. A documented representation of a condition or capability as in (1) or (2).


Different authors will present different definitions, but there are clearly nonfunctional requirements as well as functional requirements. Requirements are classified as follows


  1. Functional requirements


Functional requirements define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs.  These are generally listed, as “shall” statements starting with “The system shall… 


These include:


·        Validity checks on the inputs

·        Exact sequence of operations

·        Responses to abnormal situation, including

·        Overflow

·        Communication facilities

·        Error handling and recovery

·        Effect of parameters

·        Relationship of outputs to inputs, including

·        Input/Output sequences

·        Formulas for input to output conversion


     2.  Nonfunctional requirements


 In systems engineering and requirements engineering, non-functional requirements are requirements, which specify criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that specify specific behavior or functions. Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are “constraints”, “quality attributes”, “quality goals” and “quality of service requirements”. Non-functional requirements can be divided into two main categories.


                                             i.            Execution qualities, such as security and usability, are observable at run time.

                                           ii.            Evolution qualities, such as extensibility and scalability, embody in the static structure of the software system.

Key aspects of the process are:

Requirement Process


a.      Requirement Elicitation


This concerned with where software requirements come from and how the software engineer can collect them. It includes requirement sources and elicitation techniques.



                                                               i.      Elicit requirements from various individual sources;

                                                             ii.      Insure that the needs of all users are consistent and feasible; and

                                                            iii.      Validate that the requirements so derived are an accurate reflection of  user


                   b. Requirement Analysis


The very purpose of the analysis is to identify the requirements in a complete, accurate, consistent, and unambiguous manner.



                                                           i.          Detect and resolve conflicts between requirements

                                                          ii.          Discover the bounds of the software and how it must interact with its environment

                                                        iii.          Elaborate system requirements to software requirements


                  c. Requirement Specification


Requirements specification typically refers to the production of a document, or its electronic equivalent, that can be systematically reviewed, evaluated, and approved. For complex systems, particularly those involving substantial non-software components, as many as three different types of documents are produced:

1.      System definition,

2.      System requirements specification, and

3.      Software requirements specification.



                                                           i.          Preparation of SRS from the requirements collected



                       d. Requirement Validation


Requirements validation is concerned with the process of examining the requirements documents to ensure that they are defining the right system (that is, the system that the user expects). It is subdivided into descriptions of the conduct of requirements reviews, prototyping, and model validation and acceptance tests.



                                                          ii.          Conduct Review Meetings

                                                        iii.          Closing Issues identified in the review meeting

                                                        iv.          Approval & Kick off


                  e. Changes Request Management


On receive of any change list from the client or stakeholders that has to be discussed and reviewed with the team.



                                                           i.          Analysis major and minor changes

                                                          ii.          Made corrections in the SRS on approval of CCB

                                                        iii.          Version updated

                                                        iv.          Moved to production