Of course, a name is just a name, but it helps in explaining the tasks involved to clients. One of the most important foundational tasks of software development, or any development for that matter, is to understand the need. The software industry has kept changing the names given to these tasks - requirements gathering or data gathering or requirements elicitation. [Continue]
Andriy Solovey gives 6 reasons why software requirements are elusive. A very interesting post which poses the challenges involved in identifying the requirements. The subjectivity, personal bias and preferences and continuous changes make it difficult to really complete the task. [Continue]
One of the challenging tasks of software development is identifying the right requirements. Though there are many established techniques and practices for eliciting and gathering requirements, I have seen that every professional has his/her own way of doing it. And like estimation, it is not science, soft skills and cognitive thinking contribute a lot of the effectiveness. [Continue]
Gautam Ghosh explains how stories can be effective tools for diagnosis. Although Gautam discusses from the perspective of a HR and OD consultant, the need for diagnosis and understanding the business is equally important while developing software. Not to confuse with the user stories in XP, these stories can help bring to forefront some aspects that usually documentation misses. [Continue]
Christopher Creel presents Requirement Patterns, analogous to Design Patterns, but to cover the problem space rather than the solution space. I agree with him that requirements engineering is not given enough weightage. One way a project effort and cost estimate is brought down is by stripping down the requirements elicitation and analysis. [Continue]
Ross Rader puts it neatly about understanding what your customers are buying from you. And the treasure lies in drilling down the preliminary answers by asking more questions. I think the question Why unearths the undug gems which can be more valuable than any other feedback.
“Requirements are for you, not for me!”, blasts the CEO at the software provider. “Don’t waste my time on it, and don’t charge me for it. Just give me what I want.”, he continues while walking out of the meeting. [Continue]
Unlike a lot of others, I was introduced to Theory Of Constraints (TOC) by the business novel and was instantly addicted to the revolutionary approach, an output of exceptional work by Eliyahu Goldratt. The Theory Theory Of Constraints (TOC) is, at its basics, a problem solving approach that focuses on the constraints or limitations involved. Anything that we are part of today - work or family or organizations - involves multiple factors. [Continue]