Archive of Requirements Models Articles

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.

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.

We’ve written before about the importance of separating rules from requirements, particularly in use cases. We wrote that with the goal in mind of reducing the costs of system maintenance. Low-level rules like decision, calculation and inference rules tend to change frequently - and independently of other requirements. So a documentation approach that separates these rules from requirements can both reduce implementation costs (by encouraging separated implementation) and reduce the time required to manage and approve changes.

There are also benefits to abstracting high-level, or procedural rules, when dealing with global business requirements.

Business rules are not requirements. Yet they are often gathered at the same time as requirements, from the same sources, by the same business analysts. And unfortunately, often documented in the same artifacts. In this article we look at some of the ways that business rules are commonly hidden inside use cases.

How do you prevent analysis paralysis? That’s the question Barbara opens up for discussion on the Business Analyst Blog. The answer is somewhat simple. You stop as soon as you believe you have something that reasonably covers the goals (or use cases) that you are trying to address. When you have requirement completeness, you move on. This answer is both naive and enlightened- especially when you consider the benefits of an agile development process.

What is the right level of detail for writing requirements? What about for writing specifications (functional, non-functional requirements, etc)? The answer is that there is no one answer. But there are guidelines, and reasons to write more detail, or less detail - for any given product or project, and any given team. The reason we write requirements is so that they can be read. Understanding the readers is the key to determining which details to include in the requirements.

We all know the story about the emperor’s new clothes. I’ve been thinking about prioritization and scheduling, and as far as I know, no one is promoting that we maximize value - they (and we) have been promoting that we do the most valuable stuff first. Doing the most valuable things first does not result in getting value the fastest. In this article, we show why not.

In About Face 2.0, Alan Cooper describes the elastic user as an ill-defined user who’s characteristics change to suit the needs of the developer - sometimes an expert and sometimes a novice. However, some of the otherwise good techniques for managing actors and use cases exacerbate this problem instead of alleviating it. How should we manage use cases while still getting the benefits of Cooper’s insight?

Almost a month ago, we published an article titled Broken Requirements Ecosystem. That article built on a discussion thread at Seilevel. Since that time, the original thread has grown, and a new one has been spawned at the Catalyze site.

In short, the question was asked on the Seilevel forum- why are specs sometimes ignored by developers, and four possible reasons were suggested.  We followed up with our view, and the discussion picked up again, this time at Catalyze.

1. Original discussion thread on Seilevel’s forum: Reasons Reqs Go Unread (Discussion from 19 Jun to 26 Jun )
2. Article at Tyner Blain: Broken Requirements Ecosystem (Written on 21 Jun, Discussion to 26 Jun)
3. Thread spawned on the Catalyze forum: Broken Requirements Ecosystem (Discussion from 23 Jun to 15 Jul)
Note - the dates above for each article/forum-post are as of right now. People have submitted 23 comments across the articles, showing a lot of good insight from many different perspectives. Developers, product managers, project managers, stakeholders - lots of great comments!

Even if you read our article before, go back and follow the discussions again - starting with Seilevel’s article, and progressing to ours, following up with the conversation at Catalyze.

In our ongoing exploration of how to meld the worlds of business rules and requirements, we look at an example use case and see how to extract the business rules.