Just because your requirement is not a user story does not mean you have to throw it out when planning your next sprint. See one way (that is working) for managing non-functional requirements with an agile team.
Requirements Details – How Much is Enough?
What is the right level of detail for writing requirements? What about for writing specifications (functional, non-functional requirements, etc)? The answer is that there is no one answer. But there are guidelines, and reasons to write more detail, or less detail – for any given product or project, and any […]
Valuable and Functional Requirements
Roger asked some interesting questions on one of our previous posts about market and product requirements. In a couple recent articles, we presented some specific examples to clarify the semantics and language of different types of requirements. Roger asks six questions about functional and non-functional requirements in the comments on the last article. In this article, we answer them.
Non-Functional Requirements ERA [now available]
PEBBAK* error! Through a complete oversight / ommission / coma, the Non-Functional Requirements Equal Rights Amendment article was accidentally marked as private shortly after it was published. I was wondering why so many 404s happened when people tried to read it. Well, its back now. Enjoy it, and comment. It […]
Non-Functional Requirements Equal Rights Amendment
We know how to deal with functional requirements. We know they are important – we can walk the dependency chain from goals to use cases to functional requirements. But how do we get to the non-functional requirements? Leathej1 points out the elephant in the room – non-functional requirements don’t get enough attention when it comes to testing. Let’s look into it some more…
Non-Functional Requirements List
Marcus is building a great reference on non-functional requirements at From Start to End. He’s created a series of articles, and keeps adding more. Each post focuses on a single type of non-functional requirement. He just put up an index page for all of his posts, and he’ll be keeping that page updated as he adds more content.
Interaction Design and Structured Requirements
subtitle: Wiegers and Cooper assimilated
Wiegers promotes structured requirements. Cooper touts Interaction Design. Both have great ideas. Both “wave their hands” at parts of the process. In this post, we’ll talk about how to combine the two philosophies to get the best of both worlds.
Requirements vs Design – Which is Which and Why?
A classic debate. It comes up often. Unfortunately, it’s a source of confusion that causes many teams to shy away from staffing, creating, or managing any formal requirements processes. There’s a discussion on Seilevel’s forum where this has been brought up again, and it’s shaping up to be a fine grudge match here in Austin. We can’t let the other folks have all the fun, so we’ll chime in too.