Requirements Management – I’m embarking on a journey to help several teams manage their requirements with their existing systems and tools. This is the first in a series of articles, where the rubber meets the road. I’ll look at both the theory and the realities of what works (and doesn’t) […]
User Goals and Corporate Goals
When defining requirements, you always start in the context of a goal – either a user goal or a corporate goal. You need to be aware of both. Having a positive user experience is important, and requires a user-centered understanding. Achieving your corporate goals might be in conflict with some […]
Flashback: This Week in the Past on Tyner Blain [Dec 29]
A look back at the best from this week in the past
Global Actor Hierarchies and Personas
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. […]
A Year Ago This Week on Tyner Blain [2006-09-01]
A look back at the best from a year ago.
Flashback: A Year Ago This Week on Tyner Blain [2006-07-13]
A look back at the best from a year ago.
Separating Business Rules From Requirements Increases Agility
We’ve written in the past about why it is important to gather and manage requirements. In short, you avoid some costly mistakes, and fix others before they become too expensive. We’ve also started exploring how business requirements and business rules live and play together. But why should we bother to […]
Business Rules And Requirements – Early Thoughts
We had a great interview with James Taylor a couple weeks ago, where we talked about his new book, Smart (Enough) Systems, co-authored with Neil Raden. James is an expert on decision management systems. I spent the late 1990s working on “rules-centric” software systems that allowed us to isolate rules […]
Writing Incomplete Requirements
Writing Complete requirements is one of the twelve elements of writing good requirements. Sometimes, you don’t have the opportunity to finish the job, and are forced to write incomplete requirements. How would you go about doing that?