Welcome to MSDN Blogs Sign in | Join | Help

Inside Architecture

Notes on Architecture, OO Design, and anything else that interests me this week...

Browse by Tags

All Tags » Analysis   (RSS)
Clarifying the Use Case
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...
Using Business Process Models as the source for software requirements
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 Conceptual Models, Building Relationships
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...
Open Question: Common vocabulary: Blessing or Curse?
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...
The Usefulness of the Use Case?
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...
Example of modeling requirements in a process diagram
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...
IT to Business: "I won't read your mind"
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...
Leaving technology out of requirements gathering
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...
As-Is versus To-Be... what to model first
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...
Root Cause Analysis for Software Problems
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...
Page view tracker