There are a number of factors that can influence the approach we take to managing the requirements. I provide a brief list below (this is not an exhaustive list): the technical sophistication of the product the risk associated with a mistake distribution of the team The more technically complicated the product the more diligent our […]
I have long had an affinity for nature, having camped with my family when I was a child. For years, I have been visiting Gatlinburg Tennessee. For someone who has spent much of his time in North Carolina, it is sad that I found this place accidentally when my wife won a three-day trip. Since […]
State diagrams can also help us develop the requirements and consider software and hardware requirements that may not be so easily evoked from the customer. The state diagram describes the behavior or the software / system, specifically the number of states in which the product may be. There will be transitions between states defined by […]
Scope, Requirements, and Work Breakdown Structure The scope of the work and the requirements provide us with information from which we can build the Work Breakdown Structure or WBS. In fact, even before we are able to start doing the work to build the expected results of the project, our work breakdown structure should capture […]
I have spent considerable time in the south, specifically North Carolina. My dad was retired Special Forces and closed out his career at FortBragg (we lived in SpringLake). Those not from the south, or have not spent much time here, may not know about sweet iced tea. Sweet tea is a wonderfully refreshing concoction, especially […]
I was thinking about technical debt in the context of our recent spate of requirements postings on the blog. Technical debt, from my perspective, does not just apply to software. We incur technical debt when we implement an easy solution in the short run, as opposed to the best overall solution. In other words, we […]
The customer can seldom articulate the technical details of the product. The customer may define the product or need in terms of function and performance, but building the product from these documents will be extremely difficult or perhaps impossible. We will need some type of document to begin describing in technical terms the product that […]
This question was posed by Tom Cagley on Twitter. At first blush these may seem at odds or exclusionary, but perhaps not. I know why it may seem difficult to be innovative while we are hyper-focused on continuous improvement activities. A company that focuses on continuous improvement that tends to be incremental can occlude […]
This blog post originates from Capers Jones LinkedIn comments about toxic requirements. He posted a comment to a requirements article and brought up bloated requirements and toxic requirements. I have never heard of the name “toxic requirements” perhaps that is uniquely Capers Jones identifier – I like it. However, I believe I have experienced toxic […]
I have never worked on a project that took that approach. In my embedded product development experience, the requirements grow as the product iterations are delivered, evaluated and tested. The results of those evaluations and tests will impact the requirements. There will be additions, subtractions, and alterations of the requirements. We will update the requirements documents, […]