Home » Archives

Content in the Knowledge category

[11 Feb 2013 | Comments Off on Goals Oriented Requirements | ]

Collaborating on deriving scope from goals is undoubtedly the most controversial topic in this book. In the last five years, the surge in popularity of value chains in software development has increased awareness of the idea of collaborating on scope and deriving it from business goals.

[5 Feb 2013 | Comments Off on Customer Input For a Successful Product | ]

Studies in Human Computer Interaction (HCI), User Centered Design (UCD) and User Experience Design (UED) have found that accurate and frequent customer input is essential for a successful software product. Knowing who your customers are, what their environment is like, and what their needs are gives you the information required to plan and design a product.

[14 Jan 2013 | 2 Comments | ]

As companies transition to Agile and Scrum to manage their software development projects, how does this affect the work of business analysts? Nancy Nee, VP Global Product Strategy at ESI International, shares her opinion on the role of business analysts in Agile software development projects and how this approach impacts the requirement gathering activity. She also provides some input on how to handle conflict between stakeholders.

[9 Jan 2013 | Comments Off on Asking Open-Ended Questions | ]

Getting the important business needs out of the requirements gathering process should be the goal of every business analyst. In this article, Karl Wiegers discusses the benefits of asking open-ended questions during requirements specification. They are especially useful to discover exceptions to the normal process behaviour. You are then able to determine and describe how the system should detect and respond to an error. The last question he asks during a requirements elicitation meeting is: “Is there anything else I should be asking you?”

[7 Jan 2013 | Comments Off on Writing Better Requirements with Examples | ]

Gathering requirements for software development is not always easy and IT guys will often complains that customers have difficulties to express what they want to achieve with a new development project. In this blog post, Lars Hoidahl discusses this topic and explains how examples and screen sketches can help to write better requirements.

[12 Dec 2012 | Comments Off on User Stories That Are Too Big | ]

In this blog post, Jeffrey Davidson discusses the fact that a common issue for Scrum teams is that their user stories are too big. He explains that many teams ask for larger stories because they don’t know how to slice the work into smaller pieces. Writing smaller user stories will make your team happier and more productive. There are many reasons behind the need for small user stories.

[3 Dec 2012 | Comments Off on Minimal Viable Products | ]

In this blog post, Cory Foy discusses how to apply the Pareto law, the famous 80/20 rule, to the concept of minimal viable product. He defines two starting positions: you have to sell a solution for a problem or there is an actual need in a market. A Standish research shows that 45% of the features of a product are never used. This are the features you should not create if you want to deliver your product quickly.

[12 Nov 2012 | Comments Off on Do Not Design for Users | ]

In this blog post, Mike Long discusses the current trend to design applications for specific users or “personas”. His point is that “focusing on individuals might improve things for one person at the cost of others.” He prefers instead Activity-Centered Design (ACD) that focuses on the activity context in which individuals interact with the product.

[6 Nov 2012 | Comments Off on Ordering the Product Backlog | ]

In this article, Brent Reid discusses the fact that in Scrum, the product backlog should be ordered and not prioritized. His point is that priority has a meaning only within a certain context. Thus what is high priority one day could be low priority in the future. Thus, the product owner must deliver a totally ordered Product Backlog, even if it is difficult to make such decisions. However, as Brent Reid wrote it: “this clearly places the responsibility of resolving the problem on the product owner instead of on the …

[30 Oct 2012 | Comments Off on Four Mistakes to Avoid in Requirements Meeting | ]

Adriana Beal has wrote an interesting post discussing four mistakes to avoid when leading a requirements meeting. The first mistake is to create unnecessary meetings and/or failing to recognize when one is needed. The second mistake is failing to prioritize the order in which items will be discussed, and whenever possible, the amount of time that will be dedicated to each item. The third mistake is to fail to keep the discussion on topic. The fourth mistake is failing to engage introverted or non-assertive people. Each mistakes is discussed in …