Pragmatic Marketing has a training seminar called Requirements That Work. In support of that, they provide a list of 8 characteristics of good requirements. We change one and add two more to round it out to The Big Ten Rules. Combine this with Michael’s ten tips for writing MRDs, and we’ve got a good handle on how to create a great MRD.
Scheduling requirements changes – part 1
Software product success requires timely delivery. There are many factors that influence our ability to properly scope, schedule, and deliver software. When we propose changes in requirements we introduce risk to the schedule. We can set reasonable expectations for our stakeholders while maintaining a realistic work environment and schedule. In part 1 of this post we detail a requirements triage process that organizes requirements by complexity and allows us to set and meet expectations of delivery.
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.
Software requirements for migration projects
A very common enterprise software project is the replacement of a legacy system – migrating functionality to a new system. This type of project usually has very different constraints than a “new application” project. We will look at the characteristics of migration projects to understand how we should approach them to assure success.
Interaction design explained by Alan Cooper
There’s a Clash of the Titans joint-interview posted at FTPOnline between Kent Beck and Alan Cooper called Extreme Programming vs. Interaction Design. It’s 10 pages of back and forth. In short, these icons agree on objectives, and disagree on how to achieve them. They also spend some time (mis)characterizing each other’s positions and defining their own. In this post we will look at how Alan Cooper explains Interaction Design. We would say that he defines interaction design more as a requirements than a design activity.
Software Requirements Specification Iteration and Prototyping
Developing great software requirements demands iteration
In our previous post of an example of the software development process, we showed a linear flow through the process, as depicted in several posts over a couple weeks. What we failed to show was any of the iteration cycles, as Deepak points out by asking a great question in the comments on that post. In this post, we will show a little more about how the process works by showing how iteration fits into the machinery of software development.
Prioritizing software requirements – am I hot or not?
Prioritizing software requirements
Jason at 37 signals recently posted about essential vs non-essential requirements – the software equivalent of Am I hot or not? He talks about the prioritization decisions their team went through as part of bringing Campfire to it’s launch. Campfire is an online collaboration application that just launched today. We will talk about how their prioritization
Top Five Requirements Gathering Tips
Interviewing, Brainstorming, Documenting Use Cases, Prototyping, and Analyzing Documents are our top-five tips. Read more for details
Active Listening and Cultural Cues – When No Means Yes
Without good communication skills, you won’t understand what the stakeholders want. And you won’t structure and describe the requirements in a way that the developers will implement what you intend.
For a given project, there are three sets of requirements – the requirements you are given, the requirements you document, and the requirements that are interpreted by the delivery team.