Archive of Requirements Articles

We use actor hierarchies to organize the different users of a system. Different people play different roles, and thus do different jobs. We use different actors to identify and organize those people. When deploying a system globally, we usually discover people that do the same jobs, but do them differently. Incorporating the notion of personas lets us deal with this.

Traditional requirements happen after a multi-system architecture has been defined.

But what about the requirements that feed into that architecture? The requirements that drive the enterprise architecture decisions in the first place? We haven’t talked about those before.

Documenting processes is something most business analysts have to do. The goal of documenting the process is to communicate requirements. By establishing a shared understanding of the process, you can establish the context for the requirements. Easy processes are easy to draw and understand. When documenting a more complex process, you need to provide the same clarity and consistency. In this article we show how to document asynchronous process steps to maximize the clarity of the documentation.

An excellent article by Jonathan Babcock raises a thought provoking idea. When gathering requirements, we can end up with requirements that no one actually wants, because everyone thought someone else wanted it. This is apparently known as the Abilene Paradox, a term coined by Jerry Harvey. We can apply our insights into stakeholders and traceability to prevent it.

A rose by any other name…

When we’re learning how to write in high school and college, we’re taught that synonyms make our writing more exciting. In fact, not using synonyms can make our prose clumsy and awkward.

When it comes to requirements, the last thing you want to do is use synonyms. Except sometimes.

Some books on how to write and manage requirements mention using a glossary. Most books on requirements don’t go into enough detail about either the importance of a glossary of terms, or the precise use of the glossary of terms. Or if they do, they under-emphasize the benefits of a well-defined glossary of terms. Walking a day in the moccasins of a business rules analyst helps us all appreciate the importance of a well-managed glossary of terms.

Roger Burlton, of the Process Renewal Group, gave an excellent presentation Monday morning at the 10th annual International Business Rules Group: Developing a Business Process Architecture and Program of Change. A lot of good stuff about how to define, develop, and manage processes. One idea in his presentation was particularly compelling - that of driving process improvement strategy based on stakeholders. This approach looks at how much benefit the stakeholders can get from the improvement, and how much pain the current process causes them. A very compelling strategic prioritization tool.

I am a big fan of boxes and arrows, but this time, Jeffrey Davidson found a great article by Dan Willis before I did, and told me about it. Thanks Jeffrey! The article is about how to deal with the what and how of requirements and design - and it provides some really sage advice. But what got my attention was the lack of prioritization of requirements in his example.

In our earlier article about managing stakeholder goals, we looked at the relationships between principal stakeholder goals and end-user stakeholder goals. We also showed a way to trace those dependencies. But that approach does not provide us with any insight about the alignment (or lack thereof) between differing goals. This article explores a means to visualize those relationships.

A couple weeks ago we wrote about Outside-in Software Development, by Carl Kessler and John Sweitzer. One of their ideas about stakeholders and goals has got us thinking about traceability.