What is the difference between a business rule and a business requirement? Does the difference matter? A business requirement is something that is multi-customer, and a business rule represents a single customer’s approach to meeting that requirement. Product managers and analysts care about both, but product managers emphasize requirements, and analysts focus more on rules.
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.
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.
Top Five Requirements Gathering Tips
Interviewing, Brainstorming, Documenting Use Cases, Prototyping, and Analyzing Documents are our top-five tips. Read more for details
A Picture Is Worth A Thousand Requirements
Object oriented analysis and design (OOA/OOD) is a technique used to gather requirements and develop software, as an alternative to more traditional text-based techniques.
OOA allows for clarity of communication, by creating descriptive and unambiguous documentation of requirements. It comes with a great big giant caveat –