SAMPLE PROCESS - TEMPLATE

PRODUCT DEVELOPMENT METHDOLOGY

SOFTWARE REQUIREMENTS
PROCESS
PD-SE-PR-002

© Copyright, Techserv Consulting 1

CHANGE HISTORY
SR
SR DATE
DATE AUTHOR
AUTHOR VERSION
VERSION REMARKS
REMARKS
NO
NO

1
1 01-01-10
01-01-10 TECHSERV
TECHSERV 1.0
1.0 FIRST RELEASE
FIRST RELEASE


INTRODUCTION
PURPOSE:
PURPOSE: OBJECTIVES:
OBJECTIVES:
The Purpose of this document is to describe the
The Purpose of this document is to describe the The objective of the Software Requirements process is to
The objective of the Software Requirements process is to
“SOFTWARE REQUIREMENTS” process.
“SOFTWARE REQUIREMENTS” process. translate the software requirements into a clear, well
translate the software requirements into a clear, well
formulated, and complete Software Requirements
formulated, and complete Software Requirements
Specification Document and controlled and met throughout
Specification Document and controlled and met throughout
It covers process:
It covers process: the product lifecycle.
the product lifecycle.
•• Objectives
Objectives
•• Scope
Scope A SRS has to establish the scope of the software system
A SRS has to establish the scope of the software system
and identify interfaces with external systems, from the
and identify interfaces with external systems, from the
•• Abbreviations used
Abbreviations used customer's point of view.
customer's point of view.
•• Inputs
Inputs
•• Outputs
Outputs SCOPE:
SCOPE:
•• Tools usage
Tools usage This process applies to new product development projects
This process applies to new product development projects
•• Process Measurements and Metrics
Process Measurements and Metrics
•• Activities involved
Activities involved ABBREVIATIONS:
ABBREVIATIONS:
•• Responsibilities
Responsibilities ST –Steering Committee
ST –Steering Committee
•• Process aids
Process aids PDP – Product Development Process
PDP – Product Development Process
•• Process compliance indicators
Process compliance indicators SRS – Software Requirements Specification
SRS – Software Requirements Specification

The process definition is providing both high level and
The process definition is providing both high level and
detailed process flow. To supplement the process flow
detailed process flow. To supplement the process flow
process aids such as Guidelines // Templates // Checklists //
process aids such as Guidelines Templates Checklists
Standards have been provided to improve process
Standards have been provided to improve process
understanding and implementation effectiveness
understanding and implementation effectiveness


INTRODUCTION – Contd..…
Requirements document states what the software will do. It does not state how the software will do it.
Requirements document states what the software will do. It does not state how the software will do it.

What the software does is directly perceived by its users – either human users or other software systems. When a user
What the software does is directly perceived by its users – either human users or other software systems. When a user
performs some action, the software responds in a particular way; when an external system submits a request of a certain form, it
performs some action, the software responds in a particular way; when an external system submits a request of a certain form, it
gets a particular response. Therefore you and the users must agree on actions they can perform and response they should
gets a particular response. Therefore you and the users must agree on actions they can perform and response they should
expect. This common understanding is captured in the requirements document. How the software responds to the agreed upon
expect. This common understanding is captured in the requirements document. How the software responds to the agreed upon
request is not addressed in the requirements document. For example, the requirements document does not include screen
request is not addressed in the requirements document. For example, the requirements document does not include screen
layouts, database schemas, descriptions of communication layers – in short, no statements of design of any sort. For example,
layouts, database schemas, descriptions of communication layers – in short, no statements of design of any sort. For example,
it is a requirement for a payroll application to be able to compute and report employee earnings. It is a design issue whether to
it is a requirement for a payroll application to be able to compute and report employee earnings. It is a design issue whether to
build a system to send security enabled pay slip delivery system to employee. Again it is a design issue how the privacy of the
build a system to send security enabled pay slip delivery system to employee. Again it is a design issue how the privacy of the
data will be met in the system
data will be met in the system

This is not to say you won’t seek users’ input on some of the design, most especially on user interface design, but it is very
This is not to say you won’t seek users’ input on some of the design, most especially on user interface design, but it is very
important to recognize and Why Bother with a Requirements Document?
important to recognize and Why Bother with a Requirements Document?

Respect the boundary between the statement of requirements and how requirements are implemented. Design is the
Respect the boundary between the statement of requirements and how requirements are implemented. Design is the
responsibility of the development team they should be free to choose the most appropriate way to satisfy all aspects of the
responsibility of the development team they should be free to choose the most appropriate way to satisfy all aspects of the
requirements – features, performance, usability, etc. Usually the most appropriate way is the most simple way but sometimes
requirements – features, performance, usability, etc. Usually the most appropriate way is the most simple way but sometimes
other considerations may affect design decisions – such as opportunities for design or code reuse.
other considerations may affect design decisions – such as opportunities for design or code reuse.


PROCESS ARTIFACTS
ENTRY CRITERA
ENTRY CRITERA EXIT CRITERA
EXIT CRITERA
•• APPROVED PRODUCT REQUIREMENTS
APPROVED PRODUCT REQUIREMENTS •• APPROVAL OF SOFTWARE REQUIREMENTS
APPROVAL OF SOFTWARE REQUIREMENTS

INPUTS:
INPUTS: OUTPUTS:
OUTPUTS:
•• PRODUCT REQUIREMENTS DOCUMENT
PRODUCT REQUIREMENTS DOCUMENT DIRECT ARTIFACTS:
DIRECT ARTIFACTS:
•• REQUIREMENTS TRACEABLITY DOCUMENT
REQUIREMENTS TRACEABLITY DOCUMENT •• SOFTWARE REQUIREMENTS
SOFTWARE REQUIREMENTS

IN-DIRECT ARTIFACTS:
IN-DIRECT ARTIFACTS:
REFERENCE DOCUMENTS:
REFERENCE DOCUMENTS: •• SOFTWARE REQUIREMENTS STUDY NOTES
SOFTWARE REQUIREMENTS STUDY NOTES
•• INTEGRATED PROJECT PLAN
INTEGRATED PROJECT PLAN •• REVIEW RECORDS
REVIEW RECORDS
•• CONTRACT
CONTRACT •• MEETING MINUTES
MEETING MINUTES
•• REQUIREMENTS WORKING PAPERS
REQUIREMENTS WORKING PAPERS •• PRODUCT REQUIREMENTS TRACEABILITY
PRODUCT REQUIREMENTS TRACEABILITY
•• MINUTES OF MEETING
MINUTES OF MEETING
•• REQUIREMENTS GUIDLINES
REQUIREMENTS GUIDLINES


PROCESS ARTIFACTS
PROCESS MEASUREMENT:
PROCESS MEASUREMENT: TOOLS, TO BE USED:
TOOLS, TO BE USED:
•• MS – WORD
MS – WORD
•• NUMBER OF REQUIREMENTS CATEGORYWISE
NUMBER OF REQUIREMENTS CATEGORYWISE •• MS – EXCEL
MS – EXCEL
o FUNCTIONAL
o FUNCTIONAL
o NON-FUNCTIONAL
o NON-FUNCTIONAL
o COMPLIANCE
o COMPLIANCE
o INTELLUCTUAL PROPERTY
o INTELLUCTUAL PROPERTY

•• TIME EXPENDED ON SOFTWARE REQUIREMENTS
TIME EXPENDED ON SOFTWARE REQUIREMENTS
•• TIME EXPENDED FOR REVIEWS
TIME EXPENDED FOR REVIEWS
•• TIME EXPENDED FOR REWORK
TIME EXPENDED FOR REWORK
•• SCHEDULED DELIVERY DATE
SCHEDULED DELIVERY DATE
•• ACTUAL DELIVERY DATE
ACTUAL DELIVERY DATE

PROCESS METRICS:
PROCESS METRICS:

•• TOTAL EFFORT ON THIS PROCESS
TOTAL EFFORT ON THIS PROCESS
•• TOTAL EFFORT ON REVIEWS
TOTAL EFFORT ON REVIEWS
•• TOTAL EFFORT ON REWORK
TOTAL EFFORT ON REWORK
•• DELIVERY COMMITMENTS
DELIVERY COMMITMENTS


PROCESS CONTEXT

PRECEDING PROCESS
PRECEDING PROCESS CURRENT PROCESS
CURRENT PROCESS SUCCEEDING PROCESS
SUCCEEDING PROCESS

PD-SE-PR-001
PD-SE-PR-001 PD-SE-PR-002
PD-SE-PR-002 PD-SE-PR-003
PD-SE-PR-003
PRODUCT
PRODUCT SOFTWARE
SOFTWARE HIGH LEVEL
HIGH LEVEL
REQUIREMENTS
REQUIREMENTS REQUIREMENTS
REQUIREMENTS DESIGN
DESIGN


PROCESS FLOW
SOFTWARE REQUIREMENTS PROCESS - OVERVIEW
MANAGER
CONFIG.
REQUIREMENT

IDENTIFY
IDENTIFY UNDERSTA
UNDERSTA WRITE
WRITE ANALYZE
ANALYZE VALIDATE
VALIDATE
ANALYST

ND DEFINE
DEFINE DESCRIBE
DESCRIBE
PLAN SRS
PLAN SRS REQUIRME
REQUIRME ND SOFTWARE
SOFTWARE SOFTWARE
SOFTWARE SOFTWARE
SOFTWARE
CUSTOME AND STATE
AND STATE VERIFICATIO
VERIFICATIO
PROCESS
PROCESS NTS
NTS CUSTOME REQUIRME
REQUIRME REQUIRMEN
REQUIRMEN REQUIRME
REQUIRME
R NEEDS PROBLEMS
PROBLEMS N PROCESS
N PROCESS
(1)
(1) SOURCES
SOURCES R NEEDS NTS
NTS TS
TS NTS
NTS
(4)
(4) (9)
(9)
(2)
(2) (3)
(3) (5)
(5) (7)
(7) (8)
(8)
COMMITTEE
STEERING

Requirements As a The system It is imperative The This is the The purpose A critical
Analyst is significant requirements that the Requirements process of of element of the
responsible activity Requirement Analyst must understanding Requirements requirements
must begin interact with the development
for identifying Requirements with a Analyst help and prioritizing Validation and
customer to process is
OVERVIEW

a suitable Analyst to the customer requirements Review is
complete write the S/W describing the
approach for identify to develop a requirements. and requirements tests, analysis
gathering the sources of understandin problem determining a that are
He must involve or data that will
requirements requirements g of the statement that the customer in technical consistent, be used to
from the and customer's is completely the process of approach for complete, prove
customer. techniques to needs. independent defining, testing realistic, and compliance of
be used for of solutions clarifying, and requirements. unambiguous. the final system
requirements and specific prioritizing the with its
requirements. requirements.
gathering technologies.


PROCESS FLOW
SOFTWARE REQUIREMENTS PROCESS - OVERVIEW
MANAGER
CONFIG.

BASLINE
BASLINE
SRS
SRS
(11)
(11)
REQUIREMENT

UPDATE
UPDATE
ANALYST

CONDUCT
CONDUCT
TRACEABI
TRACEABI FORMAL
FORMAL
LITY
LITY REVIEW
REVIEW
MATRIX
MATRIX (11)
(11)
(10)
(10)
CORE TEAM
MEMBERS

Traceability The reviews Configuratio
matrix acts should be held n Manager to
as a map, periodically to ensure that
providing the ensure the approved
adequacy and
DETAILS

links SRS
completeness
necessary of baselined
for tracing requirements, and brought
the by obtaining under formal
requirements feedback change
horizontally / about them management
vertically from relevant process
stakeholders.


DETAILED DESCRIPTION
PLAN
PLAN The Requirements Analyst in association with Team Members is responsible for identifying a suitable
The Requirements Analyst in association with Team Members is responsible for identifying a suitable
SOFTWARE approach for gathering the requirements from the customer. The project manger should also identify
approach for gathering the requirements from the customer. The project manger should also identify
SOFTWARE
REQUIRMENTS suitable elicitation techniques that should be adopted for getting the needs. The supporting tools that
suitable elicitation techniques that should be adopted for getting the needs. The supporting tools that
REQUIRMENTS
would be used like checklists, sample software demos etc., should be identified before commencing the
would be used like checklists, sample software demos etc., should be identified before commencing the
PROCESS
PROCESS requirements study. The Requirements Analyst should identify, plan, estimate and schedule all the
requirements study. The Requirements Analyst should identify, plan, estimate and schedule all the
(1)
(1) tasks associated with the Requirements engineering process and the work Products associated with the
tasks associated with the Requirements engineering process and the work Products associated with the
process. The Requirements Analyst should also plan for the resources required for this process.
process. The Requirements Analyst should also plan for the resources required for this process.

PROCESS FLOW


As a first activity for requirements specification process is to identify various stakeholder and sources
As a first activity for requirements specification process is to identify various stakeholder and sources
IDENTIFY
IDENTIFY of requirements:
of requirements:
SOURCES OF
SOURCES OF
REQUIRMENTS
REQUIRMENTS Sources of Requirements could be:
Sources of Requirements could be:
(2)
(2)
•• User Needs Document
User Needs Document
•• Interview with Users
Interview with Users
•• Interviews with Management
Interviews with Management
•• Voluntary Standards
Voluntary Standards
•• Product classification
Product classification
•• Market and competitive analysis
Market and competitive analysis
•• Statutory, regulatory requirements and compliance strategies
Statutory, regulatory requirements and compliance strategies
•• Complaints/Failures and other historical data
Complaints/Failures and other historical data
•• Risk analysis
Risk analysis
•• Product documentation
Product documentation
•• Human factors studies
Human factors studies

As the project matures and requirements are derived, all activities or disciplines will receive
As the project matures and requirements are derived, all activities or disciplines will receive
requirements. To avoid requirements creep, criteria are established to designate appropriate channels,
requirements. To avoid requirements creep, criteria are established to designate appropriate channels,
or official sources, from which to receive requirements. The receiving activities conduct analyses of the
or official sources, from which to receive requirements. The receiving activities conduct analyses of the
requirements with the requirements provider to ensure that a compatible, shared understanding is
requirements with the requirements provider to ensure that a compatible, shared understanding is
reached on the meaning of the requirements. The result of this analysis and dialog is an agreed-to set of
reached on the meaning of the requirements. The result of this analysis and dialog is an agreed-to set of
requirements.
requirements.

The first step in developing requirements is to identify the customer. The term customer
The first step in developing requirements is to identify the customer. The term customer
includes anyone who has a right to impose requirements on the system. This includes end users,
includes anyone who has a right to impose requirements on the system. This includes end users,
operators, nurses, clinicians, regulatory agencies, accountants, sponsors, etc. All facets of the
operators, nurses, clinicians, regulatory agencies, accountants, sponsors, etc. All facets of the
customer must be kept in mind during software requirements process.
customer must be kept in mind during software requirements process.
PROCESS FLOW


The system design must begin with a complete understanding of the customer's needs. The information
The system design must begin with a complete understanding of the customer's needs. The information
UNDERSTAND
UNDERSTAND necessary to begin a design usually comes from preliminary studies and specific customer requests.
necessary to begin a design usually comes from preliminary studies and specific customer requests.
CUSTOMER
CUSTOMER Frequently the customer is not aware of the details of what is needed. Requirements Analyst must enter
Frequently the customer is not aware of the details of what is needed. Requirements Analyst must enter
NEEDS
NEEDS the customer's environment, discover the details, and explain them. Flexible designs and rapid
the customer's environment, discover the details, and explain them. Flexible designs and rapid
(3)
(3) prototyping facilitate identification of details that might have been overlooked. Talking to the customer's
prototyping facilitate identification of details that might have been overlooked. Talking to the customer's
customer and the supplier's supplier can also be useful. This activity is frequently referred to as mission
customer and the supplier's supplier can also be useful. This activity is frequently referred to as mission
analysis.
analysis.

It is the Requirements Analyst's responsibility to ensure that all information concerning the customer's
It is the Requirements Analyst's responsibility to ensure that all information concerning the customer's
needs is collected. The Requirements Analyst must also ensure that the definitions and terms used have
needs is collected. The Requirements Analyst must also ensure that the definitions and terms used have
the same meaning for everyone involved. Several direct interviews with the customer are necessary to
the same meaning for everyone involved. Several direct interviews with the customer are necessary to
ensure that all of the customer's needs are stated and that they are clear and understandable. The
ensure that all of the customer's needs are stated and that they are clear and understandable. The
customer might not understand the needs; he may be responding to someone else's requirements.
customer might not understand the needs; he may be responding to someone else's requirements.

PROCESS FLOW


What is the problem we are trying to solve? Answering this question is one of the Requirements
What is the problem we are trying to solve? Answering this question is one of the Requirements
DEFINE AND
DEFINE AND Analyst's most important and often overlooked tasks. An elegant solution to the wrong problem is less
Analyst's most important and often overlooked tasks. An elegant solution to the wrong problem is less
STATE
STATE than worthless.
than worthless.
PROBLEMS
PROBLEMS
(4)
(4) Early in the process, the customer frequently fails to recognize the scope or magnitude of the problem
Early in the process, the customer frequently fails to recognize the scope or magnitude of the problem
that is to be solved. The problem should not be described in terms of a perceived solution. It is
that is to be solved. The problem should not be described in terms of a perceived solution. It is
imperative that the Requirements Engineer help the customer develop a problem statement that is
imperative that the Requirements Engineer help the customer develop a problem statement that is
completely independent of solutions and specific technologies. Solutions and technologies are, of
completely independent of solutions and specific technologies. Solutions and technologies are, of
course, important; however, there is a proper place for them later in the Product development process.
course, important; however, there is a proper place for them later in the Product development process.
It is the Requirements Analyst's responsibility to work with the customer, asking the questions
It is the Requirements Analyst's responsibility to work with the customer, asking the questions
necessary to develop a complete "picture" of the problem and its scope.
necessary to develop a complete "picture" of the problem and its scope.

PROCESS FLOW


The Requirements Analyst must interact with the customer to write the system requirements. The
The Requirements Analyst must interact with the customer to write the system requirements. The
WRITE
WRITE Requirements Analyst must involve the customer in the process of defining, clarifying, and prioritizing
Requirements Analyst must involve the customer in the process of defining, clarifying, and prioritizing
SOFTWARE
SOFTWARE the requirements. It is prudent to involve users, regulators, manufacturers, maintainers, and other key
the requirements. It is prudent to involve users, regulators, manufacturers, maintainers, and other key
REQUIRMENTS
REQUIRMENTS stake-holders in the process.
stake-holders in the process.
(5)
(5)
Next, Requirements Engineering process must discover the functions that the system must perform in
Next, Requirements Engineering process must discover the functions that the system must perform in
order to satisfy its purpose. The system functions form the basis for dividing the system into
order to satisfy its purpose. The system functions form the basis for dividing the system into
subsystems. Although this makes it sound as if requirements are transformed into functions in a serial
subsystems. Although this makes it sound as if requirements are transformed into functions in a serial
manner, that is not the case. It is actually a parallel and iterative process. First we look at software
manner, that is not the case. It is actually a parallel and iterative process. First we look at software
requirements, then at software functions. Then we re-examine the requirements and then re-examine the
requirements, then at software functions. Then we re-examine the requirements and then re-examine the
functions. Then we re-assess the requirements and again the functions, etc.
functions. Then we re-assess the requirements and again the functions, etc.

PROCESS FLOW


The Requirements Analyst must interact with the customer to write the software requirements. The
The Requirements Analyst must interact with the customer to write the software requirements. The
ANALYZE
ANALYZE software requirements that are gathered and documented in the Software Requirements Specification
software requirements that are gathered and documented in the Software Requirements Specification
SOFTWARE
SOFTWARE should be analyzed further to identify any implied requirements. All the derived requirements should
should be analyzed further to identify any implied requirements. All the derived requirements should
REQUIRMENTS
REQUIRMENTS also be documented. During the analysis of requirements, the relationships between the various
also be documented. During the analysis of requirements, the relationships between the various
(6)
(6) requirements should also be identified. The mechanism of implementing the requirements namely,
requirements should also be identified. The mechanism of implementing the requirements namely,
through software, hardware, processes, services and documentation should be identified
through software, hardware, processes, services and documentation should be identified

During the requirement analysis, the operational concept and scenarios are identified. Operational
During the requirement analysis, the operational concept and scenarios are identified. Operational
concept refers to the Methods of how the system will be developed, deployed, operated, maintained and
concept refers to the Methods of how the system will be developed, deployed, operated, maintained and
disposed. It has the viewpoints of different stakeholders of the system namely, customer, architects,
disposed. It has the viewpoints of different stakeholders of the system namely, customer, architects,
developer, tester, maintainer, operator, end users. Operational concept should integrate the system life
developer, tester, maintainer, operator, end users. Operational concept should integrate the system life
cycle scenarios into a timeline behavior that satisfies the viewpoint of each stakeholder. The outcome
cycle scenarios into a timeline behavior that satisfies the viewpoint of each stakeholder. The outcome
of this analysis will also provide additional requirements which should be included in the Software
of this analysis will also provide additional requirements which should be included in the Software
Requirements Specification.
Requirements Specification.

The risks on cost, schedule, functionality, design and performance should also be assessed and
The risks on cost, schedule, functionality, design and performance should also be assessed and
documented for project risk mitigation and tracking.
documented for project risk mitigation and tracking.

All communications and documentation (including hard-copies) related with the requirements gathering
All communications and documentation (including hard-copies) related with the requirements gathering
and analysis process should be maintained.
and analysis process should be maintained.

Requirements could be classified as Stated, Implied and Derived requirements. Stated requirements are
Requirements could be classified as Stated, Implied and Derived requirements. Stated requirements are
those, which are explicitly communicated by the requirement providers during the requirement-
those, which are explicitly communicated by the requirement providers during the requirement-
gathering phase. Implied requirements are the needs about the system/product in the minds of the
gathering phase. Implied requirements are the needs about the system/product in the minds of the
requirement provider but not explicitly stated. Such implied requirements should also be recognized
requirement provider but not explicitly stated. Such implied requirements should also be recognized
and documented. Derived requirements are those requirements that are identified during the analysis of
and documented. Derived requirements are those requirements that are identified during the analysis of
requirements.
requirements.

PROCESS FLOW


REVIEW
REVIEW The Requirements Analyst must continually consult with the customer to ensure that the requirements
The Requirements Analyst must continually consult with the customer to ensure that the requirements
REQUIREMENTS are correct and complete. The customer should be satisfied that if these requirements are met, then the
are correct and complete. The customer should be satisfied that if these requirements are met, then the
REQUIREMENTS
WITH system will do what it really needs to do. All parties must agree to a way of measuring system
system will do what it really needs to do. All parties must agree to a way of measuring system
WITH
performance to ensure that the system does what the customer wants it to do. The Requirement Analyst
performance to ensure that the system does what the customer wants it to do. The Requirement Analyst
CUSTOMER
CUSTOMER and the customer should identify which requirements can be used as trade-off requirements.
and the customer should identify which requirements can be used as trade-off requirements.
(7)
(7)
Sometimes the customer is not available for consultation. In such unfortunate situations, a surrogate
Sometimes the customer is not available for consultation. In such unfortunate situations, a surrogate
customer will have to be used.
customer will have to be used.

At these reviews it is important to ask why each requirement is needed. This can help eliminate
At these reviews it is important to ask why each requirement is needed. This can help eliminate
unneeded requirements. It can also help reveal the requirements behind the stated requirements. It may
unneeded requirements. It can also help reveal the requirements behind the stated requirements. It may
be easier to satisfy the requirements behind the requirements, than the stated requirements
be easier to satisfy the requirements behind the requirements, than the stated requirements
themselves.
themselves.

PROCESS FLOW


Validating requirements means ensuring that the requirements are consistent and that a real-world
Validating requirements means ensuring that the requirements are consistent and that a real-world
VALIDATE
VALIDATE solution can be built and proven to satisfy the requirements. Each requirement should be technically
solution can be built and proven to satisfy the requirements. Each requirement should be technically
SOFTWARE
SOFTWARE feasible, and fit within budget, schedule, and other constraints.
feasible, and fit within budget, schedule, and other constraints.
REQUIRMENTS
REQUIRMENTS
(8)
(8) Requirements are often validated by reference to an existing system that meets most of the
Requirements are often validated by reference to an existing system that meets most of the
requirements. The requirements that are not satisfied by the existing system are validated by argument,
requirements. The requirements that are not satisfied by the existing system are validated by argument,
modeling, or simulation.
modeling, or simulation.

PROCESS FLOW


A critical element of the requirements development process is describing the tests, analysis or data that
A critical element of the requirements development process is describing the tests, analysis or data that
DESCRIBE
DESCRIBE will be used to prove compliance of the final system with its requirements. Each test must explicitly link
will be used to prove compliance of the final system with its requirements. Each test must explicitly link
VERIFICATION
VERIFICATION to a specific requirement; this will help expose un testable requirements. Describing the system tests
to a specific requirement; this will help expose un testable requirements. Describing the system tests
PROCESS
PROCESS informs the producers how the system will be tested, so that they know how they will be "graded." This
informs the producers how the system will be tested, so that they know how they will be "graded." This
(9)
(9) process frequently uncovers overlooked requirements.
process frequently uncovers overlooked requirements.

At this time it may be useful to examine the following definitions.
At this time it may be useful to examine the following definitions.

Validating Requirements: Ensuring that the set of requirements is consistent, that a real-world solution
Validating Requirements: Ensuring that the set of requirements is consistent, that a real-world solution
can be built that satisfies the requirements, and that it can be proven that such a system satisfies its
can be built that satisfies the requirements, and that it can be proven that such a system satisfies its
requirements. If Systems Engineering discovers that the customer has requested a perpetual-motion
requirements. If Systems Engineering discovers that the customer has requested a perpetual-motion
machine, the project should be stopped.
machine, the project should be stopped.

Verifying a System: Building the system right; ensuring that the system complies with its requirements.
Verifying a System: Building the system right; ensuring that the system complies with its requirements.
Verifying a system determines the conformance of the system to its design requirements. It also
Verifying a system determines the conformance of the system to its design requirements. It also
guarantees the consistency of the product at the end of each phase, with itself and with the previous
guarantees the consistency of the product at the end of each phase, with itself and with the previous
prototypes. In other words, it guarantees the honest and smooth transition from model to prototype to
prototypes. In other words, it guarantees the honest and smooth transition from model to prototype to
preproduction unit to production unit.
preproduction unit to production unit.

Verifying Requirements: Examination, analysis, test, or demonstration that proves whether a
Verifying Requirements: Examination, analysis, test, or demonstration that proves whether a
requirement has been satisfied. This process is iterative. The requirements should be verified with
requirement has been satisfied. This process is iterative. The requirements should be verified with
respect to the model, the prototype, the preproduction unit, and the production unit.
respect to the model, the prototype, the preproduction unit, and the production unit.

PROCESS FLOW


For the requirements that are gathered a traceability matrix should be prepared which consists of all
For the requirements that are gathered a traceability matrix should be prepared which consists of all
UPDATE
UPDATE categories of requirements (functional, interface, service etc.) specified by the customer. During
categories of requirements (functional, interface, service etc.) specified by the customer. During
TRACEABILITY
TRACEABILITY analysis this traceability matrix should be updated to include any derived requirements, which are not
analysis this traceability matrix should be updated to include any derived requirements, which are not
MATRIX
MATRIX explicitly stated by the customer. Through out the engineering life cycle, this traceability matrix should
explicitly stated by the customer. Through out the engineering life cycle, this traceability matrix should
(10)
(10) be updated to ensure the implementation of requirements across the development phases.
be updated to ensure the implementation of requirements across the development phases.

PROCESS FLOW


Project Manager in association with the Requirements Analyst schedules the Formal Review meeting
Project Manager in association with the Requirements Analyst schedules the Formal Review meeting
PLAN
PLAN of Software Requirements Specification with the Team Members with adequate notice. The
of Software Requirements Specification with the Team Members with adequate notice. The
FORMAL
FORMAL meeting to be attended by Team Members .. The draft Software Requirements Specification to be
meeting to be attended by Team Members The draft Software Requirements Specification to be
REVIEW
REVIEW circulated in advance and the comments are elicited prior to the meeting to conduct the meeting
circulated in advance and the comments are elicited prior to the meeting to conduct the meeting
(10)
(10) effectively.
effectively.

The meeting to be led by Project Manager // Requirement’s Analyst by presenting:
The meeting to be led by Project Manager Requirement’s Analyst by presenting:

Methodologies adopted in eliciting the product requirements
Methodologies adopted in eliciting the product requirements
Planned effort and actual effort
Planned schedule and actual schedule
Summary of Defects found and addressed so far
Rework effort
Rework effort
Audit report on this process, if any.

PROCESS FLOW


Requirements Analyst in association with Project Manager conducts the final review of the Product
Requirements Analyst in association with Project Manager conducts the final review of the Product
CONDUCT
CONDUCT Requirements with the Team members before it is base lined.
Requirements with the Team members before it is base lined.
FORMAL
FORMAL
REVIEW
REVIEW The meeting to be led by Project Manager // Requirement’s Analyst by presenting:
The meeting to be led by Project Manager Requirement’s Analyst by presenting:
(11)
(11)
-- Methodologies adopted in eliciting the Software requirements
Methodologies adopted in eliciting the Software requirements
-- Planned effort and actual effort
-- Planned schedule and actual schedule
-- Summary of Defects found and addressed so far
-- Rework effort
Rework effort
-- Audit report on this process, if any.

The review comments are to be documented and addressed in the Software Requirements Specification.
The review comments are to be documented and addressed in the Software Requirements Specification.
All review comments are to be preserved in the project file.
All review comments are to be preserved in the project file.

Team Members approval to be obtained to progress further in the product development cycle.
Team Members approval to be obtained to progress further in the product development cycle.

A Team Members is to look for errors, mistaken assumptions, lack of clarity and deviation from
A Team Members is to look for errors, mistaken assumptions, lack of clarity and deviation from
standard practice. The composition of the group that conducts the review is important and should
standard practice. The composition of the group that conducts the review is important and should
include all relevant stakeholders. The reviews should be held periodically to ensure the adequacy and
include all relevant stakeholders. The reviews should be held periodically to ensure the adequacy and
completeness of requirements, by obtaining feedback about them from relevant stakeholders.
completeness of requirements, by obtaining feedback about them from relevant stakeholders.

After all the defects are addressed in the SRS, the same is to be sent to Customer for review and
After all the defects are addressed in the SRS, the same is to be sent to Customer for review and
approval.
approval.

PROCESS FLOW


Based on the approvals for the Software Requirements Specification, the same would be baselined.
Based on the approvals for the Software Requirements Specification, the same would be baselined.
BASLINE
BASLINE
SRS
SRS Defect free Software Requirements Specification is to be versioned as 1.0 and baselined. Henceforth,
Defect free Software Requirements Specification is to be versioned as 1.0 and baselined. Henceforth,
(12)
(12) this document is under configuration management planning and control process, therefore, it would go
this document is under configuration management planning and control process, therefore, it would go
through formal change management process for any required changes.
through formal change management process for any required changes.

PROCESS FLOW


PROCESS GUIDANCE
PROCESS AIDS:
PROCESS AIDS: PROCESS COMPLIANCE INDICATORS:
PROCESS COMPLIANCE INDICATORS:
•• Software Requirements Specification Template (PD-SE-TP-
Software Requirements Specification Template (PD-SE-TP- EXISTENCE:
EXISTENCE:
001)
001)
•• Software requirements Specification
Software requirements Specification
•• Software Requirements Specification Guidelines (PD-SE-GL-
Software Requirements Specification Guidelines (PD-SE-GL-
001) •• Product Requirements Traceability
Product Requirements Traceability
001)
•• Product Requirements Traceability Matrix (PD-SE-TP-002) •• Review Records
Review Records
Product Requirements Traceability Matrix (PD-SE-TP-002)
•• Study notes
Study notes
•• Minutes of Meeting
Minutes of Meeting

EFFECTIVENESS:
EFFECTIVENESS:
•• No Major Non-Conformances
No Major Non-Conformances
•• Minimal Changes to Product Requirements
Minimal Changes to Product Requirements
ADDITIONAL PROCESS NOTES:
ADDITIONAL PROCESS NOTES: •• Rework to Requirements Definition effort ratio
Rework to Requirements Definition effort ratio


RACI
SR ROLES
NO

Verification & Validation

Configuration In-charge

Steering Committee
Requirements analyst

Quality Coordinator
TASK

Product Architect
Project Manager

Developer

Unit Head

Customer
1 PLAN SOFTWARE REQUIRMENTS PROCESS R A R

2 IDENTIFY SOURCES OF REQUIRMENTS R A

3 UNDERSTAND CUSTOMER NEEDS R A

4 DEFINE AND STATE PROBLEMS R A

5 WRITE SOFTWARE REQUIRMENTS R A

6 ANALYZE SOFTWARE REQUIRMENTS R A

7 REVIEW REQUIREMENTS WITH CUSTOMER R R A R

8 VALIDATE SOFTWARE REQUIRMENTS R R A

9 DESCRIBE VERIFICATION PROCESS R R A

10 PLAN FORMAL REVIEW R A

11 CONDUCTFORMALREVIEW C A R

12 BASLINE SRS A R

R RESPONSIBLE A ACCOUNTABLE C CONSULTED I INFORMED


END


SAMPLE PROCESS - TEMPLATE

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (14)

Similar to SAMPLE PROCESS - TEMPLATE

Similar to SAMPLE PROCESS - TEMPLATE (20)

More from Arul Nambi

More from Arul Nambi (20)

Recently uploaded

Recently uploaded (20)

SAMPLE PROCESS - TEMPLATE