home


What are people talking about...



Feature Article

Software Requirements in Practice – How to do it well?

Development of software requirements involves stakes of multiple groups and is rarely an uncomplicated thing. Knowing the software requirements from stakeholders is the first and the most challenging step to success of a software development effort. If done well, the chances of successful delivery significantly go up, but the key question is “how do you do it well’ and then “how do you know it’s done well”. This article attempts to share practitioners’ insights into the first question. The second question of “how do you know it’s done well” is for a future article.


Fact Finding IN ’THEIR’ VIEW

Article Sponsored By
Whitepaper contributed by IAG Consulting

The interview is a basic information gathering and validating tool. Because it is a basic tool, considered to be easy to do and tacitly assumed that everyone knows how, inadequate attention has been paid to the methodology, responsibilities or its components. Inexperienced interviewers overlook the challenges that come from the preparatory research, the interviewees, their own inexperience, the process to capture information or the environment that they are working in. They do not consistently follow basic tenets and often mistake how things really are with how things are in their views. This paper presents some of the basic tasks associated with conducting an effective consultation for eliciting information or the interview.

What's Fundamentally Wrong? Improving our Approach Towards Capturing Value in Requirements Specification

Article Sponsored By
HP

by Tom Gilb and Lindsey Brodie

We know many of our IT projects fail and disappoint. The poor state of requirements methods and practice is frequently stated as a factor for IT project failure. In this paper, I discuss what I believe is the fundamental cause: we think like programmers, not engineers and managers. We do not concentrate on value delivery, but instead on functions, on use-cases and on code delivery. Further, management is not taking its responsibility to make things better. In this paper, ten practical key principles are proposed, which aim to improve the quality of requirements specification.

© 2007-2010 Requirements Networking Group All rights reserved. contact | advertise | privacy
Requirements Networking Group