Agile / Software development

Explaining Agile Development…

Posted on:

…to your Brother-in-Law. A great article by Joe Little, on his new blog. Thanks Mishkin for telling us about it. Joe’s article serves as an excellent precursor to our comparison of agile software development methodologies. It would also be extremely effective advice for getting mindshare prior to rolling out agile […]

Communication / Consulting / Lists / Requirements / Requirements gathering

Ten Supercharged Active Listening Skills To Make You More Successful

Posted on:

Active listening is about more than gaining understanding. Active listening is about giving. Giving assurance that you understand someone’s needs. Giving confidence that you will address those needs. Giving feedback and acknowledgement that someone’s input is valuable. If you haven’t tried active listening, you may think it is a passive, receptive activity. Active listening skills will help you guide your customers and your team to do the right thing, and enjoy the experience.

Business Analysis / Communication / Consulting / Requirements / Requirements gathering / Requirements Models

How To Visualize Stakeholder Analysis

Posted on:

The first step of gathering requirements is to identify who can give you the requirements. Business processes include communication between different people inside the organization. Communication also includes people outside the organization. When gathering requirements, it can be easy to overlook the people who don’t use the software directly. Those people may still be stakeholders. Read on to see how to approach stakeholder analysis.

Business Analysis / Product Management / Requirements / Requirements Models / Use Cases

How To Write Use Case Preconditions and Triggers

Posted on:

Use case writing is key to effective requirements management. Each use case represents a single idea or logically grouped behaviors. When you define a use case, there are several mistakes you can make. Preventing those mistakes is the first order of business. The second order of business is making sure that the use cases in the system work together. This requires an understanding of the context in which the use case happens. To fully understand a use case you have to know what is promised to be true before the use case happens, as well as what causes the use case to happen. These are subtly different.