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:
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.
Behavior-Driven Development (BDD) is an Agile software development process that encourages collaboration among developers, QA and non-technical or business participants in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave.
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 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.
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.
Both functional and non-functional tests are crucial to a high-quality final product. Click here to learn about the differences and specifics of each type today!
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. Learn more about it here.
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 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 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.
SAFe has quickly become a popular scaled agile option, but there are subvariations of the framework that you might not know about. Click here for more!
Forming the foundation of information needed for the development process, Scrum artifacts are a critical part of the planning process. Learn more here.
Scrum events, or ceremonies, are one of the primary factors that makes scrum such an effective development methodology. Click here to learn more.
Quality assurance is one of the most critical pieces to the software development process & in whether your application succeeds or not. Learn about it here.
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!
There are several software testing & development methodologies commonly used, but it can be difficult to keep track of the difference. Learn more here.
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 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.
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.
Crucial to the success of any project is the ability to effectively manage risks. Learn what risk management is, how the process works, & more here.
Software testing is a critical piece of the software development lifecycle. But in a world of so much automation, should you keep your testing manual?