Cindy Vandersleen's Page

In my final article on requirements development, I want to discuss the processes involves in eliciting requirements from business stakeholders. There are several commonly held techniques that are used for gathering requirements from business customers. Some of these methods are specific to software systems or systems with some type of user interface, and some are applicable to any type of deliverable:

In previous articles we’ve discussed requirements from several viewpoints. We’ve examined the characteristics and attributes of good requirements and differentiated them from business rules. We’ve discussed the merits of developing requirements in a cascading fashion from business goals through related objectives to enable prioritization. We’ve also looked at techniques and templates to aid in remembe

In last week’s article, Susan discussed the emotions involved when a project is terminated, “back burnered” to death, or mercifully euthanized. But what about those projects that don’t or can’t get cancelled when they should? Whether due to mandatory regulatory requirements, or being beyond the point of no return some projects simply leave us no choice – they must be finished. Managing a t

In our previous 2 articles, we’ve discussed how business requirements should originate in a cascading manner from goals and objectives, to assist in assigning their relative priorities. We also reviewed tools that can be leveraged to help us remember the different areas or categories of requirements to capture. But now let’s step back and consider, just what is a requirement anyway, and wh