Browse by Tags
All Tags »
Analysis (RSS)
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...
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...
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...
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...
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...
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...
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...
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...
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...
