Comments on: Are Useful Requirements Just A Fairy Tale? (and why an IA should care)

By: Neil

Neil — Wed, 30 Nov -0001 00:00:00 +0000

Thanks for writing this article. As an frustrated IA at a smallish tech company that just doesn’t quite get IA just yet, your article is most helpful in our on going discussions. I’ve printed out copies and put them on the desks of our project managers and a VP.

By: ji

ji — Wed, 30 Nov -0001 00:00:00 +0000

Thanks Dan for the article. I think writing effective and useful requirements is a problem thoughout product development and managment teams. Looking back to the days, when I did product managment and development – few engineers , engineering managers, and product managers actually get formal training in writing good requirements – this is especially true if you work for smaller technology company. Writing effective requirments is a team effort, and I would recommend getting somebody in staff who has experience with this (please read past article – http://www.boxesandarrows.com/archives/getting_creative_with_specs_usable_software_specifications.php).

I don’t doubt there are some smart IA’s or UI designers out there who could write requirements – but let’s be real. Lot of us in our community lack the experience in this area. You’r right by pointing out that there are lot of companies out there who produce poor requirements – however, there are also good companies out there where product or program managers write the good specs and requirements – and they even work with us user experience folks.

Adapting useful requirements into product design process doesn’t happen over night – it may take many months or even years (depending on size of the company, culture, etc). So what if someone one day wrote very good requirements – it won’t matter if no one will read it or endorse it. Producing good requirments will take time (there are variety of methods and best practices). But I think it’s more important to have general consenus/committment in the company to really adapt and design products by requirements. Producing good requirement document/process could come next.

Tip for the IA’s or UI designers, you will have more influence during “business requirement or marketing requirment stage”. By the time it gets to “product or software requirement” stage, our influence will signifiantly decrease.

thanks again for your aticle Dan

By: Alison Gripo

Alison Gripo — Wed, 30 Nov -0001 00:00:00 +0000

Is that requirements aren’t done well? Or that there is a concept of this holy grail document called the requirements document? I’ve written a great deal of thes documents, and depending on the audience they are narrative tombs which I can not fathom being read to satisfy the sense that ‘work has occured’ to very detailed annotated flows and wireframes each time all the documents had to be translated in some other form in order to adequately meet the needs of the audience readng and approving the document. In the end the requirements document has always served more a dramatic minutes from large group discussions than something everyone took away and worked from. This is not to say that i don’t think requirements are critical, but I wonder at times if it’s better to break out requirements into stages written by the people who need them to serve their end goal, then to have one person be the ultimate transcriber?

By: Jonathan

Jonathan — Wed, 30 Nov -0001 00:00:00 +0000

The article’s take on the old “What vs How” issue is an interesting one. I’ve not seen it applied in the context of “business” and “functional” requirements before, but the “classical” view on this is not that the “What” is business and the “How” is function, but that one man’s what is another man’s how. The trick is to understand where you are in the chain.

For example, take this “cascade” from high-level “what” to low-level “how”:

CEO: What do we need?
We need to lower costs.

Divisional Manager: How do we lower costs?
We need to replace our paper-based ordering system.

Middle Manager:
How do we replace our paper-based system?
We need to build a replacement using XYZ.

Project Manager:
How do we build a replacement using XYZ?
We need to define the requirements.

Development Lead:
How do we define requirements?
We describe the functions of the system.

Developer:
How do I implement these functions?
I write some code.

In my experience, the confusion over requirements is not going to be solved by saying “here are the business requirements, and here are the functional ones” because it totally depends on what level you’re dealing with in the above cascade. “Business requirements” to a Middle Manager are usually pretty useless to a Development Lead, foe example.

So – I think the article is actually pretty weak in that respect.

However, he mentions using common vocabulary. Now that IS worth doing, since all levels need to use the same terms.

I was also surprised to note the absence of the most important thing about a document that starts “The system shall…” – the definition of scope. Scope equals money, either losing it or making it, and the only way you’re going to stop scope from creeping is to write down what you are going to do…

bearing in mind the above what/how cascade of course …

By: Paula Thornton

Paula Thornton — Wed, 30 Nov -0001 00:00:00 +0000

Dan: Thanks for pointing out the distinctions in requirements. Years ago I stumbled on a similar distinction but a bit more in-depth. I aligned the distinctions to “people, process and technology” — three distinct sets of requirements needed to be gathered by three distinct perspectives and then mitigated together in the end. The “process” dimension aligns to your business dimension. The real distinction here is that when interviewing an employee most questions are not carefully made distinct between their roles. They are both an employee and a human being. As an employee, they may be prepared to defend the needs/perspectives of the department or their role, as a human being, they might see things differently. To not allow for these mental distinctions asks individuals to be psychotic when answering questions.

Several years ago I offered a ‘test course’ at a national technology conference titled “Why Requirements Don’t Work”. The draw was phenomenal…as an unscheduled class it drew 32 people to an evening event (when they could have been at the beach or out on the town).

By: Larry Cornett

Larry Cornett — Wed, 30 Nov -0001 00:00:00 +0000

Great article, Dan. I’m finding more and more often that issues around requirements are the underlying cause of many project disasters. Being involved early and often in the requirements definition is critical, but also incredibly important is a process for managing changes to those requirements. I often find that organizations have intricate rules in place for managing change that impacts requirements during the development phase. However, those same organizations have no concept of managing requirements churn during the design phase. A few companies in my past have had the concept of “feature freeze” or “design freeze”, but rarely stuck to their guns when change came a’knocking. I would love to hear of some real-world examples of successful processes for managing requirements churn.

By: Tine Peeters

Tine Peeters — Wed, 30 Nov -0001 00:00:00 +0000

The distinction what-how is only a start.
First you need (as pointed out in other comments) the scope of the application.
Next you need the what, you business / user requirements.
Next you need the how, but translating the how merely to ‘an ability’ is far too weak to get ‘well-defined’ requirements. If you give all the abilities / functions as such to a engineering team, you will get an application that does not even get close to your users’ expectations (or only if you get very lucky) and your user-centered approach will not lead to the ROI you seem to be expecting.
The how should be expanded with your understanding of the user context (how do they work, what do they know, how fast do they need specific results, what are the main tasks and what are less important tasks, which tasks are related, is their a specific work or task flow, what are the relations between specific functionalities / abilities, where should specific functions / abilities be made available, the users that must and may not access specific abilities etc.).
Abilities need to be translated into behavior and design. The how should not be limited to the ability (e.g. users should be able to sort the results) but should describe how users will be able to sort the results, e.g. by clicking the table headers in addition to a separate sort dialog. If you omit such requirements or if you prefer ‘specifications’, you design will never address the users’ needs although your functional requirements correctly describe them.
I’ve worked for companies that have very strict policies in business and functional requirements, that strongly believe in their usefulness, that even think they’ve involve the users from the very beginning by making them sign off the requirements. Of course, users will think the list of requirements is complete, but listing abilities says nothing about in what way they can use these abilities and whether these abilities are depending on other ones.
So pls. translate business requirements into functional requirements and functional requirements in behavior, design and interaction requirements and the latter ones in screen specifications or user interface mock-ups so the stakeholders can visualize, grasp and understand that ‘what’s and how’s) before any coding is done. The more the engineering work will be outsourced the more specific your design and behavior rules must be. Don’t make engineering teams guess about this (and don’t you expect them to figure this all out by their selves)!

By: Thomas Eyde

Thomas Eyde — Wed, 30 Nov -0001 00:00:00 +0000

This reminds me of the User Stories used in Extreme Programming. The business requirements in this article fits nicely as the title of such a story, and the functional requirements would be the body of the story.

Personally, I like to write a combination of User Story and Use Case. I prefer the Brief Use Case using prose only, extended with numbered lists when that is useful, perhaps with some technical notes about backend systems, possible user interface and business rules.