Note: This is a follow-on to our previous blog: Requirement Quality: Garbage In; Garbage Out Many of today’s requirement management tools (RMTs) focus on (1) documenting requirements and other associated
Case Study: Vasa Warship Project The Vasa was a Swedish warship that was built over a period of four years, 1625 – 1628…it sank on its maiden voyage sailing all
Best Practices for Eliciting and Writing Requirements April 6-7, 2016 ArgonDigital invites everyone who writes requirements or has an interest in requirements to join us in April for a SPECIAL
In a previous blog: “How to improve the quality of your requirements” I addressed three key questions: How do you judge the quality of the requirements within your organization? How
This is the second of our two-part blog concerning verification and validation. In part 1 we discussed the basic concepts of verification and validatlion in terms of the context in
A question we are often asked is “What is difference between verification and validation?” This two-part blog answers that question. In part 1 we discuss the basic concepts of verification
Note: I originally came up with the list of features with a focus on features that a Requirement Management Tool (RMT) should have to better manage an organization’s requirements throughout
In our previous blog “Using Technology Readiness Levels to Manage Risk” we introduced the concept of Technology Readiness Levels (TRLs). In that article, the basic descriptions for TRLs as used
Conducting Requirement Inspections: Achieve Cost Savings through Early Requirement Defect Detection Studies show that between 25-50% of software project budgets are eaten up by rework and 70-85% of this rework
Technology Readiness Levels In a previous blog “Are the Requirements Attainable?”, we mentioned that one reason requirements may be not be attainable was because the ability to meet a given
In previous blogs we talk about Why do my requirements keep changing and Controlling and Managing Change during product or system development. Change can also be addressed from the perspective
The Problem One of the most frequent reasons for project failure is “scope and requirements creep”. Too often, the scope of a product development project changes in midstream as stakeholders
Don’t miss out on this opportunity
and request a conversation today!