Requirements and Benchmarking One of the things we can do to understand and develop our own requirements is to explore other products that are similar to our proposed product or that solve the same or similar customer problem.  Where there are similar needs met, benchmarking is a way for us to understand how other suppliers have […]

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 […]

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 […]

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 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 […]

Our project must balance the input from a myriad of people that are associated and contribute to the project, along with those funding the project to be successful.   To be able to do this, we will need to understand our stakeholders and their perspective.  Some of our the stakeholders will add requirements, support existing […]

We have written much on product requirements on the blog.  Requirements are those statements, derived from the project scope, upon which we will build the product.  A clear understanding of these and the circumstances surrounding the use of the product will improve our chances of achieving the desired development objective. Nonfunctional Requirements One of the […]

You do not have to go it alone when it comes to developing requirements. There are many templates and well-defined approaches to help in this regard.  If you are developing a complex system, it is good to break the requirements up, starting at the highest level of abstraction.  We will call that systems specification.  The […]

In keeping with our requirements work, we will start by identifying the attributes of a good requirement.  We start our project off with the requirements, so it stands to reason if we start off poorly or in the wrong direction, we will not make the objective.  This situation will get worse the longer we spend […]

Technical documentation serves as a repeatable communications medium. That is, written so that anybody reading with the appropriate competency will come away with the same conclusion.  Not filling this gap or relying upon verbal communications has great limitations. Many of us have likely played that game as children where a group of people line up […]