Alan Cooper presents the analogy that software development is like making movies in his book, The Inmates are Running the Asylum. Cooper is presenting the analogy in the context of validating the business case for investing in interaction design, but it holds true for requirements as well.
Top ten tips for preventing innovation
At a recent presentation in Austin by Seilevel about the goals and methods of requirements gathering, a member of the audience asked “What can we do with our requirements to assure innovation?” That’s a tough question with an easy answer – nothing.
What if the question had been “What can we do to prevent innovation?” That’s a better question with a lot of answers.
The Reason Why
Seth Godin has a post titled The Reason. In each of his examples, Seth asks and answers the reason why we do things that don’t have an obvious rationale.
Requirements elicitation is about asking why. When we ask why correctly, we get great insight, which enables great requirements, which can yield great software. When we ask why incorrectly, we can get a great big mess.
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.
Top ten tips for giving a better presentation
Guy Kawasaki wrote a great article last month about how to give a great presentation. You should be reading his stuff!
He goes into details about each of his ten eleven tips from his perspective. Here’s a quick summary of those tips with our thoughts.
Jargon gone amuck!
This video showing the abuse of jargon (2 minutes) is absolutely hysterical, and should be watched for humor alone. However, it also drives the point home about the effects of using jargon when writing requirements. When we write a PRD or SRS if we use the jargon of one domain, […]
Writing Requirements Unambiguously
Writing requirements without ambiguity
This is one of the harder parts of writing good requirements. Marcus tells us to avoid it with a good example here. Jerry Aubin at Seilevel has written an outstanding post on the subject, The art and science of disambiguation. Jerry starts his post with a gripping example from Weinberg and Gause:
Software Requirements – Process and Roles
Our previous post, Requirements vs design – which is which and why, describes our position on which parts of the software development process are requirements-activities, and which parts are design activities. The debate among professionals about these distinctions is ongoing, and continues in the comments on that post. The length of the debate, combined with the skills of those debating demonstrates that it isn’t a black and white issue.
In this post, we will try and explore the reasons why this debate is ongoing. We will do that by exploring the symbolism of the terms involved, as well as the roles of different members of the software development team.
Symbolism and Communication
Symbolism and communication
One of the challenges in successful communication comes from the way people use symbols as part of the organization of their thoughts. Symbolic thinking and reasoning is an incredibly efficient process. It allows us to create representational views of the world that allow us to process much more information than our brains have evolved to handle.
What does this have to do with requirements?
We see from our earlier post on requirements gathering techniques that communication is central to the most important requirements elicitation methods. Understanding how people associate ideas symbolically helps us communicate more effectively.