We’ve presented an example of the software development process across several posts over the last two weeks. In this post we tie them all together, showing the steps in process order.
Prioritization / Requirements / Software development
Posted on:
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
Austin TX / Requirements / Requirements management software
Posted on:
Requirements Management Software Will Not Solve the Problem
Requirements management software will not solve our requirements problems. Jerry Aubin of Seilevel made this great point in his presentation this evening at the IEEE Computer Society, Austin / A-SPIN event. This was a great event, focusing on how to take requirements management “to the next level” – not just […]
Communication / Presentation / Requirements / Software requirements specification / Writing
Posted on:
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, […]
Communication / Requirements / Software requirements specification / Writing
Posted on:
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:
Communication / Requirements / Software development / Software requirements specification
Posted on:
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.
Communication / Requirements gathering / Slightly off-topic
Posted on:
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.
Austin TX / Requirements / Software development / Software requirements specification
Posted on:
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.
Requirements / Requirements Models / Software development / Software requirements specification / Use Cases / Writing
Posted on:
Writing Functional Requirements to Support Use Cases
Background:
In our previous post, Sample use case examples, we created two informal use cases. The use cases were written to support product requirements defined as part of a project to reduce test suite maintenace costs. In this post, we will define functional requirements that support these use cases. This process is an example of using structured requirements, applied to a small real world project.