The worst scenario I can imagine is when we allow real customers, users, and our own salespeople to dictate “functions and features” to the developers, carefully disguised as “customer requirements.” Maybe conveyed by our Product Owners. If you go slightly below the surface, of these false “requirements” (“means,” not “ends”), you will immediately find that they are not really requirements. They are really bad amateur design, for the “real” requirements — implied but not well defined. — Mary Poppendieck Read more →
EppsNet Archive: Requirements
Behind Every Great Product
Excerpts from “Behind Every Great Product: The Role of the Product Manager” by Martin Cagan, Silicon Valley Product Group: Behind every great product you will find a good product manager, in the sense we describe here. We have yet to see an exception to this rule. Product ideas can come from any number of sources. Your job as product manager is to evaluate these product ideas and decide which product ideas are worth pursuing, and which are not. The art of product management is to combine a deep understanding of your target customer’s needs and desires with the capabilities of your engineering team and the technologies they have to work with in order to come up with a product definition that is both compelling and achievable. Of the hundreds of possible and even desirable features in the product, which are the few that are actually essential to… Read more →
Aside
Agile Training: The Four Levels of Agile Requirements
INVEST in Good Stories
What are the characteristics of a good user story? Bill Wake developed the INVEST acronym: I – Independent N – Negotiable V – Valuable E – Estimable S – Small T – Testable For a short description of each attribute, see Wake’s excellent article. Read more →
The Word “Requirement” is Just Plain Wrong
Software development has been steered wrong by the word “requirement,” defined in the dictionary as “something mandatory or obligatory.” The word carries a connotation of absolutism and permanence, inhibitors to embracing change. And the word “requirement” is just plain wrong. Out of one thousand pages of “requirements,” if you deploy a system with the right 20% or 10% or even 5%, you will likely realize all of the business benefit envisioned for the whole system. So what were the other 80%? Not “requirements”; they weren’t really mandatory or obligatory. — Kent Beck, Extreme Programming Explained Read more →
A Longstanding Absurdity
Is the bad-software problem really caused by bad requirements definition, which we could fix by doing a better job up front, if only we were more diligent and more professional in our work? We have made this our primary excuse for bad software for decades. If this was really the problem, and if processes focusing on early lockdown of requirements provided the needed solution, wouldn’t we have solved this by now? A process that requires us to lock down decisions early will maximize our risk, not manage it. — Cem Kaner Read more →
Customer Engagement
You want to actively elicit feedback from end users using short development cycles or by using prototypes and models during analysis. A good feedback cycle has the appearance of causing problems. It will cause emergent and latent requirements to surface. That means rework: the value of prototypes is that they push this rework back into analysis, where it has more value. And most important, good end user engagement changes end user expectations. It is only by participating in a feedback loop that’s grounded in reality that customers get the opportunity they need to reflect on what they’re asking for. If your customer changes their expectations in the process, you’ve both learned something. Embracing change doesn’t just mean reacting to it: it means providing the catalysts that accelerate it. — James O. Coplien and Gertrud Bjørnvig, Lean Architecture for Agile Software Development Read more →
The V Model
The graphic on the right came up for discussion at the office today. The V Model is a traditional model, still widely used, but (IMO) bad for at least a couple of reasons. Look where User Requirements and UAT are — the first and last items in the V. This ensures that the maximum amount of time goes by between users saying what they want and being able to test out the implementation. The more time that goes by between users saying what they want and being able to try it out, the more likely it is that they’re going to change their minds, for any number of reasons. That’s bad. If our testing is honest, there’s always some non-zero probablilty that the system will fail, again for any number of reasons — too slow, too buggy, not what I asked for, etc. By putting testing last, we don’t find… Read more →
Gathering Requirements
The most common verb associated with requirements is “gather.” Yet most requirements that end up fulfilled in a system aren’t gathered. Yes, I know, there are always a few requirements that are so obvious in a new system that you can “gather” them from stakeholders, but gathering implies that the requirements are already out there, fully formed and fully understood, and ready for harvest. It just doesn’t work that way. No stakeholder ever says to an analyst, “Requirements? Why, yes, I have eleven requirements. Eight are functional, one is a usability requirement, and the other two are operational requirements. Are you collecting constraints now, as well? I have three of those. Please sit down, and I will elucidate perfectly clearly on each and every one in turn.” Most requirements are discovered–or invented. Many are transformed or compromised along the way. Most stakeholders don’t consider the underlying requirements of their work;… Read more →
Changing Requirements
The most common reason for software project failure is attributed to requirements issues – badly defined, not stated correctly, changing requirements, etc. — “Tips for Discovering Requirements” Any project I’ve done that lasted longer than a day had changing requirements. If your development strategy only works with an unchanging set of requirements, you need to rethink your approach . . . Read more →
I Hold in my Hand a 63-Page Requirements Doc
I hold in my hand a 63-page requirements doc . . . We spend a lot of time reworking the requirements doc to reflect the reality of the system that we’re actually building. We also spend a lot of time reworking all the docs that derive from the requirements doc — design docs, UI docs, test plans, etc. — to reflect the changes in the requirements doc. Another way to think of this is that the project is driving the requirements, rather than the requirements driving the project. So why did we create all these incredibly detailed documents in the first place? We have a vast collection of well-documented ignorance . . . Thus spoke The Programmer. Read more →
Three Reasons for Software Project Failure
Jerry Weinberg‘s top three reasons for software projects going over budget or failing to meet their original requirements: The original budget, schedule and requirements were totally unrealistic, due to the inability of people to speak truth to power. The original budget, schedule and requirements were totally unrealistic, due to the inability of people to understand and acknowledge their own limitations (which we all have). Even in those rare cases that people pass those first two hurdles, they lose emotional control during the project when something goes wrong — and something ALWAYS goes wrong. In 50 years, I’ve never seen a project where something didn’t go wrong. When it does, the project’s success is determined by the leaders’ ability to manage themselves emotionally. Read more →
Respect the Classics, Man: No Silver Bullet
This essay by Turing Award-winner Fred Brooks is almost 20 years old now. Sadly, the ideas on incremental development are still considered outside the mainstream in IT, which continues to favor the widely-discredited waterfall approach. Read more →
Requirements are Boring
You’re working on the requirements for Project X? Boring. You’ve got someone figuring out architecture for Project Y? Boring. The guys are designing Project Z? Boring. . . . Who has built something that their customer will certify is part of what they want? That’s interesting. Who has shipped something to their customer and the customer is using it? That’s very interesting. — Ron Jeffries Read more →
The Comfort of Methodology
Ill-specified systems are as common today as they were when we first began to talk about Requirements Engineering twenty or more years ago. Yet the task of creating complete and perfect specifications is not rocket science. We have adequate and comprehensible theories at our disposal for specification of finite state automata. We have proceeded over the past decades to develop and refine a discipline of applying these theories to real-world systems. In our methodological focus, we may have lost sight of some endemic problems that plague not the process but the people who do the process. Is it possible that an engineering approach to requirements is as badly suited to our real need as would be an engineering approach to raising teenagers? I’m beginning to think so . . . — Tom DeMarco, “Requirements Engineering: Why Aren’t We Better at It?”, 2nd International Conference on Requirements Engineering There are zillions… Read more →