Brainstorming can be a simultaneously fun and effective technique for identifying software features or requirements. We’ve written previously about how to facilitate a brainstorming session and how to leverage the results. Timothy Johnson shares another way to use the results effectively. His way is more fun, and maybe just as effective.
Quality and Requirements – You Got Chocolate In My Peanut Butter
Quality writers are writing about requirements. Requirements writers are writing about quality. Just like the Reese’s Peanut Butter Cup – Two Great Tastes that Taste Great Together. You can’t have one without the other.
Foundation Series: Business Process Modeling
Business Process Modeling allows us to increase our understanding of business processes and improve communication with stakeholders and implementation teams. Business analysts will create diagrams that represent business processes. These diagrams can be used to elicit requirements, define scope, and improve communication within the team.
Four Assumptions of the Apocalypse
Business Analysts often start with four erroneous assumptions when eliciting requirements. 50% of errors in software projects are caused by requirements errors. These four faulty assumptions, presented by James A. Ward, can exacerbate the error-prone process of gathering requirements.
Mozilla Director of Product Management Blog
The director of product management at Mozilla (makers of firefox) has started a blog, Sherman’s Blog, about how Mozilla approaches product management. From the first post on the Role of Product Management by (Mr.?) Sherman, I think this blog is likely to be one to watch.
Intro to Requirements Gathering – St. Edward’s University
Welcome Dr. Franke’s students in Analysis, Modeling and Design MCIS6310! Thanks again for inviting me to present to your class on requirements gathering and requirements management. The presentation is available for download. You can get both the slides and the notes pages. The notes pages include additional content and links […]
Requirements Gathering – Interviewing the Right People
How do we find out what someone wants when they don’t know what they want or what they can have? One of the best techniques for gathering requirements is to interview users. But which users?
Imagine aliens came to the planet and offered to solve our gasoline problem. How could we tell them what we wanted? We might say we wanted cars that run on clean renewable energy. The aliens might leave thinking “Oh well, I guess they didn’t want faster-than-light travel.”
The Agile Dragon
When Alan Cooper and Kent Beck debated the benefits of eXtreme Programming versus Interaction Design, they disagreed on a lot of things. One thing they agreed on is that Agile processes are designed to minimize the impact of changing requirements. Cooper believes that it makes more sense to minimize future change by understanding the requirements better up front. Beck believes that the requirements can not be understood by the team until something is delivered. Beck’s point is that the customer doesn’t understand the requirements until he has something in his hands. We’ve shown how this is both a strength and a weakness for Agile in the real world. In The Hobbit, the dragon Smaug was missing a scale on his belly, that made him vulnerable. Agile processes have a similar weak spot.
Challenging Requirements
The hardest long term challenge in eliciting requirements is improving our ability to do it. The hardest short term challenge in gathering requirements is getting all of them. We have a lot of techniques for gathering requirements, from interviewing to brainstorming to researching. How do we know we defined all of the requirements? Everyone who manages requirements knows the value of validating requirements. But validation leaves a blind spot as it looks backwards instead of forwards. We propose to do exactly the opposite.