Software development involves determining what to develop, documenting this decision, determining how to develop it, and actually developing it.We present a framework for describing this process in terms of layers of activity. Many people use pyramid analogies, which show the magnitude of effort in each layer (lines of code versus lines of requirements, for example). Many other people use inverted pyramids to reflect the importance (or impact) of work done at different layers (a sentance defining a strategy has more impact than a line of code). Some people show PERT diagrams of waterfalls or pretty circular arrows charts showing iterative lifecycles, or any of many good analogies.
Requirements / Software requirements specification
Posted on:
How to manage data when writing requirements
Don’t trigger a data explosion with enumerated requirements. Managing requirements can be tricky when it comes to managing data (information). The difference between a good approach and a bad approach can add up to hundreds of hours of labor over the life of a project. In our picture, we show […]
Polls / Process Improvement / Requirements
Posted on:
Take this poll or we’ll shoot this kitten
[Ed: If you read Tyner Blain via RSS you have to visit the site to vote in the poll. Also, we’ll use a camera.] An earlier post on CRUD use cases started a fantastic debate (both public and private) about what it means to write great software, and if it’s […]
Lists / Polls / Requirements / Requirements Models / Use Cases
Posted on:
Top Ten Use Case Mistakes
The top ten use case mistakes We’re reiterating the top five use case mistakes from Top five use case blunders and adding five more. For details on the first five, go back to that post. There’s also a poll at the end of this post – vote for the worst […]
Requirements / Software requirements specification / Writing
Posted on:
A requirements documentation mistake
Learn from an early mistake of mine At a previous employer, the first time I played the role of requirements manager (technically, program manager – with responsibility for the functional spec), I made a bunch of mistakes – this post is about one of them. The setup We were engaged […]
Marketing / Process Improvement / Requirements / Requirements gathering / Software requirements specification
Posted on:
From MRD to PRD: The key to defining a spec
They key to writing a great spec is knowing how to specify software that mets our customers’ needs. It can be a daunting task. First, we have to define what our customer needs. High level requirements are just requirements that are too vague or high-level to be directly actionable. “We […]
Process Improvement / Requirements / Software development / Software requirements specification / Testing
Posted on:
Where Bugs Come From
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.