Agile Product Management, Marketing, and More
Posts tagged Requirements
Documenting Requirements
Dec 28th
The language of requirements is a challenge to explain: there is an art involved in writing declarative statements that specify what needs to happen without inadvertently limiting the implementation. Certainly, the choice of words is important: words like “select” and “supply” are more vague than “click the radio button for” and “type into the text box,” but there’s more to it. I’ll elaborate on that in a future post.
I continue to be more convinced that multiple methods of delivering requirements are needed to draw a complete picture. So even though one might have the language challenge under control, various types of models (both graphical and verbose) can help to provide views into the system’s requirements from all sides. But how do they relate to each other, and how do the models relate to the declarative statements that provide the granular detail of what is needed?
The methodology I’ve seen implemented most frequently, when boiled down to brass tacks, is just interviewing and observing users and identifying requirements, and then backing them up with more intricate system models. The more I reflect, however, I think there may be a smarter way. One approach I’ve seen from a few sources is to depict the system’s primary uses in the form of use cases, which can be further broken down into any number of scenarios that depict the use case with specific input values and paths through the use case; and then, writing requirements that support each use case. One point made in a highly recommended article at TechTarget.com is: requirements that don’t tie back to a use case may be a warning sign of missing use cases. Working through a deliberate methodology like this might be a step towards preventing any significant gaps in requirements capture.
The above article from TechTarget also considers data elements, and recommends entity-relationship diagrams to zero in on the data elements. As a product manager, I see that fitting in a little deeper into the cycle at the business analysis/design stage, not at the customer requirements/analysis stage. What do you think?
Non-Functional Requirements as Stories
Nov 30th
In a prior post, I suggested that the use of a thorough checklist of possible non-functional requirements categories is a good way to probe for the relevant requirements on a specific project under consideration. As I think about it now, I realize it may also help to review non-functional requirements of other projects as another source of inspiration.
My point for writing today, however, is the idea that regardless of how one arrives at those requirements, one can still use the user-story format for recording them. Particularly when the requirement is a business-level or business-driven requirement rather than a customer-driven one, this format allows the recording of the source of a requirement so that it is easier to explain and remember later:
Consider the example of the CTO constraining the team to use the existing orders database. (This was the real situation; the team was considering a second orders database that would be sychronized at night. The CTO overheard this and said “no!”) If we wrote this requirement as simply “Must use existing orders database” it would be entirely possible that a few months down the road we wouldn’t remember why we should be constrained in that way. We’d ask the product owner if she cared if we used a secondary database, and she’d say she had no objections. And we’d make a mistake of using one. Embedding the person who wants something can be very useful.
In my own experience with collecting and then analyzing requirements for several active projects (Each at a different phase of development) I have run into the problem of not remembering the source of requirements at a later date. The author also suggests thinking of them as “constraints,” rather than “non-functional requirements” — which is a suggestion the linguist in me finds appealing, as it is a more naturally meaningful phrase.
While the CIO suggestion above does illustrate the way I find the user story format to help solve the requirement-source problem, I have a related problem that I have yet to solve: remembering the details of a negotiation. Over time, different stakeholders may make differing or even competing requests. Later in deelopment, when these stakeholders ask why their suggestion was not accepted and implemented, I have a hard time remembering the rationale for a particular decision. Thoughts, anyone?
The Economic Downturn
Oct 25th
What impact does the economic downturn have on your enterprise, and on the products you manage? The answer to that, truthfully, is unknown.
The product manager, as representative of the market, may be the role best suited to finding out what the market’s changes mean to your products. Calling customers to find out what effect the market’s turmoil has on their budgets and their short and intermediate term plans is probably a wise idea for all businesses, and the answers can only help to reduce the uncertainty.
What you do with the information is, of course, up to you and depends on the product and market. But don’t go unarmed into a battle of information.
Start with the Problem Statement
Oct 25th
For all the talk about bad products and poorly designed features, many companies don’t spend enough time listening to the market. Some think they do, but they listen passively and only hear feature requests. What really helps drive a great product is to listen actively and hear problems.
Working within the problem-solution paradigm inherently demands that we accurately understand what the problems are. If we start from the incorrect starting point, following the correct path to a solution will cause us to solve the wrong problem.
This interesting article goes into linguistics and considers not just the language of problem statements in terms of the words we choose to write them in, but from the broader perspective of the framework in which we think about them. Abstracting the problem to the correct level is essential in solving the problem, which is what we are all trying to do.