In our previous post on Kano requirements classification, we introduced the concepts and showed how to apply them. One of our readers commented privately that we didn’t show how to use the techniques for prioritization. We’ll do that in this post.
Category Archives: Software requirements specification
Posted in Prioritization, Process Improvement, Requirements, Software development, Software requirements specification
Tagged features, geoffrey moore, Kano analysis, Kano requirements, managing data, MRD, PRD, prioritizing requirements, prioritizing software requirements, requirement staging, requirements prioritization
7 Comments
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.
Posted in Communication, Process Improvement, ROI, Requirements, Software development, Software requirements specification
Tagged agile requirements, business requirements, business software requirements, iterative requirements, managing data, prototyping, requirements definition, software requirements, software requirements specification, writing business requirements, writing requirements, writing software requirements
Leave a comment
Posted in Process Improvement, Requirements, Software development, Software requirements specification, Test Automation, Testing, UX, Use Cases
Tagged managing data, MRD, MRD to PRD, PRD, Requirements, requirements elicitation, software development process, software process, Use Cases, use cases, writing requirements
4 Comments
Jargon gone amuck!
topsyWidgetPreload({ “url”: “http%3A%2F%2Ftynerblain.com%2Fblog%2F2006%2F02%2F15%2Fjargon-gone-amuck%2F”, “shorturl”: “http://bit.ly/cIeV7E”, “style”: “big”, “title”: “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 [...]
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.
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.
Posted in Austin TX, Requirements, Software development, Software requirements specification
Tagged business requirements, constraints, FRS, functional requirements, managing data, market requirements, market requirements document, MRD, non-functional requirements, PRD, product requirements, product requirements document, root cause analysis, software design, software product requirements, SRS
22 Comments
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.
Posted in Requirements, Requirements Models, Software development, Software requirements specification, Use Cases, Writing
Tagged functional spec, managing data, software cost estimate, software development process, software product requirements, software requirements management, structure requirements, supporting use cases, use cases, writing functional requirements
2 Comments
Latest Articles
Comments on all Articles
