Welcome to MSDN Blogs Sign in | Join | Help

Inside Architecture

Notes on Enterprise Architecture, Systems Integration, and anything else that interests me this week...

Browse by Tags

All Tags » Analysis   (RSS)
Modeling User Experience Scenarios
I’m working on modeling some requirements for a document management system.  I’m a big fan of using models to represent every element, from goals and strategies through to business processes.  From there, I model use cases and requirements and Read More...
Make IT appear as simple as possible, but not simpler
Sometimes I hear a complaint from an IT architect who wants to have direct conversations with “the business” or “the customer” but, for some reason (usually bureaucratic), they cannot.  There is a team of analysts or project managers that they are Read More...
The Process of Strategic Planning
I'm a process guy. I'm not a big fan of the claims of process management software, but I'm a huge fan of developing and using process models to organize the activities of people, and then to drive the requirements for software from those models. So when Read More...
Collecting requirements from business processes
Ah, the sweet sounds of success.  I got the opportunity, this week, to collect a list of requirements for a strategic planning tool that we will license and use within Microsoft IT (COTS).  The fact that I got to collect requirements is not Read More...
Update to root cause analysis for poor software requirements
Just a quick note. After reading through some of the feedback on my recent post on " the root causes of poor software requirements, " I had to agree with some of the respondents: I had forgotten a branch in the analysis. So, for the past week, I've been Read More...
Understanding the root causes of poor software requirements
If I had a nickel for every time I've heard a developer complain about poor quality requirements, I'd... well... have a lot of nickels.  Let's look, for a moment, at the root causes of poor requirements and business rules.  While I consider Read More...
The business value of elegant design
In my last post , I highlighted the design process, suggesting that designers and architects should consider using creativity, in addition to methods and patterns, to build a truly useful system.  In this one, I'd like to talk about the business Read More...
Non-Functional Requirements: the "All-Other" classification
I've seen various taxonomies of requirements.  Like all taxonomies, any set of requirement types exists to classify or partition requirements into coherent groups for further analysis.  Most break down the list of requirements into things reminiscent Read More...
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...
More Posts Next page »
Page view tracker