In the Foundation series article on software processes we introduce a definition of software process as three steps – (decide, develop, deliver). That article will provide some contextfor this discussion, which dives more deeply into the three steps (decide, develop, deliver).
Communication / Requirements / Requirements management software / Software requirements specification / Writing
Posted on:
Requirements Document Proliferation
Too many companies don’t document their requirements.
Worse still, too many companies over-document their requirements.
Lists / Prioritization / Project Management / Requirements / Software requirements specification
Posted on:
Prioritizing requirements – three techniques
Now that we’ve gathered all these requirements, how do we determine which ones to do first?
The less we know about our client’s business, the more the requirements appear to be equivalent. We’ll talk about three different approaches to prioritizing requirements.
1. Classical. Let stakeholders assign priority to the requirements.
2. Exhaustive. Explore every nuance of prioritization and its application to requirements.
3. Value-based. Let ROI drive the decisions. (hint: this is the best one – scroll down if you’re in a real hurry)
4. [bonus]. A look at how 37signals prioritizes features for their products.
Communication / Consulting / Lists / Presentation / Process Improvement / Requirements / Requirements gathering / Software requirements specification
Posted on:
Brainstorming – Making Something Out of Everything
Previously, we talked about brainstorming as one of the best elicitation techniques for gathering requirements. Here are some details about how to facilitate a general brainstorming session with a group of people in 5 easy steps (and then another 5 easy steps). Seven to ten people is a good number […]
Communication / Consulting / Requirements / Requirements gathering / Software requirements specification
Posted on:
How To Interview When Gathering Requirements
We previously stressed the importance of understanding why something is a requirement. Unfortunately, we can’t just ask “why why why?!” until we reach the end of the chain. This won’t be any more effective for us now than it was when we were in kindergarden. Eventually, our listeners will get frustrated, or worse, defensive.
Communication / Consulting / Lists / Requirements / Requirements gathering / Software development / Software requirements specification
Posted on:
Top Five Requirements Gathering Tips
Interviewing, Brainstorming, Documenting Use Cases, Prototyping, and Analyzing Documents are our top-five tips. Read more for details
Communication / Consulting / Requirements / Software requirements specification / Writing
Posted on:
Are people reading your requirements? A blogversation.
Tony just put up a post at Seilevel’s blog on making sure your spec is reviewed. Kent Newsome recently posted about starting cross-blog conversations here, possibly inspired by Amy Gahran’s post about it here. Tony’s post is a great topic to cross-blog about. Three easy steps to blogversation Post your […]
Requirements / Requirements Models / Use Cases
Posted on:
CRUDdy use cases and Shakespeare
CRUD (Create, Retrieve, Update, Delete) is an acronym used to refer to a set of mundane, important, and indirect (if not implicit) requirements or use cases. To create a report on orders, you have to first create the orders and retrieve them. Further, the ability to update (edit) and delete […]
Polls / Requirements / Requirements Models / Use Cases
Posted on:
Use case series: UML 2.0 use case diagrams
The UML way to organize and manage use cases. Pros Provides a high level view of the use cases in a system, solution, or application. Clearly shows which actors perform which use cases, and how use cases combine to form business processes Cons Presents an “inside-out†view of the sytem. […]