Join Terri Wagner for an in-depth discussion in this video Managing requirements challenges, part of Project Management Foundations: Requirements (2015).
- Believe it or not it's challenging to do this requirement stuff well. It doesn't even seem to matter what kind of requirements we're talking about or what type of name we're giving them. Functional, nonfunctional or maybe even dysfunctional. This is actually hard to do. It's hard to find out what your customers want, then figuring out from what they say they want, what they actually need. It's hard to write it well and keep it up to date. Just to clarify when we talk about a customer that may be an internal or external client or group that is generating the project request.
It's difficult to make sure that everyone sees a common vision of this thing we're trying to produce. One key piece of it is, determining if we have the right information from our gathering and elicitation steps that we're going to be talking about. Then once we have all the information, can we think about it and make sense of it as a project team and come up with the requirements that actually represent the solution that we're going to be building and ultimately deploying. It sounds really straight forward yet it's remarkably difficult to do it well.
On the information side of things there are two key components. First gathering the correct information. Second making sense of the information and translating that into workable requirements with measurable deliverables. In the book Effective Requirements Practices by Young and Ralph, they identified the source of requirement errors being led by incorrect facts being offered by the customer, followed by omission, then inconsistency, ambiguity, and finally misplaced requirements.
They go on to say that the top three requirement issues project teams must overcome are first a lack of joint responsibility between the project team and the customers for the project's success. Second, the project team's use of ineffective requirements and project management practices. Third, the requirements provided by the customers often not being the real requirements. In the exercise files you will find a wind farm case study to help better understand these concepts.
For example, in our wind farm project if someone gave the project team a requirement that the turbine noise must be kept to an acceptable level at all times, that would be considered far too ambiguous. That requirement would need further refinement before it would be considered a good requirement that is actionable and measurable. In a recent online event for one of my longstanding clients we asked the question, "What's the top challenge you think impacts your ability "to accurately and clearly gather, organize "and document requirements in your organization?" Their responses may be similar to what you've experienced.
They said getting users to articulate what they really need. Customers having difficulty thinking in terms of business function. Customers not willing to commit time to helping you gather and document their requirements. And another participant said sometimes it's hard for customers to share what they need if they don't have something to shoot holes in. "Sometimes I have to build a rough draft or strawman "that they can then say, "This works, this doesn't, "I really don't need that, and oh by the way "can you make it do this?" How about you? What challenges do you typically encounter when developing project requirements? We aim to provide some solutions and tools to help you with those challenges throughout this course.
- Differentiate among enterprise, stakeholder, and requirement analyses.
- Summarize the elicitation process.
- Explain the importance of avoiding assumptions.
- Describe how to prioritize requirements.
- Identify techniques for conducting requirements analysis.
- Recall how to create a well-formed requirements checklist.
- Explain the guidelines for conducting technical reviews.