The Monty Python troupe helps us remember five (no, three sir!) things about software requirements. And now for something completely different…
Business Analysis / Communication / Requirements / Software requirements specification / Writing
Posted on:
Another Use For ‘Why?’
“Why?” The question is our inspiration and our muse. “Why?” is the justification for our requirements. The key to identifying “What?” and “When?”, which lead to “How?” and “How Much?” But there is another use for “Why?” – communication of intent (with stakeholders and implementers). Requirements documents are artifacts, but they are also dynamic documents. By documenting “Why?” a requirement is a requirement, we make it easier for future readers to understand.
Business Analysis / Requirements / Requirements gathering / ROI
Posted on:
Don’t Prevent My Success
Finding the right balance when defining requirements can be hard. On one side, we want to avoid an inadequate system – “Don’t prevent my success by excluding features I might want”. On the other side, we want to avoid cost-overruns, delayed schedules, and negative-ROI features. This can be a hard line to walk.
Business Process Modeling / Product Management / Requirements / Requirements gathering
Posted on:
Business Rules And Requirements
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.
Business Analysis / Requirements / Requirements gathering
Posted on:
How Many People for Requirements Elicitation?
How many people should be involved in requirements elicitation? A question from one of our readers via email. Hi Scott, in the last months I faced the issue of managing the requirement elicitation phase in an Identity Management project. I have a very simple question. In your opinion how many […]
Requirements / Requirements gathering
Posted on:
Nice To Have
Gathering requirements isn’t like asking kids what they want for their birthday. We aren’t giving our customers carte blanche, we are trying to identify the valuable requirements – things that solve problems and achieve value in a significant way. Needs and Wants Our customers usually know what they want. There’s […]
Business Analysis / Product Management / Requirements
Posted on:
Wants and Needs
When a client asks for a capability or feature – is it a want or a need? How do we prioritize them?
Communication / Design / Prioritization / Product Management / Requirements / ROI / Software development / Usability / Writing
Posted on:
Goal Driven Upgrades
Kathy Sierra writes (another) great article at Creating Passionate Users. This time, she talks about why users don’t upgrade and presents ways to get users to install the latest version. We focus in this article on one way in particular – using goal-driven documentation to encourage upgrading.
Communication / Design / Interaction design / Requirements Models / Use Cases / UX / Writing
Posted on:
Use Case Driven Documentation
Yesterday we wrote about focusing our documentation on what our users are trying to accomplish. With a structured requirements approach, or with an interaction-design driven approach, we’ve already solved half the problem – determining what to document.