Ideas & Inspirations | Background Topics | Inflectra

Background Topics

We believe that the right process for implementing a Requirements Management, Test Management, Application Lifecycle Management or Project Management system is critical to its success. Therefore we want to share our knowledge and experience in successfully deploying our products in different situations, configurations and environments so that you can maximize your productivity and streamline your deployment.

This knowledge base includes information on best practices for managing your end-to-end software development and testing lifecycle. Click on the items below to learn more:

Agile Estimation

Traditional software development estimating techniques are slow, long lasting exercises and as such are totally unsuited to Agile processes. New methods of estimating have emerged which fit the Agile model, requiring minimal effort to provide 'just enough' information to support prioritization and decision making. This paper offers an introduction to the most popular of these techniques, as well as a look at how such practices work in larger, multi-team projects in which normalization has become the subject of disagreement.

Traditional software development estimating techniques are slow, long lasting exercises and as such are totally unsuited to Agile processes. New methods of estimating have emerged which fit the Agile model, requiring minimal effort to provide 'just enough' information to support prioritization and decision making. This paper offers an introduction to the most popular of these techniques, as well as a look at how such practices work in larger, multi-team projects in which normalization has become the subject of disagreement.

Black Box Testing

The term refers to a common situation in which a person interacts with a system through its external interface, i.e. without looking inside. A good example of Black Box Testing may be a physician who tries to diagnose and treat an illness using the external markers of a disease. This approach is called a black box and it stands in contrast to an approach that a surgeon takes, when the latter "opens" the box and takes a peek inside.

The term refers to a common situation in which a person interacts with a system through its external interface, i.e. without looking inside. A good example of Black Box Testing may be a physician who tries to diagnose and treat an illness using the external markers of a disease. This approach is called a black box and it stands in contrast to an approach that a surgeon takes, when the latter "opens" the box and takes a peek inside.

Feature Driven Development

Feature-driven design (FDD) is an iterative and incremental software development process that follows the principles of the agile manifesto. The idea is to develop the high-level features, scope and domain object model and then use that to plan, design, develop and test the specific requirements and tasks based on the overarching feature that they belong to.

Feature-driven design (FDD) is an iterative and incremental software development process that follows the principles of the agile manifesto. The idea is to develop the high-level features, scope and domain object model and then use that to plan, design, develop and test the specific requirements and tasks based on the overarching feature that they belong to.

Functional Analysis

This section describes the various different techniques for performing a functional analysis. This typically happens after initial requirements discovery and before the full-blown requirements definition.

This section describes the various different techniques for performing a functional analysis. This typically happens after initial requirements discovery and before the full-blown requirements definition.

Requirements Definition

A System Requirements Specification (SRS) (also known as a Software Requirements Specification) is a document or set of documentation that describes the features and behavior of a system or software application.

A System Requirements Specification (SRS) (also known as a Software Requirements Specification) is a document or set of documentation that describes the features and behavior of a system or software application.

Requirements Gathering

This section outlines some of key techniques and methods that can be employed for gathering and capturing requirements on a project. It includes suggestions and ideas for ways to best capture the different types of requirement (functional, system, technical, etc.) during the gathering process.

This section outlines some of key techniques and methods that can be employed for gathering and capturing requirements on a project. It includes suggestions and ideas for ways to best capture the different types of requirement (functional, system, technical, etc.) during the gathering process.

Requirements Management

This section outlines some of the key concepts surrounding requirements and introduces some main activities that should take place on a project to ensure that a robust requirements definition underpin the system.

This section outlines some of the key concepts surrounding requirements and introduces some main activities that should take place on a project to ensure that a robust requirements definition underpin the system.

Requirements Traceability

Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards direction - from its origins, through its development and specification, to its subsequent deployment and use.

Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards direction - from its origins, through its development and specification, to its subsequent deployment and use.

Test Driven Development

Test-Driven Development (TDD) originally was created as part of the Extreme Programming (XP) methodology, where it was known as �Test-First� concept. The idea is that developers generally write their tests after the code is written and therefore are only testing the functionality as they wrote it, as opposed to testing it to make sure it works the way it was actually intended!

Test-Driven Development (TDD) originally was created as part of the Extreme Programming (XP) methodology, where it was known as �Test-First� concept. The idea is that developers generally write their tests after the code is written and therefore are only testing the functionality as they wrote it, as opposed to testing it to make sure it works the way it was actually intended!

Testing Methodologies

This background topic describes the various components of a thorough testing methodology and illustrates how SpiraTest is best suited to help you implement and manage them on your projects.

This background topic describes the various components of a thorough testing methodology and illustrates how SpiraTest is best suited to help you implement and manage them on your projects.

Use Cases

A use case is a definition of a specific business objective that the system needs to accomplish. A use-case will define this process by describing the various external actors (or entities) that exist outside of the system, together with the specific interactions they have with the system in the accomplishment of the business objective.

A use case is a definition of a specific business objective that the system needs to accomplish. A use-case will define this process by describing the various external actors (or entities) that exist outside of the system, together with the specific interactions they have with the system in the accomplishment of the business objective.

User Stories

A user story is a form of software system requirement that has become quite popular in Agile Methodologies such as Extreme Programming and Scrum. Unlike more traditional methods such as a System Requirements Specification or Use Case Diagrams, the emphasis in these methodologies is simplicity and changeability.

A user story is a form of software system requirement that has become quite popular in Agile Methodologies such as Extreme Programming and Scrum. Unlike more traditional methods such as a System Requirements Specification or Use Case Diagrams, the emphasis in these methodologies is simplicity and changeability.

Using A Task Board

The Task Board is perhaps the single most useful, and arguably most important, device that can be used on Agile  projects, often described as an 'information radiator' because it gives out the information to everyone from a central location. A Task Board is the focal point of any Agile project and serves as a good place at which to hold the stand-up meeting or Scrum.

The Task Board is perhaps the single most useful, and arguably most important, device that can be used on Agile projects, often described as an 'information radiator' because it gives out the information to everyone from a central location. A Task Board is the focal point of any Agile project and serves as a good place at which to hold the stand-up meeting or Scrum.