Browse by Tags
All Tags »
Analysis (RSS)
A Use case is a cool thing. A little too cool. The term has been occasionally misused, and in some respects, that misuse diminishes the value of a use case. To succeed, we have to know what a use case is. When you are done
Read More...
Requirements elicitation is a critical, yet under-appreciated, activity. A core capability of business analysts, the ability to get the customers to describe what they want, and need, is both a science and an art. Requirements elicitation
Read More...
Building teamwork, at the enterprise level, is a tricky thing. As a project team comes together to solve a problem, hopefully you find yourself in the same position that I've found myself in many times: with smart experienced people, all motivated to
Read More...
Requirements are an interesting thing. We cannot assume that we understand the business, and their needs, so we 'elicit requirements.' And we write them down. But "the business" is a collection of different people, and in order
Read More...
I'm a big fan of use cases. Great for describing how software is used, and puts context around the use of functionality that helps software developers to create solutions that will actually fit into human activities. On the other hand, are
Read More...
We use process models for lots of things. One is simply to understand the processes we have and to analyze them looking for opportunities to improve. But in IT, we have another good reason: to better understand software requirements. One goal that we
Read More...
In any relationship, it is dangerous for one side to "decide" what the other one wants. Marriage advisors say things like "Don't control others or make choices for them." Yet, I'd like to share a story of technologists
Read More...
I'm going to suggest a minimal way to gather requirements, one that produces a (minimum) requirements document in an iterative and agile manner. A little background In the systems space, it is common to write up a "requirements document" that attempts
Read More...
I have always taken the advice at face value: the "to be" model matters much more than the "as is" model does. Implicit in that: spend as little time on the "as is" model as you can. Perhaps, even, do the "to
Read More...
Let's assume that every problem worth solving has a cause. Interesting assumption. Reality: Any one problem may have many causes. The causes may interact in complex ways. How do we go about figuring this out? We can use the technique of Root Cause Analysis
Read More...
