Software Engineering - SDLC V-Model
Software Engineering - SDLC V-Model
Table of Contents
1. Principle of V-Model 3
1.1. V-Model Design 5
1.2. Verification Phases 6
1.2. Validation Phases 6
2. Requirements analysis 7
2.1. Business Requirement Specification (BRS)/Customer Requirement Specification
(CRS) 7
2.1.1. Importance of writing a BRS/CRS document 8
2.1.2. Writing a BRS/CRS document 8
2.1.2.1. Information to put in BRS/CRS 8
2.1.2.2. Steps of writing BRS/CRS 9
2.1.2.3. BRS Templates 11
2.2. Acceptance Test Design Plan 11
2.2.1. 11
2
Software Engineering - SDLC V-Model
1. Principle of V-Model
● Type of SDLC (Software Development Life Cycle) where the process executes in a
sequential manner in V-shape. Also known as Verification and Validation model.
● Based on the association of a testing phase for each corresponding development
stage. The next phase starts only after completion of the previous phase. ie. for each
development activity, there is a testing activity corresponding to it.
● Software Development Life Cycle (SDLC) model
○ Provides a systematic and visual representation of the SW development
process.
○ Based on the idea of a “V” shape, representing the progression of the
● Large to Small
○ Testing is done in a hierarchical perspective
○ Requirements identified →Create HLD/Detail Design phases of the project
○ As each of these phases is completed the requirements, they are defining
become more and more refined and detailed.
● Data/Process Integrity
○ Successful design of any project requires the incorporation and cohesion of
both data and processes.
○ Process elements must be identified at each and every requirement.
● Scalability
○ Flexibility to accommodate any project irrespective of its size, complexity or
duration.
● Cross Referencing
○ Direct correlation between requirement and corresponding testing activity
● Tangible Documentation
○ Every project needs to create a document
○ Required and applied by both the project development team and the support
team.
○ Used to maintaining the application once it is available in a production
environment.
● Why preferred
○ Easy to manage due to the rigidity of the model
○ Each phase has specific deliverables and a review process
○ Proactive defect tracking
○ Defects founded at early stage
● When to use
○ Where requirements are clearly defined and fixed
○ When ample technical resources are available with technical expertise
● Advantages
○ Highly disciplined model (Phases are completed one at a time)
○ Used for small projects where project requirements are clear
○ Simple and easy to understand and use
○ Focus on verification and validation activities early in the life cycle
⤷ Enhancing the probability of building an error-free and good quality product
3
Software Engineering - SDLC V-Model
○ Enables project management to track progress accurately
○ Clear and Structure Process for SW development
⤷ Make it easier to understand and follow
○ Strong emphasis on testing
⤷ Helps to ensure the quality and reliability of the SW
○ Provides a clear link between the requirements and the final product
⤷ Make it easier to trace and manage changes to the SW
○ Helps to improve communication between the customer and the development
team
● Disadvantages
○ High risk and uncertainty
○ Not a good for complex and object-oriented projects
○ Not suitable for projects where requirements are not clear and contains high
risk of changing
○ Does not support iteration of phases
○ Inflexibility: Linear and sequential model
⤷ can make it difficult to adapt to changing requirements or unexpected
events
○ Time-consuming: Requires a lot of documentation and testing
○ Overreliance on Documentation: Strong emphasis on documentation
⤷ can lead to an overreliance on documentation at the expense of actual
development work
4
Software Engineering - SDLC V-Model
1.1. V-Model Design
The V-Model is a linear and sequential model that consists of the following phases:
● Requirement Gathering and Analysis
1st phase of the V-Model ⇒ Requirement Gathering and Analysis
⤷ Customer’s requirement for SW are gathered and analyzed to determine
the scope of the project.
● Design
Are developed:
■ SW architecture
■ SW design
■ High-level design
■ Detailed design
● Implementing
The SW is actually built based on the design.
● Testing
The SW is tested to ensure that it meets the customer’s requirements and is
of high quality.
● Deployment
The SW is deployed and put into use.
● Maintenance
The SW is maintained to ensure that it continues to meet the customer’s
needs and expectations.
5
Software Engineering - SDLC V-Model
● The V-Model is often used in safety-critical systems, such as aerospace and
defense system, because of its emphasis on thorough testing and its ability to
clearly define the steps involved in the SW development process
1.2. Verification Phases
● Static analysis technique (review) done without executing code.
● Process of evaluation of the product development phase
⤷ Find whether specified requirements meet.
● Design Phase:
○ Require Design
This phase contains detailed communication with the customer to
understand their requirements and expectations. (Requirement
Gathering)
○ System Design
This phase contains the system design and the complete hardware
and communication setup for developing the product.
○ Architectural Design
System design is broken down further into modules taking up different
functionalities. The data transfer and communication between the
internal modules and with the outside world (other systems) is clearly
understood (High-Level Design HLD)
○ Module Design
In this phase, the system breaks downs into small modules. The
detailed design of module is specified (Low-Level Design - LLD)
1.2. Validation Phases
● Dynamic analysis technique (functional, non-functional), testing done by executing
code.
● Process to evaluate the completion of the development phase
⤷ Determine whether SW meets the customer expectations and requirements
● Testing Phase:
○ Unit Testing
Unit Test Plans are developed during the module design phase. These
Unit Test Plans are executed to eliminate bugs at code or unit level.
○ Integration Testing
After completion of unit testing integration is performed. The modules
are integrated and the system is tested. Integration testing is
performed in the Architecture Design phase. This test verifies the
communication of modules among themselves.
○ System Testing
Test the complete application with its functionality, inter-dependency,
and communication. It tests the functional and non-functional
requirements of the developed application.
○ User Acceptance Testing (UAT)
6
Software Engineering - SDLC V-Model
UIT is performed in a user environment that resembles the production
environment. It verifies that the delivered system meets the user's
requirement and the system is ready for use in the real world.
2. Requirements analysis
● 1st step of the validation phases
● The requirements of the proposed system are collected by analyzing the need of the
user(s)
● Establishing what the ideal system has to perform.
● Does not determine how the SW will be designed or built
● Users are interviewed then the user requirements document is generated
⤷ Describe:
○ System’s functional
○ Physical
○ Interface
○ Performance
○ Data
○ Security requirements
○ Etc…
● It is one which the business analysts use to communicate their understanding of the
system back to the users
● This document would serve as the guideline for the system designers in the system
design phase
● User acceptance tests are designed in this phase
● Formal documents:
○ Business Requirement Specification (BRS) / Customer Requirement
Specification (CRS)
○ User Acceptance Testing (UAT)
2.1. Business Requirement Specification (BRS)/Customer
Requirement Specification (CRS)
● A widely acceptable specification document
● Aims to show how to meet the business requirements on a broader level
● Offer business solutions for specific projects
● At the beginning of the product’s lifecycle, the client and the business analyst
cooperate to build the BRS/CRS
● Describes at very high level the functional specification of the SW
● Should be so self-explanatory that it removes any ambiguity associated with the
project work (Nobody is left guessing)
● Everything they need is listed in the business requirement document
● This document includes:
○ The product’s goals which are based on the stakeholders’ specifications
7
Software Engineering - SDLC V-Model
○ The product users’ expectations and needs
○ The overall scope of work
○ All the features and functions of the product
○ Usability and performance requirements
○ Any high-level constraints that can impact a successful deployment
2.1.1. Importance of writing a BRS/CRS document
● Is the foundation of a successful project
● Describe the problems and solutions
● Highlight the required outcomes to deliver necessary values
● Keeps everyone involved in the project on the same page and directs the
development team towards the same goal
2.1.2.Writing a BRS/CRS document
2.1.2.1. Information to put in BRS/CRS
● An executive summary:
○ Write this summary after completing the rest of the document
○ This high-level should outline the project requirement
○ Should summarize the following contents of the document
● Project objectives:
○ Describe the project’s goals and objectives
○ Mention what the work will achieve
○ What are the outcomes?
○ How does the project align with the goal of the business?
○ Use SMART system for project objectives
■ To simplify this product management roadmap
■ Ensure it’s succinct
● A need statement:
○ This is where you make your case as to why the project is needed
○ Provide rational and garnering support from stakeholders and employees
● Project scope
○ Why is scope management important?
○ Successful projects communicate the work scope from the beginning and stay
within the defined boundaries unless otherwise instructed
○ Clear project scope will help avoid dreaded scope creep
○ Find a scoping document template that works for you to clearly lay out your
project scope
● Requirements
○ After requirements gathering with key stakeholders, you’ll need to summarize
all of the project’s requirements in this section
○ Be mindful of high-level requirements like the “what”, as well as technical
requirements like the “how”
● Key stakeholders:
○ Identify the stakeholders involved in the project
8
Software Engineering - SDLC V-Model
○ Lay out their roles and responsibilities
○ Who will do the work?
○ What are the expectations of each stakeholder?
○ Will the business need to hire any additional resources?
● Schedule, timeline, and milestone deadlines:
○ Detail the project phases
○ Carefully outlining what is requirements and when
○ Create timelines and account for dependencies
○ Create unforeseen challenges that could arise
● Cost-benefit analysis:
○ Is where you’ll capture the associated costs involved in the project along with
the expected benefits to help you build a case for return on investment (ROI)
of the project
2.1.2.2. Steps of writing BRS/CRS
● Start by learning from previous successful projects
○ If starting feels daunting, spend some time reviewing successful past projects
○ Look at the documentation associated with these projects
○ Use your insights to outline your new business requirements documents
○ Some elements to consider as you review previous documentation include:
■ What worked well
■ What didn’t work
■ Hurdles the project team had to overcome
■ Dependencies that might affect your current project
■ Elicitation methods used during the requirements-gathering phase
● Capture your requirements
○ This may consist of many different types of requirements ranging from
high-level to technical
○ Won’t be effective without gathering and capturing all stakeholders’
requirements accordingly
○ Commonly used requirements elicitation methods:
■ Brainstorming:
● Bring your stakeholders together
● Elicit ideas and themes
● May be beneficial if there are multiple solutions identified
■ Document analysis:
● Review all existing documentation pertinent to the project
● Including previous documentation for successful projects
■ Focus groups:
● Identify stakeholders to gather input from them on a smaller
scale
● You can dig into the proposed solution further with
pre-determined stakeholders than you would in a
brainstorming session
■ Interface analysis:
● Particularly beneficial for SW solution
● Involves user interactions with an application
9
Software Engineering - SDLC V-Model
■ Interviews:
● One-on-one interviews are a popular way to gather input for
requirements
● Hone in on the stakeholder’s thoughts and perspectives
related to the project and potential solutions
■ Observation:
● Beneficial when revamping a process or workflow
● When observing a worker’s process or workflow, be mindful
not to interrupt them. Instead, ask them to review your
documentation post-observation
■ Prototyping:
● Great way to ensure that the current requirements meet all
stakeholders’ needs
● Can illustrate how a solution might work and help to determine
if requirements should be altered
■ Requirements workshops
● Conduct collaborative workshops with your stakeholders to
outline requirements together
● Generally have more direction than brainstorming sessions
with pre-determined asks of each stakeholder specified at the
beginning
■ Surveys/questionnaires:
● Can help if you’re looking to obtain feedback from a larger
group of stakeholders
● Question design is important
● Be sure to determine how best to pose questions to gather the
information you need
● Use clear, jargon-free language
○ Can often be long-winded and heavily detailed, making them difficult for your
team members to follow and understand
○ Will be viewed by lots of different stakeholders in various roles
○ Not everyone will understand technical text
○ No need to include heavy jargon
○ Try and keep your language clear, relatable and concise
○ Include a glossary of terms at the end of your document so that any technical
terms can easily be found and misunderstandings can be avoided
● Add visual elements to make content more digestible
○ Visuals and surrounding context can increase your plan’s effectiveness and
break up text heavy chunks of information
○ Research indicates that 65% of the population are visual learners
⤷ Incorporating visuals in your document can help you convey your message
and plan in a more compelling way
○ For example, a business process diagram is a typical visual seen in a
business requirements document.
○ Mapping out business processes in their current state versus the proposed
future state can help communicate requirements with ease
● Ask team members to review your document
○ Ask stakeholders to review it and validate it
10
Software Engineering - SDLC V-Model
○ Provides the opportunity for you to confirm you’ve captured all of the
requirements accordingly and offers a chance for stakeholders to provide
feedback and make changes before the project begins
○ Completing a review process also contributes to overall alignment, setting
your team up for success from the get-go
2.1.2.3. BRS Templates
BRS Document Template 1
2.2. Acceptance Test Design Plan
● Include some components like:
○ Scope
○ Approach
○ Test Environment
○ Resources
○ Responsibilities
○ Acceptance Test references
○ Entry criteria
○ Exit criteria
○ Tools
○ Etc…
● The only thing that differentiates an Acceptance test plan from a regular test plan is
the factors that result in business decisions
● On vital piece of documentation that provides guidance on how to perform
acceptance testing for a particular project
● Has to be reviewed and approved before Acceptance Test Execution
● All the subsequent changes again have to undergo a review & approval process and
have to be track
● Key points to be considered while designing Acceptance Test Plan
○ It should be Detailed and Specific.
○ Must include only what has required for testing and what information is
necessary for the team to carry out testing
○ It should be Clear and Concise
○ No ambiguity. If at all there is something that may lead to confusion, then
elaborate on it, but keep it short and effective
○ Each and every component should be written keeping only the Business
Requirements in mind
○ Reliable and adaptable
○ Consistent
○ Follow the template provide by the Organization or Customer
2.2.1.Acceptance Test Plan Template
Acceptance Test Plan Template 1
11
Software Engineering - SDLC V-Model
3. System Design
● 2nd step of the validation phase
● System engineers analyze and understand the business of the proposed system by
studying the user requirements document
● Figure out possibilities and technique by which the user requirements can be
implemented
● If any of the requirements are not feasible, the user is informed of the issue
● A resolution is found and the user requirement document is edited accordingly
● Generate The software specification document
⤷ Contains the general system organization, menu structures, data structures etc.
● May also hold example business scenarios, sample windows, reports for the better
understanding
● Other technical documentation like entity diagrams, data dictionary will also be
produced
● The documents for system testing is prepared in this phases
● Formal Document:
○ Software Requirement Specification (SRS)
3.1. Software Requirement Specification (SRS)
3.1.1.Objectives of SRS
● Lays a foundation for SW engineering activities
● Is constructing when entire requirements are elicited and analyzed
● Acts as a representation of SW that enables the customers to review whether it is
according to their requirements
● Comprises user requirements for a system as well as detailed specification of the
system requirements
● Is a specification for:
○ A specific software product
○ Program
○ Set of applications that perform particular function in a specific environment
● Serves several goals depending on who is writing it
● The SRS could be written by:
○ The client of a system
■ Used to define the needs and expectation of the users
○ The developer of the system
■ Is written for various purposes
■ Serves as contract document between customer and developer
3.1.2.Characteristic of a good SRS
● Correctness
○ User is used to provide the accuracy of requirements stated
12
Software Engineering - SDLC V-Model
○ Said to be perfect if it covers all the needs that are truly expected from the
system
● Completeness (If, and only if, it include the following element)
○ All essential requirements, whether relating to functionality, performance,
design, constraints, attributes, or external interfaces
○ Definition of their responses of the SW to all realizable classes of input data in
all available categories of situations
■ It is essential to specify the responses to both valid and invalid values
○ Full labels and references to all figures, tables, and diagrams in the SRS and
definition of all terms and units of measure
● Consistency (If and only if no subset of individual requirements described in its
conflict. There are three types of possible conflict in the SRS)
○ The specified characteristic of real-world objects may conflicts
■ (Example) The format of an output report may be described in one
requirement as tabular but in another as textual
■ (Example) One condition may state that all lights shall be green while
another states that all lights shall be blue
○ There may be a reasonable or temporal conflict between the two specified
actions
■ (Example) One requirement may determine that the program will add
two inputs, and another may determine that the program will multiply
them
■ (Example) One condition may state that “A” must always follow “B”,
while other requires that “A and B” co-occurs
○ Two or more requirement may define the same real-world object but use
different terms for that object
■ (Example) A program’s request for user input may be called a
“prompt” in one requirement and a “cue” in another
■ The use of standard terminology and descriptions promotes
consistency
● Unambiguousness
○ Unambiguous when every fixed requirement has only one interpretation
○ Each element is uniquely interpreted
○ There is a method used with multiple definition, the requirements report
should determine the implications in the SRS so that it is clear and simple to
understand
● Ranking for importance and stability
○ If each requirement in it has an identifier to indicate either the significance or
stability of that particular requirement
○ All requirements are not equally important
○ Some prerequisites may be essential, especially for life-critical application
while others may be desirable
○ Each element should be identified to make these differences clear and explicit
○ Another way to rank requirements is to distinguish classes of items as
essential, conditional, and optional
● Modifiability
○ Should be made as modifiable as likely
○ Should be capable of quickly obtain changes to the system to some extent
13
Software Engineering - SDLC V-Model
○ Modifications should be perfectly indexed and cross-referenced
● Verifiability
○ Correct when the specified requirement can be verified with a cost-effective
system to check whether the final SW meets those requirements
○ The requirements are verified with the help of reviews
● Traceability
○ Traceable if the origin of each of the requirements is clear
○ Traceable if the referencing of each condition in future development or
enhancement documentation
○ 2 types of traceability:
■ Backward Traceability: Depends upon each requirement explicitly
referencing its source in earlier documents
■ Forward Traceability:
● Depends upon each element in the SRS having a unique
name or reference number
● Especially crucial when the SW product enters the operation
and maintenance phase
● As code and design document is modified, it is necessary to be
able to ascertain the complete set of requirements that may be
concerned by those modifications
● Design Independence
○ There should be an option to select from multiple design alternatives for the
final system
○ Should not contain any implementation details
● Testability
○ Should be written in such a method that it is simple to generate test cases
and test plans from the report
● Understandable by the customer
○ An end user may be an expert in his/her explicit domain but might not be
trained in computer science
○ The purpose of formal notations and symbols should be avoided too as much
extent as possible
○ Should keep the language simple and clear
● The right level of abstraction
○ If SRS is written for the requirement stage, the details should be explained
explicitly
○ For feasibility study, fewer analysis can be use
○ The level of abstraction modifies according to the object of the SRS
3.1.3.Properties of a good SRS
● Concise
○ Should be concise
○ Unambiguous
○ Consistent
○ Complete
○ Verbose and irrelevant descriptions decrease readability and also increase
error possibilities
14
Software Engineering - SDLC V-Model
● Structured
○ Should be well structure
○ Is simple to understand and modify
○ Undergoes several revisions to cope up with the user requirements
○ Often, user requirements evolve over a period of time
○ To the modifications to the SRS document easy, it is vital to make the report
well-structured
● Black-bow view
○ Should only define what the system should do and refrain from stating how to
do these
○ Should define the external behavior of the system
○ Should not discuss the implementation issues
○ Should view the system to be developed as a black box
○ Should define the externally visible of the system
○ Is also known as the black-box specification of a system
● Conceptual integrity
○ Should show conceptual integrity so that the reader can merely understand it
○ Response to undesired events
■ Should characterize acceptable responses to unwanted event
○ These are called system response to exceptional conditions
● Verifiable
● All requirements of the system should be correct
● Should be possible to decide whether or not requirements have been met in an
implementation
15
