Home > Software Development Life Cycle > Implementation of process in SDLC

Implementation of process in SDLC

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


  1. Dwayne
    January 22, 2015 at 10:06 pm

    I like the helpful information you provide iin your articles.
    I’ll bookmark your blog and cjeck again here frequently.
    I’m quite sure I’ll learn plenty of new stuuff right here!
    Good luck for tthe next!

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: