BACHELOR OF SCIENCE (HONOURS) IN SOFTWARE DESIGN
- YEAR 3 -
- Software Quality and Process Improvement -
REQUIREMENTS PROCESS DESCRIPTION
David Flynn (A00161415)
Gary Doolin (A00166637)
Tom Wasniewski (A00148326)
Process Name: Requirements Development
Purpose: The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component requirements.
Entry Criteria
Controls
Exit Criteria
1. Team members trained to required level.
1. Review Process.
1. Ensuring all needs of stakeholders
have been documented and approved.
2. Checklist for relevant documentation.
3. Requirements Doc Template.
4. Customer Requirements Document.
2. Customer Requirements reviewed and
approved.
3. Product component requirements
reviewed and approved.
5. Time Lines
Inputs
Tasks
Outputs
1. Stakeholder’s needs, expectations and
constraints.
1. Develop Customer Requirements
1. Validated and reviewed product
requirements
2. Validated and reviewed product
component requirements
3. Product Representations (Prototypes,
Simulations, Use Cases)
2. Develop Product Requirements
3. Analyze and Validate Requirements
Metrics
Roles
1. Amount of requirements per customer’s
needs.
2. Amount of requirements for each
component.
3. No. of functional and non-functional
requirements per hour.
4. Cost savings resulting from the
requirements analyses.
1.
2.
3.
4.
Project Manager (T1, T3)
Software Architect (T1, T2, T3)
External Customer Manager (T1)
Requirements Engineer (T1, T2, T3)
Issues
Process Name: Develop Customer Requirements
Purpose: Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.
Entry Criteria
Controls
1. Team members trained to required level.
1. Review Process.
Exit Criteria
1. Customer Requirements reviewed
and approved.
2. Checklist for relevant documentation.
3. Requirements Document Template.
4. Time Lines.
Inputs
1. Stakeholder’s needs, expectations and
constraints.
Metrics
1. Amount of requirements per
customer’s needs.
2. Number of requirements translated per
hour.
Tasks
Outputs
1. Develop questions and surveys to capture
customer needs, expectations and constraints.
2. Engage relevant stakeholders using interviews
and surveys for eliciting needs, expectations,
constraints and external interfaces.
3. Translate the stakeholder needs, expectations,
constraints and interfaces into documented
customer requirements by way of use cases.
4. Through interview define constraints for
verification and validation.
1. Prepared survey and interview
questions.
Roles
Issues
1.
2.
3.
4.
Project Manager (T1, T2)
Software Architect (T3)
External Customer Manager (T1)
Requirements Engineer (T1, T2, T3)
2. Documented customer requirements
based on the needs, expectations and
constraints gathered in the elicitation
step.
3. Constraints that needs to be verified
and validated later on in the process.
Process Name: Develop Product Requirements
Purpose: Customer requirements are refined and elaborated to develop product and product component requirements.
Entry Criteria
Controls
Exit Criteria
1. Customer Requirements documents
reviewed and approved before starting.
1.
2.
3.
4.
5.
6.
1. Product component requirements
reviewed and approved.
2. Input documents reviewed and approved
before starting.
Inputs
1. Documented customer requirements
based on the needs, expectations and
constraints gathered in the elicitation
step.
Checklist for relevant documentation.
Customer Requirements Document.
Customer Constraints.
Review Process.
Requirements Document Template.
Time Lines.
Tasks
1. Establish Product and Product Component
Requirements.
2. Allocate Product Component Requirements.
Outputs
1. Product Requirements
2. Product Component Requirements
3. Interface Requirements
3. Identify Interface Requirements.
2. Constraints that needs to be verified
and validated.
Metrics
1. Amount of requirements for each
component.
2. Number of design constraints per
product.
3. Number of product and component
requirements extracted from customer
requirements.
4. Number of requirements for the
identified interfaces.
Roles
1. Software Architect (T1, T2, T3)
2. Requirements Engineer (T1, T2, T3)
Issues
Process Name: Establish Product and Product Component Requirements
Purpose: Establish and maintain product and product component requirements, which are based on the customer requirements.
Entry Criteria
1. Customer Requirements documents
reviewed and approved before starting.
Controls
1. Checklist for relevant documentation.
Exit Criteria
1. Product component requirements
reviewed and approved.
2. Requirements Document Template
3. Customer Requirements Document.
4. Time Lines.
Inputs
1. Documented customer requirements
based on the needs, expectations and
constraints gathered in the elicitation
step.
Tasks
1. Develop requirements in technical terms
necessary for product and product component
design.
2. Derive requirements that result from particular
database-oriented design decisions.
Outputs
1. Requirements specified in terms of
the product and product
component design.
2. Relationships between product
requirements.
3. Establish and maintain relationships between
requirements for considering during change
management and requirements allocation.
Metrics
1. Number of product and component
requirements extracted from customer
requirements.
Roles
1. Software Architect (T1, T2, T3)
2. Requirements Engineer (T1, T2, T3)
Issues
Process Name: Allocate Product Component Requirements
Purpose: Allocate the requirements for each product component.
Entry Criteria
Controls
1. Product Component Requirements
reviewed and approved before starting.
1.
2.
3.
4.
5.
Tasks
Inputs
1. Requirements specified in terms of the
product and product component
design.
2. Relationships between product
requirements.
3. Constraints that needs to be verified
and validated.
Review Process.
Checklist for relevant documentation.
No. of Components
Component Requirements.
Time Lines.
1. Allocate requirements to functions and queries
to be run in the database system.
2. Allocate requirements to product components in
the database structure.
Exit Criteria
1. Requirements allocation reviewed
and approved.
Outputs
1. Product Requirements
2. Product Component Requirements
3. Relationships between the newly
allocated product component
requirements.
3. Allocate design constraints to product
components in the database structure.
4. Document relationships among allocated
requirements.
Metrics
1. Amount of requirements for each
component.
2. Number of design constraints per
product.
Roles
1. Software Architect (T1, T2, T3, T4)
2. Requirements Engineer (T1, T2, T3, T4)
Issues
Process Name: Identify Interface Requirements
Purpose: Identify interface requirements.
Entry Criteria
1. Input documents reviewed and approved
before starting.
Controls
1. Review Process.
Exit Criteria
1. Interface Requirements reviewed
and approved.
2. Checklist for relevant documentation.
3. Time Lines.
Inputs
1. Relationships between the newly
allocated product component
requirements.
Metrics
1. Amount of interfaces per record type
(legal/medical/accounting)
2. Number of requirements for the
identified interfaces.
Tasks
1. Identify interfaces both external to the product
and internal to the product (differentiate among
the legal, medical and accounting types of
records).
2. Develop the requirements for the identified
interfaces.
Roles
1. Software Architect (T1, T2)
2. Requirements Engineer (T1, T2)
Outputs
1. Interface Requirements
Issues
Process Name: Analyze and Validate Requirements
Purpose: The requirements are analyzed and validated, and a definition of required functionality is developed.
Entry Criteria
1. All requirements documents reviewed
and approved.
Inputs
1. Product Requirements
2. Product Component Requirements
3. Interface Requirements
Controls
1. Required Functionality.
2. Review Process.
3. Time Lines.
Tasks
1. Establish a Definition of Required Functionality.
2. Analyze Requirements.
3. Analyze Requirements to Achieve Balance.
Exit Criteria
1. Ensure required functionality
(Security, usability, privacy) is
defined, achieved, reviewed and
approved.
Outputs
1. Validated product requirements
2. Validated product component
requirements
4. Validate Requirements.
Metrics
1. No. of functional and non-functional
requirements per hour.
2. Amount of inadequacies per
requirement.
3. No. of unused/unnecessary
requirements
4. Amount of additional requirements per
analysis.
5. Cost savings resulting from the
requirements analyses.
6. Product representations type
percentage distribution (between the
prototypes, simulations and use cases)
Roles
1. Software Architect (T1, T2)
2. Requirements Engineer (T1, T2)
Issues
Process Name: Establish a Definition of Required Functionality
Purpose: Establish and maintain a definition of required functionality.
Entry Criteria
1. Input documents reviewed and approved
before starting.
Controls
1. Time Lines.
2. Review Process.
Inputs
1. Product Requirements
2. Product Component Requirements
3. Interface Requirements
Metrics
1. Amount of functional and nonfunctional requirements per Product
Requirements Document.
2. No. of functional and non-functional
requirements per hour.
Tasks
1. Analyze the functionality of the database system
by end users.
2. Identify logical or functional partitions of the
database system.
3. Partition requirements into groups, based on
established criteria and taking into account the
nature of the data (medical, legal or accounting).
4. Allocate functional and performance
requirements to functions and sub-functions.
Roles
1. Software Architect (T4)
2. Requirements Engineer (T1, T2, T3, T4)
Exit Criteria
1. Ensure required functionality
(Security, usability, privacy) is
defined, achieved, reviewed and
approved.
Outputs
1. Derived functional and
performance product
requirements.
2. Derived functional and
performance product component
requirements.
Issues
Process Name: Analyze Requirements
Purpose: Analyze requirements to ensure that they are necessary and sufficient.
Entry Criteria
1. All Requirement Document reviewed and approved
before starting.
2. Interview Techniques (questions), surveys, etc.
documents reviewed and approved.
Inputs
1. Interview Techniques (questions), surveys,
use cases, etc. documents.
2. Time Lines.
3. Review Process.
Tasks
1. Derived functional and performance product
requirements.
2. Derived functional and performance product
component requirements.
3. Interface requirements
Metrics
1.
2.
3.
4.
Controls
1. Analyze stakeholder needs, expectations,
constraints, and external interfaces to remove
conflicts and to organize them into sections.
2. Analyze requirements to see if they satisfy the
objectives of higher level requirements.
3. Analyze requirements to ensure that they are
complete, feasible, realizable, and verifiable.
4. Identify key requirements that have a strong
influence on functionality, security and
performance of the database system.
5. Identify technical performance measures that
will be tracked during the development effort.
6. Analyze use cases to refine the customer needs,
constraints, and to discover new requirements.
Roles
Amount of inadequacies per requirement.
No. of unused/unnecessary requirements
Amount of additional requirements per analysis.
No. of insufficient requirements
1. Project Manager (T3, T4)
2. External Customer Manager (T1, T6)
3. Software Architect (T2, T3, T4, T5)
4. Requirements Engineer (T1, T2, T3, T4, T5, T6)
Exit Criteria
1. Necessary requirements
included in Requirements
Document.
2. Requirements document
reviewed and approved.
Outputs
1. Analyzed product
requirements.
2. Analyzed product component
requirements.
3. Newly emerged requirements.
Issues
Process Name: Analyze Requirements to Achieve Balance
Purpose: Analyze requirements to balance stakeholder needs and constraints.
Entry Criteria
Controls
Exit Criteria
1. All Requirement Document reviewed and
approved before starting.
1. Interview Techniques (questions), surveys,
use cases, etc. documents.
1. Necessary requirements included
in Requirements Document.
2. Interview Techniques (questions), surveys,
etc. documents reviewed and approved.
2. Time Lines.
2. Requirements document reviewed
and approved.
3. Review Process.
Inputs
1. Analyzed product requirements.
2. Analyzed product component
requirements.
Metrics
1. Cost savings resulting from the
requirements analyses.
2. Amount of potential risks per
requirement.
Tasks
1. Use proven models, simulations and prototyping
to find the balance between the stakeholder
needs and the database constraints.
2. Use the results of the analyses to reduce the
cost of the product and the risks in developing
the database system.
3. Perform a risk assessment on the requirements
and functional architecture of the database
system.
4. Examine the waterfall and prototyping lifecycle
concepts for impacts of requirements on risks.
Roles
1. Project Manager (T1, T2, T3, T4)
2. Requirements Engineer (T1, T2, T3, T4)
Outputs
1. Balanced product requirements.
2. Balanced product component
requirements.
Issues
Process Name: Validate Requirements
Purpose: Validate requirements to ensure the resulting product will perform as intended in the user's environment.
Entry Criteria
Controls
Exit Criteria
1. Input documents reviewed and approved
before starting.
1. Review Process.
1. The requirements documents
reviewed and approved.
2. Checklist for relevant documentation.
Inputs
1. Balanced product requirements.
2. Balanced product component
requirements.
Metrics
1. Amount of potential risks per
requirements.
2. Product representations type
percentage distribution (between the
prototypes, simulations and use cases)
Tasks
1. Analyze the requirements to determine the risk
that the database system will not perform
appropriately in its intended-use environment.
2. Explore the adequacy and completeness of
requirements by developing prototypes,
simulations and use cases, and by obtaining
feedback about them from relevant
stakeholders.
3. Assess the design as it matures in the context of
the requirements validation environment to
identify validation issues and expose unstated
needs and customer requirements.
Roles
1. Project Manager (T1, T2, T3)
2. External Customer Manager (T2)
3. Software Architect (T2, T3)
4. Requirements Engineer (T1, T2, T3)
Outputs
1. Validated product requirements
2. Validated product component
requirements
3. Product Representations
(Prototypes, Simulations, Use
Cases)
Issues