How do you approach starting a small requirements project as part of a large initiative within a massive enterprise? Do you boil the ocean? Your customer knows she needs “requirements” to give to her development team. She asks you – what will you deliver, and how long will it take? […]
Abstraction And “Requirements”
I don’t know how many of our readers have reached a conclusion to this debate, but we have for now. Thanks to everyone who has contributed to, enjoyed, or at least tolerated this ongoing discussion. Roger had some good comments in our previous article – we’ll try and address one of his points here. His point, I believe, is that using the word “requirements” to describe multiple levels of abstraction in the definition of a product is a bad thing.
Requirement Naming – Stick A Fork In It?
The discussion about requirements and the naming of things continues? Can we stick a fork in it already? Maybe, but probably not. Catch up on the cross-blog discussion with Roger and Adam.
Valuable and Functional Requirements
Roger asked some interesting questions on one of our previous posts about market and product requirements. In a couple recent articles, we presented some specific examples to clarify the semantics and language of different types of requirements. Roger asks six questions about functional and non-functional requirements in the comments on the last article. In this article, we answer them.
Alphabet Soup – Requirements Documents
This is my requirements document. There are many like it, but this one is mine. My requirements document is my life. [Kubrick, with some editing]. Michael provides a comparison of requirements documentation formats seen in the wild. A good companion to our earlier piece, Michael provides some “what to expect” guidance about how different companies use the different documentation formats. Check it out.
The Impact of Change and Use Cases
Market requirements change. These changes impact the use cases that support the changing requirements. Functional requirements change. These changes impact the use cases that they support. How can we leverage use cases to manage these changes? And how can we manage changes to use cases?
Requirements Documents – One Man’s Trash
…Is another man’s treasure. There are many different ways to document requirements when developing software. And there is a proliferation of requirements documents – MRD, PRD, SRS, FRS and design documents. Everyone has a perspective on what each document represents, and each person on the team has a unique perspective on what questions the document answers.
Joel Spolsky Speaks Specs
It seems that specs are like flossing: everybody knows they should be writing them, but nobody does.
Another for the wish I had said that list. Joel Sposky wrote a four part series on writing functional specifications in Oct 2000. Joel’s opening position is that all projects lasting more than a week, or with more than one developer, will be completed faster with specs than without them. He presents three giant reasons to use a requirements document as part of developing software
Three Giant Reasons
Challenging Requirements
The hardest long term challenge in eliciting requirements is improving our ability to do it. The hardest short term challenge in gathering requirements is getting all of them. We have a lot of techniques for gathering requirements, from interviewing to brainstorming to researching. How do we know we defined all of the requirements? Everyone who manages requirements knows the value of validating requirements. But validation leaves a blind spot as it looks backwards instead of forwards. We propose to do exactly the opposite.